はじめに
今回の記事は、Qiita版の読書感想文です。
読んだ本は、SNSでエンジニアの間で話題になっていた「世界一流エンジニアの思考法」という自己啓発本です。
本書では、世界最高峰のエンジニアたちが普段何を考えて、どのように日々の業務を行なっているかが述べられており、そういったエンジニアが決して天才だから世界最高峰なのではなく、習慣によるものであることを学びました。
本記事は私が世界一流のエンジニアになるために必要だと感じたことをまとめたものです。
文字だらけですみません！
４つの罠
本書を読んで、普段私が仕事をしている中で陥っていた４つの罠を発見しました。
できればキリ良く ３つ でまとめたかったのですが、どうしても４つになっちゃったので４つです。
スピードが命という罠
理解に時間をかける
これまで私は、「効率」や「スピード」こそが正義だ！という思いでコピペやAIツールを駆使しまくってガンガンタスクをこなそうと頑張っていました。
しかしこれでは、即ドラえもん頼りトラブルメーカーのび太くん状態 でした。
入社して半年以上経った今、開発をしていて感じたことが確かにありました。
それは、開発スピードがそれ以上上がらないことと、エラーなどのトラブルに弱いということです。
考えてみると当然の話で、コードや仕組みを真に理解していないままであれば、もう一度似たような機能を実装する際にまた0から調べる必要がありますし、エラーが起こってもどこでなぜ起きているのかがわかりません。
のび太くんがすべきことは、まず何をすればいいのかをしっかり理解して、必要であれば道具を使うことを検討し、どの道具を使うかもできるだけ自分で考えることです。
最初は時間がかかってもいいので 徹底的に理解することに力を入れるべき だと思いました。
エラーが起こっても状況把握と考察が最優先
エラーが起こった時も同じです。
これまで私はエラーがが起こると、すぐにそのエラーを検索にかけたりChatGPTに聞いたりしてとにかく「早くエラーを直す！」という思いで手先の作業ばかりが先行していました。
しかし実はこれではかなり効率が悪く、時間がかかってしまうと著者はいいます。
これにはかなり心当たりがありました。検索に引っかかった記事を片っ端から試して、かなりの時間を費やした挙句、結局全然違うところが原因でなにも成長がない時間だったことが何回あったことでしょうか…。
世界一流のエンジニアはまず手を止めて状況把握と考察をします。
できるエンジニアの様子を見ていると、ログを確認して、ぶつぶつと呟きながら考え、しばらくしてクエリを一つだけ打ち込むとエラーが解消されたという著者の体験が衝撃だったと述べられています。
ググれカスの罠
すぐ聞くコミュニケーション
よく初心者がプログラミングを勉強しているときに教えられるのが、
「自分で調べる力を身につけようね」
です。
わからないことは自分で調べることが当たり前だと遺伝子レベルで刷り込まれていました。
また、人に聞くのは苦手というものありました。
「こんなことで聞いてくるなよとか思われないかな」といった碇シンジのような繊細さと
「人に頼るのはなんだか悔しい」といったベジータのような高いプライドを兼ね備えた ハイネガティブ・ハイプライド人間 でした。
しかし著者は、状況によってはググるのは非効率な場合があると述べています。
例えばあるWebシステムの開発をしていて
「ここのモデル定義の仕方がわからないなー」
と感じた場合、これはすぐにチームのメンバーに聞くべきでしょう。
なぜなら、そのモデル定義の裏には、システム独自の事情や理論があるはずだからです。単なるコードの書き方では済まないはずです。
こういった自分の頭の中にあるシステム構造や理論などを含めた全体的なイメージを著書では「メンタルモデル」と述べられています。
メンタルモデルができていないことには何も始まらないのです。
また、たとえ単なるコードの書き方であっても、アルゴリズムが複雑であればネットで調べてもすぐにはわからないことがあるかと思います。その場合も即聞いた方がいいと思いました。
そして人に聞けば迷惑なのではないかというのも幻想で、思いやりさえあれば大丈夫だといいます。
「今10分ほど大丈夫？」とか、緊急でなければ「聞きたいことあるからキリがいいとき声かけて」と言って聞くタイミングを相手に選ばせたり、相手を気遣う言葉や行動が大切だということです。
ググって一発で出てくる情報以外は全て聞く くらいの意識でいいのではないでしょうか。
要は早く深く理解することが大事ってことですね。
タスクの優先順位の罠
よくタスク管理の鉄則として、タスクに優先順位をつけることが大切だと言われます。
そのとき私がこれまでにしていたイメージとしては、
１位、２位、３位…
と一つずつ順位をつけていく、もしくは
優先度高、中、低
などにグループ分けするというものでした。
しかし、世界一流は違います。タスクに順位はありません。
世の中のタスクには２種類あります。それは、
最重要か、それ以外か
です。敬意をこめて、ローランド式タスク選定法 と呼ばさせていただきます。
順位をつけるのではなく、一つ選んであとは捨てる のです。
他の誰かができるかもしれないタスクを一人が複数抱えると勿体無い上に、頭の中がマルチタスク状態になって生産性を著しく下げます。
さらに、統計によるとシステムの機能のうち実際にユーザーに使われるのは４割程度であるという結果が出ているみたいなので、最初に考えた機能を100％盛り込む必要はないらしいです。
どうしても捨てられないタスクである場合は開発スケジュールの変更で対応します。
ITエンジニアなら不確実性を受け入れろというのが著者の主張です。
仕事はやればやるほどできるようになる、の罠
タスクの進捗が思ったより悪くて、残業でカバーしたことは数え切れないくらいあります。
残業してアプリ開発のタスクを満足するまで消化して、その度に私はスッキリしていました。
「タスクも消化されたし、すごい頑張ったし、なんだかレベルアップして仕事ができるようになった気がする…！」
しかし著者は「開発のスピードや質の向上は全ては学習があってのもの」だと言います。
たしかに、よく考えてみてください。
残業でやっていることって、基本的には既に自分ができる・わかる技術を使ってひたすら実装作業をしているだけのことが多いじゃないですか。
結局、自己満だったんですよ。（泣きそう。）
もちろん頑張っていたのは、チームに貢献したい気持ちがあるからこそです。
でもそれだったら業務をやめて勉強した方が長い目で見ると開発は早く終わるということだと思いました。
もし「自分の技術向上ためにも〜…」という理由で残業をするのだとしたらすぐにやめて勉強しようと思いました。
（スケジュール的にそうはいかないときもあるけども！ぐぬぬ…）
おわりに
この本にはまだまだ印象的なお話がたくさんあって、新卒１年目で心がツルツルで透明な私にはどれも刺さりました。
特に、最後の方の章で述べられている日本国民の技術者へのリスペクトに関するお話は、私が一生をかけてでも立ち向かっていきたいと思ったお話でした。これに関してはエンジニアに限らず、日本のすべての職人業の方がぶつかる問題だと思うからです。
とにかく、私はこれから世界一流の習慣をもって、世界一流のエンジニアになるために日々頑張っていこうと思います。