「プログラマー脳」の本の感想と賛辞 〜 意味波と具象と抽象と

「プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ」という本がとても売れているようです。タイトルが若干引っかかりつつ、各所で褒める言葉を見かけたので私も購入して一通り読んでみました。

プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ(amazon)

これはめちゃくちゃいい。

私が考えてきた事との類似性、新しい考え方、チーム戦略、全てにおいて示唆がありました。プログラミングに関する書籍としては、これまで読んだ本の中で一番ためになったように感じていて、実際にすぐに行動に反映されるような内容も多々ありました。
そこで、この本から特に感銘を受けた内容と、一部はそこから発展させた私の考えについて述べます。
（ちなみになぜ自分の考えを述べるのかという事については、この本に紹介されている意味波の考え方でその意義を説明できるので、後述します。）

この本は何の本なのか - 効率的に熟達者になる

この本の概要ですが、実はサブタイトルがすべてを語っていて「優れたプログラマーになるための認知科学に基づくアプローチ」について述べた本です。優れたプログラマー、本書における別の表現では 「熟達者」 に効率的になることを目的として、その実現手段および方法の理論的な解説に認知科学を用いているのが特徴で、

• プログラマー（人間）がプログラムを読み書きする過程ではどのような事が起こっているのか
• 熟達したプログラマーと初心者のプログラマーの間の差異はどう説明されるのか
• 熟達するためにはどんな事に気をつければよいのか

という事について、認知科学的な理論と非常に具体的な実例の両方を交えて記述されています。

逆に、何の本ではないかというと、具体的な設計やプログラミング技法を主たる目的とした本ではありません。例えば、大量の通信を安定して処理するためのアーキテクチャとか、高速な計算アルゴリズムとか、複雑な業務要件の実現方法とか、そういった個々の具体的な設計や技法を直接扱うことは主目的ではありません。そのかわりに、個々の具体的な知識を身につけるにあたって、どのような考え方と実践をするとよいのか、 という事が示されています。また、プログラミング言語の種類やソフトウェアの内容に依存しない読み方・書き方については、ある程度踏み込んだ内容が書かれています。この読み方・書き方は、プログラムの一部の設計に影響するので、設計を扱わないという事ではないです。

総じて、良いものを作るための本というよりは、良いものを作れる人になるための本、と言えると思います。認知科学という特性上、人間とその行動に焦点がある、という事が技術書としては少し独特かもしれません。
また、単に読者自身が熟達者になるのではなく、初心者と熟達者の違いはなにか、熟達者を増やすためにはどうすればよいか（オンボーディング）、といった事も詳しく書かれています。

この本の構成・特徴

この項では、「効率的に熟達者になる」ことについての認知科学を用いた説明がどのように展開されていくのか、本の構成と特徴について説明します。

認知科学的な知識を章立ての順序に沿って自然に説明するスタイル

私を含む一般的なプログラマーは、認知科学には詳しくありません。そこで、この本では認知科学に関する知識を前提とせず、各トピックに沿って少しずつ認知科学的な知見が説明されていきます。熟達者になるための要素を説明していく上で、全体の流れとしては

• コードの読み方
• コードの書き方
• 複数人での作業、オンボーディング

という流れがありますが、この章立てが進んでいくと 過去に説明した知見を参照しながら次の認知科学的な知見を説明していく、というようなストーリー性のある組み立てに なっており、次の章が前の章にある程度依存するような構成になっています。まえがきにも書いてありますが、頭から順序通り読むのが良いと思います。私の場合は"ある意味"小説や漫画の感覚で読めました。
逆に言うと、始めに認知科学的な知見の全貌が示されるわけではなく、例えば最初からMECEな分類が出てくるのではなくて、最初は話の展開に必要な最小限の内容だけを出しておいて、後からその説明で不足する概念を付け足していくというような方式で知識が展開されます。例えば、次のような具合です。（P205より引用）

認知的負荷には、問題そのものがもたらす課題内在性負荷、問題の表現がもたらす課題外在性負荷の2種類があることを見てきました。しかし実際にはさらにもう1つ、これまで取り上げていない「学習関連負荷（germane cognitive load）」があります。

