はじめに
「午後になると頭が回らない」「複雑なコードを読んでいると途中で何をしていたか忘れる」「新しいフレームワークを学ぶとき、情報過多で逆に理解できない」——これらはすべて**認知負荷（Cognitive Load）**の問題である。
認知負荷理論は1988年に教育心理学者 John Sweller が提唱した理論で、「人間のワーキングメモリには厳しい容量制限があり、その限られたリソースをどう配分するかが学習と作業の効率を決める」という主張である。
この理論はもともと教育分野で生まれたが、近年ではソフトウェア開発の世界にも大きな影響を与えている。特に Matthew Skelton と Manuel Pais の著書『Team Topologies』では、チーム設計の中心原則として認知負荷理論を据えている。Martin Fowler も「Team Topologies の多くは認知負荷の概念に基づいている」と述べている。
ワーキングメモリの制約
認知負荷を理解するには、まずワーキングメモリの制約を知る必要がある。
Nelson Cowan の研究（2001, 2010）によれば:
- 同時に保持できる情報: 3〜5チャンク（Millerの7±2よりも最近の研究では少ない）
- 保持時間: 処理しなければ約20〜30秒で消失
- 処理と保持はトレードオフ: 情報を操作するほど、保持できる量が減る
Cowan の2010年の論文 "The Magical Mystery Four" では、若い成人でも長いチャンク（慣用句や短い文）は3〜4個しか想起できないことが示されている。
重要なのは、この容量制限は訓練で増やせないという点である。できるのは「チャンクの質を上げる」（より多くの情報を1チャンクにまとめる）ことと、「無駄な消費を減らす」ことだけである。
3つの認知負荷
Swellerの理論では、ワーキングメモリを消費する負荷を3種類に分類する。
┌─────────────────────────────────────────┐
│ ワーキングメモリ容量（固定・増やせない） │
├────────────┬────────────┬───────────────┤
│ 課題内在的 │ 課題外在的 │ 学習関連的 │
│ (Intrinsic) │(Extraneous) │ (Germane) │
│ 管理する │ 排除する │ 最大化する │
└────────────┴────────────┴───────────────┘
総負荷 = 内在的 + 外在的 + 学習関連的 ≦ ワーキングメモリ容量
※ 超えるとオーバーフロー → 学習停止・エラー多発・疲弊
1. 課題内在的負荷（Intrinsic Cognitive Load）
課題そのものの本質的な複雑さから生じる負荷。2つの要因で決まる:
- 要素間相互作用性（element interactivity）: 同時に考慮すべき要素の数と関係性
- 学習者の前提知識: 同じ課題でも初心者には高く、熟練者には低い
| 低い内在的負荷 | 高い内在的負荷 |
|---|---|
| 変数の命名 | 再帰アルゴリズムの設計 |
| CSSのプロパティ1つ変更 | 複数サービス間のトランザクション設計 |
| 1つのAPIエンドポイント実装 | 認証・認可システムの全体設計 |
要素間相互作用性が高い（＝同時に多くの要素を頭に入れる必要がある）ほど内在的負荷は高い。
対策（管理する）:
- 複雑な課題を独立した小ステップに分割する
- 前提知識を先に固めてからメインの課題に取り組む
- Part-whole approach: まず個別要素を理解→その後に統合
2. 課題外在的負荷（Extraneous Cognitive Load）
情報の提示方法や環境の問題から生じる負荷。学習や作業の本質とは無関係な「純粋な無駄」である。
教育分野での研究では、外在的負荷を生む典型例として以下が特定されている:
- Split-attention effect: 関連する情報が物理的に離れている（図と説明文が別ページにある等）
- Redundancy effect: 同じ情報が不必要に繰り返される
- Modality effect: すべてが視覚情報のみで聴覚チャネルが活用されていない
ソフトウェア開発文脈での具体例:
| 外在的負荷の発生源 | なぜ無駄か | 対策 |
|---|---|---|
変数名が tmp, x, data | 毎回「これ何だっけ」と考える | 意図が伝わる命名 |
| ドキュメントが5箇所に散在 | 探すのにワーキングメモリを消費 | 1箇所に集約 |
| デプロイ手順が毎回異なる | 手順を覚えるために記憶を使う | 自動化 |
| PRのdiffだけでは意図がわからない | コンテキストを推測する負荷 | PR descriptionを丁寧に書く |
| 複雑なIDE設定、環境構築 | 本題にたどり着く前に消耗 | Dev Containers、自動化 |
Team Topologies の文脈では、Matthew Skelton がこれを「組織内の外在的負荷」として拡張している:
- 「このデプロイ手順を毎回調べ直す」= 外在的負荷
- 「他チームのAPIの仕様変更を把握する」= 外在的負荷
- 「プラットフォームの使い方を学ぶ」= 外在的負荷（プラットフォームチームが解決すべき）
対策（排除する）:
- ツールの自動化（手動の繰り返しを機械に任せる）
- 情報を近くに配置する（split-attention effectの回避）
- 不要な情報を削除する（redundancy effectの回避）
- Developer Experience / Operator Experienceの改善
- プラットフォームチームによる共通基盤の提供
3. 学習関連的負荷（Germane Cognitive Load）
スキーマ（知識の構造）の構築と長期記憶への定着に使われる負荷。「意味のある努力」である。
スキーマとは、関連する情報を1つのまとまりとして記憶に格納したものである。熟練者は豊富なスキーマを持っているため、複雑な問題でもパターン認識で素早く対処できる。チェスの名人が盤面を一瞬で記憶できるのは、駒の配置パターンをスキーマとして持っているからである。
学習関連的負荷が生じる活動:
| 活動 | 何が起きているか |
|---|---|
| 自分の言葉で概念を説明し直す | 精緻化（elaboration）によるスキーマ強化 |
| 異なる文脈で同じ原理を適用する | 転移可能なスキーマの構築 |
| コードを書いた後に「なぜこう書いたか」を振り返る | メタ認知によるスキーマ修正 |
| 新しいパターンを既存知識と結びつける | 既存スキーマへの統合 |
| エラーの原因を分析して一般化する | 障害パターンのスキーマ化 |
対策（最大化する）:
- 外在的負荷を削減してリソースを確保する
- 学んだことを記事にする・人に説明する（精緻化）
- 振り返りの時間を確保する
- 異なる例題で練習する（variability effect）
- 自己説明（self-explanation）を促す
3つの負荷の関係と設計原則
2010年代以降の研究では、germane loadを独立した負荷とみなすか議論がある。Sweller自身の2010年の改訂では「germane loadはintrinsic loadに寄与するワーキングメモリリソース」と再定義している。しかし実践的には3分類モデルが有用なため、本記事では従来の3分類で説明する。
設計原則は明確:
1. 外在的負荷を最小化する（無駄の排除）
2. 内在的負荷を管理する（分割・段階化）
3. 余ったリソースを学習関連的負荷に充てる（意味のある努力）
ソフトウェア開発への応用
コード設計と認知負荷
| 設計原則 | 認知負荷の観点 |
|---|---|
| 単一責任原則 | 内在的負荷を分割（1つのことに集中） |
| 良い命名 | 外在的負荷の排除（推測不要に） |
| 適切な抽象化 | チャンク化で内在的負荷を圧縮 |
| Whyコメント | 外在的負荷の排除（意図の推測不要に） |
| 一貫したパターン | 予測可能性で外在的負荷を削減 |
| 小さい関数/クラス | 内在的負荷の制限（同時考慮要素を減らす） |
Team Topologies: チーム設計への応用
Team Topologies では認知負荷を3種類に分けてチーム設計に適用している:
| Swellerの分類 | Team Topologiesでの解釈 | 例 |
|---|---|---|
| Intrinsic | ドメインの複雑さ（germane的） | 銀行送金のビジネスロジック |
| Extraneous | 環境・仕組みの摩擦 | デプロイ手順、他チームとの調整 |
| Germane | ビジネスドメインへの集中 | ユーザー価値に直結する作業 |
チーム設計の核心原則:
- 1チームが担当するサービスの認知負荷は、そのチームが処理できる量を超えてはならない
- Stream-aligned team: germane load（ビジネスドメイン）に集中する
- Platform team: 他チームのextraneous loadを削減する役割
- Enabling team: 他チームのintrinsic loadを一時的に軽減する（スキル移転）
- Complicated-subsystem team: 特定領域のintrinsic loadを引き受ける
Sky Betting and Gamingの事例では、チームの認知負荷を1-5で自己評価するアンケートを実施し、高スコアのチームから優先的にドメイン分割を行っている。
PRレビューと認知負荷
| プラクティス | 効果 |
|---|---|
| PRを小さく保つ | レビュアーの内在的負荷を制限 |
| PR descriptionに背景・意図を書く | 外在的負荷の排除 |
| 1PR = 1つの関心事 | 内在的負荷の分割 |
| テストで意図を表現する | レビュアーの推測コスト削減 |
1日の時間設計
| 時間帯 | 認知リソース | 適した作業 |
|---|---|---|
| 午前 | 豊富 | 内在的負荷が高い作業（設計、複雑なバグ修正） |
| 定例後 | やや消耗 | 外在的負荷が低い整理済みタスク |
| 夕方 | 枯渇気味 | 振り返り（学習関連的負荷を生む） |
AI活用と認知負荷
AIツールは認知負荷の観点で以下のように位置づけられる:
| AI活用 | 削減する負荷の種類 |
|---|---|
| コード補完 | 構文記憶の外在的負荷 |
| ドキュメント検索（MCP） | 情報探索の外在的負荷 |
| 自動レビュー | レビュアーの内在的負荷の一部をオフロード |
| タスク管理自動化 | 「次何するんだっけ」の外在的負荷 |
| 振り返りの自動分析 | 学習関連的負荷に集中できる環境を作る |
注意: AIに「考える部分」まで任せると学習関連的負荷もオフロードされ、スキーマが構築されない。「探す・覚える・整える」をAIに任せ、「考える・判断する・統合する」は自分でやるのが最適バランスである。
認知負荷を測定する
2024年の研究（Springer）では、3種類の認知負荷を個別に測定する質問票が開発・検証されている。実務では以下の簡易指標が使える:
- 「この作業中、本質的でないことを考えている時間はどれくらい？」→ 外在的負荷の指標
- 「この1時間で、実際にドメイン問題を解いていた時間は？」→ 学習関連的負荷の指標
- チーム単位: 「担当システムの理解度を1-5で」→ 内在的負荷の指標
まとめ
| 負荷 | 定義 | 開発での例 | 対処 |
|---|---|---|---|
| 課題内在的 | 課題自体の複雑さ | マイクロサービス間の依存設計 | 分割する・前提知識を固める |
| 課題外在的 | 環境・提示方法の問題 | ドキュメント散在・手動デプロイ | 徹底的に排除する |
| 学習関連的 | スキーマ構築の努力 | 振り返り・記事執筆・パターン抽出 | リソースを確保して最大化する |
「忙しいのに成長していない」と感じたら、外在的負荷に消耗されている可能性が高い。環境とツールを整え、外在的負荷を削り、浮いたリソースを学習関連的負荷（意味のある努力）に回す——これが認知負荷理論の実践的メッセージである。
参考文献
- Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285.
- Cowan, N. (2010). The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why? Current Directions in Psychological Science, 19(1), 51-57.
- Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution.
- Sweller, J., van Merriënboer, J., & Paas, F. (2019). Cognitive Architecture and Instructional Design: 20 Years Later. Educational Psychology Review, 31, 261-292.