チームトポロジーとは？エンジニアリング組織の構成方法

チームトポロジーとは何か？

チームトポロジーとは**「ビジネス価値のフロー（流れ）を最大化するための、適応型の組織設計モデル」**である。

従来の組織設計（階層型組織図）と決定的に異なるのは、以下の点を最優先することである。

チーム間の依存関係を整理し、無駄なコミュニケーション（調整コスト）を削減することで、各チームが自律的に動ける状態を作り出すことが目的である。

なぜ、従来の機能別組織（フロントエンド部、バックエンド部、インフラ部など）ではうまくいかないのだろうか。そこには2つの強力な法則が働いている。

1968年にメルヴィン・コンウェイが提唱した法則は、現在でも有効である。

「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出すように拘束される」

つまり、組織がサイロ化していれば、システムも分断され、統合が困難になる。逆に、疎結合なマイクロサービスを作りたいなら、まず組織を疎結合な独立したチームに分割しなければならない。これを**「逆コンウェイ作戦（Reverse Conway Maneuver）」**と呼ぶ。

もう一つの重要な概念が「認知負荷」である。人間の脳（ワーキングメモリ）が一度に扱える複雑さには限界がある。チームトポロジーでは、この負荷を以下の3つに分類し、「課題外在性負荷」の削減を目指す。

認知負荷がチームの容量を超えると、何が起きるだろうか？

チームはシステム全体を理解しきれなくなる。すると、「動いている部分は触りたくない」「デプロイして壊れたらどうしよう」という不安が支配し始める。その結果、システムに対する**「オーナーシップ（所有者意識と責任）」が欠如**する。

「自分の担当範囲以外は知らない」という態度が蔓延し、障害対応はたらい回しにされ、デリバリー速度は劇的に低下する。

チームトポロジーの狙いは、適切なチームサイズと責任範囲を設定することで、チームが健全なオーナーシップを取り戻すことにある。

無秩序なチーム編成を避け、認知負荷を適切に管理するために、チームトポロジーでは組織を以下の4つのタイプだけに分類することを推奨している。

役割: ビジネスの主要な価値の流れ（ストリーム）に沿って配置されるチーム。
特徴: 企画、開発、テスト、運用まで、一連のフローに対してエンドツーエンドの責任（オーナーシップ）を持つ。他チームへの「依頼待ち」を極力なくし、自律的に価値を届ける組織の主役である。健全な組織では、全チームの8〜9割がこのタイプになる。

役割: ストリームアラインドチームが自律的に動けるよう、インフラやツールを「セルフサービス」で提供するチーム。
特徴: 社内開発者を「顧客」と見なし、使いやすく認知負荷の低いプラットフォーム（Thinnest Viable Platform）を提供する。単なる「インフラ運用係」ではなく、プロダクトチームの生産性を上げるための「プロダクト」を作るチームである。

役割: 特定の技術領域（セキュリティ、テスト自動化、AIなど）のギャップを埋めるための専門家チーム。
特徴: 作業を代行するのではなく、一時的にストリームアラインドチームに入り込み、技術指導やコーチングを行うことで、チームの能力（ケイパビリティ）を向上させる。「魚を与えるのではなく、釣り方を教える」チームである。

チームの「形」だけでなく、「関わり方」も意図的に設計する必要がある。

モード	説明	向いている状況
コラボレーション (Collaboration)	2つのチームが密接に協力し、一緒に課題を解決する。	新しい技術の導入時や、APIの仕様が決まっていない探索フェーズ。
X-as-a-Service	一方のチームが提供するAPIやツールを、もう一方が利用する。	プラットフォームが成熟しており、ドキュメントだけで利用可能な状態。最も認知負荷が低い。
ファシリテーション (Facilitation)	一方のチームが他方を支援し、障害を取り除く。	イネイブリングチームが他チームの学習を支援する場合など。

重要なのは、これらのモードは固定ではなく、時期によって使い分けるということである。最初は「コラボレーション」で一緒に作り、安定したら「X-as-a-Service」に移行するといった動的な変化が求められる。

チームトポロジーは、一度導入して終わりの「新しい組織図」ではない。

プロダクトのフェーズが変われば、必要なチームの形も、最適なインタラクションも変わる。定期的に「今のチーム境界は適切か？」「認知負荷が高まりすぎていないか？」を問い直し、組織をリファクタリングし続けること（組織センシング）こそが、高速なフローを維持する鍵である。

自分のチームがどのタイプに当てはまるのか、そして「認知負荷」によってオーナーシップが損なわれていないか、メンバーと話し合うところから始めてみると良い発見が得られるかもしれない。