認知科学的な知見については、このような記述がしばしばあります。私はあまり気になるレベルではありませんでしたが、若干の後出し感があるかなとは思いました。後出し感が気になる方にとっても、この本の知見自体は有用だと思うので、どうしても気になる場合は自分自身で後出し部分を再構成するつもりで読むとよいのではないかと思います。（というのも、意味波の項で説明しますが、まさにそのような取り組みが理解をする上で重要なことなので。このような本の構成になっている事自体が、意味波を強く意識したものであると思います。）

すぐに使える具体的な結論と、豊富な演習

この本では、以下のようにすぐに使える具体的な結論が明示されていて、実用性・具体性が非常に高いのがポイントです。

• 単純な記憶の有無で読み書きの効率が圧倒的に変わる
• 素早く覚えるにはフラッシュカードを使う
  • 文法もデザインパターンも
• 能動的に考えて記憶を強化する
• 問題解決能力を向上させるには、
  • 反復的に意図的な練習を行う
  • 独力で自分自身で問題を解く事よりも、範例を見る事の方が効果的

資格試験をしている人にとっては自明かもしれませんが、小学校でも使うフラッシュカードが勉強に有効であるならばプログラミングにもそれは有効と考える方が自然で、実際に有効であるとこの本の中で主張されています。また、範例を見せる事に関しては、例えば中学や高校の数学の授業で例題を解くという行為がそれにあたります。そして反復的に意図的な練習を行うために類題を解いています。小学校、中学校、高校でやるようなことを、プログラミングの勉強においてもやるべきというのは、大変真っ当な事だなと思いました。
スポーツや音楽の世界では、フォームや"型"の練習が重要で、そうした基礎的な練習は一流になるためには欠かすことのできない要素と感じます。とすれば、プログラミングでもそうなのではないかと私は思っていたのですが、実際そうなのだという事が論文を挙げて示されていて、ですよね〜〜〜と思いました。

他にも、この本の中には知識を実際に使えるようにするために具体的な演習が豊富に盛り込まれています。きちんと定着させるために、この演習の全てに取り組むことを強くおすすめします。 ここで述べた以外にも、多くの示唆に富む事実があります。

際立って重要な事実たち

フラッシュカードや範例といった具体的な方法は重要ですが、他にも理論として重要な内容がいくつもあります。
この項では、今の私が際立って感銘を受けた事柄について記していきます。

メンタルモデル

人間が何かを考えるとき、何らかの仮説や部分的な理論に基づいて推論をする ことがあります。
このような推論において、人間は考える対象を"扱いやすい形"に単純化して考えています。この「人間がものを考える事のしくみ」の基本と位置づけられるのが、メンタルモデルというものです。

たとえば、私達は感覚器官を通してすごく沢山の情報を受け取っていますが、その情報のすべてが「今考えたいこと」に対して必要とは限りません。目の前に保育園児が5人いて、椅子がいくつかあって、すべての園児が椅子に座れるかどうかを数える状況を想像します。このとき、椅子の光沢や細部の形状は重要な情報ではなくて、ただ椅子が何個あるのかという椅子の数だけが重要な情報です。自分が触れている情報から椅子を抽出してしまえば、その他の情報は不要な情報になります。
これは、感覚器官を通して受け取る情報に限ったものではありません。頭の中で考え事をするとき、考える対象を単純化したり、自分が既に知っている別の概念を用いてアナロジー的に理解することで、考えやすくなる場合があります。
このように単純化やアナロジー等によって、問題についての推論を行いやすくするモデルのことをメンタルモデルと言います。（この本の中では、「メンタルモデルは、目の前の問題について推論するために、ワーキングメモリの中で概念を抽象化するものである」という定義が好ましいと述べられていて、言いたい事としてはほぼ同じ事だと思うのですが、細かい違いについて記事の最後に少し述べます。）

