チーム・オブ・チームズ

英語名 Team of Teams
読み方 チーム オブ チームズ
難易度
所要時間 2〜4時間(初期設計)
提唱者 Stanley McChrystal (Team of Teams, 2015)
目次

ひとことで言うと
#

大組織を小さなチームのネットワークとして機能させ、各チームが自律的に動きながらも全体として協調するアジリティを実現するフレームワーク。元米軍特殊作戦司令官スタンリー・マクリスタルが、対テロ作戦で培った組織変革の知見を体系化した。

押さえておきたい用語
#

押さえておきたい用語
共有意識(Shared Consciousness)
組織全体が同じ状況認識を持つこと。情報の透明性と定期的な共有によって、各チームが全体最適の判断を自律的に下せる状態を指す。
権限移譲された実行(Empowered Execution)
現場のチームが上層の承認を待たずに自ら意思決定して行動すること。共有意識が前提となり、信頼のもとで権限が委ねられる。
リエゾン(Liaison)
チーム間を橋渡しする連絡担当者のこと。各チームから他チームへ派遣され、情報の流れと相互理解を促進する役割を担う。
O&Iフォーラム(Operations & Intelligence Forum)
全チームが参加する定例の状況共有会議。マクリスタルの部隊では毎日90分のビデオ会議で7,000人以上が情報を共有していた。

チーム・オブ・チームズの全体像
#

チーム・オブ・チームズ:小チームのネットワークで大組織を動かす
小チームのネットワーク構造共有意識SharedConsciousnessチームA自律実行チームB自律実行チームC自律実行チームD自律実行リエゾン情報共有チーム間リエゾン
チーム・オブ・チームズ導入フロー
1
小チーム編成
4〜8名の自律チームを構成する
2
リエゾン配置
チーム間に橋渡し役を派遣する
3
共有意識の構築
O&Iフォーラムで全体の透明性を確保
権限移譲された実行
現場が自律的に判断し素早く動く

こんな悩みに効く
#

  • 組織が大きくなるにつれて意思決定が遅くなり、市場の変化についていけない
  • 部門間のサイロが深く、チーム同士が何をしているか互いに把握できていない
  • 情報が上層部に集中し、現場が動くには常に承認待ちが発生する
  • 小さかった頃のスピード感を、規模が大きくなった今の組織でも取り戻したい

基本の使い方
#

小チームを編成する

組織を4〜8名の小さなチームに再編する。各チームが明確なミッションを持ち、チーム内で意思決定を完結できるようにする。

  • 既存の部署をそのまま流用するのではなく、ミッション単位で切り直す
  • チームサイズが大きすぎると意思疎通コストが跳ね上がるので、8名を上限にする
  • 各チームにオーナーシップのある目標(OKRなど)を持たせる
リエゾンを配置する

各チームから1名ずつを他のチームに派遣し、チーム間の情報の流れを作る。

  • リエゾンは「出向」ではなく「橋渡し」。元のチームにも所属したまま、定期的に他チームのミーティングに参加する
  • 人選はコミュニケーション能力が高く、全体最適の視点を持てる人が望ましい
  • リエゾンの役割を「情報伝達」と「相互理解の促進」に明確化する
O&Iフォーラムを設計する

全チームが参加する定例の状況共有会議を設ける。情報の透明性を組織全体に広げる。

  • 頻度は週1〜毎日。変化の速い環境では毎日が望ましい
  • 各チームが2〜3分で「今何をしていて、何に困っていて、次に何をするか」を共有する
  • リーダーは「指示を出す場」ではなく「文脈を与える場」として運営する
権限を現場に移譲する

共有意識が醸成された段階で、意思決定権限を現場チームに委ねる

  • 「承認が必要な範囲」と「現場で即断してよい範囲」を明文化する
  • 権限移譲は一気にではなく、小さな領域から段階的に広げる
  • 失敗を罰するのではなく、学習として組織に還元する仕組み(AARなど)をセットで導入する

具体例
#

例1:150名のSaaS企業がリリースサイクルを3倍速にする

従業員150名のSaaS企業。プロダクトチーム、営業、カスタマーサクセス、インフラの4部門が縦割りで動いていた。機能リリースには部門横断の承認が必要で、企画から本番デプロイまで平均12週間かかっていた。

