フレームワーク活用ガイドひとことで言うと#
チームが担うドメイン知識・技術スタック・外部依存関係などの認知的な負担の総量を可視化・計測し、チームのキャパシティを超えていないかを診断するフレームワーク。『チームトポロジー』のスケルトンとパイスが提唱した概念で、チームが過負荷になると意思決定の質が下がり、デリバリーが遅延し、メンバーが疲弊することを前提に、負荷の適正管理をチーム設計の中心に据える。
押さえておきたい用語#
- 認知負荷（Cognitive Load）
- ある作業を遂行するために必要な精神的な処理量のこと。心理学者ジョン・スウェラーの認知負荷理論に由来する。チーム文脈では、チームが理解・記憶・判断すべき情報の総量を指す。
- 内在的認知負荷（Intrinsic Cognitive Load）
- タスクそのものの本質的な複雑さに起因する負荷。ドメインの難しさ、コードベースの複雑さなど。
- 外在的認知負荷（Extraneous Cognitive Load）
- タスク遂行に本来不要だが、環境やプロセスのせいで発生する余計な負荷。ドキュメント不足、ツールの乱立、不明確なプロセスなど。削減すべき第一ターゲット。
- チームトポロジー（Team Topologies）
- ストリームアラインドチーム・プラットフォームチーム・イネーブリングチーム・コンプリケイテッドサブシステムチームの4類型でチーム構造を設計するアプローチ。認知負荷の管理が設計原則の中心にある。
チーム認知負荷の全体像#
こんな悩みに効く#
- チームの担当範囲が広がり続け、メンバーが「何でも屋」になって疲弊している
- デリバリーのスピードが落ちているが、原因が人手不足なのかチーム設計なのか分からない
- チームを分割すべきタイミングの判断基準がない
- 新しい技術やドメインを学ぶ余裕がなく、チームの技術的成長が停滞している
基本の使い方#
チームが理解・記憶・判断すべきすべてのものをリストアップする。
- ドメイン知識: 担当するビジネス領域の数。1チーム1〜2ドメインが理想
- 技術スタック: 使っている言語、フレームワーク、インフラの数
- コードベース: 所有するリポジトリやサービスの数・規模
- 外部依存: 他チームとのAPI連携、共有データベース、承認プロセスの数
- ツール・プロセス: CI/CD、モニタリング、チケット管理など日常的に使うツール群
棚卸した項目を「内在的」「外在的」「学習的」に分類し、各項目の負荷の重さを高・中・低で評価する。
- 内在的（本質的な複雑さ）: ドメインのルール、アルゴリズムの複雑さ、法規制の理解
- 外在的（環境に起因する余計な負荷）: ドキュメント不足で毎回人に聞く、レガシーコードの解読、不明確な承認フロー
- 学習的（成長のための負荷）: 新技術の習得、ドメイン知識の深化
- チームメンバーに「自分の担当領域を新人に1時間で説明できるか？」と問う。「無理」なら負荷過大のサイン
外在的負荷は本来不要なものなので、最初に削減ターゲットにする。
- ドキュメント整備: 「毎回人に聞かないと分からないこと」を文書化する
- ツールの統合・削減: 用途が重複するツールを整理する
- プロセスの簡素化: 形骸化した承認フローや会議を廃止する
- 依存関係の削減: 他チームへのリクエスト待ちが頻発するなら、APIの自律的な利用やセルフサービス化を検討
外在的負荷を削減しても総量がキャパシティを超えるなら、チーム構造の変更を検討する。
- チーム分割: 1チームが3ドメイン以上を持っているなら、ドメイン境界で分割する
- 責任の移管: 特定の技術的な複雑さをコンプリケイテッドサブシステムチームに切り出す
- プラットフォームチームの新設: 全チームが共通で苦労しているインフラ・ツーリングを専門チームに集約する
- イネーブリングチームの活用: 新技術の導入支援を専門チームに依頼し、学習負荷を分散する
具体例#
従業員200名のEC企業。3年前にモノリスをマイクロサービスに分割し、28個のサービスが稼働していた。開発チームは4チーム（各5〜7名）で、1チームあたり平均7サービスを担当。
デプロイ頻度は分割直後に向上したが、最近は再び低下。原因を探ると、各チームが担当サービスの全容を把握しきれず、変更の影響範囲の調査に時間がかかっていた。
認知負荷の棚卸し結果:
- ドメイン知識: 1チームあたり3〜4ドメイン（注文、在庫、配送、決済が混在）
- 技術スタック: Go、Python、Node.jsの3言語が混在
- 外部依存: チーム間のAPI呼び出しが平均12本
対策:
- ドメイン境界でチームを再編: 4チーム→6チームに分割し、1チーム1〜2ドメインに
- 言語の標準化: 新規開発はGoに統一（既存のPython/Nodeは段階的に移行）
- プラットフォームチーム新設: CI/CD、モニタリング、共通ライブラリを1チームに集約
6か月後、デプロイ頻度は週3回→週8回に回復。チームメンバーへの調査で「自分の担当領域を新人に説明できる」と回答した割合は**35%→78%**に改善した。
BtoB SaaS企業のカスタマーサクセスチーム10名。オンボーディング、技術サポート、契約更新、アップセル提案、顧客データ分析、社内へのフィードバックの6つの機能を全員が兼任していた。
メンバーの疲弊が深刻化し、離職率は年30%。マネージャーは「人が足りない」と増員を要求していたが、直近1年で3名採用しても状況は改善しなかった。
認知負荷を分析すると、問題は人数ではなく負荷の種類の多さだった:
- 内在的負荷: 製品知識（機能200以上）、顧客業種ごとのドメイン知識（8業種対応）
- 外在的負荷: CRM・チャットツール・分析ツールなど9つのツールを常時使い分け、ナレッジベースが更新されておらず毎回Slackで質問
- 学習的負荷: 月1回の製品アップデートへの追従がほぼ不可能
対策:
- 外在的負荷削減: ツールを9→5に統合。ナレッジベースを1か月かけて全面更新
- チーム分割: 「オンボーディング専任（3名）」「既存顧客担当（5名）」「テクニカルサポート（2名）」に機能分割
- 顧客業種を「IT・金融」「製造・小売」「その他」の3グループに分け、担当者のドメイン知識を集中
1年後、離職率は30%→8%に激減。CSAT（顧客満足度）も4.0→4.5（5点満点）に改善。増員せずに対応可能な顧客数が15%増加した。
シード期のスタートアップ（エンジニア6名の1チーム）。プロダクト開発に加え、インフラ構築、カスタマーサポート、データ分析、採用面接まで全員が担当していた。
プロダクトのPMFが見え始め、ユーザー数が月40%で成長する中、開発速度が急激に低下。バグ対応とカスタマーサポートに時間を取られ、新機能の開発が月2本→月0.5本に激減していた。
CTOが認知負荷の棚卸しを実施:
- 1チームが担うドメイン: 4つ（ユーザー管理、決済、コンテンツ配信、分析）
- 技術スタック: React、Next.js、Go、PostgreSQL、AWS 15サービス
- 外在的負荷の最大要因: カスタマーサポート対応（エンジニアが日替わりで担当、1日平均2.5時間消費）とインフラの手動運用
段階的に対策を実行:
- 即効策（1週目）: カスタマーサポートをCSチームに移管。FAQを整備し、エンジニアへのエスカレーションを技術的なバグのみに限定 → エンジニアの可処分時間が日2.5時間回復
- 短期策（1か月）: インフラをTerraformでIaC化し、手動運用を80%削減
- 中期策（3か月）: シリーズA調達後にプラットフォーム専任エンジニア2名を採用。6名のチームは「決済・ユーザー管理」と「コンテンツ・分析」の2チームに分割
半年後、新機能のデリバリーは月0.5本→月3本に回復。チーム分割の判断基準として「1チームが担うドメイン数が3を超えたら分割を検討する」というルールを定着させた。
やりがちな失敗パターン#
- 「人を増やせば解決する」と考える — 認知負荷の問題はチームの責任範囲と構造の問題。人を増やしてもドメインの数やツールの複雑さは減らない。まず負荷の種類を特定してから採用判断する
- 内在的負荷と外在的負荷を区別しない — すべてを「仕事が大変」で片付けると打ち手が見えない。外在的負荷（余計な複雑さ）は削減でき、内在的負荷（本質的な複雑さ）はチーム境界の再設計で対処する
- チーム分割だけで解決しようとする — 分割するとチーム間のコーディネーションコストが新たな外在的負荷になる。分割と同時にAPIの契約やコミュニケーションパスを設計する
- 学習的負荷をゼロにしようとする — 外在的負荷を削った余白は、新しい技術やドメイン知識の学習に充てるべき。学習負荷をゼロにするとチームの成長が止まる
まとめ#
チーム認知負荷は、チームが担うドメイン・技術・プロセス・依存関係の総量を可視化し、キャパシティの範囲内に収めることを目指すフレームワークだ。鍵は3種類の認知負荷を区別すること。外在的負荷（環境やプロセスに起因する余計な複雑さ）を最優先で削減し、学習的負荷（成長のための投資）の余白を確保する。それでも総量がキャパシティを超えるなら、チーム分割や責任移管でチーム境界を再設計する。「メンバーが自分の担当領域を新人に説明できるか」というシンプルな問いが、負荷の過不足を測る最も実用的なリトマス試験紙になる。