AI を導入する前に、まずチームをバリューストリームで再編する

企業に AI を持ち込む前に、ツール選びやモデル選びよりずっとリターンの大きいことが一つある。まずバリューストリーム沿いに技術チームを再編することだ。 私はこれまで、AI ツールを買い、モデルをデプロイし、人にも研修を受けたのに、納品は相変わらず遅く、現場はかえって疲弊している企業をいくつも見てきた。根本原因はほぼ一つに絞れる。AI が弱いのではなく、チームが技術層（フロントエンド、バックエンド、アルゴリズム、運用保守、セキュリティ）で間違って切られていること。エンドツーエンドの機能一つが四つ五つのチームをまたぎ、引き継ぎのたびに何かが落ちる。要件が少し、コンテキストが少し、責任感が少し。チームの境界を正しく直して初めて、AI を拡大する土壌ができる。境界が歪んでいれば、AI は間違った構造の上で借金を加速して積み上げるだけだ。

本稿は実践可能な組織設計手法、Team Topologies（Skelton & Pais, 2019）を提示する。核心は三つ。バリューストリームでチームを切ること、各チームの認知負荷（cognitive load）をにらむこと、内部プラットフォームをプロダクトとして扱うこと。以下、製造業の実シーンで解剖していく。

ある製造業の CIO（事例は実プロジェクトを匿名化したもの）が私にこう語った。スマート品質検査の AI 機能をリリースしたが、技術は難しくなかった。カメラで瑕疵を識別し、モデルは既製品を使う。難しかったのは納品だ。フロントエンドチームが画面を作り、MES チームが工単の流れを改め、アルゴリズムチームがモデルをデプロイし、運用チームがサーバーを管理し、その上セキュリティチームが審査を入れる。一つの機能が 5 チームをまたぎ、4 回の正式な引き継ぎを経て、3 ヶ月も引きずった。 どのチームもサボっていたわけではない。ただ、引き継ぎのたびに何かが落ちた。

チームの切り方が納品スピードを決める

一、コンウェイの法則は半分しか語らない

コンウェイの法則はこう説く。システムのアーキテクチャは、それを作るチームのコミュニケーション構造を映し出す。 フロントエンドとバックエンドでチームを切れば、前後端分離のシステムができる。チームがどうコミュニケーションするかで、システムがどう育つかが決まる。この法則は実証で繰り返し検証されてきた。

だがコンウェイは「こうなる」と言っただけで、良いアーキテクチャが自ずと育つようにチームをどう設計すべきかは語らなかった。この隙間を埋めたのが、2019 年の Skelton と Pais の『Team Topologies』だ。チームには四つの基本タイプと三つの相互作用方式があり、更に一つの貫く原則がある——認知負荷をにらむこと。

二、四つのチーム：再編の選択肢として使え、用語として暗記するな

私はこの四つのチームを「再編時に呼び出せる選択肢」として説明する。定義を暗記させるためではない。

ストリームチーム（stream-aligned team）——組織の主力であり、大多数を占めるべきもの（原書の表現は most、具体比率は示していない）。 「ストリーム」とは持続するバリューストリームのことだ。ストリームチームはこの流れの一段をエンドツーエンドで担う。要件を理解し、開発し、リリースし、運用する。あるチームがストリームチームかどうかは一つで判定できる。外部チームに依存せず、ユーザーに価値を届けられるか。あの CIO に戻ろう。もしスマート品質検査機能が一つの「品質検査ストリームチーム」に帰属していたら——そこにはフロントエンドに詳しい者、MES 連携に詳しい者、アルゴリズムデプロイに詳しい者、運用に詳しい者が揃っている——この機能は一つのチームで完遂し、引き継ぎはゼロになる。これが本来あるべき姿だ。

大企業で最もよくある問題は、システムはエンドツーエンドなのに、チームが技術層の横断面に切られていることだ。エンドツーエンドの納品のたびに、複数チームの報告境界を貫通しなければならない。業界を変えても病根は同じだ。金融の与信リスク管理機能を例に取れば、App チーム、コアシステムチーム、リスクモデルチーム、データチームの四つをまたぐ。電商と通信も同じ痛みを別の言葉で抱えている——販促機能は商品、取引、マーケティング、倉庫をまたぎ、料金プラン変更はチャネル、課金、CRM、ネットワークをまたぐ。横に切ったチームで縦のバリューストリームを受けると、必然的に至る所で引き継ぎが生じる。

