team-topologies

チームトポロジー

Matthew Skelton と Manuel Pais の著書『Team Topologies』に基づく、組織設計におけるチーム優先のアプローチです。4 つの基本的なチームタイプ、3 つのインタラクションモード、そしてコンウェイの法則とチームの認知負荷への意図的な配慮を扱います。変更を迅速に届けるためのエンジニアリング組織を構築し、システム、技術、市場の変化に合わせて組織を進化させ続けるために活用してください。

基本原則

チームがデリバリーの単位であり、組織はそのコミュニケーション構造を製品として出荷します。 コンウェイの法則によって、システムアーキテクチャはチームの実際のコミュニケーション方法を反映します。そのため、チームの境界やインタラクションは、ソフトウェアそのものと同じように意図的に設計する必要があります。各チームの責任範囲を認知負荷に合わせ、大半のチームをビジネスの変化の流れに沿わせ、チーム間のインタラクション方法を明示し、変更を迅速に届けられるよう最適化するための生きたアーキテクチャ上の意思決定として、できあがったトポロジーを扱ってください。

スコアリング

目標：10/10。 以下の原則に照らして、組織とチームの設計を 0〜10 で評価します。現在のスコアと、10/10 に到達するために必要な具体的な変更を報告してください。

• 9-10： ストリームアラインドチームが、認知負荷に合ったエンドツーエンドの範囲を担当しています。プラットフォームチーム、イネーブリングチーム、複雑なサブシステムのチームは、その負荷を軽減する場合に限り存在します。インタラクションモードが明確に定義され、意図的に進化しています
• 7-8： 大部分はストリームアラインドチームで、実質的なプラットフォームもありますが、所有権の共有、未定義のインタラクションモード、または過負荷のチームが一部にあります
• 5-6： チームタイプは名付けられているものの、境界が技術レイヤーで分けられています。コラボレーションの範囲が定まっておらず、プラットフォームの利用が義務付けられています
• 3-4： あらゆる場所にコンポーネントチームがあります。チケット駆動の共有サービスがあり、すべての変更が複数のチームをまたぎます
• 0-2： 組織がコンウェイの法則を無視しています。プロジェクト単位で人員を頻繁に入れ替え、「全員が全員と話す」状態で、認知負荷という概念もありません

フレームワーク

1. コンウェイの法則と逆コンウェイ・マヌーバー

基本概念： 「システムを設計する組織は、その組織のコミュニケーション構造を写した構造の設計を生み出す」（Mel Conway）。組織のコミュニケーションとシステムアーキテクチャは同型であり、比喩ではなく必然的に互いを反映します。逆コンウェイ・マヌーバーはこれを活用します。望ましいアーキテクチャを決めたうえで、チームとそのコミュニケーション経路を形作り、そのアーキテクチャが自然に生まれるようにします。

有効な理由： チームが構築できるのは、調整可能なインターフェースに限られます。そのため、組織が発見できる設計の範囲は、コミュニケーション経路によって制約されます。組織を再構成すればシステムも再構成されます。コンウェイの法則に逆らえば、摩擦が恒常化し、アーキテクチャが劣化します。

主な知見：

• インターフェースはチーム間のコミュニケーションが生まれる場所に現れ、境界はコミュニケーションがない場所に現れます。システムには組織の会話が記録されます
• アーキテクチャを左右するのは組織図ではなく、実際のコミュニケーション構造（チャット、コードレビュー、会議への招待）です
• 「全員が全員と話す」状態は、絡み合ったシステムを生み出します。制約のないコミュニケーションは、制約のない結合を意味します
• 適切に設計された組織に必要なのは、チーム間のコミュニケーションを増やすことではなく、減らすことです。チームをまたぐ雑談が広範に行われているのは、健全なコラボレーションではなく、境界の設計ミスを示しています
• チーム、報告系統、採用を決める人は誰であっても、アーキテクチャ上の意思決定をしています。アーキテクトは組織を共同で設計する必要があり、組織再編にはアーキテクチャレビューが必要です
• 目標とするアーキテクチャとチーム構造が衝突した場合は、チーム構造が優先されます

適用例：

