Team Topologies メモ
- コンウェイの法則(1968)
- システムはそれを作る組織と同じ構造の設計になる
- コンパイラを4つのチームで作ったら4つのパスを持つコンパイラになる
- 共通DBAチームがいると、全サブシステムが一つの共通DBを使う構造になる
- 一方で、そのような設計のシステムに携わる開発者の認知負荷は高くなる
- Software that fits your head. = そのソフトウェアについて頭の中で全部わかっている状態が一番、開発のパフォーマンスが出る
- 開発者の認知的負荷は以下の三種類に大別される
- Intrinsic = 要素技術的内容
- Extraneous = 環境的内容 (デプロイ方法など)
- Germane = ドメインにフォーカスした内容
- Extraneous を大きく減らし、Intrinsic を抑制し、Germane に注力することで開発のパフォーマンスが上がる
- →チームを分割してデザインすることで Intrinsic/Extraneous な認知負荷を増やさないようにする。
- チーム内のコミュニケーションは広帯域に、チーム外のコミュニケーションは低帯域コミュニケーションにする
- チーム間のパスを最小化
- それでいて必要な場合に必要なコミュニケーションを誘発できる仕組み
- → Team API
- Team API には コード、バージョン管理、ドキュメント、チームの原則、コミュニケーションスタイル、中期計画などが含まれる
- ジェフ・ベゾスも「チームはDos攻撃に備えて、SLA/クォータ/スロットリングを定義しておくべき」と言っていたとのこと
- これまで小さなチーム体制として出てきた以下のチームにはそれぞれ弱点がある
- feature チーム：フィーチャーを追加し、引き継ぎはするが、あとの面倒はみない。(悪い場合には、来たときよりも美しくというボーイスカウトルールに反してしまうこともある)。
- プロダクトチーム：時折、専門的な知識の助けが必要になる
- ツールチーム：ツールがサイロ化する
- ここで提案するチームの定義は4つ
- Stream-aligned Team：中心となるチーム。このチームが価値を生み出す。フィーチャーをデリバリーする安定したフローを築く
- Enabling Team: 先んじて学習し、Stream-aligned Team が自律するのを助けるチーム
- Complicated-subsystem Team: 専門的な知識を必要とするサブシステムを提供するチーム
- Platform Team: Stream-aligned Teamが利用するプラットフォームを提供するチーム
- それぞれのチーム間のインタラクションモードは3つ、それぞれの強み弱みは
- コラボレーション：2つのチームが混ざり合ってインタラクションを多く働く
- 強み：素早いイノベーションを提案できる。引き継ぎが少なくてすむ。
- 弱み：コンテキスト共有のための認知負荷が非常に高い。チーム間の責任が曖昧になる。
- X as a Servise: 片方のチームがもう一方へサービスを提供し、サービス利用側チームのユーザーエクスペリエンスを重視したモード。
- 強み：クリーンなAPIを持ったサービスにより、利用側の認知負荷が抑えられる。
- 弱み：高度なサービスマネジメントが必要になる、また、一度決めたAPIのイノベーションは遅くなる。
- ファシリテーション：片方がもう一方を支援する
- 強み：支援される側の障害が取り除かれる
- 弱み：ファシリテーションを提供する側は経験豊富であることが求められる。また相互の文化の違いで戸惑うことも多い。
- 参考