まず、プロダクト領域ごとに6名前後のスクワッドを8つ編成。各スクワッドにエンジニア、デザイナー、CSメンバーを配置し、「顧客課題の発見からリリースまで」を1チームで完結できる体制にした。

次に、スクワッド間にリエゾンを配置。インフラチームからは各スクワッドに1名ずつ技術アドバイザーとして参加させた。毎週月曜に全スクワッドが参加する30分のO&Iフォーラムを開始し、各チームが「今週のゴール・ブロッカー・学び」を共有。

3か月後、リリースサイクルは12週 → 4週に短縮。顧客からの機能要望への初回応答時間も平均18日 → 5日に改善した。CTOの承認待ちが解消されたことが最大の要因だった。

例2:病院グループが救急搬送の受入率を改善する

5つの病院を傘下に持つ医療グループ。救急搬送の受入率が**68%**にとどまり、「たらい回し」が問題になっていた。各病院が独立して空床管理をしており、グループ全体の空き状況をリアルタイムで把握できなかった。

各病院の救急部門を1チームと見立て、チーム・オブ・チームズの構造を導入。まず、5病院の救急担当者が参加する毎朝15分のO&Iフォーラム(ビデオ会議)を開始。各病院が「空床数・対応可能な診療科・当日の手術予定」を共有した。

さらに、各病院から1名ずつリエゾンナースを選出し、週1回は他の病院で半日勤務する「交換勤務」を実施。互いの現場を知ることで、「この症例ならB病院が受けられる」という判断が現場レベルでできるようになった。

6か月後、グループ全体の救急受入率は68% → 89%に改善。搬送先決定までの平均時間も23分 → 11分に短縮され、地域の消防本部からも高評価を受けた。

例3:グローバル製造業が新製品開発のリードタイムを半減させる

日本・アメリカ・ドイツに拠点を持つ製造業(社員数2,800名)。新製品の開発リードタイムが18か月と競合の2倍近くかかっていた。原因は、各拠点が設計→試作→品質検証をシーケンシャルに進め、拠点間の引き継ぎに毎回4〜6週間のロスが発生していたこと。

製品カテゴリごとに8〜10名の多拠点スクワッドを5つ編成。各スクワッドに日米独のエンジニアを混在させ、設計から品質検証まで並行して進める体制にした。

毎日のO&Iフォーラムは時差を考慮して日本時間17時(米国朝、ドイツ昼)に設定。15分で各スクワッドが進捗とブロッカーを共有。リエゾンとして各拠点の品質管理者が全スクワッドのSlackチャンネルに常駐し、リアルタイムで技術判断をサポートした。

1年後、新製品の平均開発リードタイムは18か月 → 9か月に半減。拠点間の引き継ぎロスがほぼゼロになり、3つの製品ラインで同時開発が可能になったことで、年間の新製品投入数も3品目 → 7品目に増加した。

やりがちな失敗パターン
#

  1. 共有意識なしに権限だけ移譲する — 現場が全体像を知らないまま自律的に動くと、各チームが局所最適に走りバラバラになる。権限移譲は共有意識の構築が必ず先
  2. O&Iフォーラムを報告会にしてしまう — リーダーへの「報告」になると、チーム間の横の情報共有が起きない。フォーラムの主語は「チーム→チーム」であって「チーム→上司」ではない
  3. リエゾンを形だけ置く — リエゾンに権限も時間も与えず名ばかりの兼任にすると、橋渡し機能が働かない。業務時間の**最低20%**はリエゾン活動に充てるルールを設ける
  4. 組織図だけ変えて文化を変えない — チーム・オブ・チームズは構造だけでなく、信頼と透明性の文化が土台。「失敗を隠す」「情報を囲い込む」カルチャーが残ったままでは機能しない

まとめ
#

チーム・オブ・チームズは、小チームが持つ機動力を大組織でも発揮するための構造設計である。共有意識で全体像を揃え、リエゾンでチーム間をつなぎ、O&Iフォーラムで透明性を担保したうえで、権限を現場に移譲する。ポイントは**「情報を流してから権限を渡す」**という順序を守ること。構造を変えるだけでなく、信頼と透明性のカルチャーを同時に育てることで、大組織でもスタートアップのようなスピードが手に入る。