コンテンツにスキップ

Team Topologies

概要

従来の階層的な組織図やマトリクス型の管理体制は、コンプライアンスや報告ラインを示すのには役立ちますが、実際の価値創造の構造やコミュニケーションの実態（誰が誰と連携して仕事を進めているか）を正確に反映していません。このような静的な組織図に過度に依存すると、作業の分断、サイロ化、そしてデリバリーの遅延というアンチパターンに陥ります。

この問題を解決する理論的基盤となるのが、1968年に提唱されたコンウェイの法則です。この法則は、「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計（アーキテクチャ）を生み出すよう制約される」と定義しています。つまり、機能別に分断されたサイロ型の組織からは、密結合で変更が困難なモノリシックなシステムしか生まれません。

Team Topologiesは、このコンウェイの法則を逆手にとった「逆コンウェイの戦略」を提唱します。これは、望ましいソフトウェアアーキテクチャ（疎結合で独立したマイクロサービスなど）を実現するために、先にチーム構造とコミュニケーション経路をそのアーキテクチャに合わせて再編成するという戦略です。

本モデルは、ソフトウェアデリバリーの最小単位を「個人」ではなく「チーム」として捉えるチームファーストの思考に基づいています。明確な目的を持つ長寿命の自律的なチームを構築し、それらの境界と関わり方を動的に設計することで、組織全体の「価値の素早い流れ（Fast Flow）」を持続的に実現するための適応型モデルを提供します。

4つの基本チームタイプ

Fundamental Team Types 組織内の曖昧さを排除し、認知負荷を適切に保つため、Team Topologiesではあらゆる技術チームを次の「4つの基本チームタイプ」のいずれかに分類（または移行）することを推奨しています。

ストリームアラインド・チーム（Stream-Aligned Team）

ストリームアラインド・チームは、特定のビジネスドメイン、製品、サービス、ユーザーペルソナなど、価値の継続的な流れ（ストリーム）に沿って編成された主要なチームです。このチームの最大の目的は、他のチームへ作業をハンドオフ（引き継ぎ）することなく、アイデアの構想から本番環境へのデプロイ、運用、そしてフィードバックの収集までを極めて自律的、かつ迅速・安全にエンドツーエンドで実行することです。

「プロダクトチーム」や「フィーチャーチーム」ではなく「ストリームアラインド」と呼ぶ理由は、現代のサービスが単一の製品にとどまらず、マルチチャネル（モバイル、ウェブ、IoTなど）での継続的なデザインと価値のフロー（流れ）を重視する必要があるためです。

期待される振る舞いと特徴：

  • 機能のデリバリーにおいて、安定した継続的なフローを生み出す。
  • 本番環境の最新のフィードバックに基づいて、迅速に軌道修正を行う。
  • デザイン、開発、テスト、運用、セキュリティなど、デリバリーに必要な一連のケイパビリティ（能力）をチーム内に内包する（個人の専門性ではなくチームとしての能力）。
  • Amazonの「2枚のピザチーム」のように、高度に分散・独立したアーキテクチャを所有し、ランタイムの成功に責任を持つ。

イネーブリング・チーム（Enabling Team）

イネーブリング・チームは、特定の技術や製品ドメインの専門家で構成され、ストリームアラインド・チームが不足しているケイパビリティ（能力）を獲得できるように支援するチームです。ストリームアラインド・チームは常に迅速なデリバリーのプレッシャーに晒されており、新しい技術（例：AI、自動テストフレームワーク、継続的デリバリーなど）を調査・学習する時間を確保することが困難です。

イネーブリング・チームは、ストリームアラインド・チームに代わって調査や試行を行い、適切なツールの選択や実践方法のガイダンスを提供することで、このギャップを埋めます。

期待される振る舞いと特徴：

  • 技術的な選択を強制する「象牙の塔」になることを避け、サーバントリーダーシップの精神で他チームの自律性を高める。
  • 他チームの課題を先回りして検知し、一時的（数週間から数ヶ月）に深く関与して知識を移転する。
  • 恒久的な依存関係を作るのではなく、ストリームアラインド・チームが自己完結できるようになった時点で関与を終了する（初日から自分たちが不要になることを計画する）。
  • コミュニティ・オブ・プラクティス（CoP）とは異なり、専任のメンバーによって構成され、特定のチームの能力向上に集中的に取り組む。

