「世界一流エンジニアの思考法」を読んで
名著というコメントをあちらこちらで見かけていたので、年始で帰省している際の移動中などを使って読んでみた。結果、移動中に限らずいろんなところで読み進めてしまうくらい学びになる内容が盛りだくさんでした。
記憶の定着と、これから自分自身のエンジニアとしての方針と重ね合わせつつ、特に印象に残った点をピックアップしまとめていこうと思います。
学びや気づき
試行錯誤は「悪」である
問題が発生した時、あれこれ手探りで試すのではなくまずは自分の頭のメンタルモデルを使って仮説を立てて証明する。この一連の手順が、手当たり次第に可能性を試すことによる時間のロスを排除し、圧倒的な効率を生んでいるのだ。
単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない
頭の中に仮説を立てて、それを証明することは自分の知識につながる。反面、思いつきで試行錯誤してなんとか上手くいったことは自分自身の成長につながらず、また同じ問題に直面した時に同じように詰まってしまう。これは去年自分自身ですごく痛感していたところだった。
あんまり仕組みがよくわかってないまま技術を扱って、あんまりよくわからないけどなんとか解決できた。このパターンだと確実に次回も同じように詰まるし、あんまりよくわかっていないままでなんとかやり過ごしてしまう。後にも出てくるが頭脳労働である以上、生産性を高めるのは「理解しているか」なんだということをはっきりとさせられるところだった。
頭がよくても「理解」には時間がかかる
どんなに頭がいい人でも理解には時間がかかるものなのだ。頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
自分は速く弾くことはできる。でも、リズムがちゃんととれていないから、簡単なストロークでも、気持ちいい演奏ができない。つまり、誰もが知っている「基礎」が身についていなかった。そして、「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」ものなのだ。
そもそも学習における「理解」とは何かを、筆者は下記の3つで表している。
- その構造をつかんで、人に説明できること
- いつでもどこでも即座に取り出して使えること
- 知見を踏まえて応用がきくこと
この中でも1つ目の「その構造をつかんで、人に説明できること」はブログなどで記事を出すことによって最も身に付くものではないかと思う。
「クリエイティブ」であることに自分自身憧れてそうありたいと思っているが、「クリエイティブ」とは知識の応用であると捉えた場合、やはりベースに必要なのは「構造に対する理解」の量なんだろうなと読んでいて感じた点だった。ここの「理解」の部分について軽く見ず、自身のクリエイティブを高めていく目線でも今年はかなり意識していきたい。
「Be Lazy」というマインドセット
Be Lazyとは「怠惰であれ」という意味を持つ。
これは、アジャイル、スクラム開発の世界でも頻繁に言われている非常に重要なポイントだが、端的にいうと「より少ない時間で価値を最大化するという考え方」だ。できるだけ最小の労力で楽をする方法を探ろうというマインドセットだ。
一流エンジニアたちは「いかにやることを減らすか？」に頭を使っている。一般的にたくさんの機能を速く実装することはいいことだと思われがちだが、本当は「悪」だ。なぜなら、統計によると実際はソフトウェアの機能のうち40％ぐらいしか使われないからだ。
日本人チーム 「優先順位つけたので、上からやっていこう！ できれば全部やりたい！」
インターナショナルチーム 「最初の1つピックアップしたら、他はやらない。フォーカスはひとつ」
海外チームと日本人のチームには上記のような意思決定基準の違いがあるようで、海外ではあれもこれもとならずに「実際にできるキャパ」を考える。
100個のタスクがあったら、本当に必要なのは20%程度。この箇所は目から鱗だった。自分もついつい「あれもやらなきゃ」とか「あれやってなくて大丈夫だろうか」とか考えがちで心配性なのだが、優先順位を上から全部さばくというマインドはいったんリセットする必要があると感じた。
「楽」をしてより高い価値を生むためにはを、筆者は下記のようにまとめている。
- 1番重要な「1つだけ」をピックアップする癖
- 時間を固定して、その中で価値を最大化する
- 「準備」「持ち帰り」をやめてその場で解決する
- 物理的にやることを減らす
これらを初めから実践することは難しいところだと思うが、常に意識することで生産性に大きく変化が現れそうだと感じるので意識していきたいところ。
コードリーディングのコツは極力コードを読まないこと
コードを端から端まで読もうとして、今自分が何を読もうとしているのかわからなくなる。超大規模なソースに触れた経験はないにしても、筆者の書いていることにうんうんと共感しながら読み進めていた。
実装は動くものと信用して極力見ない。インターフェースと構造を理解する。ダイヤグラムや、関係性のグラフを書いたりしながら。
筆者がコードリーディングの早いエンジニアに質問して帰ってきた返答は上記のようなもの。読む量を減らして、脳に余裕を生む。できるだけ脳に負荷を上げない方法で理解できるようにするか、というアプローチが非常に有効ということだった。
自分にとって難しすぎると感じるときは、たいてい脳の使い方が間違っているサインだ
ここは非常に頭に刻んでおきたい。なんもわからん……で疲弊した時には、アプローチ方法を見直すといったことを習慣的に行っていけるようにしていきたい。
AI時代には「専門性」こそが強みとなる
AI関連については、やはりアメリカでも相当なインパクトがあるようで、最終章でしっかり触れられていた。
ここで書かれていることは、
- 世間に沢山コードが落ちているものは今後AIがコーディングできるようになる
- 誰もやったことがないものに取り組んでいる専門家は、AIがとって代わることは原理的にあり得ない
ということで、世間に右往左往してしまうことなく、自身の「専門性」を磨くことは必ず武器として活き続ける。と力強く書かれている。この「専門性」については中途半端なものではないことが前提となっていると思っているが、AIに仕事が奪われそうだから別の生き方を考えるのではなく、信じる「専門性」を伸ばすこと。その専門性をもって「誰もやったことがない新しいことができる」ようになること。これがこれからのエンジニアにとっての生存戦略となっていく、と自分は解釈した。
「批判」の文化がすべてをぶち壊しにする
最後に、おそらく日米のIT業界を見て筆者が最も言いたかったであろうことが書かれている。
自分は海外に出たことがないので比較対象がないが、日本の不完全なものを寄ってたかって「批判」する文化にはSNSなどを通して本当に辟易としている。
そしてこの文化が「ソフトウェア開発」という行為においては致命的に作用している、と述べられている。実際に自分もそうだと思う。初めから完璧なものを求めている人があまりにも多いと思うし、いっしょに良くしていく、というスタンスで触れる人は同じような開発者以外にはほとんどいないのではないかとすら感じる。
書籍の中で述べられているコントリビュート（貢献）と感謝のループはまさしく日本の社会が目指していくべき姿だと思うし、自分もシステムを開発する人間のひとりとして、ループを広めていけるように努力していきたいと思う次第だ。
まとめ
全編通して学びが多く、特に年始に読んで本当によかったと思っています。
今年の目標としては、特に「理解することに時間をかけ、いつでも取り出し可能な状態のものを増やす」を掲げていこうと思います。曖昧なままで取り扱っていたものや、根本的に理解が足りていない必須知識（セキュリティやネットワーク周り、代表的なアーキテクチャなど）についての理解をいつでも取り出し可能な領域まで深める。
その上で、今メインで使っている技術（TypeScript, React, Next.js）について、検索が不要なくらいに手に馴染んだ部分を多くしていく。結果として生産性が上がっていき、開発チームやプロダクトに大きく貢献することができる。このゴールは自己評価ではなかなか難しいので、実際の現場で全力でやっていくしかない。
また、やってみたいこととしてはOSSへのコントリビュートを経験してみたい。そこでどんどんディスカッションにも参加して、海外の人々とのコミュニケーションを取れるようになっていく。
こうして書いているうちにも、いろいろとやりたいことが出てきているのでまたブログでさくっとまとめていきたい。