はじめに
どうもこんにちは、もきお(@mokio_50)です。
会社の同僚に何気なくおすすめされた本。それが「世界一流エンジニアの思考法」でした。単なる自己啓発本かなと思っていたら実践的に使えることが盛りだくさん。
この本はエンジニアとして働き始めて少し経った頃に読むのが一番実感できる部分が多い気がしています。
今回の記事はこの本の要約と、内容についてどう感じたかを書き連ねました。
導入部分
この本を読む前は「あー一流のエンジニアがこれまでの自分自身の思考を振り返りながら作成した本なんだろうなー」と思っていましたが、筆者は一流ではなく三流エンジニアでした。
作者の牛尾さんは44歳でマイクロソフトに入社。そこで一流エンジニアたちに出会う。
自分だったら一流エンジニアの凄さに圧倒され打ちひしがれてしまうところだが牛尾さんは深く観察し、なにか自分にプラスに働く要素がないかを常に考えていた。
それは本当に重要なことで、どうしても才能や幼少期からプログラミングをやってたからと理由をつけて一流のエンジニアに対して一線を引いてしまいがちだが、そうではなく少しでもそこに近づくためにはどうすればいいかを考えながら日々吸収する意志を持ってその人達と接することが大切なんだなと改めて感じさせられました。
1章 一流のエンジニアは何が違うのだろう？
一流のエンジニアとの違いは
・試行錯誤は悪という考え方
・理解に時間をかける
試行錯誤は悪という考え方
最初読んだとき試行錯誤しちゃいけないの！？と思いましたが、読み進めていると試行錯誤を否定しているのではなくただ闇雲に試行錯誤しちゃいけないよってことが書いてあるように感じました。
手を動かす前にまずは仮説を立てる事が重要。
仮説を立てた上で試行錯誤していく必要があるのかなと思いました。
理解に時間をかける
生産性が高いエンジニアほど理解に時間をかけているそう。
理解の定義
・その構造を掴んで、人に説明できる
・いつでもどこでも即座に取り出して使えること
・知見を踏まえて応用できること
この章で特に共感したのは以下の部分
既存のコードを理解するとはコードのロジックを読むのではなくコードの意図とその背後のアーキテクチャを理解すること。
基礎練習は誰にでもできるが、習慣に時間がかかるもの
「理解に時間はかかるもの」として急がず徹底的に理解する習慣を身につける。
2章 アメリカで見つけたマインドセット
「Be Lazy」(怠惰であれ)という考え方は「より少ない時間で価値を最大化するという考え方」
この考え方を達成するための習慣
・優先順位を付ける
日本人の一般的な考え方として仮にリストにタスクが5つあったとした場合、これは「第1優先、これは第2優先...」みたいな感じで5つ全てに優先順位を付けることが多い。しかし海外メンバーは「最初の一個をピックアップしてほかはやらない。一つのことにフォーカスする」という感覚だそう。
確かに毎日今日はこれとこれを終わらせようという感じでタスクをこなしてたので、これだけはやろうと一つにピックアップしてタスクを進め、終わったら次のタスクにフォーカスしてタスクをこなすようにしていきたいなと思いました。
3章 脳に余裕を生む情報整理・記憶術
3章では以下が印象に残りました。
ミーティングの議事をその場で書かない。軽いメモ程度に留めておく。「後で人に説明すること」を意識して話を聞く。
会議の内容を人づてにどうわかりやすく説明できるかを意識しながら会議に参加していきたいと思います。
4章 コミュニケーションの極意
印象に残ったのは以下２つ
付加的な情報は聞かれてから答えれば良い。最初から全て説明せず、「情報量を減らす」コミュニケーションの仕方が重要
これもあれも事前に伝えとかないといけないと思い聞かれたこと以外も色々と答えてしまいがちですが聞かれたことだけに答えれば良いという考え方。他に知りたい情報があれば相手から聞いてきてくれる。
プルリクのレビュー数を減らすためには「読んだ人がどう感じるのか？」を意識しながらコードを書く必要がある。コードもまた「読み物」だ。
プルリクでつつかれそうな内容は事前に直しておく、自身で納得がいってないが修正が必要な部分は事前にプルリクにコメントしておく。ここらへんは今後も意識していきたいですね。
5章 生産性を上げるチームビルディングとは？
近年は「サーバントリーダーシップ」と呼ばれるマネジメントが主流になっているそう。
サーバーントリーダーシップとはリーダーは〈ビジョンとKPI〉は示すが、実際にどの用に動くかはチームが決めること
タスクの割り振りも自らやっていく。基本的にメンバーがやりたい仕事を「自分がやるよ」と選択していく。
と書いてあり、自主性を重んじようという考えのもと働くことを推奨しているように感じました。
２年以上エンジニアとして働いて、少しずつですが「マネジメントするとしたらどう接するのがいいのかなー」と考える時間が増えてきました。
実際業務している中で自主性を重んじようとする精神は大事だなと思うのは大前提として自身も感じる事がある一方で、誰に対しても自主性を重んじようとしすぎるのも良くないのではないかな？と思うこともしばしばあります。
人には人の乳酸菌ではないけれど、タスクを振られたものをそつなくこなし、返って生産性が高い人もいる気がします。
自主性を重んじようという姿勢をベースに置きつつも、自主的にタスクを巻き取るよりも振られたタスクを淡々とこなしている方が楽しい、やりがいを感じる人がいればタスクをこちら側から降ってあげる。
そこを見極めるために1on1を定期的に行いしっかりとコミュニケーションを図っていこうと思いました。まぁまだエンジニアになってからマネジメントしたことないんですけどね笑
その他この章で役に立ちそうだと思った内容は以下
・上司であっても人に何かを依頼したり意見したりするときはかなり丁寧な言い回しを心がける。
・レビュー等で意見が対立するときも「決してその人自身を否定しない」ことを心がける
6章 仕事と人生の質を高めるには？
タイムボックス制を導入する
9時-18時みたいに仕事をする時間を決めてしまう。時間になったら作業が途中だろうがやめてしまう。
エンジニアはリモートワークができてしまうためプライベートと仕事の時間が曖昧になりやすいなと感じます。
それによってまだ時間があるからとダラダラと仕事を進めてしまうことも多々ありました。
もちろん当日中に終わらせないといけないタスクがあるとかなら別なのですが、これからいいところなのに！というところで強制終了してしまうことで早く明日また仕事がしたい！と不思議とモチベーションが上がるようになりました。ゲームを一日一時間だけと決められてしまい一時間で強制的に止められてしまったときの感覚のようです。
7章 AI時代をどう生き残るか？
仕事がAIに取って代わられたときはその時はその時に考えればいい。AIを不安視しすぎないことが大切なんだなと読んでて感じました。
気にすることなく専門性があるのものをひたすらに追求し続けていくこと。それがAI時代を乗り越えるために必要。
最後に作者の牛尾さんは日本のエンジニアを取り巻く文化に対して熱い想いを語ってました。
日本にとって致命的な足かせにならない「批判文化」というものがある。
とあり、完璧主義な日本人は少しでも欠陥があるとすぐに批判したがる傾向にあるのはX(旧Twitter)でよくわかります笑
どんなシステムにもバグはつきもので改善していくしかないことはもっと理解されるべき
実際にリリースされているアプリをみて欠陥があると「なんだここのアプリは？」と自身もまだまだ感じてしまっているのでバグに寛容になれるよう意識していかないといけないですね。
おわりに
いかがだったでしょうか？今までこれをやってきてよかったとか、ここはこう改善していこうとか色々と気付かされ、今後のエンジニア人生に役立つ一冊でした。
少しでもこの本が気になった方はぜひ手にとって見てみてはいかがでしょうか？
最後までご覧いただきありがとうございました！
記事を書くモチベーションになりますので少しでも良かったと思っていただけたら左上のいいねボタンポチッといただけますと幸いです。