コンプリケイテッド・サブシステム・チーム（Complicated-Subsystem Team）

コンプリケイテッド・サブシステム・チームは、ビデオ処理コーデック、高度な数学的モデル、リアルタイムの取引照合アルゴリズムなど、専門的な知識がなければ理解や変更が困難な、極めて複雑なサブシステムの構築と保守を担うチームです。

このチームの目的は、ストリームアラインド・チームの「認知負荷」を軽減することにあります。もしこれらの複雑な要素をストリームアラインド・チームが抱え込めば、彼らの認知負荷の限界を超え、価値のフローが停止してしまいます。

期待される振る舞いと特徴：

  • 単なる「共通コンポーネントを共有するためのチーム」ではなく、認知負荷の観点から「専門知識が不可欠な場合」にのみ例外的に結成される。組織内に存在する数はごく少数であるべきです。
  • 初期の開発フェーズではストリームアラインド・チームと密接にコラボレーションし、サブシステムが安定した後はインターフェースを通じた提供へと関わり方を変化させる。
  • 利用するチームのニーズを尊重し、システムのデリバリー速度と品質を維持する。

プラットフォーム・チーム（Platform Team）

プラットフォーム・チーム（大規模組織においてはプラットフォーム・グルーピング）は、ストリームアラインド・チームが自律的に作業できるようにするための内部サービスやツール（基盤）を提供するチームです。インフラのプロビジョニング、監視、デプロイメントパイプラインなどの低レベルな複雑さを隠蔽し、使いやすいセルフサービスとして提供することで、ストリームアラインド・チームの認知負荷を大幅に削減します。

期待される振る舞いと特徴：

  • プラットフォームを「内部顧客向けのプロダクト」として扱い、信頼性、ユーザビリティ、そして開発者体験（DevEx: Developer Experience）を最重視する。
  • 分厚く複雑なプラットフォームを構築するのではなく、ストリームアラインド・チームのニーズを満たす「最低限の実行可能なプラットフォーム（TVP: Thinnest Viable Platform）」を目指す。
  • 強制的な標準化ではなく、チームが簡単に正しいことができる「ゴールデンパス（推奨される最適な経路）」を提供する。
  • ストリームアラインド・チームとコラボレーションしてニーズを理解し、迅速なプロトタイピングでフィードバックを得る。

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

Team Interaction Modes

チームの境界を定義するだけでは不十分であり、チーム同士が「いつ、どのように」関わるべきかを明確にすることが不可欠です。Team Topologiesでは、コミュニケーションのオーバーヘッドを管理し、システムアーキテクチャを適切に形作るために、3つのコアとなるインタラクション（相互作用）モードを定義しています。

コラボレーション

コラボレーション（共同作業）は、2つのチームが密接に協力し合い、新しい技術の探求や未知の課題の解決に当たるモードです。

特徴と適用場面：

  • イノベーションや新しいアプローチの迅速な発見に非常に有効であり、チーム間のハンドオフ（引き継ぎ）による遅延を防ぎます。
  • 一方で、お互いのコンテキストを深く理解する必要があるため、両チームの認知負荷は一時的に著しく上昇します。
  • コンウェイの法則により、コラボレーション中のチーム間で開発されるソフトウェアは、境界が曖昧になり密結合になる傾向があります。
  • したがって、コラボレーションは「高い価値（報酬）が期待できる明確な目的」のために「一時的（または断続的）」に行うべきであり、同時に3つ以上のチームとコラボレーションすることは避けるべきです。

X-as-a-Service

X-as-a-Service（サービスとしての提供）は、一方のチームが提供するコンポーネント、API、またはプラットフォームを、もう一方のチームが「サービスとして」消費するモードです。

特徴と適用場面：

  • 日常的な密接なコミュニケーションを必要とせず、境界が明確に保たれるため、両チームの認知負荷を低く抑えることができます。
  • システムの予測可能なデリバリーと安定したフローを実現するのに最適です。
  • このモードが成功するためには、提供側（プラットフォームチームやコンプリケイテッド・サブシステム・チームなど）が「最小限のやり取りで機能する」状態を作ることが絶対条件となります。優れたプロダクトマネジメント、明確なドキュメント、バージョン管理、そして優れた開発者体験（DevEx）の提供が求められます。
  • ストリームアラインド・チームは、複数のチームと同時にこのモードで関わることが一般的です。