プラットフォームチーム——ストリームチームのために道を敷く。 プラットフォームチームはインフラ、CI/CD、共通サービスを提供し、ストリームチームが「セルフサービス」で能力を取り出せるようにする。毎回チケットを出して頼み事をしなくて済むように。判定基準は一つだ。内部プラットフォームをプロダクトとして運営しているか（ユーザーがいて、ロードマップがあって、SLA がある）、それともチケットを請け負う「内製下請け」に成り下がっているか。大企業の IT 部門の多くは後者のデッドループに陥っている。プラットフォームを作っても誰も使わず、業務チームが迂回して各々勝手に作り、プラットフォームチームが下請けに退化する。Netflix の Spinnaker（継続的デリバリー）、Spotify の Backstage（開発者ポータル）は、プラットフォームをプロダクトとして運営した範例だ。この二つはよく混同される。Spinnaker は Netflix、Backstage は Spotify。報告書で間違えないように。

イネイブリングチーム（enabling team）——ストリームチームの底上げを図り、目標は自らを失業させること。 業務納品を直接担うのではなく、ストリームチームの能力を引き上げる。新技術導入のコーチ、DevOps 変革のファシリテーター、セキュリティ・コンプライアンスの顧問。ストリームチームとの関係は師匠と弟子であって、発注者と受注者ではない。大企業にとって、外部の伴走コンサルが最も演じるべき役割はまさにこれだ。能力移転を行うことであって、長期的な依存を作らないこと。

複雑サブシステムチーム——深い専門性が必要な硬い骨を片付ける。 あるサブシステムが極めて深い専門性を要する時（リスクエンジン、推薦アルゴリズム、暗号、動画コーデック）、独立して専門家チームに任せ、ストリームチームの認知負荷を爆発させない。このチームは少ないべきだ。組織から複雑サブシステムチームがたくさん湧き出るなら、それは往々にして本来プラットフォームであるべき能力を煙突に細分してしまった証拠だ。

チームの類型を分けるだけでは足りない。チーム間の付き合い方も定義する。Team Topologies は三つの相互作用を提示する。協調（collaboration）は二つのチームが深く共に取り組むもので、不確実な新シーンに適すがエネルギーを食い、短期間しか使えない。X-as-a-Service は一方のチームが能力をプロダクトとして提供し、もう一方がセルフサービスで消費する、最も効率的で常態であるべき方式。促進（facilitating）はイネイブリングチーム専用だ。組織設計が解くべき核心問題は、できるだけ多くの相互作用を「X-as-a-Service」にすることだ。長期にわたり「協調」に頼るなら、プラットフォーム化ができていない証拠だ。あの CIO の場合で見る。品質検査ストリームチームとプラットフォームチームの間は X-as-a-Service であるべきで、プラットフォームがセルフサービスの CI/CD 入口を提供し、品質検査チームが自ら使う、一声かける必要はない。もし毎回のデプロイでプラットフォームチームを引っ張り出して「協調」の会議を開くようなら、それはプラットフォーム化が行き届いていないのであって、問題は態度ではなく、プラットフォームがプロダクトとして扱われていないことにある。

健康な組織：四つのチームの分業

三、なぜ「人を足す」と「プロセスを足す」でも救えないのか：認知負荷

Team Topologies の最も過小評価されている貢献は、認知負荷（cognitive load）を組織設計の中心に据えたことだ。

一つのチーム（5〜8 人）の認知負荷には限界がある。十数個の無関係なシステムを同時に保守させ、六つ七つの上流とやり取りさせ、更に三つの新フレームワークをこなさせれば、必ず過負荷になる。結果は品質低下、納品遅延、バーンアウトだ。

これがあの CIO のもう一つの謎を説明する。「3 人足したのに、なぜ依然として遅いのか。」根っこは、この一団が同時に無関係な仕事を多すぎる背負っていることだ。人は実は足りている。人を足すことは、同じ混乱の中でより多くの者を空回りさせるだけだ。プロセスを足すのは更に悪い。プロセスはもう一層の認知負荷を食い、もともと仕事をできた者にフォーム記入、会議、決裁回しにより多くの時間を費やさせる。

大企業が最も削りやすい肥やしは、組織が自ら加えた負担である——チーム間の押し付け合い、頻繁なコンテキスト切り替え、決裁回し。これを削るのに新しい技術は一切要らない。ただ「余計なことを増やさない」だけで済む。

具体例を出そう。ある銀行のコアシステムチームの責任者。チームは 7 人で、同時にリスク管理、カスタマーサポート、監督報告、マーケティングの四つの上流とやり取りし、互いに無関係な三つのモジュールを保守している。毎日、チーム間の承認回し、すり合わせ、コンテキスト切り替えの処理だけでチームの精力のほぼ半分を食う。こういうチームにどれほど良い AI ツールを押し込んでも使いこなせない。新しいことを学び、プロセスを変える余分な認知帯域が残っていないからだ。救うにはまず負担を減らす。無関係なモジュールを外に切り出し、チームを一本のバリューストリームだけに責任を持たせる。

