はじめに
本記事では、ITエンジニア本大賞2024のビジネス書部門でベスト10にランクインした、「世界一流エンジニアの思考法」 の要点と読了後の感想をまとめていきます。
『世界一流エンジニアの思考法』を読んだことがない人、または内容を復習したい人におすすめです。
どんな本なのか？
米マイクロソフトでソフトウェアシニアエンジニアを務めている自称三流プログラマの牛尾剛さんが同社で学んだ一流エンジニアたちの思考法について、その効果や具体的なアクションプランなどをわかりやすく紹介してくれる本です。
以下2点を意識していることがアピールされているので、気軽に手に取れる一冊となっています。
- 導入の難易度が低いこと
- 再現性が高いこと
要点PickUp！
第１章 世界一流エンジニアは何が違うのだろう？
試行錯誤は「悪」である
試行錯誤は時間がかかる上に新しい知識を学べないことが多いのでやるべきではないということ（正確には根拠無くいろいろ試すのは良くないよということ）
ではどうするのがよいのか？
→以下のように仮説をつくって動くようにする
- 事実（データ）を一つ見つける
- いくつかの仮説を立てる
- その仮説を証明するための行動をとる
複雑な技術をコントロールできている感覚を得る
これを得るために基礎をおろそかにせず勉強しようということ
牛尾剛さんが実際に実践したのは以下の3点とのこと
- 提示後や週末に、プログラミングの基礎を学ぶ
- C＃の言語仕様を勉強する
- LeetCodeを一番簡単なレベルから毎日やる
「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣をつけると、圧倒的に試行錯誤が減って問題を一直線に解決できるようになっていったそうだ。
頭の中に「メンタルモデル」をつくる
メンタルモデル（自分の心の中のイメージや理論のこと）をつくることで、頭の中で考えを整理したり、問題発見にいたるプロセスが大幅に高速化するということ
メンタルモデルの例
- システム思考
- MVP
など
いろいろ有名なものをインプットしてみて、独自にアレンジして使ってみよう。
まずエキスパートに頼る
（とくに既存システムがある場合は）あれこれ考える前にまず「エキスパートに頼る」のがベストプラクティスであるということ
「ググレ、カス」な文化は日本では奨励されがちだが、チーム全体の生産性を考えると無駄な部分が多い。
エキスパートから情報をシェアされ、そのレベルから理解するフェーズに入ることで、肝心なことにフォーカスすることができる。
個人的な意見だが、例えば配属当初の新卒メンバなどの学習のため、という場合はこの限りではないと思う。あくまで生産性を意識する場合の話だ。
第２章 アメリカで見つけたマインドセット
「Be Lazy」というマインドセット
日本語にすると「怠惰であれ」、端的に言うとより少ない時間で価値を最大化する考え方のこと
これを達成するための習慣は以下の通り
- 望んでいる結果を達成するために、最低限の努力をする
- 不必要なものや付加価値のない仕事をなくす
- 簡潔さを目指す
- 優先順位をつける
- 時間や費やした努力より、アウトプットと生産性に重点を置く
- 長時間労働しないように推奨する
- 会議は時間内で効率的かつ生産的に価値を提供する
いかにやることを減らすか？
「減らすこと」自体に価値があるということ
具体的なアクションプランは以下の通り
- 一つだけピックアップする
- 時間を固定して、できることを最大化する
- 「準備」「持ち帰り」をやめてその場で解決する
- 物理的にやることを減らす
リスクや間違いを快く受け入れる
無難な選択肢を実施してミスをしないことよりも、挑戦して失敗することでフィードバックを得て修正していべきということ
重要な点は以下の通り
- 間違いを厳しく批判しない
- 失敗から学ぶ
- Fail Fast(早く失敗する)
- 実験が推奨されている
- 「現状維持」ではなく、臨機応変が推奨される
第３章 脳に余裕を生む情報整理・記憶術
マルチタスクは生産性が最低なのでやらない
今手を付けている仕事を一つに限定すべきということ
例えば、会議中に内職したりするのやめようねって感じ
一日４時間は自分だけの時間を確保する
毎日４時間をブロックして、自分の作業だけをしようということ
Slackやメールを一切閉じて自分の作業だけをすることはとても罪悪感があるかもしれないが、その負を補ってあまりあるほど生産性が上がるのであればやったほうが合理的である。
その４時間以外はレスポンシブになれば、他のメンバーの業務が滞ることもない。
なぜ同僚たちは「記憶力」がいいのだろう
記憶するためのコツは「理解度を高める」ことにあるということ
具体的なアクションプランとしては以下
- 自分がやったことをクリアに説明できるよう時間をかけて言語化してみる
説明可能にするということは、構造を整理して把握して、脳のメモリに乗せる必要があり、これが記憶の定着に繋がるということ
第４章 コミュニケーションの極意
「情報量を減らす」大切さ
とくにエンジニアには、最初に渡す情報を少なくしようということ
例えば担当機能の実装中にエラーが起き、それが解決できずに困っている場合、先輩エンジニアに質問を行うだろう。
日本、少なくとも私の経験上では、その時に自分の環境の詳細や、調べたこと、試したこと、その他あらゆる情報を入れれば入れるだけ良いという文化がなんとなくある。
本項はこれを根本から否定するような考え方を紹介していて、最初に渡す情報は必要最低限にして付加的な情報は聞かれてから渡すほうが良いと断言している。
理由はシンプルで、たくさん書いてあると読むのも理解するのも大変だから。
付加的な情報がなくとも解決すれば、それで終わりだし、付加的な情報が必要であれば、必要なものだけ聞かれるので答えればよい。
聞かれそうだなーということを必死に網羅しようと頑張っても、お互いに得することは実はあまり無いのである。
個人的には、「情報量が多いほど良い」という文化は、プログラミング初心者の時、忙しい先輩に質問する際にそういう指摘をされることで刷り込まれたような気がする。
相手が求めている情報への感度を研ぎ澄ます
「相手が本当に欲しい情報は何か？」を意識することが生産性を向上させるカギであるということ
具体的なアクションプランとしては、日頃から人に伝えることを前提とした準備（メモ）をしておくというものがある。（人に質問された際の工数削減にもなる）
よく使うコマンドやクエリ、ワークフローなど、自分用にまとめているものを他人にもわかりやすくまとめておく習慣をつけよう。
クイックコールのすすめ
リモートワーク環境の中でチャットでは伝えにくいようなことは気軽に電話をかけちゃうことで生産性が上がるということ
音声のほうが100倍以上情報量があり、インタラクティブ性、フィードバックが速いので、間違いなくやったほうがいい。
実際オフラインのときは質問したい人のデスクまで歩いていって気軽に質問しているのだから、問題のあろうはずがない。
もちろん、かける前に一言了解を得るのは大前提。
第５章 生産性を高めるチームビルディング
「サーバントリーダーシップ」とは何か
サーバントリーダーシップとは、リーダーは＜ビジョンとKPI＞のみを示し、そのためにどう動くかはチームが主体的に考えて意識決定していくという考え方のこと
対して、現状の日本で主流なのは「コマンドコントロール」という考え方で、リーダーが部下に指示を出し、部下の状況を把握、確認し、管理していく、いわゆる「マイクロマネジメント」なスタイル。
サーバントリーダーシップ制では、メンバーが主体で動くことが前提となり、リーダーの役割は以下
- ビジョンとKPIを示す
- メンバーから相談があれば、その障害を取り除く
大切なのは、メンバーを「社員」として扱うのではなく、立場の同じ「ステークホルダー」として扱うこと
「仕事を楽しんでいるか？」を確認する文化
マネージャーが意識すべきは仕事の進捗や課題より、メンタル面であるということ
サーバントリーダーシップにおいて大切な考え方の一つ
いかにメンバーたちが幸せに働けるかに高い関心を寄せ、エンパワーしよう。
「仕事は楽しむもの！」
ボスの役割はサポートすること
マネージャーの役割はメンバーの障害を取り除くこと、つまりサポートするところにあるということ
相談があればいろいろアドバイスをするが、細かく指示することはなく、自分から積極的にアドバイスしにいくこともしない。
あらかじめ、誰にでも（目上の人にも）相談しやすい空気をチーム内で作っておくことも大切である。
第６章 仕事と人生の質を高める生活習慣術
生産性を上げたければ定時上がりが効率良い
長期的に見ると、生産性を上げるのは長時間労働ではなく学習であるということ
仕事を定時で切り上げて、その後自分のやりたいトピックを勉強する。
そうすることで根本的な生産性を上げることができる。
「タイムボックス」制で、学習の時間を確保する
仕事をやめる時間を決め、それを守ることで結果的に生産性が上がるということ
脳の酷使をやめること、また浮いた時間でリフレッシュを行うことで結果的に生産性を上げることができたそう。
また、今どれくらい何に時間を使っているのかを分析して、何にどれくらい時間を配分するかを決めるとなお効果が高いとのこと。
「脳の酷使をやめる」三つの工夫
デスクワークにおいて生産性向上を阻む大きな要因は身体以上に「脳の疲れ」なのでやめようということ
具体的なアクションプランは以下
- 瞑想をする（マインドフルネス）
- ディスプレイから意識的に離れる
- しっかり睡眠時間をとる
第７章 AI時代をどう生き残るか？
どんな職業ならAIに食われないだろう？
AIに食われないものは、少なくともしばらくは身体的なもの、対人的なもの、創造的な仕事や、芸術などの分野ではないかということ
AIが完璧な料理を作れても、完璧な演奏ができたとしても、しばらくの間、人は人が作ったものを求めるだろう。なぜならばこれらは不完全さが個性であるからだ。
AI時代には「専門性」こそが強みとなる
時流に惑わされず「専門性」を追求する姿勢こそが正しい選択なのでは、ということ
エンジニアに限らず、AIに今の仕事がとって変わられたらどうしよう。。。と考える人は少なくないだろう。
そんな人を救う一言
「いいトリックがあって、自分が何年も頑張ってきた分野のコンテキストで、どうしたらAIとアラインできるかを見つけ出して、そこから行くんだよ。それはたぶん、多くの分野でとてもインパクトがある。」
つまり、目の前の仕事を頑張って己の専門性を高めていくことが最良の打ち手であるということだ。
個人的にはAIに関するエンジニアリングを学んでいく等の打ち手が最良なのでは？と思っていたので意外だった
まとめ・感想
個人的に今の状況に刺さる内容が多く、明日から試してみようと思うことがてんこもりでした。
思考法を紹介するだけでなく、なぜそれが良いのかを自分の経験談で示してくれているので、今の自分にも効果があるか、イメージしやすかったです。
また、内容も若手からベテランまでだれでも試せるものがほとんどだったり、説明が複雑なものはイラストを交えてわかりやすく解説されていたのも助かりました。
まだ4月ですが、今年の個人的良書ランキングのトップに入ってくることは間違いないです！
最後に、本記事の内容についてご指摘、ご質問などありましたら、どしどしコメントいただけると嬉しいです。
以上、ご覧戴きありがとうございましたmm