ファシリテーション

ファシリテーション（支援・促進）は、一方のチーム（主にイネーブリング・チーム）が、他のチームの障害を取り除き、新しい能力の獲得やアプローチの導入を支援するモードです。

特徴と適用場面：

  • 指導、メンタリング、コーチングを通じて、支援される側のチームが可能な限り早く「自立」できるようにすることが目的です。
  • ファシリテーティングを行うチームは、複数のチームを横断的に支援する中で、プラットフォームや既存コンポーネントの「欠陥や使いにくさ」を検知し、組織全体の改善につなげる役割も担います。
  • 支援を受ける側のチームには、新しいアプローチを学ぶためのオープンな姿勢が求められます。

認知負荷とチーム設計

チームファーストの組織設計において最も重要な制約の1つが、チームが処理できる「認知負荷」の限界です。認知負荷を無視してチームに過剰な責任を与えると、コンテキストスイッチによる疲弊、モチベーションの低下、そしてデリバリーの深刻なボトルネック化を招きます。

認知負荷の3類型

心理学者のJohn Swellerによる定義に基づき、ソフトウェア開発における認知負荷は次の3つに分類されます。

  1. 内在的負荷（Intrinsic Cognitive Load）: タスクそのものに固有の難しさ。例：プログラミング言語の構文や基本原則の知識。
  2. 課題外的負荷（Extraneous Cognitive Load）: タスクが実行される環境やプロセスに起因する余分な負荷。例：複雑なデプロイ手順、使いにくいテスト環境、不要な承認プロセスなど。
  3. 学習関連負荷（Germane Cognitive Load）: 学習や高いパフォーマンスを達成するために必要な、ビジネス価値に直結する負荷。例：顧客のビジネスドメイン（金融、医療など）の深い理解、サービス間の相互作用の設計。

組織は、自動化やプラットフォームの提供によって「課題外的負荷」を極限まで排除し、トレーニングやペアプログラミングによって「内在的負荷」を最小化することで、チームの頭のメモリを顧客価値の創造である「学習関連負荷（Germane）」に集中させる必要があります。

チームサイズとダンバー数

チームが高い信頼関係を築き、認知負荷を適切に共有するためには、チームサイズを制限する必要があります。人類学者のRobin Dunbarの研究に基づく「ダンバー数」によれば、人間が深く信頼できる関係を構築できる限界は約15人であり、日常的に緊密に連携するソフトウェア開発チームの最適なサイズは5〜9人（Amazonの2枚のピザチームと同等）とされています。

このダンバー数は、チームの集合体（トライブや部門）をスケールさせる際にも適用されます。約15人（深い信頼）、約50人（相互の信頼）、約150人（能力を記憶できる限界）といった境界を超えるごとに組織の力学は変化するため、アーキテクチャやグループの境界線をこれに合わせて再設計する必要があります。

ドメイン境界とチーム境界の一致

システムがチームの認知負荷を超えないようにするためには、ソフトウェアの境界線を「チームサイズ」に合わせて適切に分割（分離）する必要があります。この分割の自然な継ぎ目を破断面（Fracture Planes）と呼びます。

  • ビジネスドメインの境界（Bounded Context）: ドメイン駆動設計（DDD）の概念を用い、ビジネス領域ごとにシステムとチームを分割します。これが最も推奨される主要な破断面です。
  • その他の破断面: ビジネスドメインだけでは分割が難しい場合、「規制・コンプライアンス（例：決済データ処理の分離）」「変更頻度（例：日次更新 vs 四半期更新）」「リスク許容度」「チームの地理的配置」「特定のレガシー技術」といった破断面を組み合わせてシステムを分割します。

単一の巨大なデータベースを共有するモノリス「Joined-at-the-database Monolith」や、独立したサービス群に見えてリリース時に全結合テストが必要な「分散モノリス」などの隠れたモノリスは、チームの自律性を奪い認知負荷を増大させるため、これらの破断面を用いて解体しなければなりません。

第二版の進化（2025年）

2025年に発行された『Team Topologies 第二版』では、初版からの数年間の実践とフィードバックに基づき、現代の組織が直面する課題に適応するための重要な概念の明確化と拡張が行われました。

エコシステム思考への転換

