https://images-na.ssl-images-amazon.com/images/I/51HEm7DocNL._SX351_BO1,204,203,200_.jpg
- Chapter 1
- 認知負荷
- 内発的動機付け（自律、熟達、目的）
- 認知負荷
- Chapter 2
- コンウェイの法則 1968年
- 逆コンウェイ戦略 Lean と DevOps の科学 2018
- many-to-manyのコミュニケーションは複雑なシステムを生み出す傾向にある
- ツールの選択がチーム間のコミュニケーションに影響を与える
- チーム間に明確な責任境界を設けるのであれば別々のツールを使ったり、同じツールでも別院スタンスで使うのがよい。これは心当たりあるなー
- Chapter 3
- 小さなチーム（5〜9人）を標準とするのはなぜか？グループの認知と信頼において、お互いのことを詳しく知って親密な関係を気づけるのは5人くらいというダンバー数を根拠としている
- チームは安定している必要があるが、固定してはいけない
- 時々人を入れ替えたりするのが大事っぽい
- チームファーストなアプローチ：チームの責任範囲をチームが扱える認知負荷に見合ったものにする
- これ、理屈はわかるんだけど、現実には難しいケースも多いのではないか。チーム分割によって責任範囲を小さくしたくても、人がいなければやりようがないわけで…そういう時はどうやるべきなのかなあ。
- チームが扱うドメイン
- 経験則1：各ドメインを単一のチームに割り当てる。ドメインがチームに対して大きすぎる場合はドメインをサブドメインに分割し、サブドメイン毎にチームを割り当てられないか検討する
- 経験則2：単一チームがシンプルなドメインを2〜3つ扱う。シンプルなドメインであればコンテキストスイッチのコストを容認しやすい。
- 経験則3：複雑なドメインを割り当てたチームには、それ以外のドメインは割り当てるべきではない。
- 経験則4：1つのチームに煩雑なドメインを2つ以上割り当てるべきではない
- Chapter 4
- DevOpsトポロジー
- DevOpsチームのミッションや期限が不明瞭だとアンチパターンに陥る可能性がある
- サイロが組織内に増えてしまう
- Chapter 5
- 4つのチームタイプ
- ストリームアラインドチーム
- 「プロダクト」や「フィーチャー」ではない理由として、組織レベルでフローに注目しやすくするというものがある
- UX、アーキテクチャ、テストなど
- イネイブリングチーム
- ストリームアイランドチームはデリバリーや素早い対応を求められ、新しいことを調査・学習する余裕がなかなかない
- イネイブリングチームはストリームアラインドチームを支援する
- ビルドエンジニアリング、継続的デリバリー、デプロイ、テスト自動化など
- コンプリケイテッド・サブシステムチーム
- システムの中でスペシャリストの知識が必要となるパーツの開発・保守する責任を持つ
- 複雑なサブシステムを含むor利用するシステムを担当するストリームアイランドチームの認知負荷を減らすことが目的
- プラットフォームチーム
- ストリームアラインドチームが自律的に仕事を行えるようにする
- ストリームアラインドチームのオーナーシップは本番環境アプリケーションの開発・運用・修正を含む全体
- プラットフォームチームは内部サービスを提供し、ストリームアラインドチームの認知負荷をさげる
- ストリームアラインドチーム
- チームの振る舞いやインタラクションをどうするかによって同じようなことをしていても異なる区分のチームになるということっぽい。
- 一時的にイネイブリングチームを作るということも可能。
- 4つのチームタイプ
- Chapter 6
- チーム間のコミュニケーションをさほど要せずに、設計からデプロイまでの作業を完遂できる能力を推進するアーキテクチャを作ることが重要
- 節理面：ソフトウェアシステムを簡単に複数に分割できる自然な継ぎ目
- Chapter 7
- チーム間の基本的なインタラクションモード
- コラボレーションモード：他のチームと密接に協力して作業する
- X-as-a-Serviceモード：最小限のコラボレーションで何かを利用または提供すること
- ファシリテーションモード：障害を取り除くために他のチームを支援したり支援を受けたりすること
- チームの形成の逆コンウェイ戦略を使う場合、アーキテクトには社会的スキルと技術的スキルが求められる。また、技術だけではなくビジネス戦略や組織構造、人事に関する権限も必要。
- これは納得できる。システムのアーキテクチャが組織構造によって変わってくるとすると、システムアーキテクトは組織を変える権限が必要だよね。
- チーム間の基本的なインタラクションモード
- Chapter 8
- 組織設計において重要なのは組織そのものだけではなく設計ルールを設計すること
- 達成すべきことに応じてインタラクションモードは使い分ける
- コラボレーションモードの場合、高コストだが新しいアプローチの探索に適している
- X-as-a-Serviceモードの場合、予測可能なデリバリーに適している
- 組織的センシング
- チーム、チーム内外のコミュニケーションをセンサーとして扱う
- Chapter 9
-
- チームから始める
-
- 安定した変更のストリームを特定する
-
- 最低限のプラットフォームを特定する
- ドキュメント一式でもプラットフォームである、というのは発見だった
-