文脈	適用方法	例
目標とするアーキテクチャ	まずチームを形作り、アーキテクチャが後からついてくると想定します	疎結合なサービスを目指すなら、独立してデプロイできる、小規模で疎結合なチームを編成します
組織再編の提案	アーキテクチャ変更としてレビューします	チームの統合には、人事だけでなく、テックリードやアーキテクトも承認します
絡み合ったシステム	組織図ではなく、実際のコミュニケーションをマッピングします	チャットやレビューのグラフから、「独立している」チーム間に隠れた結合が明らかになります

2. 4つの基本的なチームタイプ

中核となる考え方： すべてのチームを4つのタイプのいずれかに分類します。ストリームアラインドチームは、ビジネス上の変化の流れを端から端まで担当する、主要なタイプであり、ほとんどのチームがこれに該当します。イネーブリングチームは、ストリームアラインドチームの能力を高めた後、次のチームへ移ります。複雑なサブシステムを担当するチームは、深い専門知識（ML モデル、コーデック、価格設定エンジンなど）を内包します。プラットフォームチームは、ストリームアラインドチームの認知負荷を軽減する、魅力的な社内プロダクトを提供します。

効果がある理由： 「API チーム」や「DevOps チーム」のような曖昧な役割定義では、どこにも属さない作業が蓄積し、連携も予測しにくくなります。明確に定義された4つのタイプに分類すれば、抜けや重複が可視化され、変化の流れに対する各チームの目的が明確になり、組織の他のメンバーが各チームに何を期待すべきかも分かりやすくなります。

主なポイント：

• ストリームアラインドチームが標準です。他の3タイプは、ストリームの負荷を軽減する場合にのみ正当化されます
• イネーブリングチームがいつまでも関与し続けるなら、依存先になっています。クローズしたチケット数ではなく、移転した能力で評価しましょう
• 複雑なサブシステムを担当するチームが正当化されるのは、真に専門性が必要な場合だけです。管理上の都合を理由にしてはいけません。ほとんどの組織では、必要なチームはゼロか1つです
• プラットフォームは、ストリームの負荷を軽減するために存在します。セルフホストするより導入が難しいなら、それはプラットフォームではなく負担です
• アンチパターン：共通サービスチームはチケットキューのボトルネックになります。「DevOps チーム」が開発と運用の間に入ると、サイロがもう1つ増えます。あらゆる場所にコンポーネントチームを置くと、すべての機能開発で多数のチームをまたぐことになります

適用例：

コンテキスト	適用方法	例
曖昧なチームの役割定義	4つのタイプから1つを選ぶ	「コアサービスチーム」→ 社内の利用者と SLA を持つプラットフォーム
高度な専門能力	シンプルなインターフェースの背後に複雑なサブシステムを置く	レコメンデーションエンジンチームが、スコアリング API を各ストリームに公開する
新しいプラクティスの導入	期間を限定したイネーブリングチーム	テスト自動化の専門家が各ストリームを8週間支援した後、離れる

参照：references/team-types.md

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

基本概念： チーム間のインタラクションは、厳密に3つのモードで行います。すなわち、コラボレーション（発見のために2つのチームが緊密に協力する）、X-as-a-Service（一方のチームが、明確なインターフェースを通じて他方のチームが提供するものを利用する）、ファシリテーション（一方のチームが、他方のチームの学習や改善を支援する）です。やり取りするチームのペアごとに1つのモードを選び、明示的に宣言してください。

効果がある理由： 組織で生じる問題の多くは、インタラクションが定義されていないことに起因します。サービスを期待しているチームが共同設計に巻き込まれたり、コーチングを期待しているチームがチケットキューに回されたりします。モードを宣言することで相互の期待が定まり、調整コストに上限を設けられ、対人関係の摩擦を有用な設計上のシグナルに変えられます。

主な知見：

• コラボレーションは発見のためのもので、コストが高くなります。境界が曖昧になり、両チームの認知負荷が増すため、期間を区切り、各チームが同時に行うコラボレーションは1つに限定してください
• X-as-a-Serviceは、発見の速さと引き換えに予測可能性を得る方法です。確立されたインターフェースには適していますが、境界がまだ定まっていない段階には適しません
• モードは意図的に移行させます。コラボレーションでインターフェースを見つけ、そのインターフェースが安定したらX-as-a-Serviceに移行してください
• 継続的な摩擦は、組織の状態を把握するためのデータです。ぎこちないコラボレーションは境界が適切でないことを示し、使いにくいサービスはプラットフォームにプロダクトとしての改善が必要であることを示します
• 一時的な変更であることを宣言したうえで、主要なプラットフォーム機能を導入するためにコラボレーションへ戻るのが標準的な方法です

