【書評】『世界一流エンジニアの思考法』を読み直してみた

2025.02.26

この記事をシェアする

はじめに

こんにちは、CloudBuildersのsugawaraです。

みなさん、『世界一流エンジニアの思考法』って書籍はご存じでしょうか？2023年10月に出版され、当時話題になっていましたね。発売直後に自分も即購入して実際に読んでみたのですが、色々と学びの多い書籍でした。それから早1年が過ぎ、最近はエンジニアとして行き詰まりや伸び悩み、成長実感がないなど思うことがあったので、現状を打破すべく改めて再読してみました。

今回は『世界一流エンジニアの思考法』を読み直して得た学びと個人的に感じたことをまとめてみます。

著者紹介

著者の牛尾剛さんはMicrosoft Azureの中の人。具体的には、Azure Functions（AWSで言うLambda）の開発チームに在籍中です。大学卒業後、大手SIerに入社して様々なプロジェクトを経験し、その後は（アジャイル）開発やコンサルで独立・起業をしています。書籍内で言及される国内のエンジニアやSIerの問題点などについては当時の体験がもとになっていると思われます。

また、以前にも書籍を出版されており、なんとうちにもすでに1冊ありました！『ITエンジニアのゼロから始める英語勉強法』という英語学習本です！（一応元英語教員なのでこーゆー本は好き）

カバーそでにある著者紹介をみると、2013年の出版当時はまだ国内で働いていたときのものでした。海外で英語を使ってワークショップを開催するために英語学習をされていたようです。そしてその経験をもとにエンジニア向けの英語学習に関する書籍を出版されたんですね。最後はGAFAMへ転職してアメリカに移住し、実際に英語で仕事をされている。このストーリーは超かっこいいですね。いやー、とっても憧れます。

↓↓我が家の本たち

ちなみに書籍が大盛況のため、色々なインタビュー動画がYouTube上にあります。書籍からは読み取れない牛尾さんの人柄がよくわかります。動画を見た第一印象は、「あれ？フツーの大阪のおじさんだ！」でした。末尾にリンクを貼っておきますので、ご興味のある方は見てみてください！

目次と概要

下記は本書籍の目次になります。

第１章　世界一流エンジニアは何が違うのだろう？―生産性の高さの秘密
第２章　アメリカで見つけたマインドセット―日本にいるときには気づかなかったこと
第３章　脳に余裕を生む情報整理・記憶術―ガチで才能のある同僚たちの極意
第４章　コミュニケーションの極意―伝え方・聞き方・ディスカッション
第５章　生産性を高めるチームビルディング―「サーバントリーダーシップ」「自己組織型チーム」へ
第６章　仕事と人生の質を高める生活習慣術―「タイムボックス」制から身体づくりまで
第７章　ＡＩ時代をどう生き残るか？―変化に即応する力と脱「批判文化」のすすめ

Microsoftにいるつよつよエンジニアから学んだことや日米におけるIT業界や働き方の違いについて学ぶことができる書籍となっています。

先日発表された、ITエンジニア本大賞2025では惜しくも大賞は逃しましたが、特別賞を取ったとったみたいですね。

学びと所感

さて、ここから実際に書籍の内容をみていきます。特に印象に残った第1, 2, 4, 7章のみをここでは取り上げていきます。

第1章世界一流エンジニアは何が違うのだろう？―生産性の高さの秘密

本章では、Microsoftの一流エンジニアの生産性の高さについて、牛尾さんの実体験がつづられています。個人的にグサグサ刺さったところを引用していきます。

まずは牛尾さんが同僚とモブプロをしていて、同僚がいとも簡単にエラーを解決したという箇所です。情報収集をして、わかっていることから仮説を立てて検証し、そして実行する。いきなり手を動かさないということの重要性を説明していますが、自分が特に刺さったのが、思いつきで試行錯誤することは悪というところです。それについては、下記のように説明しています。

“振り返ってみれば、丸一日かけたのに、私は「何も成長していない」のだ。 単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない。まったく同じ状況で、同じ問題が起こったら、メモをとっておけば、次回の解決に役立つだろうが、問題が少しでも違えばお手上げだ。似たような問題が生じれば、また同じだけ時間を使ってしまうことも十分あり得るのが残念すぎる。”

