同僚がおすすめしていて、現代のエンジニアとしての知見を得るために読むことにした。
ハンドブックと聞くと僕はペラペラの本をイメージするんだけど、この本は全然そんなことなくてカバーしている範囲がかなり広い(文字も多い)。ので、自分が特に興味を持った箇所についてかいつまんで記録しておく。本当にごく一部なのでなんとなく気になったら書籍の方をあたってみることをおすすめします。
DevOpsとは
- DevOpsはリーン生産方式の原則をITのバリューストリームに応用した結果
- DevOpsの大原則として3つの道がある
- フローの原則: 開発から運用、そして顧客に仕事の成果を送り届けるまでの流れを加速する方法
- フィードバックの原則: さらに安全なシステムを作るための手段
- 継続的な学習と実験の原則: 日常業務の一部として改善のリスクを組織的に引き受けるための高信頼マネジメント文化と科学的アプローチの奨励
バリューストリームのパフォーマンスを測定するためのメトリクス
- チケット作成→作業開始→作業完了のうち、
- リードタイム: チケット作成～作業完了までの時間
- プロセスタイム: 作業開始～作業完了までの時間
- 僕はこれまでリードタイムとプロセスタイムを混同して使っていたので改めたい
- 完全正解率
- 下流の顧客が『そのままの形で使える』仕事を受け取った割合
- いわゆる「手戻り」率の逆だという理解
コンウェイの法則を念頭に置いた組織とアーキテクチャの設計(いわゆる逆コンウェイ戦略)
- 市場指向: 顧客のニーズにすばやく呼応することを意図して作られている。組織の中で重複が発生することがよくある。DevOpsを採用している多くの著名企業は、このタイプを採用している
- 職能指向: 専門能力の育成、活用、分業、コスト削減に適している
- 本書では市場指向のチームを推奨しているが、職能指向でも動きの素早い優秀な組織を作ることはできる。Etsy, Google, GitHubなどの多くの企業が職能指向的な運用を残している
- これらの企業に共通しているのは、高信頼マネジメントの企業文化である。そのような文化のもとでは、各部門は効果的に協力することができており、すべての仕事の優先順位付けは透明で、しかも優先順位の高い仕事は高いすばやく完了させられるだけの柔軟性がある
- トヨタの第2のパラドックス: トヨタが職能横断的な市場指向のチームのベストプラクティスとは対立する職能指向の組織を持っていることに多くの研究者が頭を悩ませた
- 検索しても引っかからなかった
- 組織変更によって継続的な進歩と適応の方に向かうことはできない。決定的なのは、人がどのように行動し、どのように反応するかであって、組織の形ではない。トヨタが成功した根本的な原因は、組織構造ではなく、社員の能力と習慣を鍛えて育てたことにある
- そうかも知れないけど、逆コンウェイ戦略を真っ向から否定しているような？あまりしっくりきていない。だからこそパラドックスなんだろうけど
- マトリックス指向: 職能指向と市場指向の2つのタイプを結合することを意図している。しかし、1人の作業者が複数の上司に仕えるなどして、複雑な組織構造になることが多く、職能指向、市場指向のどちらの目標も達成できない場合がある
- さまざまな技術スキルを訓練し、成長させているジェネラリストは、スペシャリストと比べて桁違いに仕事ができる。そして、キューと滞留時間がなくなるため、作業フロー全体が改善される
- ここでいうジェネラリストはいわゆるT型人材のことを指していることについて注意
- マイクロサービスにあたるものを最初から実装しようとしていたら、たぶん失敗していた。問題は、現在のアーキテクチャから必要とされるアーキテクチャにどのようにマイグレートするか
- 「境界ではなくブイ」を作ることが目標。誰も越えてはならない明確な境界線を引くのではなく、安全でサポートが受けられる部分を示すブイを置く。組織的な原則に従う限り、ブイの向こうに行っても構わない
- なんとなくいい言葉だなーと思ったので抜粋
その他小ネタ
- ダークローンチテクニック
ダーク ローンチとは、実際のユーザーから発生したトラフィックをコピーして新サービスに送信し、新サービスからの結果をユーザーに返す前に破棄すること
- 組織がアジャイル風の実践を使っていると言いつつ、実際には、テストと欠陥の修正をプロジェクトの最終期に行っているような場合を、ウォータースクラムフォールアンチパターンと呼ぶことがある
- おもしろい
- ペアプロするとプログラマー2人分よりも仕事のペースは15%下がるがエラーフリーコードは70％から85%に上がる。テストとデバッグは最初のプログラミングと比べて何倍もコストがかかることが多いので、これは注目すべき結果
- つまり、不確実性の低いコーディングではペアプロの効果は薄く、不確実性の高いコーディングではペアプロの効果が高いと理解
個人的に一番興味深かったのは組織設計に関する箇所で、これまでは現実的にはマトリックス指向くらいしか無いんじゃないかなあというぼんやりとした感覚で暮らしてきていたけど、否定的だったので頭を殴られた感じだった。
市場指向が良いというのは分かるけど、自分の経験上は「重複」による非効率が許されているほど人的リソースが潤沢な(あるいは集中と選択ができている)状況を見た記憶がない。
職能指向でも動きの素早い優秀な組織を作ることはできる、ということで具体的な実装イメージは何なんだろう？と思うのだけど、例えばGoogleならSREとかが実装イメージになるのかな？他にもデザイナーとかプランナーとかいるだろうし、正直良くわかってない。
仮にマトリックス指向であっても、横断的な職能指向組織と縦割りの市場指向組織の価値観が一致していれば「作業者が複数の上司に仕える」状態を緩和して結果的に動きの素早い優秀な組織というものをつくることのできる余地があるようにも思うけど、このあたりもあまり具体的なイメージは無い。まあ、難易度はかなり高いんだろうなとは感じる。どうやっても複雑な組織構造であることには変わりないわけだし。
このあたりは興味がありつつ、ちょっと消化不良に終わってしまったので誰か話せる人が居たら話してみたい。
もっと早くこの本を読み終わるつもりだったけど、結局3週間くらいかかってしまっている。 ここ最近バタバタしてるのもあるけど、それにしても安定的に読書に時間を割けてないのが問題。
とはいえ時間をスケジュールアプリでガツッと抑えるみたいなのはアンチパターンだと思うので、本へのタッチポイントをどうにかして増やすのが良いんだろうなあ。
しかし、ノーアイディア。 人によって勉強スタイルはぜんぜん違うなと改めて感じてもいるので、自分に合った勉強スタイルをもう少し模索しても良いのかも知れない(自分の場合は実践が伴わないと全く身にならないという自覚と、興味があることに対しては人よりも行動力が強いという自覚はある)。