適用例：

コンテキスト	適用方法	例
新しいプラットフォーム機能	まずコラボレーションし、その後X-as-a-Serviceに移行	Streamとplatformが6週間にわたってロギングAPIを共同で開発し、その後利用する
2つのチームが終わりのない会議を続けている	意図するモードを宣言	サービス関係だと合意し、定例同期をなくしてAPIを公開する
ストリーム内の機能ギャップ	ファシリテーションによる支援	支援チームが可観測性のプラクティスでペアを組み、四半期以内に支援を終了する

参照：references/interaction-modes.md

4. チームの認知負荷とチーム規模に適したソフトウェア

中核となる考え方： 責任範囲をチームの認知能力に合わせます。チームには3種類の負荷があります。内在的負荷（作業そのものが必要とするスキルやテクノロジー）、外在的負荷（ツール、環境、プロセスなど、提供の仕組みに関する負荷）、そして有効負荷（価値を生み出すドメイン思考）です。外在的負荷を最小限に抑え、内在的負荷を考慮し、有効負荷に割ける能力を確保します。そして、ソフトウェアの規模をチームに合わせ、決してその逆にしてはいけません。

効果がある理由： 負荷が能力を超えると、チームは混乱します。コンテキストの切り替え、浅いオーナーシップ、防御的な計画、リードタイムの増加、オンコールへの不安が生じます。チームが担当するドメイン数を制限すると、熟達に十分な深さのオーナーシップを保てます。また、長く存続するチームなら、グループがまとまるまでにかかる数カ月の時間を有効活用できます。

主な知見：

• 人数ではなくドメインを測ります。複雑なドメインはチームあたり1つとし、決して2つにしません。チームは単純なドメインを2〜3つ担当できます。1つの複雑なドメインを複数のチームに分割してはいけません
• 過負荷を解消する方法はチームの拡大ではなく、ドメイン数を減らすことです。ソフトウェアの規模がチームの規模を超えているなら、ソフトウェアを分割します
• チーム API を整備すると、チームを利用しやすくなります。コード、ドキュメント、オンコール、チャットチャンネル、作業上の合意事項を通じて、会議を開かなくても他のチームが連携できます
• プロジェクトごとの人員配置より、長く存続するチームが優れています。まとまったチームを解散すると、数カ月かけて築いた信頼が失われ、再びチームがまとまるまでのコストが発生します
• ダンバー数に基づくグループ編成を尊重します。チームは約5〜9人とし、チームのグループ編成では15人、50人、150人近くに自然な限界があります
• 外在的負荷は最も低コストで取り除けます。整備された開発経路、テンプレート、プラットフォームサービスにより、組織再編をせずに有効負荷へ割ける能力を取り戻せます

活用例：

状況	活用方法	例
チームが混乱を報告している	ドメイン数を数え、分類する	複雑なドメイン1つ＋単純なドメイン3つ → 単純なドメインを2つ手放す
チーム間のオンボーディングに時間がかかる	チーム API を公開する	各チームが担当者、ドキュメント、オンコール、チャンネル、依頼方法を一覧にする
プロジェクトが終了した	チームを維持し、作業を移す	まとまったチームを次の業務の流れに割り当て直す。原則として解散しない

参照：references/cognitive-load.md

5. フラクチャープレーン：チームが所有できる単位にソフトウェアを分割する

中核となる考え方： ソフトウェアを自然な境界、つまりフラクチャープレーンに沿って分割し、それぞれの部分を1つのチームが完全に所有できるようにします。デフォルトの分割軸はビジネスドメイン（DDDの境界づけられたコンテキスト）です。それ以外の分割軸には、規制コンプライアンス、変更頻度、チームの所在地やタイムゾーン、リスク、パフォーマンスの分離、テクノロジー、ユーザーペルソナがあります。

有効な理由： 1つのチームの認知負荷を超えるソフトウェアは共有所有を余儀なくされます。また、恣意的な分割やレイヤー単位の分割では、チーム間の結合が再び生まれます。一緒に変化する境界に沿って分割すれば、変更の大半を1つのチーム内に収められます。さらに、サービス境界とチーム境界が一致すれば、コンウェイの法則は不利に働くのではなく、味方になります。