もう思い当たる節がありすぎる！試行錯誤したことは自分なりにまとめてはいるが、それは個別・具体的なものしか解決できない。抽象化ができないため、応用も利かない。

これに関しては自分のダメダメさを痛感します。最近は何かとChatGPTに聞いて、ついそのまま解決できるかコピペして試してしまう。エラーなどに遭遇した際には、一度立ち止まって、本当に必要なことは何かを整理して目星をつけてから手を動かすようにしていきたいですね。

とはいえ、このことを意識しただけで、じゃあ「さっそくエラー時には立ち止まって現象を整理して、何が必要な対応なのかを見つけられるようになれる」のかと言えばもちろんNoです。

ここで必要とされるのは理解することです。そして、誰にとっても何かを理解するには時間がかかります。これはシニアエンジニアであっても例外ではない。しかし、シニアエンジニアの場合、これまでに積み重ねられた基礎があるため、理解にかかる時間はジュニアエンジニアのそれと比べると圧倒的に短くなる。だから基礎をしっかりとやる、と言う牛尾さん。

著者が実践したプログラミングを基礎からやり直す作戦は以下の3つです。

定時後や週末に、プログラミングの基礎を学ぶ。
C#の言語仕様を勉強する。
LeetCodeを一番簡単なレベルから毎日やる。

これをベテランのエンジニアが実行するのって、シンプルにすごくないですか？牛尾さんはずっと三流エンジニアを自称していますが、Microsoftに入社された方ですよ。40代でSIer含め業界歴も20年ほどの方が、もう一度基礎に戻るという決断をしたことに感化されて、最近自分もインフラを基礎からやり始めました。

2月は下記の書籍を使ってサーバまわりを集中的にやってます。前職がネットワークエンジニアだったこともあり、正直サーバについてあまりよくわかっておらず、とりあえずLPIC Level2までは取りましたという状態です。案件ではLambdaなどサーバレスが多くて、なかなか業務でサーバ構築する経験がないんですよね。。。

この件はまた別で記事にしようと思います！

第2章アメリカで見つけたマインドセット―日本にいるときには気づかなかったこと

最初に紹介されるマインドセットである、Be lazy（怠惰であれ）：「より少ない時間で価値を最大化するという考え方」自体は目新しいものではないです。きっとみんなこれが理想だと思いますが、なかなか実践できないものですね。ここに日米間で少し考え方に差異があるようです。

日本の場合、タスクに優先順位（高・中・低など）をつけて順番に処理していくことが一般的かと思います。しかし、このBe Lazyのマインドセットで大切なのは、一番重要なことのみにフォーカスすることです。優先順位をつけてすべてをやろうとはせず、もっともインパクトのあるもののみに集中する。それ以外は捨て去るという大胆なアプローチ。これを可能にするのが、“仕事は「どれだけやったか？」ではなく、「どれだけ会社にインパクトを与える仕事ができたか？」のほうが重要なのだから”という考え方です。

〇時間残業したとか、タスクを〇個消化できたという考えをしていた自分にはとても耳が痛い話ですね。このマインドセットは必ずしも顧客ありきの受託開発やSIer／SES企業には適用できないかもしれません。それでも、時間や仕事量ではなくインパクトで考えるという意識は持っておきたいですね。

また、“時間を固定化して、できることを最大化する“ということも個人的な学びになりました。簡単に言うと、決められた時間という制約の中で、最大限の成果を出すように努めるということです。例えば、プレゼンの準備期間がたくさんあると、あれもこれもと詰め込みたくなりますが、限られた時間の中で準備するとなると、大切なものだけに絞って準備する必要があります。

自分の場合はリモートワークのため、やろうと思えばいつでも仕事ができてしまいます。あとちょっとが終わらなかったから、あとで寝る前や次の日の早朝にやろうとついつい考えてしまい、業務時間外にちょっとした調べものやコーディングなどをしてしまったり。（そして気づくとけっこー時間が経っている。。。）

時間を固定化することで、業務中のパフォーマンスを上げ、さらには業務時間外の時間を自分のために使うことで、ワークとライフをキチンと切り分けたほうがいいなと感じました。それによってメリハリが生まれますし、深夜や早朝の時間を趣味や個人学習に充てることができますからね。

