導入
最近、ふと会社の本棚で「世界一流エンジニアの思考法」という本が目に入り、ちょうど何か新しい、そして読みやすい（技術詳細などではない）本を探していたため手に取ってみた。
初めは、「世界一流エンジニア」なんて不思議な日本語だな、なんて思っていたが、読み始めるとまあ止まらない。本の内容が、ちょうど今自分が感じ始めていたことと重なる部分があったり、参考にしているギタリストが同じだったりと、不思議なほど自分と親和性が高いように感じられたためである。
一気に読み終えてしまったが、ちゃんとアウトプットとして何か残しておきたいと感じ、こちらに備忘録として記事を作成する。
今回は1章の、そして考え方の部分にのみフォーカスを当てて書いていく。具体的なツールなども出てくるがそれは記載しないので、興味がある方はぜひ読んでみていただきたい。
もし本を買う気がなくても、著者のnoteで近い話が読めるのでぜひ訪問していただきたい（このnoteをベースに本が作成されている）。
基本的に自分向けの雑記となり、かつ自分に深く刺さった「理解の重要性」に焦点を当てた文章になると思う。
ただ、この業界で、そしてプログラマーとして仕事をしている方は、ぜひ一度手に取ることをおすすめしたい。（勧められなくったって読んでる、なんて人も多いかもしれないけど）
自分のスペック
前提として、私のスペックというか経歴を簡単に記載しておく。
- IT業界3年目（= 社会人歴）がもう少しで終わる
- 1社目のSES企業を11ヶ月で退職
- 同時に現在働く会社に入社し、エンジニアとして勤務しちょうど2年が経つ
- そこで、フロントエンド・バックエンド・インフラ等一通り（広く浅く）携わる
- チームメンバーからのエラー相談等も最近は少し的を射た回答ができるようになってきた（と思う）
とても平凡な経歴である。
しかし、そのような人でもこの本は大いに参考に、むしろある人にとっては救いになるかもしれないと感じている。
前提
内容に入る前にこの本の筆者について、すごく簡単で恐縮だが紹介させていただく。
その方が、より内容が身に入る気がする。
- 米マイクロソフトのAzureFunctionsプロダクトチームシニアエンジニアとして勤務
- 1971年生まれ
- 私は「一流エンジニア」ではない。なにも謙遜しているわけではなく、ガチの「三流」だ、と本書で述べられている
この、「三流」というところで、「本当なのだろうか、、、？」と邪推してしまう。というのも、マイクロソフトで働くエンジニアの方々などほんの一握り、ましてや世界規模で利用されるAzureのプロダクトを担当しているだなんて、相当聡明な方しかいないはず、と思っているからだ。
しかし、もしそれが本当ならば、凡人の自分にとって大きな希望となるはずである。人間は都合の良いことを信じがちなので気をつけなければならないが、ここは素直にこの方を信じて進みたい。
本題
というわけで、ここから本の内容に触れつつ、自分の感想も残していく。
あくまで自分向けなので、フラットに内容を見たい方はぜひ自分で本を読んでほしい。
世界一流エンジニアは何が違う？生産性の高さの違い
この本の1章のタイトルである。マイクロソフトという世界最大手のIT企業の一つで働く人たちの圧倒的な生産性について述べられている。
自分は無関係のように感じられるかもしれないが、私たちの身の回りにも
- なぜか問題解決が早い人
- 自分では解決できなかったことを相談したところ、いとも簡単に、そして魔法使いのように解決してしまう人
- 残業などはせずとも、多くのアウトプットを出す人
というような、似たような人たちは存在する。
なぜこのような人たちは問題解決力・生産性が高く、そして自分がそうなるためには何が必要なのか、を教えてくれるのがこの章である（と思っている）。
はじめに：思考錯誤は悪である
著者は、元々は上記のようないわゆる「技術イケメン」ではなかったらしい。プログラミングに憧れを持っているが、プログラミングは苦手だったそうだ。
しかし業務の中で自分の思考法を変える転機があったそうで、そのエピソードが記載されている。
ざっくりと以下のような内容である。
ある日、プログラムでうまく動かない箇所があった。自分で解決しても良いが、経験則から原因解明だけで数時間~数日かかってしまいそう。そこで、同僚にペアプログラミングをしてもらった。
エラーログを表示し、自分ならその中の問題を見つけ試行錯誤し、あたりをつけ修正→動作確認→違う場合は他の箇所にあたりをつけ修正→動作確認、、とするところだ。
しかし、彼は一つのログを見て、仮説を立て始める。手は一切動かさない
そして、クエリを一つ投げ、見事その原因を突き止めてしまった。
加えて、他の同僚の方が言っていたことが以下だったそうだ。（大まかな内容）
障害の調査をするとき、いきなり手を動かして色々なクエリを投げてはいけない。ログをみて、何が起こっているかを推測し、それを解決するようなクエリをなげてそれを証明するのだ
そう、上記のように、この本では「試行錯誤は悪である」と述べられている。何かの対応の際、とりあえずこれはどうだ、こっちはどうだと試すのは良くない、むしろ悪であるのだと。
これを読み、「いやいや、そりゃ多少はエラーから推測してるよ」などと思ったかもしれない。ただ、（これは私自身の経験も大いに含むが、）以下のような行動をとったことはないだろうか。
- 新しい機能を実装する際、ネットで似たようなユースケースを探し、あまり理解しないままコピペしたら動いたのでOKとした
- エラーの原因がわからず、stack overflow で探したら同じ境遇の記事がヒットし、それをそのまま利用した
- システムがどうやらうまく動いていないが、原因がわからずとりあえずAIに聞き、答えの通りに修正したら動いたのでそのまま利用した
私は、恥ずかしいことにどれも心当たりがたくさんある。特に今より経験が浅い頃は、巨大な業務のコードを前にし、「おそらくこれを理解していたら期日に間に合わない」と勝手に決めつけ、上記のような行動をとることが多かったと思う。（ただ面倒だったことの言い訳かもしれないが）
ただ、それでは「今のコードで何が起こっているのか」を理解しないまま、「何をしているのか」を理解していないコードに置き換え、動いたから良しとしているだけである。
だから、次似たような箇所を修正するときも結局わかっていないし、開発のスピードや効率もずっと上がらないという結果を招いてしまう。
本で紹介されている障害対応とは少しズレるかもしれないが、本質的には同じことだと思っている。
どうしてそのような行動をとってしまうのか
ここは、本の内容というより私の実体験から、上記のようなことをしてしまう原因を挙げていく。
- 期日を優先している「つもり」になっている
- 「わからないことは恥」とどこかで思ってしまっている
- わからないことが多すぎて、理解する煩わしさから目を背けてしまう
もっとあるかもしれないが、ここまでにしておき詳細にみていく。
1. 期日を優先している「つもり」になっている
日々色々なタスクが降ってきて、納期や期日が設定されていることだろうと思う。そして、それはあまり経験がない時や、プロジェクトに入って間もない時でもそうだったりする。
そうすると、関連する箇所や処理全体を確認している暇などなく、とにかく何かしら「進んだ感」を求めてしまう。とりあえずモーダルを表示して、そこで初めて利用されているapiのメソッドを調べて、、というように、全体の理解を飛ばし、その一部のみに焦点を当てたくなる。
もちろん、最終的に開発する時はその部分部分を作りつなげていくのだが、場当たり的に開発していくと、似たような実装を探し似たように書きなんとなく動いた、となりがちだと思っている。
私自身も経験があるのだが、そのような手順で進めていくと、結構多くのファイルを作成し動くものができたのにも関わらず、それら一つ一つをちゃんと説明できない、ということがあったりする。
ここまでを、原因1としておく。
2. 「わからないことは恥」とどこかで思ってしまっている
この業界で日々作業をしていると、毎日のようにわからないこと、初めて見るものなどに遭遇する。そして、なぜか「他の人は理解していて、自分だけ分かっていないのではないか」と考えてしまう。特に、業界は入り立てや勉強し始めの頃に多い気がする。
その結果、周囲の人に聞くことができず、調べても理解半分くらいで、なんとなく分かった気になる・見様見真似で作成するというようなことをしてしまう。
（特に日本では、自分で調べて！のような風習が強く、なおさらその流れに拍車をかけていると思う）
この心理的障壁は、理解を妨げる原因の一つではと思っている。
3. わからないことが多すぎて、理解する煩わしさから目を背けてしまう
要するに、「理解するのが面倒」だと思って避けてしまうということだ。これは、とても自覚があり、何か言えたものでもない。
初めて業務のソースコードに触れた時、知らないライブラリ・大規模で全体の見えないdbスキーマ・複雑で何をしているのか分かりそうもないコードなど、多くのわからないことが出てきて圧倒されたことを覚えている。しかも、原因2にある通りあまり聞くこともできなかった。
正直、それを理解してからタスクの完了を目指せるほどの理解力はないと思ってしまっている節があった。今考えると、単に理解することの面倒さ・煩わしさから目を背けたくて、そういったものを一旦排除し、目の前の一部のコードと向き合うことで、なんとか心の安定を保持していたように思う。
（まあ、全てを初めから理解するのは基礎知識的な面で難しいところもあるだろうけど。）
世界一流エンジニアはどうなのだろう？
今までは、「思考錯誤は悪である」という前提と、そのような行動をとってしまう原因について簡単に考えてみた。
ここで、本の内容に戻る。では、世界一流のエンジニアたちはどうなのだろうか？
やはり、私たちとは頭の出来が違うので、色々な情報を1,2回みただけで理解し、サクサクと問題解決をしてしまうのだろうか？
再度引用になるが、著者が2人の技術イケメンと昼食を一緒に取った時のエピソードから、その疑問を紐解いてみる。
マイクロソフトでは、チームのアーキテクチャが非常に複雑なため、マイクロサービスごと内部用の説明映像があり、学習ができるようになっているそうだ。
彼らはどのようにそれと向き合うのか話していたとのことだ。そこで二人から出た話は、（著者にとっても、私にとっても）大変予想外のものだった。
ビデオを見ても難しいので10回は見る。特に難しいところはポーズし、メモしている
自分も同じで、何度も何度も見返している
そう、いくら賢く聡明な人たちでも、理解するのには時間がかかるのだ。
しかし、その基礎的な部分の理解を決して怠らない。その結果、システムの構造や処理の流れを掴むことができ、障害が起きた時にあたりをつけるのが早く、また機能追加の際も何をどこに追加すればいいのか・修正すればいいのかがすぐにわかる、ということである。
この文章を読み、全てが腑に落ちたような気がした。というのも、自分でも少しだけその感覚が最近わかってきていたからである。
現在携わっているプロジェクトは、立ち上げは別会社の方々がプロトタイプを作成してくださり、そこに機能追加や改修をしていくという形で開発業務をしている。
そして、その中であまり理解していなかった部分（frontendで、drag & drop を利用し機能を実現している部分）に大きめな改修が必要となり、随分とわからなかったので手っ取り早い実装は諦め、細かく処理を見ていくことにした。
すると、最初は何をしているのか、どう実現しているのか全くわかっていなかったのだが、だんだんと全体像が見えてきた。どこで何を定義していて、動きの制御はここで設定していて、コンポーネントへのid付与はここで、、、というように。
すると、完全に理解したとまでは言えないが、今回の改修では何を作る必要があり、それにはこれも必要だからこれを作成し、ここは型が変わるからその修正が必要で、、という形で、何をすれば良いのか、実装に着手する前からわかったのである。
これは大きな衝撃であり、感動であった。今まで、ずっと何かモヤモヤした感覚、わかったようなわかっていないような（実際にはわかっていない）状態で業務をしていて、自分がシステムを操っているという感覚がなかった。しかし、今までで一番複雑で難しいと思われた箇所の実装が、一番理解できていて、自信を持った実装をすることができたのである。
結果、特に実装後エラーなども報告はなく、よく動いてくれた。
この一件で、私は今まで理解することができないと決めつけることでその煩わしさから逃げていたのだということと、逆に理解することがどれほど重要か、ということに気付かされた。
まとめ
理解することを諦めない（自戒）
この、「理解することを徹底する」というのは、開発者、特に経験の浅い人において一番避けがちなのではないかと思ったりする。わからないことが多すぎると、流石にしんどいし。
しかし、そこで諦めてはいけないのだと強く感じた。その場その場で対応していると、その時は身についた気になっていても、実際は何も変わっていない。しかも、応用も効かない。
一方、一度ちゃんと理解してしまえば、障害がどこで起きているのかという仮説を立てる精度は上がり、新しい機能の追加も自信を持って、より短時間で完了することができる。なんて良いことだろうか。
しかし、現代はAIの発達による誘惑も大きくなっている。今までは、自分のケースと全く同じという記事は出てこなかった。しかし現在、AIは自分の状況に特化した回答を即座にくれてしまう。そりゃ、使うよねと思う。
もちろん、面倒な作業の効率化など、大いに役立つものであるとは思う。しかし、プログラムで大きなシステムを作る・管理するとなれば、それについて理解していなければいけないというのは明白だし、そういった文脈のない中におけるAIの解答というものは、まだまだ足りていない部分も多い。
そして、私などまだまだではあるが、理解した上での開発の面白さは、それまでと段違いであったことも言及しておきたい。もちろん、最初はいちいち立ち止まることになれていないので、割と苦痛ではあった気がする。しかし、そのシステムがちゃんと自分の手の上で動かせているというような感覚があり、普段のようなこれを試して、なんかエラー出たから修正して、、というものよりも、思った通り開発すると思った通り動く、ということがとても面白かった。
偶然ながらこの業界を選んだことに感謝さえした。
というわけで長々と書いてきたが、とにかく（理解していない状態での）「試行錯誤は悪」であり、「いくら天才でも理解するのには時間がかかる」のだ。この、理解するのは天才でも時間がかかる、というのは、ある人にとっては言い訳ができなくなり厳しいものかもしれないが、反対に「誰でも理解には時間がかかるものだし、最初は分からなくて当然」と考えることを良しとしてくれ、多大な希望をくれる言葉でもあると思う。
少なくとも、「自分にもできるのでは、、？」と私には思わせてくれる、ある種の劇薬であった。
これからどんどんAIによる自動化や効率化が進んでくるかもしれない。しかしその中で、誰でもできる基礎的な「理解をする」ということにちゃんと取り組んでいきたいと思わせてくれる、そんな本だった。本当に、読んでよかったと思う。
余談
ちなみに冒頭に記載したが、この本には著者の趣味であるギターと交えて上記の内容を説明している。
そこで、トモ藤田さんという、バークリー音楽大学で教授（か助教授）を務めているプロギタリストの方の名前が出てくる。
教授職の傍ら、色々なレッスン動画をyoutube等で公開してくださっており、日本語での説明動画もあるためありがたい限りである。偶然、私もギターの上達に悩みトモ藤田さんの動画に辿り着いていた人間の一人であった。
牛尾さんも趣味でギターを演奏するし、早く弾くこともできるが、なぜか「弾ける感」がなかったという。そこでトモ藤田さんの動画に出会い、衝撃が走ったという。
それはリズムに関する基礎練の一つで、ギターを持たずに両手でリズムを取る、という練習の解説動画だったという。
著者のnoteでは以下の言葉が引用されている
「リズム詳しくわかってないので、なんとなくできているから」
そう、「なんとなくできている気がする」or「そんな簡単なことできている」と思い込んでしまうために、こういった練習はスルーしてしまいがちである。他にも、初心者は早く弾くことに憧れて、「できている」と思い込みスピードを上げてしまうとか。（すごく自覚があります。。）
しかし、いざちゃんとゆっくりのテンポでミスなく、正確にできるかを試してみると、意外とミスをしていたり、音の長さが中途半端だったり、ノイズが聞こえているけどスルーしていたりと、「簡単だ」と思っていることができていないことに気づくのだ。
正直、「本当はできていないのだ」と自覚するのは痛みを伴う行為である。だって、早く先に進みたいし、今までのことが少し無駄っぽく思えちゃうし。
ただ、そこができないまま演奏しても、やっぱりちゃんとできないもので、いつまでもなんとなくできていることから抜け出せない。
しかも、歴が長くなればなるほど、その勘違いが強固になっていく気もする。
これは、ギターに限らずプログラミングや業務でも全く同じだと思う。なんとなく周囲の記述を見て実装する。またその経験が積み重なることで同じような場面ではソースが書けてしまうということから、「できている」と思い込んでしまう。結果、本当は基礎的な理解ができておらず、応用は効かないし、エラーの際もどこが悪いのか分からない、なんてことを経験した人も多いのではないだろうか。（私は特に当てはまっています。。）
ただ、そこで一度ちゃんと立ち止まること。そして、急がず理解に努め、ちゃんとわかっている状態でコードを書くことを目指すべきなのだなぁと、改めて感じた。
当たり前だと思うかもしれないが、この「簡単なこと」を本当にできている人は少ないのかもしれない。
しかし、「いくら賢くても理解には時間がかかる」という言葉が、それを実行する勇気をくれる。そうだとしたら、自分にもできるのではないか、そして理解するのに時間がかかってしまってもそれはあたりまえなのだ、と。
私は、この本を読んでいてそこが一番希望であった。開発のスーパーマンたちは、そうなるような思考回路を持つようにした or 自然と持つような行動をしていたのだろう。
著者のnoteでほぼ本の内容と同じことが記載されており、そこでも確認できる。
本は買わないけど、という方はぜひ一度以下のサイトを訪問してみてほしい。
トモ藤田さんのyoutubeチャンネル