第二版では、組織を厳格な計画と統制によって動く「効率的な機械（Efficient Machine）」として扱う従来のアプローチからの脱却を強く促しています。リーダーは、中央集権化や重複の排除によるコスト削減の誘惑に抗い、代わりに方向性を共有するプロバイダーたちが織りなす「繁栄するエコシステム（Fruitful Ecosystem）」を育む必要があります。このエコシステムは、機械的なプロセスではなく、コミュニティでの実践や組織全体での「積極的な知識の伝播（knowledge diffusion）」によって繁栄します。

スチュワードシップ（Stewardship）

従来のプロジェクト型の働き方に見られる「作って終わり」というシステム所有の概念は、排他的な縄張り意識（テリトリー行動）を生み出しがちでした。第二版では、EBSCO社の事例などに見られるように、単純な「所有」から「継続的なスチュワードシップ（世話役）」へのマインドセットの転換が不可欠であると説かれています。チームは警察のようにコードを取り締まるのではなく、顧客のニーズの変化に合わせてソフトウェアという「庭」を継続的に手入れし、進化させる庭師としての責任を担います。

組織的センシング（Organizational Sensing）と自己操舵

変化の激しい市場において、組織は固定的な計画に従うのではなく、環境の変化や内部の摩擦をリアルタイムに感知して自ら方向を修正する「自己操舵」の能力を持つ必要があります。 安定したチームと明確なインタラクションは、組織内外のシグナルを高解像度で検知するための「感覚器官（Senses）」として機能します。

特に重要なのは、IT運用（Ops）を単なる保守作業として扱うのではなく、開発（Dev）に対する「高い価値をもつインプット」として扱うというフィードバックシステムの構築です。これを実現するためには、「新機能開発チーム」と「保守チーム」を分断するアンチパターンを廃止する必要があります。1つのチームが新旧両方のシステムを並行して運用し、過去の運用から得たテレメトリやインサイトを直接新しい設計に活かします。

エンタープライズ対応

認知負荷の制限と Fast Flow の原則は、ソフトウェア開発の枠を大きく超え、あらゆる知識労働へと適用範囲を広げています。現在では、製薬会社の研究開発（R&D）、グローバル法律事務所、人事（HR）、さらには病院の救急医療など、非IT部門でもこの原則が活用されています。

さらに、単一の企業内にとどまらず、GovTech Singaporeに見られるような国家規模のデジタルトランスフォーメーションや、未公開株式（PE）ファンド・ベンチャースタジオが複数の企業群全体を横断的に運用するためにTeam Topologiesのパターンを適用するといった、大規模なエンタープライズレベルでの実践が急速に広がっています。

バリューストリーム・グルーピング (Value-stream Grouping)

「バリューストリーム・グルーピング」とは、複数のチームを共通のミッションや価値の流れ（バリューストリーム）のもとにまとめた大規模なグループ（コンテナ）を指す概念です。このグループの内部はフラクタル（入れ子）状の構造になっており、ストリームアラインド・チームや小規模な内部プラットフォームなど、様々な基本チームがその中で連携して機能しています。

社内の他チームにサービスを提供する「プラットフォーム・グルーピング」も、このバリューストリーム・グルーピングの特殊な形態の一つとして明確に位置づけられており、組織が大規模になってもチームファーストの原則を保ちながら、価値の素早い流れを持続させるための重要な枠組みとなっています。

Thinnest Viable Platform（TVP）と Platform Grouping

40〜50人以上の組織では、プラットフォームは単一のチームではなく、複数のチームをまとめたコンテナである「プラットフォーム・グルーピング」として構成されます。初版で「プラットフォームを1つのチームとして記述したこと」が引き起こした「すべてを担う巨大な単一プラットフォームチームを作ってしまう」という誤解を解消するため、定義が明確化されました。

このグルーピングの内部には、外部と同じように「ストリームアラインド」や「イネーブリング」といった基本チームが入れ子状（フラクタル）に存在します。また、Trade Me社の事例に代表されるように、プラットフォームは網羅的である必要はなく、開発者の認知負荷を減らすための「最低限の実行可能なプラットフォーム（TVP: Thinnest Viable Platform）」であるべきです。TVPは、強制ではなく開発者が使いたくなるような優れた開発者体験（DevEx）とゴールデンパスを提供し、エコシステム全体を簡素化することに注力します。

実践への適用

Team Topologiesは一度適用して終わりの静的なモデルではなく、組織の成長や技術トレンドに合わせて継続的に進化させるためのフレームワークです。