メンタルモデルは、部分的な推論を大きく助ける反面、適用できる領域がある程度限定されています。また、同じ事柄に対して複数のメンタルモデルが存在していたり、メンタルモデル同士が矛盾したりする場合もあります。メンタルモデルはある意味で「世界に対する仮説」とも言えますが、確立された物理法則とは異なり、「同じ前提を満たすすべての物体に同じ法則が成立するとは限らない」といった特徴があります。
また、メンタルモデルには教訓としての意味もあります。例えば、Wikipediaには「野生動物は危険だ」というメンタルモデルが挙げられていますが、このメンタルモデル（先入観？教訓？決めつけ？）によって、野生生物というものへの認識が何もない人と根本的な振る舞いが変わります。メンタルモデルによって、そもそも問題を問題として初めて認識できるというような場合も存在しており、単なる法則の枠組みを超えて、物事の捉え方を規定する要素もあります。

一般に、何らかの物事を理解するということは、自分の中にメンタルモデルを構築するという事と解釈することもできます。プログラミングにおいては、読者のメンタルモデルの構築を自然に促したり、あるいは多くの人が自然に持っているメンタルモデルに沿ったコードの場合には理解が進みやすくなります。
そのため、メンタルモデルを明示する ことが実装上の一つの指針として機能します。例えば、クラスをふんだんに使って具体的な実装をすることは、場合によってはメンタルモデルの構築を助けるかもしれません。ただし、私はこのようなコードは"途中の段階"である可能性もあると思っています。詳しくは「応用論：具体性に特化した設計と"その先"」の項で述べます。

可読性の詳細化 - 認知特性と活動のマトリクス

プログラミングにおいて、可読性や保守性という概念が考え事のテーマになりがちですが、単に可読性や保守性というと曖昧な事があります。この可読性という曖昧な概念（の一部）を、認知特性と活動という2つの切り口で整理したマトリクスがこの本に掲載されています。それぞれの詳細についてはこの本に説明を譲るとして、次に表のみ引用します。

認知特性	助ける活動	害を及ぼす活動
エラーの発生しやすさ		増強
一貫性	検索、理解	転写
拡散性	検索
隠れた依存関係		検索
暫定性	探索
粘性		転写、増強
段階的評価	探索
役割表現力	理解
マッピングの近接度	増強
ハードな心的操作		転写、増強、探索
副次的表記	検索
抽象化	理解	探索
視認性		理解

※P240 表12.1より引用

これらの認知特性の間には、相互にトレードオフ的な状況が発生する場合が多々あります。
例えば、単純なものでは、変数の名前を長くするか短くするか、という事があります。全体的に変数の名前を長くするようなコード規約をつくると役割表現力は増加しますが、一方で拡散性（≒記述の長さ）も上がります。
このように、これまで雑に可読性と表現してきた概念が詳細化されているのは非常に納得感があります。
いくつかの指標がある中で、どのようなバランスを目指すかというのはまさしく設計なので、これは認知特性に関するコード設計に役立つ概念です。この概念があると、単に「可読性を高くする」という表現に留まらず、「意図的に役割表現力を高くしていく」「意図的に拡散性を低くしていく」といった踏み込んだ選択が可能になります。

認知を超えた自動化/自律的段階の重要性

考える対象を認知するという事は重要ですが、高速に処理を行う＝熟達した処理を行うためには、考えずに処理ができるまでに自動化する事が必要です。
自動化するには、認知的段階、連合的段階、自律的段階という３つの段階を経る必要があります。これを意図的に進める上で有効なのが、具体的な結論の項で述べた「反復的に意図的な練習を行う」ことであり、「独力で自分自身で問題を解く事よりも、範例を見る事の方が効果的」ということです。

ちなみに、これはかつて登大遊さんが論理的思考の放棄や論理的思考の放棄の具体的方法として説明されていた事とある意味で似たような内容と感じます。（ただし、鉄球を想像しながらも手が動く状態は過程というより結果であって、まずは単純に手を動かすようなことをしまくって、その結果として流れるように手が動く状態になるのかなと思いましたが。）

意味波 - 抽象→具象→抽象の波

初心者が概念を学ぶとき、その理解が進む過程をモデル化したものとして意味波(semantic wave)というものがあります。一言でいうと、理解が抽象→具象→抽象という順で進むというモデルです。