主な知見：

• まずはビジネスドメインに沿って分割し、具体的な必要性（PCIの適用範囲、10倍のパフォーマンス上のボトルネック、変更頻度の不一致）がある場合に限り、別の分割軸を検討します。
• テクノロジーは通常、最も避けるべき分割軸です。フロントエンド／バックエンド／DBAに分割すると、すべての機能に3つのチームが必要になります。
• 分割案のリトマス試験として、その部分を独立したサービスやSaaSとして提供できるかを確認します。できない場合、境界から依存関係が漏れています。
• 「モノリス」はコードだけを指すものではありません。モノリシックなデータベース、密結合したリリース計画、組織全体に必須の標準化も、チームの独立性を妨げます。
• 3つのチームが所有するコードは、誰のものでもありません。すべての成果物に1つの所有者を割り当てるか、プラットフォームに切り出すか、管理責任者を定めてインナーソースとして運用してください。
• 1つのシステム内の異なる部分を、それぞれ別の分割軸に沿って分割してもかまいません。システム全体を1つの分割軸に統一する必要はありません。

用途：

コンテキスト	適用方法	例
モノリスの分解	まず境界づけられたコンテキストを特定する	注文、決済、カタログ → それぞれを3つのチーム所有サービスにする
あらゆる部分にコンプライアンス負担がある	規制の適用範囲に沿って分割する	PCIに関わるフローを、監査対象の1つのサービスとチームに分離する
変更頻度が混在している	変更頻度に沿って分割する	毎週変更される価格設定を、毎年変更される台帳から分離する

参照：references/fracture-planes.md

6. プラットフォームをプロダクトとして運営し、状況を把握して進化させる

中核となる考え方： プラットフォームを、ストリームアラインドチームを顧客とする社内プロダクトとして運営します。まずは、ストリームを加速させる最小限のもの、つまり審査済みのサービスをまとめた wiki ページでもよい「実用最小限のプラットフォーム（Thinnest Viable Platform）」から始めます。そのうえで、トポロジー全体を動的なものとして捉えます。摩擦、待ち時間、オンコール対応の兆候を手がかりに、チームの境界や連携モードを変える必要があるタイミングを把握します。

効果がある理由： ユーザーを囲い込んだ、利用を義務付けられたプラットフォームは、失敗を伝えるフィードバック経路がないため、官僚主義に陥っていきます。一方、任意の利用であれば、プラットフォームは魅力を保たなければならず、プロダクトとして規律を持って運営することで、実際のニーズを解決し続けられます。トポロジーを一度きりの組織再編として扱う組織は、プロダクトや市場の変化に伴い、コンウェイの法則との不整合に再び陥ります。

主な知見：

• プラットフォームの評価基準は、提供した機能ではなく、削減した認知負荷です。プラットフォームは大きいほどよいわけではありません
• 実用最小限のプラットフォームを徹底します。キュレーションとドキュメント（「このサービスを、この方法で使ってください」）から始め、キュレーションだけでは不十分になった領域でのみソフトウェアを開発します
• 社内の開発者は顧客です。ユーザー調査を行い、ロードマップと SLA を公開し、プロダクトの指標と同様に、利用状況と開発者エクスペリエンスを追跡します
• ストリームが離脱できる場合、プラットフォームは価値で選ばれる必要があります。利用の義務付けは、プラットフォームの失敗が深刻になるまで隠してしまいます
• シャドープラットフォーム、増加する待ち時間、繰り返し発生するチーム間の摩擦、オンコール対応の負担は、トポロジーを進化させる必要があることを示す兆候です
• 最終形となるトポロジーはありません。形式的な行事ではなく、兆候をもとに、数四半期ごとにチームの境界と連携モードを見直します

適用例：

状況	適用方法	例
プラットフォームチームの立ち上げ	プロダクトの手法を導入する	ロードマップ、社内ユーザー調査、オフィスアワー、SLA 付きのバージョン管理された API
プラットフォームの乱立	TVP を基準に見直す	ストリームが実際に使う 6 つのサービスに絞り、残りはキュレーションする
組織に再び「違和感」がある	状況を把握するレビューを行う	摩擦の記録と待ち時間のデータをもとに、意図的な境界変更を 1 つ行う