第4章コミュニケーションの極意―伝え方・聞き方・ディスカッション

この章は日本では応用しづらいかもしれないと思いつつ読んでいました。自分がもっとも面白く読めたのは、情報量を減らすという部分。何かを伝える際、たくさん情報があっても受け手側は処理しきれない。これは行政のパワポ資料が文字だらけなのが目に浮かびました。もちろんプレゼンなどもそうですが、日々のコミュニケーションでもこれが当てはまるようです。

分かりやすい例は、エラーが出た時の同僚とのやりとりです。日本だったら、誰かに質問する際には、礼儀作法として（？）どこまで調べたか、なにを試したかなどを書くべきとされているかと思います。一方、Microsoftのエンジニアは「このエラー出たけど、なんか知ってる？」というレベルの会話から始まる（！）。そして、対話しながら適宜必要な情報を提供していくスタイルらしいです。

最初からすべてを説明しないコミュニケーションによって、情報量を減らし、脳の負担を軽減するという。これは海外というか、Microsoftのつよつよエンジニアだからできることなのかなとも感じました。もし日本でこれを自分よりもできるエンジニアにやった場合、やっぱり色々と指摘されるのでは？~~（というか以前に色々と言われた）~~

自分はエラーなどつまづいたとき、過不足なく書こうとしてついつい長文で詳細を書いてしまいがちなのですが、こんな感じでもっとフランクにチャットができる文化はちょっと羨ましいなとは思いました。長文のチャットだと、書き手も読み手も疲れちゃいますよね。

第7章ＡＩ時代をどう生き残るか？―変化に即応する力と脱「批判文化」のすすめ

章のタイトルにある通り、いまはまさにAIの時代です。2023年にChatGPTが登場して以降、毎日様々な生成AIによるサービスが生み出されています。簡単なタスクやコーディングであれば、ジュニアレベルのエンジニア以上のアウトプットを出してきます。ここでよく言われるのが、エンジニア不要論ですね。

牛尾さんの意見では、自分の専門性を活かして生成AIと共存を図るというもので、”誰もやったことのないものに取り組んでいる専門家は、AIがとって代わることは原理的にあり得ない“と語られています。

ただ、”誰もやったことのないものに取り組んでいる”人ばかりではないのかなと個人的に思います。たしかに、顧客の要件に合わせる、自分の状況に合わせることは必要です。しかし、みんながみんな日々新しいことに挑戦しているわけではありません。それこそ、世界中で使われているAzureのようなクラウドプロバイダーの構築をするなんてかなりレアでしょう。

そうなると、絶対的に必要とされるエンジニア職は減りそうだと感じています。特に、ジュニアレベルのエンジニアのIT業界への参入障壁はかなり高くなったという印象です。今後はさらにDevinのようなAIエージェントを駆使することが一般的になってくると、エンジニア1人を雇うよりもAIエージェントのほうがコスパが良く、スムーズに開発を進められるようになりそうです。

ちょうど先日、DeNAの会長である南場さんが既存事業の人員を半分まで削減し、AIを使った新規事業に人員を割り当てるというお話をしていました。また、従業員10名足らずでユニコーン企業に成り上がれることも話されています。（詳細はこちら）

南場さんもエンジニア不要論自体には否定的で、業務知識を持ったAIエンジニア（？）の需要については拡大するという立場であり、牛尾さんとだいたい似た立場なのかなと思われます。

自分のようなよわよわエンジニアは、今後AIに食われないように身の振り方を慎重に考えざるを得ないなと感じました。専門性の獲得だけに留まらず、これまでAI分野はあまり追えていなかったのですが、改めてAIをもっと活用できるようになるべきと痛感しました。

なお、第7章の後半では、日本とアメリカの文化差について語られています。ここは牛尾さんの筆にかなり熱がこもっている気がします。日本の批判文化や完璧主義と海外の感謝の文化やフィードバックによる好循環の対比や、SIerの技術力低下などなど。日米比較については、必ずしも手放しで賛成できる内容ではないのですが、かなり強く自論を展開されています。気になる方は書籍を手に取ってみてください！