• まず一般的な概念を学ぶ（抽象）
  • 何のために使われるのか、なぜそれを知る必要があるのか
• 概念の詳細を学ぶ（具象）
  • この抽象→具象を「アンパッキング(unpacking)」という
• 最後に、概念が一般的にどのように機能するかを知って腹落ちする（抽象）
  • この具象→抽象を「リパッキング(repacking)」という

したがって、初心者が概念を獲得するには、抽象→具象→抽象という抽象と具象の行き来を、適切なタイミングで行う必要があるということです。これは、概念を教えられて獲得する場合にも言えることなので、概念を教える場合にもこれを意識する必要があります。
この抽象→具象→抽象という意味波のモデルに従うと、概念を教える場合には3つのアンチパターンがあります。

• ハイフラットライン：抽象的な説明のみを行う
• ローフラットライン：具体的な説明のみを行う
• 下降専用エレベーター：抽象度の高い話から具体的な話に行くが、リパッキングを忘れている

※P252、図13.3より引用

個人的には、この「下降専用エレベーター」というものが非常に学びの深いものでした。つまり、抽象→具象と説明を進めて、最終的に具象→抽象に戻るような行いをして、自分自身が持つそれまでの知識となじませて、長期記憶にネットワークを構築するようなことをしなければ、個別の具体論を具体的な場面で認知することはできても、積極的に問題解決などに活用できるようにならない ということです。いわゆる応用力が無い状態が、このように引き起こされるという事でした。
応用力のある状態に到達するには、具体的な操作ができる事では不十分で、具体的な操作を繰り返した上でそれを抽象論としてリパッキングする過程が必要になるという主張については、なるほどと思いました。

実際、私は昔から、少なくとも高校生ぐらいからこのリパッキングする過程をかなり無意識的にやっていて、まさにこの記事を書いているように、何かを学ぶと自然とそれをまとめたくなる気持ち（欲望？）があります。一般にアハ体験などと言われる体験がありますが、おそらくこのアハ体験を意識的に発生させる方法がリパッキングで、「ああそうか」と思うために/思ったことを記録するためにまとめる記事を書いていたりします。
ところが、当然ですが、一般にはそんな事が習慣になっているとは限らないので、下降専用エレベーターのような体験をすると、そのままになる場合があります。そうすると、私のように趣味でリパッキングする場合と知識の定着に差が出る事になります。自分が過去に接触した人を振り返ってみると、この下降専用エレベーターなどのアンチパターンから"自力で"復帰する力がその後の定着を左右していたように思われ、自分の過去の取り組みの至らなかった部分がある程度わかったように思いました。

この本の話の進め方について

ところで、実はこの本における話の進め方も、この意味波を強く意図した説明になっています。つまり、まず一般的な概念としての説明をはじめて、演習を交えて具体的に掘り下げて行き、最終的には実用上の効果や抽象的な結論を示す、という説明が繰り返されます。
演習をすべてやった方がよい、というのはまさにこの事と密接に関係しています。つまり、抽象→具象→抽象という波を意識して知識を実用的な状態で定着させるためには、アンパッキングとリパッキングを進めるために演習が不可欠なのです。

*argsについて

ちなみに、これは全く本題ではないのですが、この本のunpackingの説明でpythonの可変長引数*argsを扱っています。じつはこれは秀逸な洒落になっていて、pythonでてきとうな関数に対してリストやタプルに*をつけて引数を渡すことをunpackingといいます。
https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists

>>> list(range(*args))            # call with arguments unpacked from a list
[3, 4, 5]

*でunpackするよ、というのをかけた洒落で、思い出しやすく/定着させるためのフックにもなっています。
読んでいて楽しい気持ちになりました。

応用論：具体性に特化した設計と"その先"

この項で述べることは、この本に書かれている事というよりも私の考えが中心です。みなさんも是非考えてみてください。

設計論でしばしば登場する考え方として、様々な概念をとにかく細かくクラスとして定義していくというものがあります。ネタツイではありますが、以下のようなものが例として挙げられます。

※出典：https://twitter.com/MinoDriven/status/1621425477528457217

