はじめに
こんにちは。インプルの横浜です。
今回はエンジニア界隈で少し前に話題になっていた『世界一流のエンジニアの思考法』を読んでみて
書籍の中でも特に実務に活かせそうな内容を具体例を交えてお伝えしていきます。
仮説を立ててから動く
業務でエラーに遭遇した時思いつく限りの方法を1つ1つ試して解決はしたが膨大な時間を浪費したことはありませんか?
私もとりあえずコードを書き換えて動かしてみたり、むやみにログを吐き出せてみたりと考えるより先に手を動かして作業を進めてしまうことが多々ありました。
しかし、著書によるとできるエンジニア は
最初の一つのログだけを見て「仮説」を立て始めた。手は一切動かさない。
世界一流のエンジニアの思考法より引用
というのです。
例えばエラーに遭遇したら、すぐにエラーの示すコードを思いつきで修正するのではなく、エラー文を読んで何が原因かの仮説を立て、それを実証するためのコードの変更を行う。
できるエンジニア はすぐに手を動かさずに、思いつきでコードをいたずらに修正するのではなく、根拠を持った仮説を自分の頭で考えた上で初めて手を動かすのです。
この考え方を実務に活かそうと私は最近エラーに遭遇したら最初の5分はすぐに手を動かさずにコードを読み直すようにしました。
手当たり次第にやるよりも考えつく修正案の精度が上がって生産性がアップしました!
自分の時間を作る
基本的に仕事をしていると誰しも途中で別のタスクが入ってくることが多々あると思います。
それによってマルチタスクになってしまい、仕事のペースが落ちたりと困ることも多いでしょう。
しかし、著書によるとできるエンジニア は
「今手をつけている仕事を一つに限定する」
~中略~
毎日4時間をブロックして、Teamsもメールも一切閉じて、自分の作業だけをする
世界一流のエンジニアの思考法より引用
とマルチタスクを行わない工夫をしています。
著書で紹介されている人間の脳の発達に関する研究でも人間にとってマルチタスクが向いていないことは示されてます。
しかし、急に入る仕事は自分では調整できない と言う方がほとんどだと思います。
この問題の解決策として早朝に自分のプライオリティの高いタスクに着手するというのはとても生産性が高いです。
特にクライアントも同僚もまだ働き始めていない早朝は集中して仕事を行うのにすごくおすすめです。
弊社ではフレックスタイム制を導入していいて7:00から出社可能なのですが、私も7:00から業務を行えば9時をすぎるまではほとんど連絡が来ることがありません!
人が読みやすいコードを書く
エンジニアであれば仕事を進める上でコードのレビューを受ける機会は多いですよね。
レビューのコメントの中に指摘ではなく、コードの意味の説明求められたことないでしょうか?
それはなぜなのか?著書ではこう説明されていました。
「読んだ人がどう感じるか?」を意識しながらコードを書く必要があった
世界一流のエンジニアの思考法より引用
常に言われているし、時々思い出すけれどもコードを読む人のことを考えてどれだけコードをかけているでしょうか?
ビジネスの場の開発において自分1人で完結することはほとんどの場合でありません。
チームで開発したり、リリース後の保守は保守部門の人が行ったりと自分以外が自分の書いたコードに関わることは常なのに「読んだ人がどう感じるか?」を意識しないと技術的な負債は増える結果となってしまいます。
では、どうすればコードの読みやすさを意識できるのか?
翌日の仕事初めに前日のコードをざっと見直すだけでも違和感には気付けたりすることが多々あります。
特に前日にそのコードを書いた自分がざっと見るだけで理解できないコードであれば他の人はなおさら理解できないことは想像に難くありません。
レビューに出す前に時間があればそのコードから目を離した後にコードを見直してみてください!
まとめ
- すぐに手を動かさずに、仮説を立てる
- タスクの差し込みがない環境を作って、集中して作業する
- 将来の読み手を意識してコードを書く
今回はすぐに実務に活かせそうな内容をピックアップしてお伝えしましたが、世界一流のエンジニアの思考法にはエンジニアとして活躍していくために必要だと感じる内容がふんだんに盛り込まれた内容でしたので、興味を持った方はぜひご一読を!