Amazon の「ツーピザチーム」はコミュニケーションコストを語る。人が増えると、メンバー間のコミュニケーション経路数（n(n-1)/2）が跳ね上がり、意思決定が遅れる。Team Topologies はもう一層深い説明を加える。8 人前後を超えると、認知負荷も管理できなくなる。組織設計が真にやっていることは、職能で報告線を引くのではなく、認知負荷でチームを分け、各チームの負担が耐えられる範囲に収まるようにすることだ。

大企業への一言健康診断。あなたの「最も忙しい人」は、同時に 5 件以上の無関係な仕事を背負っていないか。もしそうなら、何人足し、どれだけプロセスを足しても救えない。切り直すしかない。

四、どう動くか：逆コンウェイ操作

これが最も操作性の高い一手だ。先にアーキテクチャ図を描いてからチームを変えるのではない。先にチーム構造を変え、アーキテクチャを自ずと望む形に育てるのだ。

伝統的なやり方は、目標とするアーキテクチャ図を描き（「マイクロサービスにするぞ！」）、チームにそれに沿って変えるよう求めることだ。これはほぼ常に失敗する。既存のチーム構造がアーキテクチャを常に自分の形に引き戻すからだ。コンウェイの法則が働いている。

逆コンウェイ操作は逆だ。まずバリューストリーム沿いにチームを再編し（ストリームチームを画し、プラットフォームチームを建て）、チーム境界を将来のサービス境界にする。するとアーキテクチャは自ずと合理的なサービス分割に向かう。チーム間は自然に API で通信し、データベースを一つ共有することはなくなるからだ。

あの CIO に戻る。私は彼にマイクロサービスフレームワークを先に選ばせなかった。もっと素朴なことをやらせた。「品質検査」というストリームを一つのチームとして独立させ、従来のフロントエンドチーム、MES チーム、アルゴリズムチーム、運用チームから各一人ずつ抽出し、6 人の品質検査ストリームチームを作り、品質検査機能をエンドツーエンドで担わせた。三週間のうちに三つのことが起きた。第一週、彼らは従来 MES 工単の流れに引っかかっていた一段が、実はアルゴリズムチームの介入を必要としないことに気づき、チーム内部で直した。第二週、彼らはモデルのデプロイを「運用チーム待ちの列に並ぶ」からチーム内セルフサービスに変えることを自ら決めた。プラットフォームチームが CI/CD のセルフサービス入口を開いてくれたからだ。第三週、彼らは最初のエンドツーエンド小機能をリリースし、いかなるチーム境界もまたがなかった。人は増やさず、ツールも変えず、横に切った層を縦のストリームに立て直した。 納品サイクルが 3 ヶ月から 3 週間に戻った。思いがけない収益もあった。このチームは改善提案を自ら出し始めた。彼らが初めて自分たちのストリームの全貌をはっきり見、結果に全責任を負うようになったからだ。かつて 5 チームをまたいでいた時、誰一人として品質検査ストリーム全体に責任を感じていなかった。

製造業事例：品質検査機能、再編の前後

意思決定者にとって、これは直感に反するがレバレッジの大きい結論だ。アーキテクチャ図で繰り返し悩むより、組織図にメスを入れるほうがいい。 アーキテクチャを変えるのは結果であり、組織を変えるのがレバレッジだ。

誰が使っているか

  • 銀行業（TT 公式重点業界 + 強規制の参照）：teamtopologies.com には専門家コラム『When DORA metrics meet governance in banking』がある。そこで引用される DORA 研究の結論は硬い。外部承認（external approvals）はリードタイム、デプロイ頻度、復旧時間と負の相関がある——チーム間の事後承認が増えるほど、納品は遅く、障害復旧も遅くなる。これはまさに本稿の主張を裏付ける。コンプライアンス要件をストリームチームに内蔵し、承認を前倒しにし、事後のチーム間承認回しにしないこと。ClearBank などの英国デジタル銀行は公式生態系で繰り返し言及され、銀行業は「強規制下でバリューストリーム再編を行う」最も参照性の高いシナリオだ。
  • Zalando（EC、プラットフォームをプロダクトとする範例）：内部開発者プラットフォームをストリームチームのセルフサービス能力とし、TT コミュニティで頻繁に引用されるプラットフォーム化の標本。
  • AutoTrader UK（自動車分類プラットフォーム）：TT 公式が繰り返し引用する実際の採用事例。バリューストリームでの再編 + 内部プラットフォームのプロダクト化。
  • KPMG UK（2024 年に TT 公式ソリューションパートナーとなる）：TT を大企業/金融顧客にもたらす——TT は主流企業コンサルティングに入ったというシグナルだ。
  • Netflix / Spotify（「プラットフォームをプロダクトとする」精神の範例、TT 採用事例ではない）：TT 成書（2019）の前にプラットフォームをプロダクトとして運営しており、この原則を裏付けるが、TT 四チームモデルの採用としては数えない。