参照：references/case-studies.md

よくある間違い

間違い	失敗する理由	対策
開発チームと運用チームの間に「DevOps チーム」を作る	第三のサイロと、引き継ぎ待ちのキューが増える	セルフサービスのツールを提供するプラットフォームチーム、または能力を育てるイネーブリングチームを設置する
イネーブリングチームを恒久化する	能力が移転せず、ストリームが依存し続ける	明確な終了条件を設け、期間を限定した活動にする
プラットフォームの利用を義務付ける	囲い込まれたユーザーが失敗を覆い隠し、プラットフォームは官僚主義に陥る	利用を任意とし、プラットフォームが価値で選ばれるようにする
技術レイヤーごとにチームを分ける	すべての機能で複数チームをまたぐことになり、引き継ぎがリードタイムの大部分を占める	ビジネスドメインの分割面に沿ってチームを分け、ストリームアラインドなオーナーシップにする
プロジェクト終了時にチームを解散する	信頼関係を壊し、毎回、チーム形成・混乱期のコストを払い直すことになる	長期存続するチームを維持し、人をプロジェクトに配置するのではなく、仕事をチームに流す
共有サービスチームをチケット対応のキューにする	すべてのストリームの作業が、1 つのボトルネックを経由することになる	プラットフォームをプロダクトとして運営し（セルフサービス化）、またはイネーブリングチームに転換する
認知負荷ではなく人数でチームの規模を決める	ドメインが多すぎたり、複雑すぎたりすれば、大規模なチームでも混乱が続く	ドメインを数えて分類し、1 チームあたり複雑なドメインは最大 1 つにする
連携モードを暗黙のままにする	期待が食い違い、調整のための会議が増殖する	チームのペアごとにモードを明示し、意図的に見直して進化させる

クイック診断

質問	いいえの場合	対応
各ストリームに沿ったチームは、通常の変更を引き継ぎなしで提供できますか？	チーム間のキューによってフローが滞っています	ビジネス変更をエンドツーエンドで担える単位にチームを再編します
すべてのチームを4つのタイプのいずれかとして特定できますか？	曖昧な役割が、担当者のいない作業を生み出します	各チームを分類し、適合しないチームは転換または解散します
依存関係にあるチームの各ペアについて、インタラクションモードが明示されていますか？	期待の不一致によって摩擦が生じています	ペアごとに、コラボレーション、X-as-a-Service、または促進のいずれかを明示します
各チームが担当するドメイン数は、認知負荷の目安の範囲内ですか？	混乱、浅いオーナーシップ、提供の遅れが生じています	ドメインを再割り当てし、複雑なドメインは各チーム最大1つにします
サービスとリポジトリの境界はチームの境界と一致していますか？	コンウェイの法則との不整合が生じ、共有オーナーシップが広がっています	フラクチャー・プレーンに沿って再分割し、各成果物にオーナーを1人置きます
プラットフォームの利用は任意で、削減できた負荷が測定されていますか？	義務化によって、プラットフォームの問題が覆い隠されています	プラットフォームをプロダクトとして運用し、自発的な導入とDevExを追跡します
イネーブリングの取り組みには期限と終了条件が設定されていますか？	学習が進まず、恒久的な依存に置き換わっています	事前に終了日と能力移転の目標を設定します
トポロジーを把握し、進化させるための定期的な仕組みがありますか？	システムや市場の変化に伴い、設計が劣化しています	摩擦、待ち時間、オンコールの兆候を四半期ごとに見直します

参考資料

• "Team Topologies: Organizing Business and Technology Teams for Fast Flow" Matthew Skelton、Manuel Pais 著
• "Accelerate: The Science of Lean Software and DevOps" Nicole Forsgren、Jez Humble、Gene Kim 著
• "The Mythical Man-Month: Essays on Software Engineering" Frederick P. Brooks Jr. 著

著者について

Matthew Skelton は、ソフトウェア組織における迅速なフローを専門とするコンサルティング会社 Conflux の創設者であり、Team Topologies の共著者です。Manuel Pais は、チーム間のインタラクションとデリバリーの実践を専門とする独立系のIT組織コンサルタント兼トレーナーです。2人はともに、変化を迅速かつ持続的にフローさせることを最適化する、チームを中心とした組織設計に取り組んでいます。