先週から「Effective DevOps」を読んでいた．去年出版されたときにパラパラと気になる箇所を読んだけど，書評記事を書いていなかったこともあり，改めて読み直すことにした．本書は「DevOps」をテーマにしつつ，その本質としてはサブタイトルにもある「4本柱による持続可能な組織文化の育て方」となる．よって，タイトルだけを見て「DevOps の技術面」を学べるのかなと期待すると，ある意味期待を裏切られる可能性もあり，まず目次を見てみると良いかと．そのためにも目次を載せておく．

作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2018/03/24
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

第 Ⅰ 部 : devopsとは何か
- 1章 : 大局を見る
- 2章 : devopsとは何か
- 3章 : devopsの歴史
- 4章 : 基本的な用語と概念
- 5章 : devopsに対する誤解とアンチパターン
- 6章 : 効果的なdevopsのための4本柱
第 Ⅱ 部 : コラボレーション
- 7章 : コラボレーション:ともに仕事をする個人たち
- 8章 : コラボレーション:誤解と問題解決
第 Ⅲ 部 : アフィニティ
- 9章 : アフィニティ:個人からチームへ
- 10章 : アフィニティ:誤解と問題解決
第 Ⅳ 部 : ツール
- 11章 : ツール :エコシステムの概要
- 12章 : ツール:文化を加速させるもの
- 13章 : ツール:誤解と問題解決
第 Ⅴ 部 : スケーリング
- 14章 : スケーリング:変曲点
- 15章 : スケーリング:誤解と問題解決
第 Ⅵ 部 : devops文化への架け橋
- 16章 : devopsの4本柱を使って架け橋をつくる
- 17章 : devops文化への架け橋:ストーリーから学ぶ
- 18章 : devops文化への架け橋:人と人のつながりを育てる
- 19章 : まとめ
- 20章 : さらに深く学習するために

DevOps と devops

本書のタイトルは「Effective DevOps」だし，僕が今までブログ記事や発表資料に書いてきた表記も「DevOps」だけど，本書（タイトルを除く）では「devops」に統一されている．本書の冒頭に「Dev と Ops の対立ではなく，ビジネスを持続可能に進めていく手法」として，意図的に小文字表記にしたと書かれていた．とは言え，個人的に見慣れた表記は「DevOps」なので，本記事では「DevOps」に統一する．

誤解と問題解決

本書全体を通して興味深いのは，DevOps に対する「誤解」を問題提起し「問題解決」のために「誤解」を紐解くという観点でまとまっているところで，ある意味「アンチパターン集」としても活用できる．逆に言うと「こうすると DevOps である」という明確な定義はなく，そこは組織ごとに考える必要がある．

DevOps に対する誤解

本書には，よく聞く「DevOps の誤解」がまとまっていて，読みながら何度も頷いてしまった．その一部を以下に紹介する．

DevOps はチームである
DevOps は肩書だ
DevOps はウェブ系のスタートアップだけの問題だ
DevOps はツールの問題だ
DevOps とは自動化のことだ

確かに最近だと「DevOps = 自動化」というコンテキストの発表も多いけど，正確には「自動化も重要だけど，組織の透明性やコラボレーションを意識しないと，自動化が未知のリスクになる」と書いてあり，考えさせられる．また，僕自身も2017年に一時期「DevOps エンジニア」と自己紹介をしていた時期もあり，恥ずかしくもある．

4本柱

本書では「DevOps とは何か？」という概論と歴史の紹介に続き，サブタイトルにもある「4本柱」の解説があり，以下のように定義されている．記事の冒頭にも書いた通り，文化面の話が中心になっている．それぞれ紹介していこうと思う．

コラボレーション
アフィニティ
ツール
スケーリング

4本柱「コラボレーション」

4本柱の1個目「コラボレーション」は，メンバー同士うまく協力することを意味している．協力とは言え，内容は幅広く，コミュニケーションの手段（即時性／負担／コンテキストなど）を適切に選んだり，傾聴を通じて共感と信頼を育てたり，双方向メンタリングを行うなども紹介されている．

特に「人それぞれ異なる目標（モチベーション）を持っている」という話は，今までも意識してきたものの，改めて考えさせられた．具体的には，現在のキャリアを重要視している人もいれば，カンファレンス参加などのネットワーキングを重要視している人もいれば，収入のための仕事であると割り切っている人もいる．エンジニアリングマネージャーやプロジェクトリーダーにも役立つ内容になっている．

なお，コミュニケーションの手段としては，即時性の観点で「雑談」も入っていたらもっと良さそうだなと思う．僕自身は「雑談」を大切にしていて，以下のような内容を発表したこともある．

f:id:kakku22:20190531014953j:plain

kakakakakku.hatenablog.com

4本柱「アフィニティ」

4本柱の2個目「アフィニティ」は，チーム間の関係を築き，チーム目標の違いを乗り越えることで，4本柱の1個目「コラボレーション」の延長線上にあるとも言える．

「アフィニティの誤解」の中に「運用エンジニアは企業にとって開発者ほど役に立たない」という内容があるが，過去の経験として，運用エンジニアに限らず，特定のチームの価値を正しく理解できず，必要性を疑ってしまったこともある．今になって，うまく関係を築けていなかったなと反省している．心理的安全性という言葉でまとめるのが適切かどうかはわからないけど，チーム間の相互理解に悩みがあれば，読んでみるのが良いと思う．

4本柱「ツール」

4本柱の3個目「ツール」で，やっと技術面の話だ！と思うかもしれないけど，文化を改善するために目的意識を持ってツールを選定しようという内容になっている．DevOps を支える技術の詳細に興味があれば，例えば「Infrastructure as Code」などを合わせて読むと良さそう．

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

作者: Kief Morris,宮下剛輔,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2017/03/18
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

読み進めていたら「ツールの選定」という内容に興味を持った．ツールを選定するときに，機能の有無や予算だけではなく，以下を考慮するべきと書かれていた．確かに「バージョンアップの頻度」や「プルリクエストの滞留具合」などは気になるし，日本語の解説記事なども，少なければ積極的に書くモチベーションには繋がるけど，ツールを選定する立場になると，コミュニティの健全性もしくは浸透度を考える必要もありそう．

製品の開発状況
コミュニティの健全性
内部でのカスタマイズの可能性

また，自動化に対するスタンスとして「残りものの原則」という表現が紹介されている．「自動化に適切ではないタスクもある」という納得できる話なんだけど，引用元の論文タイトルに笑った．「Automation Should Be Like Iron Man, Not Ultron」ってもう．

queue.acm.org

4本柱「スケーリング」

4本柱の4個目「スケーリング」は，もしかしたら「インフラストラクチャのスケーリング」をイメージするかもしれないけど，組織変革など，組織が成長していくことを意味している．育成や採用，報酬やカルチャーフィットなど，どんな組織規模でも悩む内容がまとまっていて，一読の価値がある．

また「スケーリングの誤解」の中には「改革を始めるためには経営陣の全面的な支持が必要だ」という内容もあり，本書にも書いてある通り，裁量を与えてもらうべき場面と経営陣を巻き込むべき場面があり，適材適所に判断するのが良いと思う．個人的にも似た経験があり，以下にリンクを載せておく．全ては組織規模とフェーズによって異なると思う．

developers.cyberagent.co.jp

kakakakakku.hatenablog.com