認知負荷の少ない情報の残し方
エンジニアとして仕事をしていると、仕様書・議事録・課題チケットなど何かしらのドキュメントに情報を残すシーンがよくあります。その際、思いつきでダラダラと書いてしまうと第三者が読みにくいドキュメントが出来上がってしまいます。必要な情報が過不足なく相手に伝わるために、自分が意識していることを言語化します。
情報を一箇所に集める
自分の知りたい情報が複数箇所に散らばっていると、理解に時間を要します。〇〇については仕様書Aに記載してます。あ、でも補足事項に関しては仕様書Bに書いてます。その時の経緯はslackのここのスレッドで会話しています…というように、情報源が分散していると追跡が困難になります。
情報は可能な限り一箇所に集約します。どうしても情報源が複数にならざるを得ない場合は、それぞれの情報源が互いに参照できるよう紐付けます。読者を迷子にさせない。
認知負荷
認知負荷という言葉があります。
Wikipediaによると、物事を理解するまでに消費される脳内のワーキングメモリの量と定義されています。
In cognitive psychology, cognitive load refers to the amount of working memory resources used.
例えば霞が関パワポと称される下記画像などは、「認知負荷が高い」と言えます。理解するのに脳のリソースを多く消費しますよね。
地域循環共生圏（日本発の脱炭素化・SDGs構想）
https://www.env.go.jp/council/02policy/mat97_2_2.pdf
認知負荷の種類
認知負荷の中にはいくつか種類があります。私がよく意識するのは以下の二種類です。
課題内在性負荷・・・課題自身の複雑性からくる負荷
課題外在性負荷・・・課題とは関係ない外部要因による負荷
課題の内側・外側どちらに存在する認知負荷なのか？という点での違いです。
具体例を挙げます。
例えば、数学の二次方程式の解の公式について。
a, b, cの値・正負によって解が変化します。複雑ですよね。
これは、解の公式自身が持つ複雑さです。よって、課題内在性負荷といえます。
一方で、数学の授業を聞きたいのに、
教室がうるさい
エアコンが効いてなくて暑い
先生の滑舌が悪い
などといった外部要因のせいで授業に集中できないとき、これは課題外在性負荷が高いと言えます。
解の公式自身の認知負荷さなのか、関係ない外部要因による認知負荷なのかによって、負荷の種類を分類することができます。
我々は、課題内在性負荷に集中したいのです。
プログラミングの文脈で言うと、ネストの深いコードなどです。
あるロジックAを実装したコードがあります。このコードの中身を見ると、ifのネストがとてもとても深い実装になっていました。（ネスト波動拳）
ロジックAという課題の理解をしたいのに、ネストの深さという課題外在性負荷によって認知負荷が高くなってしまっています。早期returnをする・メソッド化するなどのリファクタリングを実施して、課題外在性負荷を軽減すべきです。
このように、課題外在性負荷によって本来向き合うべき課題の前段で脳のリソースを消費してしまうことが往々にしてあります。
なお、今挙げた課題外在性負荷・課題内在性負荷については下記のPodcastsでより詳細に話されています。
課題外在性負荷を排除しよう
自分が何か情報を残すとき、可能な限り課題外在性負荷を排除するように心がけましょう。我々が真に向き合うべきは課題内在性負荷であり、外在する認知負荷はノイズでしかないのです。