私としては、このような設計には合理性が感じられません。というのは、このような設計においては、コード量の意味での認知的負荷が増えるからです。定義が別のファイルに書いてあったなら一々定義を参照しないといけません。ある処理を行っている箇所について全体的にコードを把握しようとすると、複数のファイルを行き来しながら理解をしないといけないので、私個人的には「認知的負荷を減らす/"可読性を高める"ためにこのようなコードを書く」という事は全く信じられませんでした。

一方で、このような設計のコードを読み進めていくと必ず細かい内容が定義されているという事があり、じつはコードを読んで手続き的な意味を考えるというような点においての認知的負荷は小さくなります。つまり、上記のラーメンの設計の場合、麺の硬さの概念をクラスにしておくと、コードを辿った結果それぞれの硬さに対応した個別の具体的なメソッドに必ずたどり着くという状況になるかもしれません。そうすると、例えば麺を茹でるメソッドの中では状態を考慮する必要がなくなり、全体を把握するために必要な定義参照の数や、全体を把握するために必要な認知的負荷＝（自分の脳の）ワーキングメモリーと引き換えに、一つのメソッドの中を把握するための認知的負荷は減らす事ができます。
一般に、汎用性が高いコードというのは何らかの変数・引数が存在して、それらの値が柔軟に変化できることで汎用性がもたらされるので、そのような自由度があると必然的にコードを読み解く負荷が増える事になります。

...という事をこれまで思っていたのですが、この本の知見によれば、実はこれだけではなかったのです。
というのも、この設計でやりたい事は 「メンタルモデルをより明示的にコードで表現したい」「メンタルモデルを誰でも読み解けるようにしたい」 という事なのだと思うのです。
つまり、汎用性を考えれば麺の硬さを個別にクラスにはしないと思うのですが、「このプログラムで扱う要素として麺の硬さというものが存在するのだ」という事を、コードだけでメンタルモデルとして強くインプットするために、そのようなコードを書くことを推奨している、という事なのだと思いました。

そのような観点では、たしかにメンタルモデルを表現できているコードの方が良い...と思ってしまうかもしれません。しかし、ここで意味波の考え方を思い出してください。意味波の考え方では、理解は抽象→具象→抽象と進むのでした。もし仮にプログラムが人のメンタルモデルや理解の構造を反映すべきであるとするならば、それは最終的には抽象を反映すべきです。 実際、麺の硬さを個別にクラスにしない抽象的なコードの方が、粉落としやハリガネ、カタといった新しい硬さを柔軟に定義しやすくなります。

ただ、抽象的なコードは、熟達していない人にとっては読みにくいという事も（場合によっては）あります。そのような場合、この本においては、最終的なアウトプットの形を初心者向けに変えるのではなくて、逆リファクタリング を推奨しています。つまり、抽象的なコードを具体的な状態に意図的に書き換えて、コードを一時的に自分の理解の段階に合わせるということです。これも、意味波の考え方で納得できます。難しいコードを理解しようとすると、抽象→具象→抽象という流れに乗せる必要があって、一度具象の状態に書き換えて理解を促進するという事ですね。
また、どうしてもメンタルモデルを示しにくくなるという事であれば、それはコメントやその他の手段によって補うこともできます。

総じて、具体的に書き出せることそれ自体は、要件を達成できるという意味で良いことだと思いますが、さらに一歩進んで 抽象化されたメンタルモデルが適用される形式をコードでそのまま実現できれば、より解決すべき問題を深く理解した適切なコードという事になる と思います。具体的なコードで止まらず、抽象化できるとすればどこか、という事を考えると熟達者に近づけるのではないでしょうか。

総評

