「試行錯誤は悪だ」——世界一流エンジニアに学ぶ、考えてから動く思考法
こんにちは。AIスタートアップでプロダクト開発をやっている者です。
今回は「世界一流エンジニアの思考法」（牛尾 剛）の感想を書きます。著者はADHDを抱えながら44歳でマイクロソフトに転職し、アメリカで世界最高峰のエンジニアチームと働くようになった方です。
なぜ読もうと思ったか
転職にあたり、PMからエンジニアに戻ることにしました。
数年PMをやっていた分、コードを書く感覚は鈍っている。「エンジニアとして出直す」という状況で、技術をキャッチアップするのはもちろんだけど、それよりも先にできるエンジニアの思考をインストールしておきたいと思った。
スキルより先に思考法。どういうマインドセットで問題に向き合うか。そこがずれたまま手を動かし始めても、きっと遠回りになる気がしていた。
この本は「思考法（マインドセット）が高い生産性を形づくっている。小手先のテクニックでもTipsでもなく、その圧倒的なパフォーマンスは思考法から生まれている」という話で、タイミング的にも自分に効く内容だと思って手に取りました。
「いきなり手を動かしてはダメ」という衝撃
一番刺さったのが、著者がマイクロソフトで同僚のポールにペアプログラミングをお願いしたときのエピソードです。
障害を調査していた著者が試行錯誤していると、ポールにこう言われます。
「障害を調査するとき、いきなり手を動かして、試行錯誤していろいろクエリを投げてはダメなんだ。ログを見て、自分で多分こういうことが起こっていると推測して、その推測に合ったクエリを投げてそれを証明するんだよ」
事実（データ）を一つ見つける → いくつかの仮説を立てる → その仮説を証明するための行動をとる。
これが一流エンジニアの問題解決の型だ、というわけです。
著者はその後「思いつきによる試行錯誤は『悪』なのだということを、身をもって実感した」と書いています。試行錯誤は何も学ばない。「単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない」。
読んでいて、正直グサっときました。自分もまさにこれをやっていたので。
「早くやろうとすること」が生産性を下げる
もう一つ、逆説的な話があります。
著者がコードリーディングのスピードを上げようと焦っていたとき、優秀な同僚はそれを一切やっていなかった。彼は「コードのロジックを読む」のではなく、「コードの意図とその背後のアーキテクチャを理解するために読み込んでいた」。理解にしっかりと時間をかけることを恐れていなかった。
著者の結論はこうです。
「皮肉なことに『早くできるように頑張る』ということが最終的な生産性をむしろ下げていた」
理解が十分でないまま手を動かして努力しても、空回りになって身につかない。「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまう、と。
では「理解できた」状態とはどういうことか。著者の定義がシンプルで、深く納得しました。「人に説明できて、即座に使えて、応用がきく」——この3つが揃って初めて理解だ、と。
「なんとなくわかった気がする」は理解じゃない。そう言われると、自分の「わかった」のほとんどが怪しくなってきます。
Be Lazy：「いかにやることを減らすか」を考える
もう一つ面白かったのが「Be Lazy」という概念です。
著者のいるインターナショナルチームの一流エンジニアたちは、「いかにやることを減らすか」に頭を使っているそうです。
「端的にいうと『より少ない時間で価値を最大化するという考え方』だ。できるだけ最小の労力で楽をする方法を探ろうというマインドセットだ」
一番印象に残ったのが「会議の準備をしない」という話です。著者がコンサルタント時代、ソニックガーデンの倉貫義人さんにこう言われたそうです。
「牛尾さん。会議の準備をしないでくださいね、無駄だから。そうじゃなくて、会議の時間を価値の高いものにしましょう」
過剰準備は「不必要なものや付加価値のない仕事」の一つだ、というわけです。自分も資料準備に過剰な時間をかけてしまうことがあるので、耳が痛い話でした。
「検討より検証」——Fail Fastの精神
本書で繰り返し出てくるもう一つのテーマが「Fail Fast（早く失敗する）」です。
アメリカのチームでは失敗で怒られることがない。むしろ「フィードバックをありがとう！」と感謝される。誰がやってもうまくいくことを無難にこなしても評価されない。チャレンジしないほうが、会社の将来のリスクを高める、という考え方が根底にあるそうです。
著者の言葉を借りると——
「今の時代、検討ばかりして、さっさと『やらない』ことのほうが最大のリスクだということを肝に銘じてほしい。やらないほうが必ず失敗する確率が増えるのだ」
机上でいくら慎重に検討しても、実際市場に出したらどういう反応が返ってくるかは、実施するまでわからない。だから「検討よりも検証を」という考え方になる。
これはエンジニアリングだけの話ではなく、プロダクト開発全般に言えることだと思います。「完璧な仕様を作ってから動く」より「とにかく動くものを早く出してフィードバックを得る」——頭ではわかっているつもりでも、実際にはちゃんとできていないことが多い。
読んで意識しようと思ったこと
正直、読んですぐに何かが劇的に変わったわけではありません。ただ、これから意識していきたいと思ったことが2つあります。
1つ目は、デバッグや問題調査で「まず仮説を立ててから動く」。
これまでは「とりあえず試してみる」が多かったのですが、「ログを見て、仮説を立て、その仮説を証明するための行動だけをとる」という順番を意識したい。試行錯誤を減らせれば、調査も速くなるはずだと思っています。
2つ目は、「一番重要な一つだけ」を先に決める。
タスクが積み上がっているとき、「あれもこれも」と並行して中途半端に進めがちでした。「今日これだけは確実に終わらせる一つはどれか」を最初に決める——まずはここから習慣にしていきたいです。
まとめ
「生産性を上げる」というと、どうしてもツールとかTipsとかショートカットの話になりがちです。でもこの本は一貫して「思考法を変えろ」という話をしています。
試行錯誤しない。急がない。やることを減らす。失敗を恐れない。
どれも言葉にすると当たり前のように見えるのに、実際の仕事では逆のことをやってしまいがちです。一流エンジニアは「何をやらないか」を徹底的に考えているという視点は、エンジニアに限らずプロダクト開発全般に通じる話だと思います。
世界一流エンジニアの思考法
米マイクロソフトの現役ソフトウェアエンジニア・牛尾剛さんが、超巨大クラウド開発の最前線で学んだ思考法をまとめた一冊。「怠惰であれ！」「早く失敗せよ」など、“三流プログラマ”でもできた〈生産性爆上がり〉の技術。