はじめに—優秀なエンジニアが揃っているのに、なぜ遅いのか
本記事を読めば、(1) 開発停滞の真因である「認知負荷」を可視化でき、(2) Team Topologiesの4チームタイプで組織を再設計し、(3) 逆コンウェイ戦略でアーキテクチャと組織を同期できます。
本稿はCTO/VPoE・EMが、職能別組織の限界を「認知負荷」という測定可能な指標で診断し、ストリームアラインドチームへの移行戦略を設計する実務ガイドです。
【要約】
遅い原因：認知負荷（特に外在的負荷＝調整コスト）がチーム容量を圧迫 処方箋：Stream-aligned中心＋Platform/Enablingで負荷を分散 進め方：可視化→パイロット→横展開（Four Keys＋自律性スコアで測定） 移行期間：1-8ヶ月の段階的アプローチで組織リスクを最小化
「優秀なエンジニアが100名いるのに、なぜリリースに3ヶ月もかかるのか？」
副題：職能別組織でリードタイムが伸びる理由／Stream-aligned移行手順
なぜ職能別組織が開発を遅くするのか
【注記】 規制対応や基盤統制が強い企業では、特定領域で職能別組織が必要な場面もあります。本稿で問題視するのは、「価値提供の流れ（stream）に対するオーナー不在」が生む、過度なコミュニケーションコストと認知負荷です。
【問題の本質】認知負荷の3類型とチーム限界
Team Topologiesによる定義：
1. 内在的負荷（Intrinsic）： ドメイン知識・技術スキルそのものの複雑性 2. 外在的負荷（Extraneous）： 環境・ツール・プロセスの複雑性による余計な負荷 3. 適応負荷（Germane）： 新しい知識・パターンの学習に必要な負荷
チームが処理できる認知負荷には限界がある
→ 経験則として、ソフトウェア開発では小さめのチーム（例：5〜9人、〜10人程度）がコミュニケーション効率の観点で推奨されることが多い¹
【典型的な職能別組織の認知負荷爆発】
ケース：ECサイトの新機能追加
要求される認知： □ フロントエンドチーム：React、CSS、UXパターン、アクセシビリティ □ バックエンドチーム：Java、Spring、DB設計、API仕様 □ インフラチーム：AWS、Kubernetes、CI/CD、セキュリティ □ QAチーム：テスト戦略、自動化ツール、品質基準 コミュニケーション経路： 4チーム × (4-1)/2 = 6経路の調整コスト 各チームは他チームの文脈・制約を理解する必要（外在的負荷）
結果： 本質的な価値創造（適応負荷）に使える認知容量が不足
【認知負荷の可視化：実測例】
測定方法：チーム活動時間の内訳分析
典型的な職能別組織の時間配分（複数企業での観測例）： - 内在的負荷（実装・設計）：30-40% - 外在的負荷（調整・待機・手戻り）：40-50% - 適応負荷（学習・改善）：15-25% → 価値創造に使える時間は全体の50-60%程度 → 40-50%がコミュニケーションコストで消失する傾向
Team Topologies：認知負荷を最適化する4チームタイプ
【タイプ1】ストリームアラインドチーム
定義： ビジネス価値の流れに沿って編成された、エンドツーエンドで価値を届けられる自律チーム
構成例：「決済機能チーム」
メンバー構成（7名）： - フロントエンドエンジニア × 2 - バックエンドエンジニア × 2 - DevOpsエンジニア × 1 - プロダクトオーナー × 1 - QAエンジニア × 1 責任範囲： 決済画面UI、決済API、決済DB、決済ログ監視まで → 他チームへの依存を最小化
認知負荷の最適化： - 内在的負荷：決済ドメインに集中 - 外在的負荷：チーム内で完結、調整コスト最小 - 適応負荷：決済領域での継続的改善に注力
【タイプ2】イネイブリングチーム
定義： 他チームの能力向上を支援する専門家集団
役割例：「セキュリティイネイブリングチーム」
支援内容： - セキュリティベストプラクティスの共有 - 脆弱性診断ツールの導入支援 - インシデント対応のメンタリング → ストリームアラインドチームの自律性を高める → 継続的な依存関係ではなく、期間限定の支援
【タイプ3】コンプリケイテッド・サブシステムチーム
定義： 高度に専門的で複雑なサブシステムを担当するチーム
例：「機械学習推薦エンジンチーム」
専門性の高さ： - 推薦アルゴリズムの研究・開発 - 大規模データパイプライン - モデルのA/Bテスト基盤 → この複雑性を他チームに負担させない → APIとして明確な境界を提供
【タイプ4】プラットフォームチーム
定義： 他チームの認知負荷を下げる内部プラットフォームを提供
例：「開発者体験（DX）プラットフォームチーム」
提供サービス： - ワンクリックデプロイ基盤 - 標準化されたCI/CDパイプライン - セルフサービス型の監視・ログ基盤 - 内部向けAPI Gateway → ストリームアラインドチームが"Paved Road"で高速開発
逆コンウェイ戦略：組織とアーキテクチャの同期設計
【コンウェイの法則】
システムを設計する組織は、その組織のコミュニケーション構造をそっくりまねた構造の設計を生み出す
従来の問題： 職能別組織 → モノリシックで結合度の高いアーキテクチャ
【逆コンウェイ戦略】
理想のアーキテクチャを先に定義し、それに合わせて組織を再編成
実践ステップ：
ECサイトの例： - 商品カタログ管理 - 在庫管理 - 注文処理 - 決済処理 - 配送管理 - 顧客管理 - レコメンデーション
Step2：認知負荷に基づく境界設計
評価軸： □ 変更頻度（高頻度変更は独立させる） □ ドメイン複雑性（高複雑性は専門チーム） □ 他機能との結合度（低結合を維持） □ チーム認知容量（1チームが担える範囲か）
Step3：チームトポロジーの設計
ストリームアラインドチーム： - 注文〜決済フローチーム - 商品発見チーム - 顧客体験チーム コンプリケイテッド・サブシステムチーム： - レコメンドエンジンチーム - 不正検知チーム プラットフォームチーム： - 開発者体験チーム - データ基盤チーム イネイブリングチーム： - セキュリティ支援チーム - SRE支援チーム
Step4：アーキテクチャの同期実装
マイクロサービス境界 = チーム境界 - 各ストリームアラインドチームが独立デプロイ可能 - API契約で疎結合を維持 - 共有データベースの排除（Database per Service）
認知負荷削減の測定可能な成果指標
【プロセス指標】
デプロイ頻度の向上
目安（職能別 → ストリームアライン移行後）： 月1回の大規模リリース → 各チーム週次デプロイ リードタイム：20-40日 → 1日未満〜1週間未満（DORAのパフォーマンスレベルを目安²）
変更失敗率の低下
目安： チーム間調整ミスによる障害多発（10-20%） → 独立デプロイで影響範囲限定（5-10%）
平均復旧時間（MTTR）の短縮
目安： 障害箇所特定に複数チーム関与（6-12時間） → チーム内で完結（1-3時間）
【組織指標】
チーム自律性スコア
測定項目（各5点満点）： □ 他チーム依存なしで機能リリース可能 □ 技術スタック選択の裁量 □ デプロイタイミングの自己決定 □ 障害対応の完結性 □ KPI設定・測定の自己完結 目標：20点以上（高自律）
認知負荷分布の改善（目標値例）
時間配分の変化（組織により幅がありますが、典型的な改善目標）： - 外在的負荷：45% → 15%（調整コスト削減） - 内在的負荷：35% → 50%（本質的価値創造） - 適応負荷：20% → 35%（学習・改善の加速）
エンゲージメント向上
定性指標： - 「自分のチームで価値を届けている実感」 - 「技術的判断の裁量」 - 「学習機会の充実」 → 離職率の改善、採用力の向上
移行戦略：段階的な組織再編のロードマップ
【Phase1：認知負荷の可視化（1-2ヶ月）】
対象： 全チーム 活動：
□ 現状のチーム活動時間分析 □ コミュニケーション経路マッピング □ 認知負荷タイプ別の定量化 □ ボトルネック特定（外在的負荷の温床）
成果物： 認知負荷ヒートマップ、改善優先度リスト
現状組織のコミュニケーション経路を可視化し、認知負荷のボトルネックを特定。持ち帰って社内合意に使える形（ヒートマップ・優先度リスト）で提供します。
【Phase2：パイロットチームの編成（2-4ヶ月）】
対象： 1-2つのストリームアラインドチーム 活動：
□ ビジネスケイパビリティ1つを選定 □ エンドツーエンドチームの編成 □ マイクロサービス境界の設計・実装 □ 独立デプロイパイプラインの構築
検証項目： - デプロイ頻度・リードタイムの改善 - チーム満足度の向上 - 認知負荷分布の最適化
【Phase3：横展開と支援チームの整備（4-8ヶ月）】
対象： 全組織 活動：
□ 成功パターンの標準化 □ プラットフォームチームの立ち上げ □ イネイブリングチームの編成 □ 複数ストリームアラインドチームの展開
重要： 一度に全チームを変更しない（漸進的移行）
【Phase4：継続的最適化（8ヶ月以降）】
対象： 組織全体 活動：
□ チームトポロジーの定期見直し □ 認知負荷の継続測定 □ チーム境界の調整（合併・分割） □ 新技術・新ドメインへの適応
よくある移行失敗パターンと対策
【失敗1】マイクロサービス化だけで終わる
症状： 技術的には分割したが、組織は職能別のまま
結果： 調整コストが増大、認知負荷は悪化
対策： 組織とアーキテクチャの同時変更を原則化
【失敗2】完璧な境界設計を目指す
症状： ドメイン駆動設計の理想論で議論が停滞
結果： 何も変わらない、変革疲れ
対策： 70%の確度で開始し、継続的に境界を調整
【失敗3】プラットフォームチームの不在
症状： 各ストリームアラインドチームが独自にインフラ構築
結果： 車輪の再発明、認知負荷の増大
対策： プラットフォームチームを最優先で立ち上げ
【失敗4】イネイブリングチームの恒常化
症状： 支援チームが常駐し、依存関係が固定化
結果： 自律性が育たない
対策： 期間限定支援（3-6ヶ月）を原則化、卒業基準を明確化
まとめ：認知負荷の最適化が組織の競争力を決める
大規模組織の開発停滞は、エンジニアの能力不足ではなく、組織設計の失敗です。
Team Topologiesが示す本質： 1. 認知負荷は測定可能：時間配分分析で可視化できる 2. 組織とアーキテクチャは表裏一体：逆コンウェイ戦略で同期設計 3. チームタイプの戦略的配置：4タイプの役割を明確化
「人数を増やしても遅い」から「認知負荷を最適化して速い」へ。この転換こそが、DX時代の大規模組織が生き残る条件です。
弊社支援サービス
【認知負荷診断セッション】
対象： CTO、VPoE、EM
成果： 現状組織の認知負荷ヒートマップ／ボトルネック特定／改善優先順位
付与： 認知負荷測定シート／チームトポロジー設計テンプレ
【組織変革】Team Topologies実装支援
✓ ビジネスケイパビリティマッピング ✓ ストリームアラインドチーム設計
✓ プラットフォームチーム立ち上げ ✓ 逆コンウェイ戦略のアーキテクチャ設計
【技術組織成熟度向上】継続的最適化プログラム
✓ 認知負荷の定期測定・分析 ✓ チーム境界の動的調整支援
✓ EM/テックリード育成 ✓ Four Keys指標の改善サイクル
【認知負荷診断チェックリスト】
□ チームが他チーム待ちで作業停止する頻度（週に何回？） □ 1つの機能リリースに関与するチーム数（何チーム？） □ エンジニアが調整・会議に費やす時間（週何時間？） □ デプロイに他チームの承認が必要か □ 障害発生時、原因特定に複数チームの調査が必要か
【付録】認知負荷測定テンプレート
【テンプレ1】2週間の時間配分ログシート
日付 | 活動 | 時間 | カテゴリ -----|------|------|---------- 1/6 | 実装 | 3h | 内在的 1/6 | 他チーム調整 | 2h | 外在的 1/6 | 技術学習 | 1h | 適応 ... カテゴリ定義： - 内在的：実装、設計、ドメイン知識の適用 - 外在的：チーム間調整、待機、手戻り、ツール問題 - 適応：学習、改善活動、新技術調査
【テンプレ2】コミュニケーション経路マッピング
Step1：関与チームをリストアップ
例：FE / BE / インフラ / QA / PdM
Step2：チーム間の依存関係を矢印で図示
FE ⇔ BE ⇔ インフラ
↓ ↓ ↓
QA ← PdM
Step3：各経路の調整頻度を記録
FE ⇔ BE：週5回（毎日）
BE ⇔ インフラ：週3回
...
Step4：高頻度経路（週3回以上）を「外在的負荷の温床」として特定
【テンプレ3】外在的負荷が増えているサインチェック
□ 定例会議が週10時間以上 □ 「〇〇待ち」でタスクが停止する頻度が週3回以上 □ 仕様変更・手戻りが月に5回以上 □ 他チームへの問い合わせが1日2回以上 □ デプロイに3チーム以上の承認が必要 3つ以上該当：外在的負荷が過剰、組織再編を検討推奨
【テンプレ4】チーム認知負荷サーベイ（週次）
各メンバーが週末に5段階で自己評価（1=余裕、5=限界）： Q1. 今週の認知負荷の総量は？ Q2. うち「他チーム調整」が占めた負荷は？ Q3. 「本質的な価値創造」に集中できた度合いは？ Q4. 「新しい学習・改善」に時間を使えた度合いは？ チーム平均： - Q1が4以上：過負荷状態、要介入 - Q2が4以上：外在的負荷が支配的、組織設計を見直し - Q3/Q4が2以下：価値創造・学習が犠牲に、優先度調整必要 → 4週間トレンドで改善/悪化を判定
【参考文献】
¹ Ken Schwaber, Jeff Sutherland『The 2020 Scrum Guide』(Scrum Teamは typically 10 or fewer) https://scrumguides.org/
D. Rodríguez et al., "Empirical findings on team size and productivity in software development" Journal of Systems and Software (2012)
² DORA『DORA metrics』https://dora.dev/
Google Cloud『Four Keys』https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
Matthew Skelton, Manuel Pais『Team Topologies: Organizing Business and Technology Teams for Fast Flow』IT Revolution Press（2019年）
日本語版：『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター（2021年）
