ブログ記事
チームの設計がシステムの設計を決める：Matthew Skelton & Manuel Pais『チームトポロジー』
「マイクロサービスを導入したのに、デプロイのたびに他チームと調整が必要で、リリースが遅い」——この状況の原因は技術選択ではなく、チームの設計にある場合が多い。Matthew Skelton と Manuel Pais の『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』は、組織設計とソフトウェアアーキテクチャを一体として考えるための枠組みを提供する。
1. コンウェイの法則の逆用
「組織が設計するシステムは、組織のコミュニケーション構造のコピーになる」というコンウェイの法則は、ソフトウェアエンジニアリングの世界では古くから知られている。
本書はこの法則を受け身に受け入れるのではなく、「逆コンウェイ作戦」として積極的に活用することを提案する。望むアーキテクチャに合わせてチームを設計することで、アーキテクチャを意図的に誘導できる。
例えば、サービスを独立してデプロイできるようにしたいなら、そのサービスを担当するチームが外部との調整なしにリリースできる自律性を持つ必要がある。組織設計とアーキテクチャ設計は切り離せない。
2. 4種類のチームタイプ
本書の中心は4つのチームタイプの定義だ。
ストリームアラインドチーム: 特定のビジネス機能（ユーザージャーニーや製品ライン）の流れに沿い、価値を継続的に届ける自律したチーム。組織の大半のチームがこの形を目指す。
プラットフォームチーム: ストリームアラインドチームが自律的に動けるよう、インフラや共通ツールをサービスとして提供するチーム。
イネイブリングチーム: 特定の技術領域でストリームアラインドチームの能力を高めることを目的とした、一時的な支援チーム。
コンプリケイテッドサブシステムチーム: 特殊な専門知識が必要なコンポーネント（機械学習モデル、高度な数値計算など）を担当するチーム。
flowchart TD
SA["ストリームアラインドチーム\n価値を継続的に届ける自律したチーム"] -->|"X-as-a-Service で利用"| PT["プラットフォームチーム\nインフラ・共通ツールをサービス提供"]
EN["イネイブリングチーム\n（一時的）能力向上を支援"] -->|"ファシリテーション"| SA
CS["コンプリケイテッドサブシステムチーム\n専門技術が必要な部分を担当"] -->|"X-as-a-Service で提供"| SA
style SA fill:#e8f8e8,stroke:#4caf50
style PT fill:#e8f4fd,stroke:#4a9eda
style EN fill:#fff8e1,stroke:#f5a623
style CS fill:#f3e5f5,stroke:#9c27b0
3. 3種類のインタラクションモード
チームのタイプと同様に重要なのが、チーム間のインタラクションモードだ。
コラボレーション: 2チームが密接に協力して新しい技術や解決策を発見するモード。発見段階に有効だが、長期化するとオーバーヘッドが大きい。
X-as-a-Service: あるチームが提供するものを別のチームが利用するモード。依存を減らし、速度を上げる。
ファシリテーション: イネイブリングチームがストリームアラインドチームの能力向上を支援するモード。
インタラクションモードを変えることで、チーム間の依存とコミュニケーションのパターンが変わり、アーキテクチャの変化を促せる。
4. 認知負荷という設計の制約
本書が導入する重要な概念が「認知負荷」だ。
チームが担当するドメインが大きすぎると、誰もすべてを理解できない状態になる。コードの変更が安全かどうかを判断するために広い文脈を調べる必要があり、速度と品質の両方が下がる。
チームのサイズや担当範囲は、「そのチームが無理なく理解し続けられる量」を超えてはならない——この上限を認知負荷として設計に組み込むことが、本書の実践的な提言の核心だ。
5. どんな組織の詰まりに効くか
「サービスを分けたのに、1つの機能を出すのに複数チームの合意とスケジュール調整が要り、結局リリースが遅い」——この詰まりは、チームの責任境界がサービス境界と噛み合っておらず、自律的にデプロイできない構造から生まれることが多い。本書のストリームアラインドチームとインタラクションモードの考え方は、どこで調整が発生しているかを可視化し、依存を減らす組織形へ組み替える判断軸を与える。
もう一つは、担当範囲が広がりすぎて「変更が安全か判断するのに毎回広く調べないといけない」状態だ。認知負荷という制約を設計に持ち込むと、チームの担当ドメインを分割・移譲すべきかを、感覚ではなく負荷の観点で議論できるようになる。
6. 読むべき人と、まだ早い人
向いている人：
- マイクロサービスや DevOps 体制への移行で、チーム間の調整コストやリリース速度に悩んでいる技術リーダー
- 担当範囲が広がりすぎたチームの構造に手を打ちたいエンジニアリングマネージャー
- 共通基盤やプラットフォームの担当と責任分界が曖昧なまま肥大化している組織にいる人
向いていない人：
- 単一の小規模チームで開発しており、チーム分割やチーム間調整がまだ課題になっていない段階の人
- DevOps や継続的デリバリーの前提となる文化・プラクティスにまったく触れていない人（本書はそれらを土台とした上での組織設計を扱うため、先に足場が要る）
7. 次に開く本と、最初の一歩
本書でチーム境界と認知負荷の枠組みを得たら、次は個々のチームタイプを掘り下げる方向に進める。プラットフォームチームを「利用されるプロダクト」として運営する具体像を深めたいなら『Platform Engineering』へ、チーム境界とビジネスの境界をどう一致させるかに関心が向いたなら『エリック・エヴァンスのドメイン駆動設計』へ進むと、境界づけられたコンテキストという語彙でチーム分割の議論を裏打ちできる。運用まで含めた自律性を高めたい場合は『SRE サイトリライアビリティエンジニアリング』が次の一歩になる。なお本書は DevOps の文化を前提に置くため、そこが手薄なら『The DevOps ハンドブック』で土台を固めてから読むと効きが増す。
最初の一歩としては、自チームが担当しているサービス・ドメインを書き出し、「変更の安全性を判断するのに広く調べ直している」領域がないかを棚卸ししてみるのがよい。認知負荷の上限を超えているサインを見つけることが、組織を組み替える議論の出発点になる。
筆者の体験から
テックリード寄りの立場になってから、1つの機能を出すだけで複数チームの合意とスケジュール調整が必要になり、リリースが遅れる状況に悩んでいた頃にこの本に頼った。この本のあとは認知負荷を判断材料にし、変更のたびに調べ直す範囲の広さで語れるようになった。他チームへの依頼も「よしなにお願い」ではなく、何を渡せば何が返ってくるかを決めるインターフェースとして扱うようにしている。
ただ、4つのチームタイプに当てはめようとすると実際のチームは複数の性質を併せ持ち、かえって議論が混乱した。ラベルは出発点程度に留めている。管理画面担当チームが認証基盤やバッチ処理まで抱え込み、変更のたびに影響範囲を洗い直していた状態から一部を切り出したが、しばらくすると「頼めば何でもやってくれる便利チーム」になりかけ、依頼が雑多に集まり始めた。X-as-a-Serviceのつもりが実質コラボレーションのままだったと気づき、依頼のインターフェースを改めて決め直す羽目になった。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有