「Effective DevOps」を読んだ

はじめに

読んだ。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOpsというワードの定義が曖昧なまま数年経過し、各組織ごとに理解したDevOpsで"なんとなく"やっている。僕としてはもうDevOpsという言葉を使うのもちょっと避けていたぐらい。「今時はデブオプだー」っていう声を聴くと耳を塞ぎたくなる。

とはいえ、じゃあ自分はDevOpsを正確に理解しているのか？そもそも正確な理解なんてあるのか？自分なりの答えはあるのか？と言われるとNoで、本書はDevOpsの定義について、人間的なアプローチで迫った最初の本だと思う。

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである（監訳者まえがきより）とあるように、DevOpsは単に役割の変化だとか、ツールの導入だとか、その点だけ見ても成功しないことは多くのひとが見てきた光景だと思う。（僕もそうだ）

組織論に興味を持っている僕に、ぴったりの一冊だった。内容を復習していく。

第I部 DevOpsとは何か

DevOpsとは何か。DevOpsとはものの考え方であり、仕事の進め方である。（p3）とある。ツールではない。組織体系でもない。ものの考え方であり、それを推進するために文化を育てなければならない。だから文化的、組織的な面に徹底して着目しているのが本書である。

第I部で重要な点は以下の2点だと思う。

1. DevOpsはチームであるという誤解

なんども言うが、本書の主張は一貫している。DevOpsは「DevOpsチーム」なるものを作っても解決しない。DevOpsは考え方のフレームワークであり、組織全体に浸透する文化となるべきである。

2 .DevOpsには「正しい方法」などない

組織文化となりうるものであるので、唯一無二の組織がない以上、DevOpsも唯一の正解はない。

この基本的な考え方を抑えた上で、DevOpsに効果的な4本の柱を見ていこう。

第II部 コラボレーション

コラボレーション、ひととひとがうまく開発を行うための仕組みで、以下のような例がある。

• 非同期でのコードレビュー
• ドキュメント作成
• 問題の更新とバグレポート
• その週に進んだ内容のデモ
• 定期的な状況報告
• ペア作業

チームを分析すると、賢いチームには以下の特徴があるという。

• コミュニケーション
• 平等な参加
• 心の理論

コラボレーションはひととひとがうまくやるためのものだ。組織には様々な経歴を持ったひとがいる。そしてチームとしての目標がある一方で、個人としてもそれぞれに違う目標を持っていることを理解する必要がある。「ただの仕事」と割り切ってる人がいる一方で、自分のキャリアに重要なポジションと理解している人もいるということだ。

僕が重要だと思うのは、7.3.4 認知スタイルだ。結局、最終的に組織やコミュニケーションの問題はここに行き着くような気がする。

• 内向、外向、両向 ... 人が自分の中のバッテリーをどのようにして「充電」するか
• 質問と推測 ... 人にものを頼む時の態度の2タイプ
• スターターとフィニッシャー ... 新しい仕事をスタートするか、きっちり問題を解決して終わらせるか
• 分析的思考、批判的思考、水平思考 ... 事実と根拠から問題を分析する / 間接的に情報を集めて検討する / 情報から正当性を分析、熟考する
• 純粋主義者と現実主義者 ... 問題解決のために絶対的に最高な技術を使おうとする / コストを天平にたて実現性を重視する

いろんな認知スタイルがあることを知り、考慮しなければならない。

その後もマインドセットや評価、フィードバック、コミュニケーションの形と、組織論が続く。コミュにケーションツールを並べてみる。

• 電子メール
• 臨時の会議
• チャット
• 正式な会議
• Twitterなどのマイクロブログ
• GitHubのプルリクエスト
• 付箋紙のメモ
• PagerDutyページ
• nahiosアラート
• 書籍またはブログ
• 画像、グラフ

これらを「即時性」「オーディエンスへの浸透度」「受け手の負担」「コンテキスト」「構成の緻密さ」という観点で表にしている。

僕自身、ひとにあったツールを採用すべきであるという考えをしたことがある。口頭のコミュニケーションは苦手でもチャットだとしっかり受け取ってくれるとか、その逆があったりするので、ツールの特性には常に目を光らせるべきだと思う。

人々がうまくやるためには、信頼と共感が必要である。そもそもDevOpsの起源からして、2つの異なるチームを対話させるところからはじまった。異なる文化、経歴の人々が、コミュニケーションを通じて、信頼・共感していく、これがDevOpsの本質だというのが、本書の主張だと思う。

8章で好きな言葉を書いておく。

優れたリーダーは、自分自身や少数の「ロックスター」だけを重視してはいけない。優れたリーダーとは、周りにいるすべての人たちから最良のものを引き出せる人のことである。（p91）

そんなリーダーになりたいですね。

第III部 アフィニティ

アフィニティは、結びつき、個人間でもそうだし、チーム間の結びつきの強さのことを話題にしていると受けとりました。結びつきにはコミュニケーションが必須なので、重複するような気もしますが。