参考：teamtopologies.com/examples（公式案例集）・ teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking（銀行業 DORA 専門家コラム）

五、いつ効かないか

Team Topologies は銀の弾丸ではない。四つのよくある失敗は、いずれも大企業の真の病巣に対応する。

名前だけ変えて構造を変えない。 「フロントエンドチーム」を「ストリームチーム」と改名しただけで、報告関係は変わらず、依然として技術層——コンウェイの法律は命名術の代金を払わない。これは大企業の「看板だけ書き換えて中身は同じ」式改革で最もよくある結末だ。

プラットフォームチームがプロダクトとして扱われない。 プラットフォームチームにロードマップもユーザー体験もなく、ストリームチームが相変わらずそれを迂回し、プラットフォームはチケットを請け負う下請けに退化する。

すべてのチームが「協調」している。 協調はエネルギーを食う相互作用で、不確実な新場面に短期間だけ使える。長期に協調に頼るのは、プラットフォーム化ができていない証拠だ。表面は「協調文化が良い」、病巣はプラットフォーム化の欠如。

KPI が付いてこない。 組織図を変えたのに、相変わらず職能で評価し（フロントエンドのコード量、バグ数）、チームの振る舞いは急速に元の姿に退く。

この四条は一つの判断に対応する。組織構造、インセンティブ構造、技術アーキテクチャ。三つのうち一つを変え、残り二つが付いてこなければ、変革は必ず失敗する。

強規制業界の変種。 金融、通信は問うだろう。セキュリティ、コンプライアンス、テクノロジーリスクといった職能は、監督から独立性（segregation of duties）を求められ、安易にストリームチームに引き抜けない、と。これは法律の硬い制約であって、組織の惰性ではない——無理に割らないこと。だが横断的な承認に戻る必要もない。二つの道がある。一つはストリームチーム内にコンプライアンス/セキュリティ代表を埋め込む（彼はチームにいながら、コンプライアンスラインに点線で報告する。バリューストリームに寄り添いつつ独立性を満たす）。もう一つはコンプライアンスをイネイブリングチームとして仕立て、ストリームチームが監督要件をプロセスに内蔵するのを助ける（CI の中でコンプライアンスチェックを走らせるように）。承認を事後のチーム間承認回しではなく、チーム内部に前倒しする。監督要件を外審の関門ではなく、ストリームチームの内蔵品質に変える——これが強規制業界が「流れる」ための鍵だ。

六、あなたが聞きたいかもしれないこと

「十年間技術層で切ってきたが、再編は骨まで傷つけないか。」 傷つくが、あなたが思うよりはるかに軽い。会社全体を一度に倒して作り直す必要はない。最もひどく引っかかっているバリューストリーム（通常は皆が最も文句を言う対象）を一つ選び、単独でストリームチームとして試験的に立てる。あの CIO のように、4〜8 週間、小さなチーム一つで、納品速度の明らかな変化が見える。次のラウンドを説得するには、PPT より結果の方が効く。

「私が進めている AI 変革と何の関係があるのか。」 直接の関係がある。AI は間違った組織を直さない。既存の条件を拡大する。高業績チームが AI を手にすれば更に速くなり、間違って組み合わされたチームが AI を手にすれば、借金をより速く作るだけだ。だから組織の診断はツール調達の前に置く必要がある。これも私が「能力評価」を看板メソッド『AI 変革 7 ステップ コーチングフレームワーク』のかなり前の位置に置いた理由だ。ツールの前に、まず組織と人を見る。

「四つのチームは揃わないがどうするか。」 大多数の組織は揃わないし、揃える必要もない。真っ先に持つべきはストリームチーム（エンドツーエンド納品を保証）とプラットフォームチーム（車輪の再発明を防ぐ）だ。イネイブリングチームと複雑サブシステムチームは必要に応じて設ける。最初は持たない組織が多くて当然だ。四種類を揃えるために無理にチームを作らないこと。それは本末転倒だ。

七、意思決定者への示唆

