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

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

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

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

• 静的な「ヒエラルキー」ではなく、動的な「フロー」を重視する
• 「人間の認知負荷（Cognitive Load）」を設計の制約条件とする
• ソフトウェアアーキテクチャと組織構造をセットで考える

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

なぜチームトポロジーなのか？

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

コンウェイの法則と「逆コンウェイ作戦」

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

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

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

認知負荷理論：チームの限界

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

• 課題内在性負荷（Intrinsic）： Javaの書き方やビジネスロジックなど、仕事に不可欠な負荷。
• 課題外在性負荷（Extraneous）： 複雑すぎるデプロイ手順、使いにくいテスト環境、誰に聞けばいいかわからない社内手続きなど、価値を生まない負荷。
• 学習関連負荷（Germane）： より良い解決策を探すための負荷。ここにもっとリソースを割くべきである。

認知負荷と「オーナーシップの欠如」

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

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

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

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

4つのチームタイプ

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

ストリームアラインドチーム (Stream-aligned Team)

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

プラットフォームチーム (Platform Team)

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

イネイブリングチーム (Enabling Team)

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

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

• 役割: 高度な数学的モデルや画像処理エンジンなど、専門性が高すぎて通常のチームでは認知負荷が限界を超える部分のみを担当するチーム。
• 特徴: 認知負荷を下げるための例外的な処置として設置される。安易に増やすべきではない。

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

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

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

まとめ

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

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

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

参考

• teamtopologies.com
• チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計