ものの考え方であり、それを推進するために文化を育てなければならない。文化的、組織的な面に徹底して着目しているのが本書である。第I部で重要な点は以下の2点だと思う。DevOpsはチームであるという誤解なんども言うが、本書の主張は一貫している。DevOpsは「DevOpsチーム」なるものを作っても解決しない。DevOpsは考え方のフレームワークであり、組織全体に浸透する文化となるべきである。.DevOpsには「正しい方法」などない組織文化となりうるものであるので、唯一無二の組織がない以上、DevOpsも唯一の正解はない。この基本的な考え方を抑えた上で、DevOpsに効果的な4本の柱を見ていこう。コラボレーションコラボレーション、ひととひとがうまく開発を行うための仕組みで、以下のような例がある。問題の更新とバグレポートその週に進んだ内容のデモ定期的な状況報告ペア作業チームを分析すると、賢いチームには以下の特徴があるという。心の理論コラボレーションはひととひとがうまくやるためのものだ。組織には様々な経歴を持ったひとがいる。チームとしての目標がある一方で、個人としてもそれぞれに違う目標を持っていることを理解する必要がある。「ただの仕事」と割り切ってる人がいる一方で、自分のキャリアに重要なポジションと理解している人もいるということだ。コストを天平にたて実現性を重視するいろんな認知スタイルがあることを知り、考慮しなければならない。その後もマインドセットや評価、フィードバック、コミュニケーションの形と、組織論が続く。コミュにケーションツールを並べてみる。電子メール臨時の会議チャット正式な会議TwitterなどのマイクロブログGitHubのプルリクエスト付箋紙のメモPagerDutyページnahiosアラート書籍またはブログ画像、グラフこれらを「即時性」「オーディエンスへの浸透度」「受け手の負担」「コンテキスト」「構成の緻密さ」という観点で表にしている。僕自身、ひとにあったツールを採用すべきであるという考えをしたことがある。口頭のコミュニケーションは苦手でもチャットだとしっかり受け取ってくれるとか、その逆があったりするので、ツールの特性には常に目を光らせるべきだと思う。人々がうまくやるためには、信頼と共感が必要である。そもそもDevOpsの起源からして、2つの異なるチームを対話させるところからはじまった。異なる文化、経歴の人々が、コミュニケーションを通じて、信頼・共感していく、これがDevOpsの本質だというのが、本書の主張だと思う。8章で好きな言葉を書いておく。優れたリーダーは、自分自身や少数の「ロックスター」だけを重視してはいけない。優れたリーダーとは、周りにいるすべての人たちから最良のものを引き出せる人のことである。(p91)そんなリーダーになりたいですね。アフィニティアフィニティは、結びつき、個人間でもそうだし、チーム間の結びつきの強さのことを話題にしていると受けとりました。結びつきにはコミュニケーションが必須なので、重複するような気もしますが。チーム間で仲が悪いとか、あのチームは自分のチームの利益だけ考えて他のチームに対して排他的だとか、ありますよね。チームで行う仕事として、以下を例にあげています。6つめの人間関係こそがアフィニティに必要だが、計測が難しい。チームの文化で語られていること。確かに、どのチームにも文化と呼べるような、行動指針をほのかに感じることができる。そのチームにとって正しい文化を伝えることは、コミュニケーションをしたり、普段の仕事を通じてぼんやり浸透していくものだろう。それでも明に言葉にして伝えることが大切で、リーダーの役目なんだろうなと思った。チームに価値観を日頃から伝えていれば新しいメンバーが入ってきたときも戸惑うこともないだろう。チーム間のアフィニティを強くすることも必要。企業として共通の目標を見せつつ、各チームの目標を、競合しないように決めなければならない。この点はあまり言及されていなかった。大事なのは各チームの目標を、各チームが知っていることであり、それこそがアフィニティを強くするんだと思った。ツールここではDevOpsでよくある「ツールをいれればいいんでしょ」に対する誤解を丁寧に説いている。`「ツールに大した意味はない」という主張には、2つの意味がある。ツールを導入していることは、devops文化が定着していることの十分条件にはならないツールでは問題のある文化を修正できない。ツールは環境の既存の状況を暴き悪化させる(p181)`よくある話だが、ツールを採用するプロセスをチームで一貫させ、共有しておくことが大事だと思う。そこさえ一致しておけば、採用後に大きな問題にはなりにくいと思う。僕自身、チームにCI/CDプロセスを、ツール含めて導入したことがある。それはチームにツールを導入するはじめてのことだったから、手探りだった。結局、devopsも同じだが、「ツールを導入したからといって一晩で問題が解決することはない」ということを理解する必要があると思う。ツールが浸透するまでは時間がかかる。ツールの選定方法だってたくさんある。それを繰り返し、フィードバックして、チームに馴染むツールを見つけることを繰り返す。繰り返すがツール(技術)はツールでしかない。それで本当に問題解決したのか。使うひとたちが幸せになったのか。その観点は絶対に忘れてはならないと思う。この点も、冒頭のdevopsが目指すものと同じ話ですね。ツールも、唯一の正解はない。組織にあったものを探していくしかない。スケーリングスケーリングって何だろう?って思った。ビジネス規模拡大に対して組織・チームを増やすことだろうか?単に「スケールアウト」という言葉で言われる拡大だけを言うのではなく、何らかの問題が発生したときに「変化」させることを言っているようである。方向転換のコツ、と言ったところ。組織を大きくしたり小さくしたりするときに発生する採用、関係会社の利用、報酬について書かれている。本当にバリエーションに富んだ本だと思う。SRE的な考えに習い、ビジネスのスケールアップに対して、人材をスケールしなくて済む仕組み作りが大事だと思う。いえ、人手が必要で、その人で集めにいまいろんな会社が苦労しているのもわかる。いまいま自分は採用について関わる立場ではないのでおいておく。強い意見と弱い執着(p241)は大切だと思った。特定の立場や何らかの意見を持つことに注力するが、現在の意見と違う結論に達したら柔軟に変えられることを言う。最後に、これまでの4本柱をどう組織にインストールするか、それにはストーリーから学ぶことが重要だという。価値観を伝える上で、禁止事項を明示するというのはいいと思った。暗黙の禁止事項も多い中、禁止事項を明確にすることは、禁止事項を行ってしまったことによる被害を抑えるとともに、文化/価値観の伝達にも役立つ。神話・儀式も面白いと思った。これは神話では?これは儀式なんだよね、とまずは自覚することに気を配るべきだと思った。おわりに用語説明、事例を交えながらの各要素の説明、そしてアンチパターンの紹介と、本当に親切で、多彩な要素を、それでもコンパクトに盛り込んだ、良い本だった。自分自身がいるフェーズによって響くポイントが違うと思う。今回ももちろんすべてを吸収しきったわけではない。それでも「DevOpsに唯一の正解はない」し、「組織を作る人間同士がうまくやる文化作り」が重要であることはわかった。結局、文化とは、結果であり、人と人の、チームとチームの、コミュニケーションの積み重ねが文化なんだと思う。文化を作る、という言葉には少し違和感がある。いう文化となるよう、小さな行動を、今からはじめてみよう、そういう結論なんだと思う。今とは違うポジションになったときに読み返したいと思う一冊。議論を可視化するグラフィックレコーディングの教科書"を読んだ読んだ。次、Workbookを引っ張ってくる。