チームトポロジーの現状分析

変革の第一歩は、現在の組織の「価値の流れ（ストリーム）」を特定し、チームの認知負荷の現状を分析することです。Creditas社の事例のように、「Teamperature」などの科学的モデルを用いた定期的なアンケートや対話を通じて、何がチームの認知負荷（タスクの複雑さ、不明確な役割、レガシーシステムなど）を高めているかをデータ駆動で可視化します。これにより、直感や精神論ではなく、真のボトルネックに対処するためのTVPの構築やイネーブリングチームの投入が可能になります。

インタラクションモードの選択と変更

チーム間の関わり方は、目的とフェーズに応じて意図的に選択・変更する必要があります。 新しい技術や未知のアーキテクチャを導入する初期フェーズでは、チーム間でコラボレーションモードを選択し、一時的に認知負荷を高めてでも迅速な学習と発見を優先します。技術が確立し、APIやインターフェースの境界が明確になった後は、依存関係と認知負荷を下げるためにX-as-a-Serviceモードへと移行し、予測可能な迅速なデリバリーを実現します。また、他チームへの共感を育むために、一時的にメンバーを交換してインタラクションモードを変化させることも有効です。

不自然さ（Awkwardness）のセンシング

組織は、チーム間のインタラクションで発生する「摩擦」や「不自然さ」を、アーキテクチャや境界線の設計ミスを知らせる強力なシグナルとして活用する必要があります。 例えば、「X-as-a-Serviceで提供されているはずの社内APIを利用するために、チャットや対面で頻繁に質問しなければならない」という摩擦が発生している場合、それは「プラットフォームチームの開発者体験（DevEx）が不足している」、あるいは「ドメインの境界線が間違っている」という明確なシグナルです。この不自然さを検知した際は、一時的にCollaborationモードに戻ってAPIの境界を再定義したり、Enablingチームを投入して能力のギャップを埋めるアプローチをとります。

経営層との対話：共通言語としてのモデル

Team Topologiesは、エンジニアリング部門だけでなく、経営層を含む全社的な組織変革の「共通言語」として機能します。Yassir社の事例に見られるように、このモデルの語彙（認知負荷、Fast Flow、ストリーム、TVPなど）を共有することで、組織設計の課題と可能性を明確に言語化できるようになります。 さらに、Capra Consulting社の事例のように、経営陣自体が「指示を出す管理者」から、各チームの自律的な意思決定を支援する「イネーブリング（Leadership-as-a-Service）」の役割へとマインドセットを転換することが、真のビジネスアジリティを実現する鍵となります。

事例（Appendix Case Studies）

参考文献（References）

1. コンウェイの法則とアーキテクチャ

  • Conway, Melvin E. "How Do Committees Invent? Design Organization Criteria." Datamation, 1968.
  • Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison Wesley, 2003.

2. 認知負荷とダンバー数（チーム・個人の限界）

  • Sweller, John. "Cognitive Load During Problem Solving: Effects on Learning." Cognitive Science 12 no. 2 (1988): 257-285.
  • Weis, PhD, Laura. "Teamperature's Scientific Model - Teamperature." Teamperature.com.
  • Dunbar, Professor Robin. How Many Friends Does One Person Need?: Dunbar's Number and Other Evolutionary Quirks. London: Faber & Faber, 2010.
  • Dunbar, R. I. M. "Neocortex Size as a Constraint on Group Size in Primates." Journal of Human Evolution 22, no. 6 (1992): 469-493.

3. ハイパフォーマンスな組織とDevOps（フローの科学）

  • Forsgren, PhD, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations. Portland, Oregon: IT Revolution Press, 2018.
  • Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Portland, OR: IT Revolution Press, 2016.
  • Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing, 2009.

4. チーム力学・組織心理学・リーダーシップ

  • Edmondson, Amy. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly 44 no. 2 (1999): 350-383.
  • Pink, Daniel. Drive: The Surprising Truth About What Motivates Us. New York: Riverhead Books, 2009.
  • Tuckman, Bruce W. "Developmental Sequence in Small Groups." Psychological Bulletin 63 no. 6 (1965): 384-399.
  • McChrystal, General Stanley, David Silverman, Tantum Collins, and Chris Fussell. Team of Teams: New Rules of Engagement for a Complex World. New York, NY: Portfolio Penguin, 2015.