チーム間で仲が悪いとか、あのチームは自分のチームの利益だけ考えて他のチームに対して排他的だとか、ありますよね。悲しいですけど。

チームで行う仕事として、以下を例にあげています。

• リアクション
• 計画
• 手続き
• 不安への対処
• 問題解決
• 人間関係★

6つめの人間関係こそがアフィニティに必要だが、計測が難しい。

9.3.3 チーム内の個人的な結びつきや9.3.4 チームの文化で語られていること。確かに、どのチームにも文化と呼べるような、行動指針をほのかに感じることができる。そのチームにとって正しい文化を伝えることは、コミュニケーションをしたり、普段の仕事を通じてぼんやり浸透していくものだろう。ただ、それでも明に言葉にして伝えることが大切で、リーダーの役目なんだろうなと思った。チームに価値観を日頃から伝えていれば新しいメンバーが入ってきたときも戸惑うこともないだろう。

また、チーム間のアフィニティを強くすることも必要。企業として共通の目標を見せつつ、各チームの目標を、競合しないように決めなければならない。この点はあまり言及されていなかった。多分、大事なのは各チームの目標を、各チームが知っていることであり、それこそがアフィニティを強くするんだと思った。

第IV部 ツール

ここではDevOpsでよくある「ツールをいれればいいんでしょ」に対する誤解を丁寧に説いている。

`「ツールに大した意味はない」という主張には、2つの意味がある。

• ツールを導入していることは、devops文化が定着していることの十分条件にはならない
• ツールでは問題のある文化を修正できない。ツールは環境の既存の状況を暴き悪化させる（p181）`

よくある話だが、ツールを採用するプロセスをチームで一貫させ、共有しておくことが大事だと思う。そこさえ一致しておけば、採用後に大きな問題にはなりにくいと思う。

僕自身、チームにCI/CDプロセスを、ツール含めて導入したことがある。それはチームにツールを導入するはじめてのことだったから、手探りだった。

結局、devopsも同じだが、「ツールを導入したからといって一晩で問題が解決することはない」ということを理解する必要があると思う。

ツールが浸透するまでは時間がかかる。ツールの選定方法だってたくさんある。それを繰り返し、フィードバックして、チームに馴染むツールを見つけることを繰り返す。繰り返すがツール（技術）はツールでしかない。それで本当に問題解決したのか。使うひとたちが幸せになったのか。その観点は絶対に忘れてはならないと思う。

この点も、冒頭のdevopsが目指すものと同じ話ですね。ツールも、唯一の正解はない。組織にあったものを探していくしかない。

第Ⅴ部 スケーリング

スケーリングって何だろう？って思った。ビジネス規模拡大に対して組織・チームを増やすことだろうか？単に「スケールアウト」という言葉で言われる拡大だけを言うのではなく、何らかの問題が発生したときに「変化」させることを言っているようである。方向転換のコツ、と言ったところ。

スケーリングは次のことを意味する場合がある（p220）

• 顧客ベースの拡大
• 収益の拡大
• 需要に合わせたプロジェクトやチームの拡張
• システムに割り振る人の割合や金額の維持、改善
• 競合他社よりも早い成長

組織を大きくしたり小さくしたりするときに発生する採用、関係会社の利用、報酬について書かれている。本当にバリエーションに富んだ本だと思う。

SRE的な考えに習い、ビジネスのスケールアップに対して、人材をスケールしなくて済む仕組み作りが大事だと思う。とはいえ、人手が必要で、その人で集めにいまいろんな会社が苦労しているのもわかる。いまいま自分は採用について関わる立場ではないのでおいておく。

強い意見と弱い執着（p241）は大切だと思った。特定の立場や何らかの意見を持つことに注力するが、現在の意見と違う結論に達したら柔軟に変えられることを言う。`

第Ⅵ部 devops文化への架け橋

最後に、これまでの4本柱をどう組織にインストールするか、それにはストーリーから学ぶことが重要だという。

価値観を伝える上で、禁止事項を明示するというのはいいと思った。暗黙の禁止事項も多い中、禁止事項を明確にすることは、禁止事項を行ってしまったことによる被害を抑えるとともに、文化/価値観の伝達にも役立つ。

また、神話・儀式も面白いと思った。これは神話では？これは儀式なんだよね、とまずは自覚することに気を配るべきだと思った。

おわりに

用語説明、事例を交えながらの各要素の説明、そしてアンチパターンの紹介と、本当に親切で、多彩な要素を、それでもコンパクトに盛り込んだ、良い本だった。自分自身がいるフェーズによって響くポイントが違うと思う。今回ももちろんすべてを吸収しきったわけではない。それでも「DevOpsに唯一の正解はない」し、「組織を作る人間同士がうまくやる文化作り」が重要であることはわかった。

結局、文化とは、結果であり、人と人の、チームとチームの、コミュニケーションの積み重ねが文化なんだと思う。だから文化を作る、という言葉には少し違和感がある。こういう文化となるよう、小さな行動を、今からはじめてみよう、そういう結論なんだと思う。

また今とは違うポジションになったときに読み返したいと思う一冊。