エンジニアにおすすめの本〜「世界一流のエンジニアの思考法」

• 1. きっかけ
• 2. 本の紹介
• 3. 仮説を立てる
• 4. 理解には時間がかかる
• 5. デザインドキュメント
• 6. メンタルモデル
• 7. 仕事の難易度、理解度、脳みその負荷
• 8. 相手が求めている情報への感度を上げる
• 9. 終わりに

1. きっかけ

1. 転職して案件にアサインされるまでに時間があった
2. 何か技術的に何か勉強する指針がない
3. youtubeでこの本の紹介を見た
4. 今までの経験上、技術ではなく仕事の進め方に問題があると感じていた
5. OUTPUT大全を読んでOUTPUTの大切さがわかったため

上記の理由から普段読まない技術系ではない本を読んでみました
当記事では本書の参考になりそうな部分を独断と偏見で書いております
エンジニアの仕事に行き詰まっている人の助けになれば幸いです
※本書を確認しながら記事を更新していこうと思います

2. 本の紹介

• エンジニアおすすめ度:⭐︎⭐︎⭐︎⭐︎⭐︎
• 社会人おすすめ度:⭐︎⭐︎⭐︎

3. 仮説を立てる

問題が起こった場合にまずは仮説を立てることから始めましょう

本書の中に事例と一緒に紹介されていますので気になった方は購入してみてください

エンジニアの方にとっては当たり前かもしれませんが

1. エラー
2. 障害

上記のような障害が起こった場合まずは仮説を立てましょう
試行錯誤は悪です
なぜなら自分の血肉にならないからです

経験上障害が起こると特に試行錯誤になりやすいと感じています
もっと悪い、いきあたりばったりの対応をしてしまうことも多いです

本書ではまさに私に言われているかのように仮説を立てましょうと書かれています

1. 障害報告を受ける
2. 事象の確認、ログの確認
3. エラー発見
4. エラー内容をコピー
5. グーグル先生、ChatGPTに質問

障害が起こった場合は上記のような動きになることが多いと思います
新卒の時はまずググったかどうかを聞かれていた私にとっては体に染みついたムーブとなってしまっています
改善するためには

1. 障害報告を受ける
2. 事象の確認、ログの確認　※ここまで同じ
3. 事象からPGのあたりをつける、推測を立てる
4. 証明するための確認作業をする

上記の3、4をループさせながら問題解決を行いましょう
時間の制約はあると思いますが、たまたまググって解決してしまうと同じ障害が起こった場合にきちんと対応ができません

4. 理解には時間がかかる

マイクロソフトのエンジニアでも理解に時間はかかる

本書でも書かれていますがマイクロソフトのエンジニアでも「理解に時間がかかる」ようです
そんなことかかれると

• 日々エラーが解決できない自分
• 仕様が理解できない自分
• 設計ができない自分

がしょうがなくはないが少し自分自身を許してもいいのではないかと思えてきました。

誰しも時間がかかってしまうものだと思ってしまえば少し気持ちが楽になるかと思います。

ただ努力は必要です

立派なエンジニアには努力あるのみですが、必ず時間がかかるものだと思えば新卒の時に仕事ができなかった自分を許してあげられる気がしますね

5. デザインドキュメント

どうせ覚えていないから先にまとめておきましょう

この考え方は自分の中でとてもいいことだと思ったのでぜひ紹介させていただきます

• 何か困っている時
• 何がわからないかわからない時
• 仕様やPGが理解できない時

こんな時はデザインドキュメントを書きましょう

1. ドキュメントの範囲
2. 今の課題、問題の背景
3. 解決したい課題、問題
4. どんな方法で解決するか

本書では違う書き方をされていますが概ねこんな感じで書きましょうとあります
こんなメモを自分の中で残しておけば

1. 同じような開発をする時に見返せる
2. 同じ部分で修正など入った場合に、過去考えていることがわかる
3. 人にそのまま渡せる

このような理由からとてもいい文書になるとおもいます
誰かに質問したい時も一旦この構成で書いておけば伝わりやすくなると思います

ちなみに文書をまとめるとき私はonenoteをお勧めします

Windowsで初期状態で入っている、テキストでは物足りないが、エクセルでは多機能すぎるそんな方にちょうどいいかもしれません

ただ検索機能は微妙ですが・・・
簡単にチェックボックスを作れますしURLもリンクとして貼れますし表もタブを使えば簡単に作れるのでお勧めです

6. メンタルモデル

自分なりの理解、イメージを作りましょう

本書では頭の中でイメージを作りましょうと言われています

私の場合は頭の中で四角が一つの機能、矢印で呼び出しやインプットを勝手に作って理解を進めています

もし頭の中で難しいなら積極的に紙に書きましょう

仕様書の遷移図を見て想像するより実際に画面とボタンを触って使い方を想像する方が何倍もやりやすいと思います

言葉だけ並べても理解のスピードは遅いので自分の理解が固まるような図、イメージを積極的に作るようにしましょう

蛇足ですが筆記用具もこだわってみるとモチベーションが沸きます

紙とボールペンにお金をかけても大きく生産性が上がることはないですが、自分の好きなものに囲まれている幸せ感を仕事中に感じれれるとうれしいですよね

マウス、キーボードは商売道具なので第一優先ですが余裕がある方は一度考えてみてもいいかもしれません

7. 仕事の難易度、理解度、脳みその負荷

本書では以下のようなレベルの定義をお話しされています※厳密には違うので読んでみてください

1. 何も調べなくも実装できる
2. 調べて実装できる
3. 何かヒントになるものがあれば実装できる
4. 自分ではできない

とにかく何も調べなくても実装できるPGを増やしましょう

• Pythonの内包表記
• C#のラムダ式
• 正規表現

上記の例のようなレベル1ではないけどレベル2、3のものでちょっと調べれば・・・ちょっとググれば・・・
みたいな書き方は多くあると思います

それらをメンタルモデルを使ってより多くをレベル１に持っていきましょう

なぜレベル1がいいかというと

• 調べる時間がなくなる
• 覚えている、イメージできるから理解できる時間が短くなる
• 結果脳の負荷が減る

上記のような効果が期待できます

if文、for文をわざわざ調べ直さなくても理解ができるように、難しい書き方を調べずに理解できるようになればよりPGの理解が早くなると思われます

理解の時間が少なくなった分他のことにリソースを使えばより生産的な働き方ができますね

8. 相手が求めている情報への感度を上げる

みなさんはメモを取る時、これを忘れそうだから文章に残す時「自分がわかる」文章になっていないでしょうか？

ぜひ明日からは誰かに聞かれた時ように資料を残してみましょう

めんどくさいと思われるかもしれませんが

1. 自分が困ったことは大抵別の人も困っている
2. 聞かれた時に読まれる前提で作っておくと渡しやすい
3. 渡した資料の説明が少なくて済む

上記のように誰かに聞かれる前提で資料を残しておけば誰かの役に立ちます

引き継ぎの時に苦労しなくて済みます

苦労しなくなった分自分の作業に集中できます

個人的には再度説明しなくて済むのはめんどくさいのでありがたいです

この情報もonenoteでまとめておくと共有もしやすいのでやってみてください

誰かのために情報をまとめておくことが最終自分のためにもなってくるのでぜひ挑戦してみてください

9. 終わりに

とにかく自分の主観をたくさん書かせていただきました

この投稿をする上で本書を何度も読み直しました

絶賛したいのに忘れていることが多く自分でもがっかりしていましたが、こんなに一つの本に向き合うことが今までなかったのでとても貴重な経験になったと思います

より自己研鑽をしていくためにもアウトプットを頑張っていこうと思います