調べた。試した。わからなかった。
目次
ググった。Stack Overflowも見た。ChatGPTにも聞いた。
コードをコピペして、動かしてみた。
エラーが出た。また検索した。別のコードを試した。
3時間経った。
で、結局何がわかったのか。
何もわかってなかった。
「試行錯誤」は努力じゃない
試行錯誤って、なんか頑張ってる感じがする。
手を動かしてる。画面に向かってる。何かを調べてる。
でも、マイクロソフトで働く牛尾剛さんは、こう言っている。
「試行錯誤は悪だ」
最初これを聞いたとき、意味がわからなかった。
だってプログラミングって、試行錯誤の連続でしょ？ エラーが出たら直して、また動かして、の繰り返しでしょ？
違った。
一流のエンジニアは、闇雲に手を動かさない。
事実から仮説を立てて、それを証明するプロセスを踏む。
つまり、「とりあえずやってみる」の前に「なぜこうなるのか」を考える。
この順番が、決定的に違う。
コピペで動いても、何も残らない
正直に言う。
私もずっとコピペで生きてきた。
エラーが出たらStack Overflowで検索して、一番上の回答をコピペ。動いた。解決。
でもね、1週間後に同じエラーが出たら、また同じことを検索してる自分がいた。
これ、成長してない。
なぜか。
理解してないから。
コピペで動かすのは簡単だ。でも、なぜそのコードで動くのかを理解してないと、脳に何も残らない。
一流のエンジニアは、コードを読むスピードが速いわけじゃないらしい。
むしろ、理解に時間をかける。
コードの意図は何か。背後にあるアーキテクチャは何か。なぜこの設計なのか。
それを丁寧に、時間をかけて理解する。
だから、一度理解したことは忘れない。応用もできる。
「聞く」が最速だった
もう一つ、一流のエンジニアがやっていること。
すぐに人に聞く。
「え、それって迷惑じゃない？」
私もそう思ってた。相手は忙しいし、自分で調べるのが礼儀だと思ってた。
でも、これが間違いだった。
自分で30分調べてわからないことを、詳しい人に聞いたら5分で解決した。
こういう経験、たぶんあるでしょ。
一流のチームでは、「クイックコール」というのが頻繁に行われるらしい。
チャットで「今、5分いい？」と聞いて、1対1でビデオ通話する。画面共有しながら一緒に考える。
一人で悩むより、圧倒的に速い。
「聞くのは恥ずかしい」
「自分で調べるべき」
「相手の時間を奪いたくない」
全部、ただの言い訳だった。
頭の中に「地図」を作る
もう一つ、大事なことがある。
メンタルモデルを作る。
メンタルモデルって何か。
簡単に言うと、頭の中に「地図」を作ること。
たとえば、新しい技術を学ぶとき。
断片的な情報をいくら集めても、頭はぐちゃぐちゃのまま。
でも、「この技術は全体としてこういう構造で、ここがこう繋がっていて…」という地図が頭にあると、新しい情報がスッと入ってくる。
一流のエンジニアは、この地図を意識的に作る。
コードを書く前に、短いドキュメントを書く人もいる。
設計の意図、問題の背景、解決策の理由。
たった数ページ。でも、これを書くことで頭が整理される。
そして、整理された頭で書いたコードは、質が違う。
今日からできること
ここまで読んで、「じゃあ何をすればいいの？」と思ったかもしれない。
一つだけ。
次にエラーが出たら、コピペする前に30秒だけ考える。
「このエラーは何を言ってるのか」
「なぜこのエラーが出たのか」
「何が原因として考えられるか」
30秒でいい。
それだけで、コピペしたコードの意味が変わる。
「なんとなく動いた」から「理解して動かした」に変わる。
この差は、今日は小さい。
でも、1年後には巨大な差になる。
試行錯誤で時間を溶かし続ける人と、理解を積み重ねて成長する人。
どっちになりたいか。
答えは、もう決まってるでしょ。
参考書籍
- 牛尾剛『世界一流エンジニアの思考法』 マイクロソフトのエンジニアが実践する、試行錯誤より「理解」に時間をかける働き方。一流と二流の差はここにある。
合わせて読みたい
牛尾剛『世界一流エンジニアの思考法』──AI時代に勝ち残るエンジニアの秘密 この記事で紹介した「試行錯誤は悪」の原典。なぜ理解に時間をかけるのかが詳しくわかる。
『「Learn Better」学びの質を劇的に変える6つのステップ』 理解を積み重ねる学習術。コピペではなく「本当に身につく」学び方の科学的メソッドを解説。
『ズンク・アーレンス「TAKE NOTES!」』 メモを「第二の脳」に変える方法。断片的な情報を整理して、理解を深める技術を紹介。
『なぜ考えても答えが出ないのか』 思考を加速させる2つの突破口。闇雲に調べるのではなく、仮説を立てて効率的に解決する方法。