3つの認知負荷

内在性認知負荷

学習内容を構成する要素同士が関連している（要素間のインタラクティビティ＝相互依存のようなもの、が高い）ので、作業記憶に高い負荷がかかり、うまく処理できないことを意味する
これはその学習内容自体が本来備える複雑さのこと
本質的な難しさ。そのものの複雑さ

内在性認知負荷の対策

要素を分解するなど、学習量を調整する
俯瞰 → それぞれの要素を順番に学ぶ → 俯瞰 のステップを設計する
- 孤立要素効果（isolated elements effect）

外在性認知負荷

教材の作りが不適切なために作業記憶にかかる余計な認知負荷のこと
非本質的な難しさ。インターフェースに問題がある

外在性認知負荷の対策

インターフェースの改善
ルールや制約の導入（開発の現場なら：フォーマッター、レビュー、型のある言語、チーム内ガイドラインの整備など）
デザインシステムや、デザイン原則の導入

学習関連負荷

「適切」な認知負荷であり、脳がスキーム（世界を理解するための枠組み）を構築しているときに発生する
メンタルモデルを作るまでの負荷で、このフェーズを経るとのちの認知負荷軽減につながる
表面的理解 → 本質的理解 にいたるまでの、最初の負荷

考察

外在性認知負荷 / 内在性認知負荷とどう向き合うか

「クソコード」のような解像度の低いワードは外在性認知負荷であると考える
- 内在性認知負荷にフォーカスできない状況なので、まず外在性認知負荷を削減しよう、と言い換えられる
B2Bが扱う「そもそも複雑なドメイン」（軽減税率の計算とか、在留資格の申請とか）では、内在性認知負荷を隠すこと自体がそのプロダクトの存在意義である。そのため外在性認知負荷がゼロであることがスタート地点になる（本筋ではないがリファクタの重要性の説得材料にもなる）
- 「そもそも複雑なドメイン」にペルソナがどう取り組みたい（またはどう取り組むべきか、の提供側の思想）によって内在性認知負荷をどう減らすか？が変わる
これはペルソナが「熟達したい」（最終的にその複雑性を学習して習得したい）のか、それとも「ただやり過ごしたい」のか、という問いに置き換えられる
- アラン・クーパーは「永遠の中級者」に向けてデザインせよと言った。これは「ただやり過ごしたい」の方に近いかも
  - エクセルは誰よりも詳しいが、コンピュータのことは何も分からない人の話

熟達したい

この場合、正しく交通整理（孤立要素効果などを使う）して外在性認知負荷を取り除いた上で内在性認知負荷は隠蔽しない（教科書、教材など）
立ち向かうドメインの内在性認知負荷は必要かつ価値のあるものと考えて、前者のアプローチを推奨する。それによってペルソナの価値創出に使える能力を増やす

ただやり過ごしたい

この場合、外在性認知負荷を取り除いた上で、さらに内在性認知不可をできる限り隠蔽する
立ち向かうドメインの内在性認知負荷自体をそもそも不要なものと考えて、後者のアプローチを推奨する。それによってペルソナの価値創出に使える時間を増やす

まとめ

	熟達したい	ただやり過ごしたい
アプリの例	Figma、Notionなどモードレスなもの（習得、解決するとレバレッジが効く種類の課題に対応する）	SmartHRの年末調整、Freeeの確定申告のようなモーダルなもの
課題のコンテクスト有無	特定のコンテクストを持たない（幅広い、または無限の用途）	特定のコンテクストを持つ
ユーザーとの接し方	エンパワーメント型（人の能力の拡張・強化を手助けする）	ソリューション型（人のリソースを節約する）
目的地への移動の比喩	階段のようなもの（体力を使って、自分の位置を把握しながら、自発的に目的地に到着する）	エレベーターのようなもの（体力を使わずに、自分の位置も仕組みもよくわからないけど、楽に目的地に到着する）
プログラミングパラダイムによる分類	オブジェクト指向	手続き型、タスク指向
APoSDの分類	小クラス主義（シャローモジュール、大きいインターフェース、浅い実装）/ Java	大クラス主義（ディープモジュール、小さいインターフェース、深い実装） / Ruby
内在的認知負荷との向き合い方	必要かつ価値のあるもの（熟達するべきもの）と考える	不要なもの（やり過ごすべきもの）と考える
ペルソナにもたらす価値	価値創出に使える能力を増やす	価値創出に使える時間を増やす

Hikari Tsuchiya (hikarock)

認知負荷の種類と考察

3つの認知負荷

内在性認知負荷

内在性認知負荷の対策

外在性認知負荷

外在性認知負荷の対策

学習関連負荷

考察

外在性認知負荷 / 内在性認知負荷とどう向き合うか

熟達したい

ただやり過ごしたい

まとめ

参考