示唆一：AI を導入する前に、まずチームトポロジー図を一枚描く。 あなたが最後に AI ツールを導入する前、チームトポロジーを描いたことがあるか。チームが技術層で間違って切られていれば、どんなに強い AI も間違った構造の上で借金を加速して作るだけだ。これ一つで大企業の無効な IT 投資の少なくとも半分を遮断できる。具体的な動作：すべてのチームを列挙し、各チームがどのバリューストリームをエンドツーエンドで担当しているかを明示する。書き出せないものは技術層で切られている証拠で、優先的に再編する。

示唆二：認知負荷の健康診断を一度やる。 「人が足りるか」はもう見ない。同時に 5 個以上の無関係なシステムを保守しているチーム、3 個以上の上流を同時に相手にしている人はいないか。これらを洗い出す方が、人を足したりプロセスを足したりするよりずっと役立つ。AI は一部の負荷（コードを書く、資料を探す、初段階のスクリーニング）を肩代わりできるが、それは負荷を意識的に再配分するという前提の上だ。過負荷のチームに「AI 現場導入」という仕事をもう一つ背負わせるのではない。

示唆三：内部プラットフォームをプロダクトとして扱う。さもなくば必ず下請けに堕する。 プラットフォームにはユーザー、ロードマップ、SLA、採用率に責任を持つ人が要る。AI 時代、このプラットフォームは更にモデルゲートウェイ、プロンプトライブラリ、エージェント実行環境を取り込む——これが後の「採用フレームワーク」の稿で展開する基盤だ。

示唆四：AI に間違った境界を固めさせない。 これは現在 AI エージェントを導入している組織に特化して話す。チームに AI エージェントを加える時、間違ったチームの切り方は拡大される。エージェントは既存の、間違った境界に沿って自動化し、間違った構造をより頑固にする。AI エージェントを導入する前に、まずチーム境界が正しいことを確認する。これがシリーズ第 11 篇の重点だ。

逆方向の自己点検（答える時に美化しないこと）：あなたのチームはバリューストリームで切られているか、それともフロントエンド/バックエンド/運用/セキュリティで切られているか。あなたの最も忙しい人は、同時に 3 件以上の無関係な仕事を背負っていないか。内部プラットフォームを使う人がいなければ、それはプラットフォーム化失敗の赤信号だ。二つのうち一つでも答えに詰まるなら、AI を導入する前にまずチームを再編する——それがリターンの最も大きい前置動作だ。

次の一手

これは「AI 時代のソフトウェア工学変革」シリーズの第 2 篇（「ゆっくり学ぶAI」欄第 172 期）だ。コンウェイ（組織がアーキテクチャを決める）から Team Topologies（組織をどう設計するか）へと進んできた。次篇（第 3 篇）はより基礎的な問題を見る。AI がコード生産をほぼ無料にする時、ソフトウェア工学のボトルネックはどこに移るのか？

シリーズ説明：本シリーズは AI プログラミングツール、組織アーキテクチャ、ソフトウェア工学パラダイムの最新の進化を継続的に追跡する。例えば 2026 年のコンウェイの法則の AI エージェント時代における新変化、最新ツール生態系の成熟度など。本シリーズをフォローして、更新され続けるインサイトを入手してください。

本シリーズについて

「AI 時代のソフトウェア工学変革」は、通信・金融・製造・EC などの業界の CIO/CDO/CTO とデジタル担当者に向けた深い研究シリーズで、全 15 篇。200 篇以上の学術論文と業界レポートに基づき、証拠レベルの注記を付けた意思決定参考を提供する。

私は元 IBM エンジニア、ICF 認定コーチで、通信事業者や大企業の AI / デジタルプロジェクトの現場導入を担ってきた。ここに書いたのはすべて、企業と共に穴を抜けてきた実戦の判断だ。

読み終えて「我が社もこんな姿なのでは」と思ったら——私は「チームトポロジー 20 問自己点検表」を作り、30 分の 1V1 診断対話も提供している。あなたの組織で最も先に再編すべきバリューストリームを切り出すサポートをする。必要なら：公式アカウント「AI決策者洞察」にメッセージを残すか、メール coach@iaiuse.com まで。

参考資料

  • Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press.（四チーム / 三相互作用 / 認知負荷の原典出所、一次情報源）
  • Conway, M. (1968). How Do Committees Invent? Datamation.
  • Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
  • IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations.（多組織採用の振り返り、二次）https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
  • Netflix Spinnaker / Spotify Backstage——内部プラットフォームのプロダクト化範例
  • AutoTrader UK——TT 公式引用の採用事例（詳細は teamtopologies.com リンクで補完予定）
  • 公式案例集：https://teamtopologies.com/examples