『チームトポロジー』完全解説：4つのチームタイプと3つのインタラクションモードで変わる組織設計
なぜ今『チームトポロジー』なのか
「組織図通りにチームを作ったのに、なぜかうまくいかない」
「チーム間の連携がスムーズにいかず、プロジェクトが遅延する」
「優秀なエンジニアがいるのに、組織全体としてのアウトプットが上がらない」
こうした課題に直面している組織は少なくありません。従来の組織設計は「職能」や「プロダクト」を軸に行われてきましたが、ソフトウェア開発の現場ではチーム間のコミュニケーションコストや認知負荷が組織のパフォーマンスを大きく左右します。
マシュー・スケルトンとマニュエル・パイスによる『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（原題：Team Topologies: Organizing Business and Technology Teams for Fast Flow）は、この課題に対する明確な答えを提示します。
本書が提唱する4つのチームタイプと3つのインタラクションモードというシンプルなフレームワークは、組織設計に新しい視点をもたらします。本記事では、『チームトポロジー』の核心的な概念を体系的に解説します。
本書の核心：4つのチームタイプと3つのインタラクションモード
4つの基本的なチームタイプ
本書は、ソフトウェア組織のチームを4つの基本タイプに分類します。
1. ストリームアラインドチーム（Stream-Aligned Team）
定義: 価値の流れ（ビジネス価値を顧客に届けるフロー）に沿って働くチーム
特徴:
- 組織の中心的存在
- エンドツーエンドで顧客価値を提供
- プロダクトやサービスの一部を担当
- 可能な限り自律的に動ける
例:
- プロダクトの特定機能を担当するチーム
- 顧客セグメントごとに分かれたチーム
- ユーザージャーニーの特定部分を担当するチーム
ポイント: ストリームアラインドチームがスムーズに価値を届けられることが組織全体の目標です。他の3つのチームタイプは、すべてストリームアラインドチームを支援するために存在します。
2. プラットフォームチーム（Platform Team）
定義: 他のチームの認知負荷を下げる基盤を提供するチーム
特徴:
- 内部プラットフォームを「プロダクト」として提供
- ストリームアラインドチームが本来の価値提供に集中できるようにする
- セルフサービス型のAPI・ツール・インフラを整備
例:
- CI/CDパイプラインの提供
- データ基盤の構築・運用
- 認証・認可基盤の提供
- ログ・モニタリング基盤
ポイント: プラットフォームチームは「便利屋」ではありません。明確なプロダクトとしての基盤を提供し、利用者（ストリームアラインドチーム）の生産性を高めることが使命です。
3. イネーブリングチーム（Enabling Team）
定義: 能力ギャップを埋める支援を行うチーム（期間限定）
特徴:
- 専門知識を持ち、他チームのスキルアップを支援
- コンサルタント的な役割
- 支援が終われば次のチームへ移動
- 依存関係を生まないよう注意
例:
- 新技術導入の支援チーム
- セキュリティ・アクセシビリティの専門支援
- テスト自動化の推進チーム
- 開発プラクティスの向上支援
ポイント: イネーブリングチームは期間限定で関わります。支援終了後、ストリームアラインドチームが自走できる状態にすることが目標です。
4. コンプリケイテッド・サブシステムチーム（Complicated-Subsystem Team）
定義: 高度な専門知識が必要な複雑な領域を担当するチーム
特徴:
- 数学的アルゴリズム、高度な技術的専門性が必要
- ストリームアラインドチームの認知負荷を下げるために分離
- 専門性の高い少数精鋭チーム
例:
- 機械学習モデルの開発・運用
- 動画エンコーディングエンジン
- リアルタイム取引システム
- 暗号化・セキュリティライブラリ
ポイント: このチームタイプは必要最小限にとどめます。安易に「複雑だから分離」すると、逆にコミュニケーションコストが増大します。
3つのインタラクションモード
チームタイプを定義しただけでは不十分です。チーム間の関わり方も明確にする必要があります。
1. コラボレーション（Collaboration）
定義: 2つのチームが密に協力して働く
特徴:
- イノベーションと発見に最適
- 認知負荷は高い（両チームが相手の領域も理解する必要がある）
- 探索フェーズに適している
- 期間限定で行う
適用場面:
- 新しい技術・アーキテクチャの探索
- 複雑な問題の共同解決
- チーム間の境界が不明確な初期フェーズ
注意点: コラボレーションは認知負荷が高いため、長期化させないことが重要です。明確な終了条件を設定しましょう。
2. X-as-a-Service
定義: 一方のチームが他方に明確なサービスを提供する
特徴:
- 責任が明確で予測可能
- 認知負荷は低い（APIを通じた疎結合）
- 安定したフェーズに適している
- スケーラブル
適用場面:
- プラットフォームチームからストリームアラインドチームへのサービス提供
- 成熟したAPIやツールの提供
- 標準化された手続き・プロセスの提供
ポイント: X-as-a-Serviceは最も効率的なインタラクションモードです。コラボレーションで得た学びを、X-as-a-Service化することで組織全体に展開できます。
3. ファシリテーション（Facilitating）
定義: 一方のチームが他方の能力ギャップを縮小する支援を行う
特徴:
- イネーブリングチームの典型的な働き方
- 教育・メンタリング・伴走支援
- 支援対象チームの自立が目標
- 期間限定
適用場面:
- 新技術の導入支援
- ベストプラクティスの普及
- チームのスキルアップ支援
ポイント: ファシリテーションは依存関係を生まないように注意します。支援終了後、相手チームが自走できる状態を目指します。
チームタイプとインタラクションモードの組み合わせ
| 組み合わせ | よくあるパターン | 注意点 |
|---|---|---|
| ストリームアラインド × プラットフォーム | X-as-a-Service | プラットフォームを「プロダクト」として提供 |
| ストリームアラインド × イネーブリング | ファシリテーション | 期間限定、自立を目指す |
| ストリームアラインド × コンプリケイテッド | X-as-a-Service | 専門領域をサービス化 |
| ストリームアラインド × ストリームアラインド | コラボレーション（一時的） | 長期化させない |
コンウェイの法則と組織設計
コンウェイの法則とは
コンウェイの法則: 「組織のコミュニケーション構造がシステム設計に反映される」
1967年にメルヴィン・コンウェイが提唱したこの法則は、組織設計とシステムアーキテクチャの関係を説明します。
具体例:
- 4つのチームでコンパイラを作ると、4パスのコンパイラになる
- サイロ化した組織は、サイロ化したシステムを生む
- フロントエンド・バックエンドで分かれた組織は、API境界で分断されたシステムになる
逆コンウェイ戦略
逆コンウェイ戦略: 望ましいシステム構造に合わせて組織を設計する
従来は「組織に合わせてシステムを作る」でしたが、逆コンウェイ戦略では「理想のシステム構造を先に定義し、それに合わせて組織を設計」します。
実践例:
- マイクロサービスアーキテクチャを目指すなら、各サービスごとに自律したチームを作る
- フロントエンド・バックエンドの統合を目指すなら、フルスタックチームを編成
- データドリブンな組織を目指すなら、データサイロを壊す組織設計を行う
組織の3つの構造
本書では、組織には3つの異なる構造があると指摘します：
- 公式構造（組織図）: 組織図に表れる階層構造
- 非公式構造（実際のコミュニケーション）: 日常的に誰と話しているか
- 価値創造構造（実際の価値の流れ）: 顧客価値がどう生まれているか
重要: 組織図（公式構造）は実際のコミュニケーションや価値の流れを反映していないことが多いです。『チームトポロジー』は価値創造構造に組織を合わせることを推奨します。
認知負荷という新しい視点
認知負荷の3種類
本書の最も革新的な概念の1つが「認知負荷」です。チームが抱える負荷を3つに分類します：
1. 課題内在負荷（Intrinsic Cognitive Load）
定義: 問題領域の本質的な難しさ
例:
- 金融システムの複雑なビジネスルール
- リアルタイム性が求められる配信システム
- 大規模データ処理の最適化
対処法: 削減できないため、チームが扱える範囲に収める
2. 課題外在性負荷（Extraneous Cognitive Load）
定義: 環境や手続きの煩雑さによる負荷（削減対象）
例:
- 不明瞭なドキュメント
- 複雑すぎるデプロイ手順
- 非効率な承認プロセス
- 技術的負債
対処法: 積極的に削減する（自動化、標準化、ドキュメント整備）
3. 学習関連負荷（Germane Cognitive Load）
定義: 新しい知識習得のための負荷
例:
- 新しい技術の学習
- ドメイン知識の習得
- ベストプラクティスの理解
対処法: 必要な負荷だが、タイミングと量を調整する
認知負荷を活用したチーム設計
原則: チームの認知負荷が適切な範囲に収まるよう設計する
実践方法:
- 課題外在性負荷を削減: プラットフォームチームが基盤を整備
- 複雑ドメインを分離: コンプリケイテッド・サブシステムチームに切り出し
- 学習をサポート: イネーブリングチームが支援
- チームの境界を調整: 認知負荷が高すぎる/低すぎる場合は境界を見直す
チームの認知負荷を測る問いかけ
- チームは「なんでも屋」状態になっていないか？
- メンバーが抱える技術・ドメインは多すぎないか？
- 外部への問い合わせ対応で本来の仕事ができていないか？
- 新メンバーのオンボーディングに時間がかかりすぎていないか？
チームファースト思考の重要性
ダンバー数と信頼関係
ダンバー数: 人間が安定した社会関係を維持できる人数の認知的限界
- 5人: 深い信頼関係を築ける人数
- 15人: 高い信頼を保てる人数
- 50人: 効果的に協働できる人数
- 150人: 顔と名前を一致させられる人数
チームサイズの最適範囲: 本書は7〜9人を推奨します。
- 5人以下: スキルの多様性が不足
- 10人以上: コミュニケーションコストが急増
チームの安定性が重要
原則: 人を流動させるのではなく、仕事をチームに流す
アンチパターン:
- プロジェクトごとにチームを再編成
- 優秀なメンバーを次々と別のチームに異動させる
- 短期的な人員補強を繰り返す
ベストプラクティス:
- チームを長期的に安定させる
- チームとして学習・成長する時間を確保
- チーム単位で責任範囲を明確にする
内発的動機づけ（自律・熟達・目的）
ダニエル・ピンクの「モチベーション3.0」から引用されるこの概念は、チーム設計でも重要です：
- 自律性（Autonomy）: チームが自分たちで意思決定できる
- 熟達（Mastery）: チームとしてスキルを高められる
- 目的（Purpose）: チームの仕事が意味のあるものと感じられる
チームトポロジーの設計は、この3つを最大化することを目指します。
実践に向けて：まず何から始めるか
ステップ1: 現状の可視化
まず、現在の組織を4つのチームタイプとインタラクションモードで整理します：
問いかけ:
- 各チームはどのタイプに該当するか？
- 実際のインタラクションモードは何か？
- 「便利屋チーム」になっているチームはないか？
- ストリームアラインドチームは価値をスムーズに届けられているか？
ステップ2: ボトルネックの特定
価値の流れを阻害している要因を特定します：
観点:
- 認知負荷が高すぎるチームは？
- チーム間の依存関係が複雑すぎないか？
- コラボレーションが長期化しているチームは？
- プラットフォームがサービスとして機能しているか？
ステップ3: 小さく始める
組織全体を一度に変えるのではなく、小さな改善から始める：
具体的アクション:
- チームAPIの明確化: 1つのチームから始める
- インタラクションモードの明示: チーム間の関係性を文書化
- 認知負荷の削減: 最も負荷が高いチームの外在性負荷を減らす
- コラボレーションの期限設定: 終わりのないコラボレーションに終了条件を設ける
ステップ4: 継続的な進化
組織設計は一度で完成するものではありません：
進化のサイクル:
- センシング: 組織やシステムの変化を感知
- 適応: チームタイプやインタラクションモードを調整
- 学習: 何が機能し、何が機能しなかったかを振り返る
- 進化: 新しい知見を次の設計に活かす
まとめ
『チームトポロジー』は、ソフトウェア組織設計に明確なフレームワークを提供します：
核心的な概念
-
4つのチームタイプ
- ストリームアラインドチーム（中心）
- プラットフォームチーム（基盤提供）
- イネーブリングチーム（支援、期間限定）
- コンプリケイテッド・サブシステムチーム（専門領域）
-
3つのインタラクションモード
- コラボレーション（探索、高負荷、期間限定）
- X-as-a-Service（安定、低負荷、スケーラブル）
- ファシリテーション（支援、自立を目指す）
-
認知負荷の管理
- 課題外在性負荷を削減
- 複雑ドメインを適切に分離
- チームの境界を認知負荷で調整
-
コンウェイの法則
- 組織構造がシステムに反映される
- 逆コンウェイ戦略で理想のシステムを実現
-
チームファースト思考
- チームサイズ7〜9人
- チームの安定性を重視
- 内発的動機づけを最大化
本書が提供する価値
従来の組織設計が「職能」や「プロダクト」を軸としていたのに対し、『チームトポロジー』は価値の流れと認知負荷という新しい視点を提供します。
この視点により：
- チーム間の関係性が明確になる
- 組織のボトルネックが見える化される
- 継続的な組織改善の指針が得られる
- スケーラブルな組織設計が可能になる
次のステップ
本書を読んだ後の実践ステップ：
- 現状を4つのチームタイプで整理する
- インタラクションモードを明示する
- 認知負荷が高いチームを特定し、外在性負荷を削減する
- 小さな改善から始め、継続的に進化させる
参考文献
- マシュー・スケルトン、マニュエル・パイス『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』翔泳社、2021年
- 原著: Matthew Skelton, Manuel Pais. "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019
『チームトポロジー』は、組織設計に悩むすべてのエンジニアリングマネージャー、プロダクトマネージャー、経営層にとって必読の一冊です。本記事が、本書の理解を深める一助となれば幸いです。
Discussion