仕事で“無理をしている”と感じるときは「脳の使い方が間違っているサイン」――。そう語るのはベストセラー『世界一流エンジニアの思考法』の著者、米マイクロソフト現役エンジニアの牛尾剛さんだ。脳にとって一番合理的な仕事の仕方とは？

（※本稿は、前掲書から一部抜粋したものです）

◆◆◆◆

いつも脳がぐったり疲れていた私

　私はプログラマでありながら、何を隠そう一番苦手で克服できていないことが、コードリーディング（ソースコードを読むこと）だ。ものすごく時間がかかるし、時間をかけたわりに読み間違えたりするし、脳がぐったりと疲れるので、敗北感しか残らない。

　マイクロソフトに来た当初、この問題をマネージャのプラグナに相談したら「最初は2 時間かかるだろうけど、3カ月もしたら5分で終わるわよ」と言われたが、そもそも今の自分は最低でも4時間かかるが……と愕然としたものだ。

　私は自分のキャリアの中で、OSS（オープンソースソフトウェア）の開発に関わることはあったが、巨大で複雑なコードベースを読んで理解する必要に迫られたことがほとんどなく、一からコードを書くのは得意だが、どうやったら他人のコードを読んでしっかり　把握できるのかがよくわからなかったのだ。

　当然、私は自分の周りのエンジニアたちにコツを聞いてまわったが、どうも要領を得ない。多分息を吸って吐くようにコードリーディングができてしまう人からすると、コツを　改めて聞かれてもよくわからないようだ。

超優秀な同僚の衝撃のひと言

　あるとき思い立って、入社間もない若い同僚のクーパーに聞いてみた。彼は、私が複雑すぎてうんざりしていた巨大なアーキテクチャにも怯ひるむことなく挑んでいて、しかも読むのがものすごく速い。悩みを相談すると、好青年のクーパーはこう言った。

「コードリーディングのコツは、極力読まないことですよ。他のデベロッパーのことを信頼して、実装はちゃんと動くものとする。だって、たくさんコード読むと、圧倒されちゃうでしょ？」

　なるほど……目からウロコだった。自分はいつもコードを端から端まで読もうとして、細かく読んでいるうちに、自分がどこにいるのかわからなくなって混乱したり、忘れたり、脳が疲れ切ってしまうことが頻繁にあった。

　これは、自分が低レベルだからだと思っていたが、どうやらそうではないようだ。私は常に自己評価が低い性格だが、「自分ができないからこうなのだ」という思い込みはたいてい大きな事実誤認を生む。本質は脳の使い方にあるようだ。

いかに脳みその負荷を減らすか

　クーパーはさらにこう解説してくれた。

「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係性のグラフを書いたりしながら。実装はちゃんとできていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにしてるかな」

　確かによくよく考えると、コードを読むのは本当に必要な部分（クラスの役割やパターン、インターフェイスの理解）で十分だ。自分は理解するために端から端まで実装を読んでいたが、そうすると脳みそのCPUをフルに消費してしまう。そして、肝心な部分に脳のリソースを使えないため、ひどく疲れる割に頭に入らないことに気づかされた。

　読むことを減らして、脳に余裕を生む―早速このクーパーメソッドに従って、コードリーディングしてみた。本来、構造的にややこしいはずだが、余計なコードは極力読まず、使っているインターフェイスだけを理解しようと努めてみる。すると、2時間もたたないうちにこう思った。

「楽勝じゃね？」

「難しすぎる」と感じるのは脳の使い方が間違っている

　新規のコードベースや、そのプロジェクトと別のプロジェクトがどう関連しているのかはわからない。でも、それでよかったのだ。全部をゼロから理解するのは難しいから、不明な点は素直に人に聞いた。もちろん一部の実装コードは読んだが、普段と比べて脳の疲れが全くない。読む箇所が少ないのでつらくもなんともなく、正確に読めている。

　プログラマにとって、コードリーディングの正確さとスピードは最重要な要素だが、やみくもに頑張るのではなく、いかに「自分の脳の負担を減らすか？」と考えるアプローチが非常に有効だったのだ。

