チームトポロジーとは - 4 つのチーム型と 3 つのインタラクションモード

チームトポロジーとは

チームトポロジーは、Matthew Skelton と Manuel Pais が 2019 年の同名書籍 (IT Revolution) で提唱したフレームワークで、ソフトウェア開発組織のチーム構造を 4 つの基本型と 3 つのインタラクションモードで設計する。狙いは組織図を整えることではなく、着想から利用者に届くまでの流れを詰まらせないことにあり、そのためにコンウェイの法則を意図的に利用する。書籍は 2025 年 9 月に第 2 版が出たが、4 型と 3 モードという骨格は変わっておらず、2026 年 8 月時点の公式サイトでも中核概念として掲げられている。

4 つのチーム型

4 型は担当技術で分かれるのではなく、流れの中でどんな役目を負うかで分かれる。既定は Stream-aligned で、組織の大半をここに置き、残る 3 型は Stream-aligned の流れが詰まらないようにするために用意する。逆に言えば、既存の部署に 4 つの名前を割り当て直しただけでは何も変わらない。

チーム型	説明	例
Stream-aligned	ビジネス価値を継続的に届ける	注文チーム、決済チーム
Enabling	他チームの障害を取り除き、足りない能力を見つける	テスト自動化の推進、アーキテクチャ支援
Complicated Subsystem	数学・計算・専門知識の密度が高い部分を担当	動画コーデック、機械学習モデル、暗号処理
Platform	内部プロダクトとして基盤を提供	CI/CD、インフラ

3 つのインタラクションモード

チーム間の関わり方は 3 つに限る、という制約がこのフレームワークの要点だ。「必要なときに必要なチームと話す」状態は一見健全に見えるが、誰と何のためにいつまでつながるのかが決まっていないため、会議とすり合わせが際限なく増えていく。

モード	説明
Collaboration	2 チームが期間を区切って一緒に働き、新しい方法や境界を見つける
X-as-a-Service	一方が提供し他方が利用する。境界が API や文書で固定されている
Facilitating	一方が他方を指導し、詰まりの除去を助ける (Enabling チームの標準モード)

コンウェイの法則

Collaboration は発見のための一時的な形なので、境界が固まったら X-as-a-Service へ移す。移さずに常設すると、双方のチームが相手側の事情を抱えたまま働き続けることになり、認知負荷が下がらない。

この型とモードの設計を支えているのが、次のコンウェイの法則の使い方である。

「システムを設計する組織は、そのコミュニケーション構造をコピーした設計を生む」

❌ 意図しないコンウェイの法則:
  フロントチーム + バックエンドチーム + DB チーム
  → 3 層アーキテクチャが固定化

✅ 逆コンウェイ戦略:
  望ましいアーキテクチャに合わせてチームを設計
  注文チーム (フルスタック) → 注文マイクロサービス
  決済チーム (フルスタック) → 決済マイクロサービス

認知負荷とチームサイズ

チームが担当するサービスの数と複雑さは、チームの認知負荷の上限内に収める必要がある。認知負荷は 3 種類に分けて考える。問題そのものの難しさ (内在的)、ツールやデプロイ手順といった周辺事情の複雑さ (外在的)、ドメインを理解して価値ある判断に振り向ける負荷 (学習的) である。設計の勘所は、外在的な負荷を Platform チームが吸収し、Stream-aligned チームが学習的な負荷にリソースを回せる状態を作る点にある。チームサイズは 5〜9 人程度が目安で、根拠はダンバー数の内側の層 (深い信頼を保てるのは 5 人前後、信頼関係を維持できるのは 15 人前後) に置かれている。ただし人数を守っても所有サービスが多ければ上限は超えるので、実際の判断材料は人数より「1 チームが持つサービスの数と、その変更に必要な知識の広さ」になる。

Platform チームの役割

Platform チームは CI/CD パイプライン、IaC テンプレート、監視基盤、セキュリティ基盤などを内部サービスとして提供する。Stream-aligned チームはこれらを X-as-a-Service モードで利用し、ビジネスロジックに集中する。Platform チームの成果物は「使いやすい内部プロダクト」であり、Stream-aligned チームが顧客だ。落とし穴は、利用を義務化して使わせる方向に倒すことにある。書籍が置く基準は、提供範囲を必要最小限に絞り、Stream-aligned チームが自力で組むより明らかに楽な状態を先に作ることだ。使われない内部基盤は、それ自体が全チームの外在的な認知負荷として残る。

チームトポロジーの進化

チーム構造は固定ではなく、組織の成長に合わせて進化させる。初期は 1 チームで全てを担当し、成長に応じて Stream-aligned チームを分割する。分割の合図は人数ではなく、担当ソフトウェアの認知負荷が 1 チームの上限を超えたことだ。特定の個人しか触れない領域が出てくる、リリース間隔が伸びる、といった形で先に現れる。関わり方も同じで、Collaboration は発見が終わった時点で X-as-a-Service へ、Enabling チームの支援は対象チームが自走できた時点で終了させる。畳む判断まで設計に含めておかないと、型と接点だけが増えて元の縦割りに戻る。

導入時に最初に見る数字は、チーム数や階層の深さではない。1 チームが所有するサービスの数と、変更を本番へ届けるまでに何チームの合意が必要かの 2 つだ。この 2 つが下がらない組織変更は、呼び名を付け替えただけで終わっている。