個人的には、過去に読んだプログラミングの本では一番勉強になりました。
常々、少なくとも4年前から「世の中コードの書き方に関する格言は多いけど、コードの読み方に関する格言は少ない」と思っていた私にとっては、待望のコードの読み方の解説でした。特に私自身というよりは、他の人にどうやってコードの読み方を伝えればよいのか・読み方を上達してもらうにはどうすればよいのかと思う事がしばしばあったので、その解決の糸口が得られたように思います。
また、コードを書く立場としても、「可読性とは？」「こう書き換えた方が認知的負荷が下がるのでは？」というようなある種の議論について「本当にそうか？」と思う事が多かったのが、概念として細分化される事によって正しくメリット・デメリットを議論できるようになり、これは非常に良い事だと思いました。
意味波という考え方については、意味波という名前ではないにしても「学問は螺旋のように抽象と具象を往復して深まっていく」みたいな事は中学生〜高校生ぐらいには認識していて念頭にあったつもりなのに、「具象→抽象が欠けている教授法"下降専用エレベーター"はアンチパターンである」という認識が全くなかったので、私はだいぶポンコツだなあと思いました。まあ、ポンコツでも頑張ってやっていくしかないので、良い学びの機会を得られた事に感謝してやっていきます。また、このことは一般に「アウトプットするとなぜ理解が深まるのか」という事への認知科学的な一つの答えになっているのかな、とも思い、そのような点でも示唆がありました。
大変良い本で、万人に推薦できる本であると思います。

その他の補足

この記事で取り上げていない内容について

例えば命名の重要性などは、認知科学的なアプローチでなくても従来より言われている事なので割愛していますが、それ自体は重要な事であると思います。メソッド名は4単語までにした方がよいとか、ここでも具体的な示唆があります。
変数の役割の11分類や、コードに書き込みをして具体的に読み進める方法なども効果的です。

具体例がセンスフル

意味波の項で述べたunpackingと*argsの例もそうですが、他にも「変数は箱かラベルか」というようなメンタルモデルの例であったり、具体例の選び方が非常に秀逸であると思います。

抽象化と単純化の違い

メンタルモデルの定義について、この本の内容と私が書いたことの微妙な違いとしては、抽象化ではなく単純化やアナロジーという言葉を使っている事があります。抽象化と単純化は似ている概念ですが、私の考えでは、以下のような違いがあります。

• 抽象化：Aを抽象化して得られる概念Xは、常に「AはXである」という性質を満たす
• 単純化：Aを単純化して得られる対象Sについては「AはSである」とは必ずしも言えない

したがって、もとの性質が変わってしまうような場合には抽象化ではなく単純化やアナロジー、あるいは一種の近似として理解すべきと思います。
（これは、おそらく数学的な考え方に由来するもので、数学で概念を抽象化する場合は多くの場合ここで述べた意味での抽象化になっていると思います。しかし世間では単純化のことを抽象化と言う場合があるように思いました。）

ちなみに、ChatGPTによると以下のようです。私が上に書いたことと同じかなと思いますが、いかがでしょうか。

抽象化と単純化は似たような概念ですが、微妙に異なります。

抽象化とは、ある対象や概念から本質的な特徴や共通点を抜き出し、それをより一般的なレベルで表現することです。例えば、複数の動物を考えたとき、それらの共通点を抜き出して「動物」という抽象的な概念を考えることができます。抽象化は、複雑な現象を簡単に表現するために用いられることがあります。

一方、単純化とは、対象や概念を単純にすることです。これは、複雑な現象を扱いやすくするために、必要以上に複雑な要素を除外して単純に表現することがあります。ただし、単純化が過剰に行われると、必要な情報や詳細が欠落する場合があります。

簡単に言えば、抽象化はより一般的で抽象的なレベルにまで情報をまとめることを意味し、一方、単純化は情報を簡単にすることを意味します。

科学に対する接し方について

認知科学の分野はまだまだ発展途上で、論文つきで示されている内容についても、例えば統計的に意味のあるデータに基づいた議論であるかとか、厳密に根拠のある法則として扱ってよいかといった事については、疑問符がつくような場合もあると思っています。別の言い方をすると、この本で紹介されている様々な考え方そのものがある種のメンタルモデルであって、相互に矛盾したり、厳密には間違っていたりという事も全然あると思います。そのあたりは、すべての主張を鵜呑みにして良いという事ではないと思っています。
ただ、この本の中で述べられているとおり、メンタルモデルは厳密に考えて誤っていても有用な事があり、また改善していくこともできます。絶対的な事実としてではなく、「現時点においてはある程度有効な情報の塊」として、私はこの本を評価しています。