　人が「自分にとって難しすぎる」と感じるものには二つのケースがある。一つは、自分の基礎的な学力が足りていないもの。これは地道に積み上げるしかない。例えば私なら証明書の実装を自分で書けと言われたら初歩の勉強から始めないといけないだろう。でも、こんなケースはまずないし、そもそも手を出さなければ良い。

　二つめは、自分が無理なやり方をしているケースだ。「自分には何かが足りない、才能が足りないから、こんなに大変」と思い込んでいる場合だ。自分にとって難しすぎると感じるときは、たいてい脳の使い方が間違っているサインだ。

　才能の差なのではなく、脳に余裕のない状態で酷使している可能性が高い。

いかに「レベル1」を増やすかが生産性に直結する

　この問題を仕事の難易度レベルにそって、さらに深掘りしてみよう。脳の使い方のアプローチがよりクリアになるはずだ。

レベル1：何もググらずに即座に実装できるもの。

レベル2： 問題をどう解決するかはすぐに思いつくが、具体的な方法は忘れているので、ググる必要があるもの。

レベル3： 自分は解法を知らないが、スパイクソリューション（課題把握のための大まかなプログラム）をしたらできそうなもの。

レベル4：自分だけでは解決が難しい、もしくはものすごく時間がかかるもの。

　これまで私は、レベル4をクリアできるようにならねば、という焦りから必死に取り組むのだが、一人でやると丸一日つぶれたり、それでも理解が中途半端だったりすることがよくあった。自分のできなさ加減を思い知らされて、相当つらい気分になるし、仕事としての成果も出ない。

　自分の実力を冷静に分析したとき、エバンジェリストやコンサルタント職が長かったおかげで、レベル2の知識は結構ある。例えばリフレクション、動的クラスローディング、コンカレントなプログラミングのコンセプトも「知っている」が、作業には「Google が必要」である。

　そこでふと、生産性とはいかに「レベル1」を増やすかではないか――レベル2がそこそこある私の場合、レベル3や4の増加を目指すよりも、レベル2案件をレベル1に向上させたほうが生産性が高いのではという気づきを得た。

自分がしんどいと思う「努力」は一切やめる

　コードリーディングが遅い根本的な原因は、コードを見たときにどういう挙動をするか明確にすぐにイメージできないか、もしくは構造の把握が下手だからだ。だが、レベル1のものが増えると脳の負担は激減する。

　例えばプログラマなら、プログラミングを学んだら最初に出てくるものの一つFor ループ（プログラムを繰り返し実行する構文）の挙動は、誰でも自信を持てているだろう。このループを見て一瞬で把握できるような理解を、他のコーディングにも広げていけばよい。すると、もっと重要で細かい部分に目が配れるようになる。

　構造の把握は、パターンやイディオムや、その言語のライブラリの癖に慣れてくると理解のスピードが上がるだろう。重要なことは、自分がしんどいと思う「努力」は一切やめてしまうこと。自分が「楽しくなくて、苦しい」と思うときは、「無理」があるサインだ。自分のレベルに合ってないことをやっても上達しない。

「今、解けない」部分を見極めて割り切る

　私が人生の趣味で唯一「できるようになった」ギターの例を考えると、究極のコツは「他の人がびっくりするようなスローなテンポ、自分が心地よく弾けるスピードで、メトロノームと一緒に練習する」ことだったが、これをプログラミングに当てはめると、自分が楽に取り組める難易度の低いもので練習すべきなのだ。

　つまり、プログラミングの場合、レベル1の課題がもっともコントロール感がある。その水準のものでいいので、自分が何も見ずにさくさくコーディングできるものを増やしていく。

　これは「自分の脳の負担を減らす」非常に合理的なアプローチだ。

　レベル1の領域を増やしつつ、レベル3の仕事は素直にラーニングコースなどでさっと学んでしまうのがよいだろう。問題はレベル4がきたとき、どうしたらいいかだ。 　

　やらないのも一つの選択肢だ。自分には手に負えないことを素直に認めて、人に頼るのもいいし、その分野のラーニングをやることで底上げされてレベル3くらいまで理解が深まるかもしれない。

　いずれにせよ重要なのは、「今の自分では解けない」としっかり見極めること。自分のレベルが上がればいつの日かそれがレベル3の範囲になるかもしれないが、それまでは割り切って他の部分での生産性を最強にすればいいのだ。