2023年2月に発売された『プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ』（秀和システム）。著者のフェリエンヌ・ヘルマンス博士は、プログラミング教育やプログラミング言語の研究に取り組んでいます。本書では、最新の「認知科学」に基づき、プログラミングの際のさまざまな作業や技術の取得を効率的におこなうための方法を解説しています。
優れたプログラマーになるにはどうすればいいのでしょうか。この本の翻訳を担当した水野貴明さんにお話をうかがいました。
目次
感覚的なものが言語化された
――本書を翻訳して、水野さんご自身が得た学びを教えてください。
水野：
秀和システムの編集者さんとは以前から付き合いがあり、「おもしろい本があるから翻訳を担当しませんか？」と久しぶりに連絡をいただきました。
翻訳を担当したことで、たくさんの学びがあります。本書は認知科学的な観点から、プログラミングをはじめとした開発全体での“所作”について書かれています。直感的に「そうだろうな」と思っていたことに対して、裏付けが書かれている本です。
たとえば、読みづらいコードは、なぜ読みづらいのか。読みやすいコードは、なぜ読みやすいのか。具体的な理由が本書には書かれています。感覚的なものが言語化されているんです。
本書には事例と説明が書かれていて「マジかよ！？」と思ったこともあります。「人は認知的負荷の高い作業をマルチタスクでこなすことはできません」と書かれているんですね。
自分はマルチタスクが得意だと思っていたんです。でも本書によれば、おそらく得意というのは幻想で、効率は下がっているんですよね。
マルチタスクを避けるのは難しいですが、一度はじめたことは、なるべく完了まで持っていくようにして、フロー状態をつくれるように努力しています。
あとは、新人の方がプロジェクトに入るときに「どうすればもっとうまくプロジェクトに入ってもらえるか」というオンボーディングの学びにもなりました。
――オンボーディングの学びですか。どのような学びがあったのでしょうか？
水野：
本書の中に、よくある事例が載っているので紹介します。経験を積んだ開発者は、コードが対象とするビジネス領域や開発ワークフローなどを、初心者の方へ一気に紹介してしまいがちです。そして紹介が終わると小さなバグを修正したり、小さな機能開発をするなどの簡単なタスクを与えたりするのですが、大体うまくいきません。これ、自分の経験からも「本当にそうだな」と思うんです。
開発には知識が必要で、知識には「ビジネスに関するもの」と「システムに関するもの」があります。それらがあって初めてコードの修正などができるんです。最初は複数のことではなくて、1つのことだけやってもらう。たとえば、知識を得るためにドキュメントの制作をしてもらうなどですね。自分の仕事でも、オンボーディングをするとき、まずはドキュメントの制作をお願いするように変えました。
本書は初心者の方が読んでも役に立つのですが、経験を積んだマネージャークラスの方にはとくに役立つと思います。これまで初心者の方への接し方が間違っていたことに気づける本です。
コードを理解するには、意外とアナログな方法が役立つ
――本書の中に「ある調査によると、プログラマーの時間のほぼ60％は、コードを書くことよりも理解することに費やされています」とあります。水野さんご自身もそう感じますか？
水野：
そうですね。コードを読んで理解する時間は多いです。僕の場合、最近は火消し作業というかトラブル対応が多いので……。たとえば、開発していたメンバーが辞めてしまい、システムはあるんだけど理解できている人が誰もいない、といったケースなどです。
そういうトラブルが起きたとき、まずは「何が起きているのか」を理解する必要があります。火元の原因探しですね。そのためにコードを読んで理解することに時間を費やします。
――まさに本書の中に、他人が書いた馴染みのないコードを読んで理解する方法について書かれています。その方法について教えてください。
水野：
まず、コードを印刷するか、PDFに変換してタブレットで書き込めるようにします。そして、すべての変数を丸で囲み、同じ変数や関連した変数を線でつなぎます。そうすると、つながりがわかって理解しやすくなるんです。この方法は僕の中では、かなり新鮮でした。
経験を積んだ方なら、コードのチャンク化（情報を組み合わせるまとまり）ができています。だから「ここがこうなら、あそこはこうなっているはず」と頭の中で理解できます。でも経験のない、あるいは浅い方の場合は、紙やタブレットで書きながら理解していく方法が役立つと思いますね。
他にも、本書では結構アナログな方法が紹介されています。
たとえば、プログラミング言語を覚える方法として「フラッシュカード」を利用する方法が紹介されています。受験勉強で英単語を覚えるときによく使うやつです。アナログなやり方ですが、しっかり記憶しないと読んで理解できないのは当たり前だよなと思います。
コードを書く際に、調べる時間はもったいないので、生産性を高めるためには覚えておくことが大事です。
コーディング中の混乱が起きる理由
――本書では「コーディング中の混乱が起きる理由」について書かれています。どのような理由か教えてください。
水野：
混乱には「知識不足」「情報不足」「処理能力の不足」という3つのタイプがあります。それぞれには異なる認知プロセスがあり、それが問題に関連しています。
- 知識不足＝長期記憶の問題
- 情報不足＝短期記憶の問題
- 処理能力の不足＝ワーキングメモリの問題
個人的には、ワーキングメモリの問題が一番大きいのかなと思います。最も起こりやすいともいえます。コードを書いているときに「あれ？ いま何やってたんだっけ？」という状態になるのもワーキングメモリの問題です。
長期記憶と短期記憶の問題は調べれば何とかなりますが、ワーキングメモリの問題は調べるだけでは何ともなりません。途中でわけがわからなくなります。解決するために、リファクタリング（外側から見た動作は変更せず、プログラム、ソースコードの内側のみ整えること）や依存関係グラフ（ソースコードなどのメタデータを格納する場所に保管しているロックファイル）の作成など、少し面倒な処理が必要になります。
――処理能力と関連して、本書の中には「割り込み」の問題も書かれていました。割り込まれてしまうと作業が中断して、集中できるまでに時間がかかりますよね。
水野：
とても集中できている状態の「フロー状態」になるまでには、時間がかかるという話は有名です。でも、意外とわかっていない人が多くて、開発者以外の方がカジュアルに話しかけてくることはありますよね。
フロー状態から抜けた後、またフロー状態に戻るまでにかかる時間は人によって違いますし、割り込みを不快に思うかどうかも人によって違います。
なので、自分のチームメンバーには、開発者に直接コミュニケーションしないように伝える場合もありますね。人によっては、まずは僕に話をしてもらって、タイミングを見計らって僕から開発者に伝えるようにしています。
“良いコード”とは？
――より良いコードを書くための方法が本書の中で紹介されていました。良いコードとは何でしょうか？ また、良いコードを書くための方法についても教えてください。
水野：
良いコードというのは、一般的には拡張のしやすさやメンテナンスのしやすさなどが挙げられます。
本書においての良いコードというのは「認知的負荷を与えずに読み書きできる理解しやすいコード」です。プログラマーの間では、「コードの臭い」という言葉があります。「このコードは、何かヤバそうな臭いがする」と感じることがあるんです。なんでヤバそうな臭いがするのかというと、長すぎるメソッドや重複したコードなどで効率的なチャンク化ができていないため、読んだり理解したりするのにすごく認知的負荷がかかるからです。
そうならないように、読みやすくて理解しやすいコードを書く必要があります。変数やクラス、メソッドに適切な命名をする、コメントを書く、デザインパターンを利用するなどの方法があります。
本書の翻訳をしてから、僕がおこなうレビューでも命名についての指摘が多くなりました。ルールを決めて、それに沿った命名をしてもらっています。そうしたほうが読みやすいからです。レビューにおいて「なぜそうしたほうがいいのか」という理由の説明がしやすくなりました。感覚の言語化に役立っています。
（取材／文：川崎博則）
