チームトポロジー(Team Topologies)
1. 概要
定義: チームトポロジーは、マシュー・スケルトン(Matthew Skelton)とマニュエル・パイス(Manuel Pais)が2019年に提示した組織設計モデルであり、速いソフトウェアデリバリーのフロー(flow)を組織の第一目標に据え、4つの基本チームタイプと3つのインタラクションモードでチーム構造を意図的に設計し、チームの認知負荷(cognitive load)を管理可能な水準に保つことで、組織が生み出すソフトウェアアーキテクチャを望む方向へ導くアプローチである。
チームトポロジーが登場した背景は、ソフトウェアデリバリーのボトルネックがもはや「技術」ではなく「組織構造」にあるという現場の自覚である。 クラウドネイティブ・マイクロサービス・DevOpsが普及して個々の技術力は底上げされたが、チーム間の過度な依存や引き継ぎ、承認待ち、中央集権的な統制がデリバリー速度を蝕む中核要因として残った。 伝統的な機能別組織(開発・QA・運用・DBAチームを分離)は、一つの機能をリリースするのに複数チームを経由させ、リードタイムを延ばし責任の所在を曖昧にする。
二つ目の背景は、コンウェイの法則(Conway's Law)の再解釈である。 コンウェイは「システムを設計する組織は、その組織のコミュニケーション構造をそのまま複製した設計を生み出す」と述べたが、これはすなわち組織図がアーキテクチャを決定するという意味である。 チームトポロジーはこの法則を受動的に受け入れず、望むアーキテクチャを先に定義したうえでその形に合わせてチームを配置する、逆コンウェイ機動(Inverse Conway Maneuver)を戦略的に活用する。
三つ目の背景は、人間の認知容量に対する現実的な認識である。 一つのチームが担う領域(ドメイン・技術スタック・運用範囲)が広がるほど、メンバーの頭に入れておくべき知識の総量が増え、この認知負荷が閾値を超えると品質低下・デリバリー遅延・燃え尽きに直結する。 チームトポロジーは「チームをソフトウェアデリバリーの基本単位とし、チームが担える分だけに責任範囲を制限せよ」という原則を前面に掲げる点で、個人ではなくチームファースト(team-first)の思考への転換を求める。
2. 4つの基本チームタイプと3つのインタラクション
チームトポロジーの核心は、組織に存在しうるチームをわずか4つのタイプに収斂させ、チーム間の関係を3つのインタラクションモードに制限することである。 タイプとインタラクションを少数に制限する理由は、選択肢が少ないほど組織構造が単純・明快になり、チーム間の責任境界とコミュニケーション経路が明確になるからである。 下の概念図は、4タイプとそれらの間の典型的な関係を一目で示す。
flowchart TB
SA1["ストリーム整合チームA(Stream-aligned)"]
SA2["ストリーム整合チームB(Stream-aligned)"]
PLAT["プラットフォームチーム(Platform)"]
ENAB["イネイブリングチーム(Enabling)"]
CSUB["複雑サブシステムチーム(Complicated-subsystem)"]
PLAT -. "X-as-a-Service" .-> SA1
PLAT -. "X-as-a-Service" .-> SA2
ENAB == "Facilitating" ==> SA1
CSUB -. "X-as-a-Service" .-> SA2
SA1 -- "Collaboration" --- SA2
ストリーム整合チーム(Stream-aligned team)は組織の中心であり価値提供の主役であって、特定のビジネスドメインやユーザージャーニーのような一つの「フロー」をエンドツーエンド(end-to-end)で担う。 たとえば「決済」「検索」「モバイルオンボーディング」のように一つの価値ストリームを専任し、設計・開発・テスト・デプロイ・運用を自ら行って外部依存なく速く提供することを目標とする。 チームトポロジーは、組織全体でこのタイプが大多数(推奨的には他の3タイプの合計より多く)を占めるべきであり、残りの3タイプはすべてストリーム整合チームの認知負荷を軽減するために存在すると見る。
プラットフォームチーム(Platform team)は、ストリーム整合チームが繰り返し必要とする下層能力(デプロイパイプライン、可観測性、認証、データベースのプロビジョニングなど)をセルフサービス型の内部プロダクトとしてまとめて提供する。 核心は、プラットフォームを「チケットを受けて処理する窓口」ではなく、使いやすく文書化の行き届いたプロダクトとして扱うことである。これはプラットフォームエンジニアリング([[platform-engineering]])と直接つながる。 プラットフォームがうまく設計されれば、ストリーム整合チームはインフラの詳細を知らなくてよくなり、認知負荷が大きく下がる。
複雑サブシステムチーム(Complicated-subsystem team)は、専門的・数学的な深さが要求され誰もが扱えるわけではない特定のサブシステム(例: ビデオコーデック、リアルタイム決済清算エンジン、機械学習の推薦モデル、金融リスク計算機)を専任する。 こうした領域をストリーム整合チームに任せると特定の少数に知識が偏り認知負荷が急増するため、専門性を一箇所に集めて別チームに分離するのが合理的である。
イネイブリングチーム(Enabling team)は、ストリーム整合チームが新しい技術・方法論(例: テスト自動化、セキュリティ能力、クラウド移行)を習得できるよう、一時的にコーチング・メンタリングする役割を担う。 イネイブリングチームは仕事を代わりに行うのではなく能力を移植して退くことを目標とし、常駐せず数週間〜数か月単位で介入する点が特徴である。
3つのインタラクションは次のとおりである。コラボレーション(Collaboration)は、二つのチームが一時的に緊密に協働して新しいものを発見するモードであり、革新の速度は速いが境界が曖昧になり認知負荷が増す。 サービスとしての提供(X-as-a-Service)は、一つのチームが他チームに明確なインターフェース(チームAPI)を通じて機能を提供するモードであり、明快で拡張性が高くプラットフォームチームの基本モードである。 ファシリテーション(Facilitating)は、イネイブリングチームが他チームの障害を取り除き能力を育てるのを助けるモードである。
| チームタイプ | 主な責任 | 継続性 | 基本インタラクション |
|---|---|---|---|
| ストリーム整合 | 一つの価値ストリームのend-to-end提供 | 常設(長寿命) | コラボ・X-as-a-Serviceを受ける |
| プラットフォーム | セルフサービス内部プラットフォーム提供 | 常設(長寿命) | X-as-a-Serviceを提供 |
| 複雑サブシステム | 知識集約モジュールを担当 | 常設(必要時) | X-as-a-Serviceを提供 |
| イネイブリング | 能力コーチング・障害除去 | 一時的 | Facilitatingを提供 |
チームの規模と寿命も設計要素である。 チームトポロジーは「アマゾンのツーピザチーム」原則とダンバー数(Dunbar's number)を根拠に、一つのチームをおおよそ5〜9名程度の信頼関係が保たれる小規模に留め、課題が終われば解散するプロジェクト式チームではなく長く維持される長寿命(long-lived)チームに課題を流す方式を推奨する。 チームが頻繁に再編されると、そのたびに信頼形成とドメイン学習のコストが再発してフローが途切れるためである。 この観点からは、ストリーム整合・プラットフォーム・複雑サブシステムの各チームは常設し、イネイブリングチームのみ一時的に運用するのが自然である。
3. 認知負荷と逆コンウェイ機動、そしてチームAPI
チームトポロジーを実際に機能させる運用原理は、認知負荷の計測と制限である。 認知負荷は、(1)課題内在性負荷(言語・フレームワークのような基本技術の学習)、(2)課題外在性負荷(デプロイ環境・手順のように本質と無関係な複雑さ)、(3)学習関連負荷(解決すべきドメイン問題そのもの)に分けられる。 チームトポロジーは、プラットフォームと自動化で外在性負荷を最大限に除去し、チームの責任ドメインを分割して学習関連負荷を担える範囲に制限せよと処方する。 たとえば一つのストリーム整合チームが互いに無関係なドメインを7〜8個同時に担っているなら、それは認知負荷超過の信号であり、ドメインを分割するかチームを増やすべきである。
アーキテクチャの境界をどこで引くかは、破断面(fracture plane)の概念で判断する。 破断面とはソフトウェアを分割しやすい自然な境界であり、ビジネスドメイン(DDDの境界づけられたコンテキスト)、規制順守の領域、変更頻度、性能隔離の要求などが代表的な基準である。 下のフロー図は、逆コンウェイ機動を通じて「望むアーキテクチャ → チーム設計 → 結果のアーキテクチャ」へとつながる過程を示す。
flowchart LR
A["目標アーキテクチャ定義(疎結合モジュール)"] --> B["破断面の特定(ドメイン/規制/変更頻度)"]
B --> C["モジュールごとにストリーム整合チーム配置"]
C --> D["認知負荷の評価(過負荷点検)"]
D -->|"過負荷"| E["ドメイン分割/プラットフォーム吸収"]
D -->|"適正"| F["チームAPI定義(インターフェース明示)"]
E --> C
F --> G["コンウェイの法則により目標アーキテクチャが創発"]
G -.フィードバック.-> A
チーム間の境界を明確にするため、チームトポロジーはチームAPI(Team API)という概念を用いる。 チームAPIとは、一つのチームが外部に公開する「取扱説明書」であり、提供するコード・サービス・文書、バージョン方針、連絡方法、業務時間、ロードマップ、作業依頼の仕方を明示する。 チームAPIがうまく定義されれば、他チームは人に一つひとつ尋ねずともそのチームの成果物を消費でき、組織全体のコミュニケーションコストが急減する。 これこそX-as-a-Serviceのインタラクションを支える実質的な仕掛けである。
たとえばある企業が、デプロイ1件に「開発→QA→セキュリティ→運用」の4段階の引き継ぎで平均12営業日かかっていたとする。 これを決済ドメイン専任のストリーム整合チームへ再編し、セキュリティ・デプロイをプラットフォームチームのX-as-a-Service(ポリシーをコード化して組み込んだパイプライン)に吸収すれば、引き継ぎが消えてリードタイムが数日以内に短縮される効果が期待できる。 実際の数値は組織・ドメインによって大きく異なるため断定は難しいが、引き継ぎ回数の削減がリードタイム短縮の核心的なてことなる点は、多くの事例で共通して観察される。
4. 伝統的組織・類似モデルとの比較
チームトポロジーの差別性は、既存の組織モデルと比べると明確になる。 伝統的な機能別組織は職務の専門性を集めるには有利だが、一つの機能のリリースに複数チームの引き継ぎが必要でフローが途切れ、リードタイムが長くなる。 対してチームトポロジーのストリーム整合チームは引き継ぎをなくしてフローを最適化する。
広く知られたSpotifyモデル(スクワッド・トライブ・チャプター・ギルド)とも比較される。 Spotifyモデルが「自律的なスクワッド」という文化的志向を強調するのに比べ、チームトポロジーはチームタイプとインタラクションを明示的なルールとして定型化し、認知負荷という計測可能な基準を提示する点でより処方的(prescriptive)である。 実際、Spotify自身も自社モデルが「複製用の青写真」ではなく特定時点のスナップショットだったと述べており、再現性の面でチームトポロジーが補完的な役割を果たす。
具体的な事例として、グローバルなフィンテック企業は「決済」「融資」「不正検知」をそれぞれストリーム整合チームに置き、不正検知の中核ML エンジンは複雑サブシステムチームに分離し、共通のデプロイ・可観測性はプラットフォームチームがX-as-a-Serviceで提供する構造をしばしば採用する。 DevOpsの成果指標を扱うDORA研究([[dora-metrics]])でも、疎結合で自律的なチーム構造がデプロイ頻度・変更リードタイム・変更失敗率・復旧時間の4指標すべてで上位成果と相関することが繰り返し確認されており、これはチームトポロジーが目指す構造と方向が一致する。
| 区分 | 機能別組織 | Spotifyモデル | チームトポロジー |
|---|---|---|---|
| 最適化対象 | 職務の専門性 | チーム自律性・文化 | デリバリーフロー・認知負荷 |
| チーム境界の基準 | 技術職務 | プロダクト領域(緩い) | 破断面(ドメイン・変更頻度) |
| インタラクション規定 | 暗黙的 | 緩い(チャプター・ギルド) | 明示的な3種 |
| アーキテクチャ戦略 | 事後結果 | 暗黙的 | 逆コンウェイ(意図的) |
5. 深化: プラットフォームエンジニアリング・DevOpsとの連携および最新動向
チームトポロジーは、2022年以降台頭したプラットフォームエンジニアリングの流れと事実上対をなして再注目されている。 プラットフォームエンジニアリングが「内部開発者プラットフォーム(IDP)をプロダクトのように提供しよう」という技術・運用戦略なら、チームトポロジーはそのプラットフォームを誰が(プラットフォームチーム)どんな関係で(X-as-a-Service)提供し消費すべきかを組織設計の言語で規定する。 ガートナーは2026年までに大規模ソフトウェア組織の相当数がセルフサービスの内部プラットフォームチームを持つと予測してきており、これはチームトポロジーのプラットフォームチーム概念が実務標準として定着しつつあることを示唆する(正確な数値・時期はレポートの版により異なるため一般化して理解すべきである)。
最近は、プラットフォームそれ自体を一つのストリーム整合組織のように運用しようという「プラットフォーム as a product」の深化議論、そして生成AIの導入がチームの認知負荷に及ぼす影響に関する議論が活発である。 AIコーディング支援が外在性負荷を下げる一方、生成コードの検証・セキュリティ責任が新たな学習関連負荷として加わるため、チーム境界と責任範囲を再設計すべきという視点が提示される。 また、イネイブリングチームを通じてAI活用能力を組織全体へ広げるモデルや、複雑サブシステムチームが社内のLLM・RAGパイプライン([[retrieval-augmented-generation]])を専任するモデルも事例として登場している。
出題の観点から、チームトポロジーは「組織構造がソフトウェア品質・速度に及ぼす影響を論ぜよ」「マイクロサービス移行時の組織設計方策」「プラットフォームエンジニアリング組織の運用戦略」といった設問と強く連携する。 解答を構成する際は、①コンウェイの法則・認知負荷で問題を定義し、②4チームタイプ・3インタラクションで解法を提示し、③逆コンウェイ機動・破断面・チームAPIで具体的な実行戦略を加え、④DORA・プラットフォームエンジニアリングと連携して効果を立証する流れが効果的である。
6. 考慮事項および示唆点
技術士の観点から、チームトポロジーの導入は単なる組織図の再編ではなくデリバリーアーキテクチャ全般の再設計として取り組むべきであり、次の事項を総合的に考慮する。
- 適用戦略(漸進的移行): 全社一括の改編は抵抗と混乱を招くため、リードタイムのボトルネックが深刻な一つ二つの価値ストリームからストリーム整合チームへ転換し、プラットフォームチームを並行して育てる漸進的な逆コンウェイ機動が現実的である。組織変化には体系的な変革管理と経営層の後援が不可欠である。
- トレードオフ(自律 vs 標準、専門性の分散): ストリーム整合チームに権限を渡すほどデリバリーは速くなるが技術の断片化・重複投資が増えうるため、プラットフォームチームのゴールデンパスで標準を吸収してバランスを取るべきである。複雑サブシステムチームの分離は専門性を守るが知識の孤立(サイロ)とボトルネックを生みうるため、イネイブリングチームと文書化で緩和する。
- 認知負荷計測の難題: 認知負荷は定量化が難しいため、チーム調査・ドメイン数・オンコール負担・インシデント頻度などの代理指標を併用して定期的に点検すべきであり、過負荷の信号が見えればドメイン分割やチーム増設をためらってはならない。
- ガバナンス・セキュリティとの整合性: 自律的なストリーム整合チームが増えるほどセキュリティ・規制順守をチームごとに再実装する危険が高まるため、ポリシーをコードで(Policy as Code)プラットフォームに組み込みDevSecOps([[devsecops]])と結合するのが安全である。
- 展望・連携技術: チームトポロジーはマイクロサービス・DDD・プラットフォームエンジニアリング・SREと結合するときシナジーが最大化し、今後AI支援開発の拡大に伴い「チーム単位の認知負荷」を再定義する方向へ進化すると見込まれる。組織は構造を固定物ではなく継続的に感知し進化させる対象として扱うべきである。
参考資料
- Matthew Skelton, Manuel Pais, "Team Topologies", IT Revolution, 2019. https://teamtopologies.com/book
- Team Topologies 公式サイト(概念・キーコンセプト整理). https://teamtopologies.com/key-concepts
- Melvin Conway, "How Do Committees Invent?", 1968. https://www.melconway.com/Home/Committees_Paper.html
- Gartner, "What Is Platform Engineering?". https://www.gartner.com/en/articles/what-is-platform-engineering
一言まとめ: チームトポロジーは、デリバリーフローと認知負荷を基準に組織を4つのチームタイプ(ストリーム整合・プラットフォーム・複雑サブシステム・イネイブリング)と3つのインタラクション(コラボレーション・X-as-a-Service・ファシリテーション)で意図的に設計し、逆コンウェイ機動で望むアーキテクチャを創発させる現代的な組織設計モデルである。