組織図では担当が分かれているのに、一つの機能を公開するまで何チームもの承認や引き継ぎが必要になる。共通基盤を使うための依頼が積み上がり、開発チームが待ち続ける。こうした問題は、人数や努力よりもチーム境界と関わり方に原因があるかもしれません。
チームトポロジー（Team Topologies）は、価値を届ける流れとチームが扱える認知負荷を基準に、組織の形を考えるアプローチです。4つの基本的なチームタイプと3つのインタラクションモードを使い、誰が何を持ち、チーム同士がどの期間、どの深さで関わるかを整理します。
名称だけを部署へ貼り付けても、依存関係は変わりません。ストリームに沿ったチームが、日常的な他チームの調整なしに価値を届けられるかを中心に考え、専門支援や基盤を必要な形で提供します。
この記事では、4つのチームタイプ、3つの連携方法、認知負荷の見方、現状の組織を見直す手順を解説します。主にソフトウェア開発組織の考え方ですが、複数チームが一つの価値提供に関わる業務にもヒントがあります。
この記事を読むと次のことがわかります
価値の流れと認知負荷からチーム境界を考える
従来の組織図は、開発、テスト、運用、セキュリティなど専門分野ごとの管理には便利です。しかし顧客へ一つの価値を届ける流れが部署を横断すると、引き継ぎ、待ち時間、優先順位の衝突が増えます。
チームトポロジーでは、価値の流れを中心にチームを置き、そのチームが自律して扱える範囲へ責任を整えます。同時に、覚える技術や業務知識が多すぎないよう、他のチームが基盤や専門支援を提供します。
認知負荷には、課題そのものに必要な負荷、環境や道具の使いにくさが生む負荷、学習によって能力を高める負荷という見方があります。基盤や支援で減らしたいのは、価値へ直接つながらない設定作業や複雑な手続きです。業務知識まで外へ追い出さないようにします。
価値の流れを選ぶとき、既存システムの境界をそのまま採用すると、技術都合の分割を固定する可能性があります。顧客が受け取る結果、事業の能力、変更を独立して進めたい範囲から考え、システム境界が妨げるなら改善対象にします。
チームの大きさと安定性も前提になります。頻繁に人が入れ替わる大規模な作業グループでは、共通理解と所有感を保ちにくくなります。長く協働できる小さなチームへ明確な使命を渡し、必要な専門家との関係を設計します。
チーム間の通信構造がシステム設計へ影響するというコンウェイの法則も背景にあります。望むアーキテクチャへ合わせてチーム境界を考える逆コンウェイ戦略は有用ですが、組織図を変えるだけで技術的な結合が消えるわけではありません。双方を段階的に整えます。
組織図より顧客へ届くまでの流れを見る
企画から公開、運用までの工程を並べ、どこで別チームの回答や作業を待つかを確認します。引き継ぎ回数だけでなく、依頼の往復や優先順位調整も見ます。
価値の流れは製品単位とは限りません。特定の顧客層、業務能力、継続的なサービスなど、独立して改善できる単位を検討します。
チームの認知負荷には扱える上限がある
チームが担う業務領域、技術、運用、規制、利用ツールが増え続けると、学習と切り替えに時間を取られます。すべてを一つのチームへ任せることは、自律性ではなく過負荷になる場合があります。
負荷を単純な作業量だけで見ず、問題の複雑さ、変更頻度、暗黙知の多さを確認します。支援や基盤で減らせる負荷と、価値提供のためチーム内に残す知識を分けます。
チーム境界は固定せず学習に合わせて進化させる
市場、製品、技術が変われば、適した境界も変わります。最初から完璧な組織図を作るのではなく、流れの遅れや負荷を観察し、境界と関わり方を調整します。
組織変更を頻繁に行うこととは違います。一定期間試し、リードタイム、待ち時間、チームの負担などから効果を確かめます。
名称変更より責任・権限・依存の変化を確認する
既存部署をストリームアラインドと呼び直しても、承認権限や運用責任が別部署に残れば、自律性は高まりません。名称ではなく、仕事を完了するために必要な外部調整を見ます。
変更時には、担当範囲、意思決定権、利用できる基盤、支援の受け方を一緒に設計します。
4つのチームタイプで価値提供と支援の役割を分ける
4つのチームタイプとは次の通り。
- ストリームアラインドチーム
- イネーブリングチーム
- コンプリケーテッドサブシステムチーム
- プラットフォームチーム
これらのチームタイプは、部署を分類するためのものではありません。価値の流れを担うチームを中心に、専門知識、複雑な領域、共通基盤をどのように支えるかを考えるためのパターンです。
一つのチームが時期によって異なる役割を持つこともありますが、同時に多くを担うと期待が曖昧になります。主な責任と、他チームへ提供する価値を明らかにします。
ストリームアラインドチームを増やすほど、共通機能の重複が起きる可能性があります。小さな重複を直ちに禁止するのではなく、各チームの自律性と保守負担を比べます。安定した共通ニーズが見えたら、プラットフォームへ育てる選択があります。
プラットフォームの利用者は社内の開発者であっても、顧客として扱います。利用開始までの時間、文書を見て自己解決できる割合、障害通知のわかりやすさを測ります。機能数だけを増やすと、プラットフォーム自体が新しい認知負荷になります。
イネーブリングチームの支援テーマは、相手チームの依頼だけで決めるとは限りません。複数チームに共通する障害を観察し、優先度を提案できます。ただし、標準を一方的に押し付けず、現場の制約と学習目標を合意してから伴走します。
4タイプに当てはまらない管理、人事、営業などの部署を無理に分類する必要はありません。チームトポロジーのパターンは、ソフトウェアを継続的に届ける流れを改善するために使い、組織全体のあらゆる機能を説明する万能分類として扱わないようにします。
ストリームアラインドチームは価値の流れを端から端まで担う
ストリームアラインドチーム（Stream-aligned Team）は、顧客や利用者へ継続的に価値を届ける流れへそろえたチームです。設計、開発、テスト、運用など、成果を届けるための能力をできるだけチーム内に持ちます。
何でも自前で作るのではありません。共通基盤や専門支援を利用しながら、日常的な引き継ぎなしに変更を進められる状態を目指します。
イネーブリングチームは不足する能力の獲得を支援する
イネーブリングチーム（Enabling Team）は、ストリームアラインドチームが新しい技術や方法を身につけるのを期間限定で支援します。代わりに作業を請け負い続けるのではなく、相手チームが自走できることを目標にします。
支援には、ペア作業、研修、設計相談、試行の伴走などがあります。開始時に獲得したい能力と終了条件を決めます。
コンプリケーテッドサブシステムチームは高度な専門領域を持つ
コンプリケーテッドサブシステムチーム（Complicated Subsystem Team）は、高度な数学、映像処理、デバイス制御など、専門性が高く他チームが抱えると認知負荷が大きい部分を担当します。
単に難しい作業を集めるチームではありません。明確な境界と利用方法を用意し、他チームが内部の専門知識をすべて理解しなくても使えるようにします。
プラットフォームチームは使いやすい共通サービスを提供する
プラットフォームチーム（Platform Team）は、開発、配備、監視、認証などの共通機能を内部サービスとして提供し、ストリームアラインドチームの負荷を下げます。
利用を強制するだけの基盤ではなく、利用者である開発チームが自分で使えることが重要です。文書、セルフサービス、信頼性、問い合わせ体験も製品として改善します。
3つのインタラクションモードで関わる深さと期間を決める
チームタイプだけでなく、チーム間の関わり方、つまりは連携方法を明示するのがインタラクションモードです。同じ二つのチームでも、新機能の探索期は密に協働し、安定後はサービスとして利用するなど、時間とともにモードが変わります。
インタラクションモードには次の３つがあります。
- コラボレーション
- エックス・アズ・ア・サービス
- ファシリテーティング
関わり方が曖昧だと、支援のつもりが恒久的な依頼窓口になったり、サービス利用のはずが毎回個別調整になったりします。開始時に目的と終了条件を決めます。
コラボレーション中は、成果物の所有者が曖昧になりやすいため、期間終了後にどのチームが運用と意思決定を持つかを先に決めます。共同作業が終わった後も全員の承認が必要なら、依存関係は残ったままです。
サービスとして提供する場合は、インターフェースだけでなく、サービスレベルと利用者の責任を明らかにします。提供側が保証する範囲、利用側が設定する範囲、障害時の連絡方法をそろえると、個別の問い合わせを減らせます。
ファシリテーティングの終了時には、相手チームが実際の課題を自力で解けるか確認します。資料を渡したことや研修を開催したことだけを完了条件にせず、次の実践を観察し、必要なら短いフォローを行います。
モードはチーム同士の合意だけでなく、関係者にも共有します。コラボレーション期間中は通常より対応量が増えること、サービス化後は窓口が変わることを伝えます。周囲の期待が以前のままでは、決めた関わり方へ移行しにくくなります。
コラボレーションは二つのチームが密に探索する
コラボレーション（Collaboration）は、複雑な課題や新しい領域で、二つのチームが一定期間、共同で設計と実行を行うモードです。知識を早く交換できますが、双方の集中力を多く使います。
恒久的な会議体にせず、対象課題、期間、成果を決めます。課題が理解できたら別のモードへ移ります。
エックス・アズ・ア・サービスは明確な窓口から利用する
エックス・アズ・ア・サービス（X-as-a-Service）は、あるチームが提供する機能を、他チームが明確なインターフェースから利用するモードです。プラットフォームやサブシステムでよく使われます。
利用のたびに担当者へ依頼しなくても済むセルフサービスが理想です。仕様、品質目標、変更通知、問い合わせ方法を整えます。
ファシリテーティングは能力獲得を一時的に助ける
ファシリテーティング（Facilitating）は、専門知識を持つチームが、相手チームの学習と障害解消を支えるモードです。イネーブリングチームが主に使います。
成果を納品するのではなく、相手が次回から自分で実行できることを目指します。支援後の確認とフォロー期間も決めます。
一つの依存関係に複数モードを同時適用しない
同じテーマで、共同開発なのかサービス利用なのか、支援なのかが曖昧だと、責任と優先順位が混乱します。主なモードを一つ選び、必要なら期間を分けます。
たとえば最初の一か月はコラボレーション、その後はサービス利用へ移すという設計ができます。切り替え条件を可視化します。
現在の依存関係から小さく組織設計を見直す
全社組織を一度に変える前に、一つの価値の流れを選びます。顧客要求から本番利用までを追い、待ち時間、引き継ぎ、必要な知識、繰り返す依頼を可視化します。
そこで、ストリームチームへ移す責任、サービス化する共通機能、期間限定で支援する能力を考えます。人の異動だけでなく、権限、ツール、文書、運用責任も変更対象です。
現状を描くワークショップには、管理職だけでなく実際に依頼と引き継ぎを行う担当者を含めます。公式フローにはないチャット相談、手作業、非公式な承認が待ち時間を支えていることがあるためです。
変更案には、移行中の責任も必要です。新チームへ運用を渡す日、既存チームが支援を続ける期間、未移行の案件を誰が持つかを決めます。新旧の境界が重なる期間を放置すると、二重対応や責任の空白が生まれます。
評価制度が個別部署の成果だけを重視していると、価値の流れを優先する行動と衝突する可能性があります。組織図だけでなく、目標、予算、優先順位の決め方も確認し、望むチーム間関係を阻む仕組みを見直します。
価値の流れと待ち時間を一つ選んで描く
最近公開した機能や顧客対応を一件選び、開始から完了まで関わったチームと待ち時間を並べます。理想の業務フローではなく、実際に起きた往復を記録します。
最も長い待ち時間や繰り返す調整を一つ選び、境界の問題か、優先順位の問題か、能力不足かを見ます。
チームが抱える認知負荷を対話で把握する
担当サービス数、技術スタック、運用当番、規制、問い合わせなどを並べ、学習が追いつかない領域を聞きます。単純な件数ではなく、変更頻度と理解の深さを確認します。
負荷を減らす案として、範囲を分ける、基盤へ移す、専門支援を受ける、不要な仕組みを廃止する方法があります。
一つの関係だけモードと終了条件を試す
毎回個別依頼している基盤機能をサービス化する、専門チームが二か月だけ伴走するなど、小さな実験を選びます。提供側と利用側の双方で成功条件を決めます。
待ち時間、問い合わせ回数、変更の完了時間、チームの負担を前後で比べます。数字だけでなく、必要な会話の質も振り返ります。
組織変更を人の評価や責任追及にしない
依存が多いことを特定チームの非協力と決めつけず、現在の構造がどの行動を促しているかを見ます。優先順位や権限が別なら、協力だけでは解決しません。
役割変更による不安やキャリアへの影響も対話します。新しい境界に必要な技能と学習時間を用意し、名称変更だけで期待を増やさないようにします。
チームの名称ではなく価値の流れと関わり方を設計しよう
チームトポロジーは、価値を届ける流れとチームの認知負荷を基準に組織を考えるアプローチです。ストリームアラインド、イネーブリング、コンプリケーテッドサブシステム、プラットフォームという4つのチームタイプを使います。
チーム間の関わり方は、コラボレーション、エックス・アズ・ア・サービス、ファシリテーティングの3モードで明示します。目的、期間、終了条件を決め、恒久的な調整を増やさないことが大切です。
まず一つの価値の流れから、実際の待ち時間と認知負荷を確認しましょう。名称を変えるのではなく、責任、権限、基盤、支援方法まで整え、小さく試して結果から境界を更新します。
今回のポイント
