「世界一流エンジニアの思考法」を読んで
Contents
はじめに
「世界一流エンジニアの思考法」を読みました。 とても素晴らしい本だと感じたのでその感想を今のうちにまとめておこうと思います。
本の概要
全７章からなる本です。
1~5章は筆者の牛尾剛さんがマイクロソフトのAzure Functionsチームで働いた経験を元に彼のチームの世界最高峰の思考法を実例を元に紹介されています。
6章はエンジニアとしての仕事面だけではなく、仕事以外で気をつけるべきポイントや思考法について紹介されています。
最後の7章はChatGPTをはじめとしたLLMの登場によってエンジニアの仕事にどのような変化があったのか、それについてどう対応指導考えるべきかが紹介されています。
各章で個人的に印象に残った部分を引用しながら紹介して感想を書いていこうと思います。
第１章 世界一流のエンジニアは何が違うのだろう？
試行錯誤をするのではなく、事実から仮説を立てて検証する
まず手を動かす、試行錯誤は悪である
私も若い頃はこのようなやり方をやっていたなぁと思い出しながら読んでいました。
何も考えずに手当たり次第試してみる、というのが役に立つこともあるかもしれませんが、仕事として成果を出すために闇雲に試行錯誤するのは良くないなと改めて感じました。
感覚で問題がこれだろうと決めつけていたのが問題であくまでファクトを積み上げるべきだった
耳が痛くなる一言でした。経験を積めば積むほど昔の経験が問題を推察してしまうことがあるように感じます。
障害などの問題を解決する場合にはファクトベースで仮説を立てていくことが大事だと改めて感じました。
理解は時間がかかるものとして急がずに徹底的に理解する習慣をつける 理解の三原則は
- その構造を掴んで人に説明できること
- いつでもどこでも即座に取り出して使えること
- 知見を踏まえて応用が効くこと
これも本当に大事だと思いました。成果を出すために焦って理解が浅いまま進めてしまうと後で痛い目を見ることはありそうだよな、と思いました。
急がば回れ、しっかりと技術をベースから理解することが結果的に早くなるというのは実際の仕事でも感じているところがあったのでとても納得感がありました。
デザインドックを書く ドキュメントを書くことで頭が整理される。抜け穴も見つかる。 考えているときにドキュメントを書けば後でそれをシェアするだけでよくなる
より難しい問題に取り組むときには非常に大事なことだと思いました。
考えならがドキュメントを書いて結果的に頭が整理される、というのは仕事術として良い方法だと感じました。
メンタルモデルを作るのが大事 頭の中でシステムの動作をイメージとして想像すること
これも非常に共感しました。頭の中で具体的なイメージがあればあるほど実際のコードを書いた時のスピード感がより早いと感じることは多々あります。
逆に頭の中のイメージがボヤッとしているとコードを書くのも時間がかかります。
これを「メンタルモデルを作ることが大事」という言葉で表現されているのはとてもわかりやすかったです。
複雑なシステムほど自分で調べるのではなくエキスパートに頼る方がはるかに効率的 自分で調べてわからない場合に聞く（ggrks）のは日本人の文化で、既存システムがある場合はエキスパートに頼るのはベストプラクティス
これは日本の開発者あるあるだと思いました。私も「新人の頃は自分で調べてどうしてもわからないことを聞く」というようなことを言われていました。
ただ仕事をしていて既存のシステムがあった場合にコードをみてわからない部分もそれを作った人に聞くとそのコンテキストなどを含めて説明してもらえるのでこの文化はとてもよいと感じました。
第２章 アメリカで見つけたマインドセット
最も大事な思考法はBe lazy、より少ない時間で価値を最大化する 望んだある結果を達成するために最低限の努力をする
この思考法もとても大事だと感じました。私も既成概念にとらわれてしまうことは良くあるので、常に意識していたいことです。
時間や費やした努力よりアウトプットと生産性に重点を置く
努力を評価しがちなのでちゃんと結果を見ることは大事だと改めて感じました。
長時間労働しないように推奨する 会議は会議の時間内で効率的かつ生産的に価値を提供する
これも普段から意識していきたいです。
優先順位 一番高い一つをピックアップして他はやらない 不要なタスクを減らすことで本来やるべきタスクに集中できる 物理的にやることを減らす。仕事はどれだけやったかではなくどれだけインパクトのある仕事をやったかが大事
この話も耳が痛いです。優先順位をつけた上で1番目と2番目を並行して進める、ということは容易にやってしまうので、「最優先以外はやらない」という考え方があるということもちゃんと意識していきたいです。
リスクや間違いを受け入れる やってみて早くフィードバックを受けて間違いを訂正していく 検討ばかりしてさっさとやらないことが最大のリスク
Try & Errorをして失敗を受け入れていくことで良い良いものをスピード感持って作っていけるのかなと感じました。
同じ失敗を繰り返して進化のない人への対応は評価。KPIを決めて達成できなければクビ 失敗は結果でどんなフィードバックを得たかが大事
ただ失敗を受け入れるだけで成長しないのはダメ。失敗を受け入れてフィードバックを受けて成長して次はより高レベルな失敗をする、ということなんだなぁと思いました。
失敗を受け入れる実践法 フィードバックを歓迎するムードを作る 検討ではなく検証
ただ失敗してもいいですよーと言ってるだけだと実戦はなかなか難しそう。ムード作りは大事だよなーと思いました。
アーキテクチャやツールで決めかねているならどっちでもよい、趣味で選ぶ。圧倒的な差なら決めかねない、決めかねるなら差は少ないはず。
この言葉は青天の霹靂でした。技術選定で何かしらの理由をつけて最後に選んでますが、結局は趣味だよなーとひっかかるところが昔からありました。
確かに圧倒的な差があれば即決できるし、決めかねるなら差は少ないはず、というのはとても納得感がありました。
最後は趣味で選ぶ、と言い切ってしまっているのも清々しくて良いです。
不確実性を受け入れる 納期は絶対、の神話は捨てる
Azureの現場ですらこの考え方なので納期を守るっていうのは本当に難しいことでそれを目指してはいないんだなと知りました。
思考回路を形作る実践
- 楽に達成できる計画にする。たくさん物量をこなす＝生産性が高い、ではない。価値にフォーカスする。
- 無理、断る練習をする。無理は承知だけど、は疲弊を生み改善がされない
- 他の文化の視点を学ぶ
日本だと「頑張る」というのが安易に選択しがちなので、無理、断る、というのが結果的に価値に繋がるという考え方は大事だと思いました。
結果を出す、からバリューを出す、へ KPIは定時で無理なく達成できるものであるべき
こう言った指標は基本的に達成がかなり難しいものを設定するのだと思っていましたが、真逆でした。
第３章 脳に余裕を生む情報整理、記憶術
コードリーディングのこつは極力読まないこと 他を信頼して実装は動くものと捉える
これができる環境がとても素晴らしいです。場合によってはインターフェースが信じられないコードもあるのでここは見極めが必要かなと感じました。
いかに脳みその負荷を減らすか 余計なコードはなるべく読まずに使ってるパラメータとインターフェースを理解する 自分にとって難しすぎると感じてる場合は脳を酷使し過ぎているケース
ここは目的によるかなぁ。ユースケースレベルで読みたい場合は詳細を追うべきではない、逆に詳細をみたい場合は詳細を追うべき。
仕事の難易度別で考える L1 何もググらずにできる L2 ググればできる L3 スパイクソリューションがあれば出来る L4 自分では無理 L2→L1を増やすと生産性が上がる
これはホントその通りだと思いました。ググらずにできることが一番生産性が高いのは間違い無いです。
それを忘れずに日々精進していきたいです。
アウトカム至上主義が上達を阻害する アウトプットが遅くなっても技術を徹底的に理解して、整理してすぐに取り出せるレベル1にしてこそ生産性があがる
ここでも急がば回れ、ということですね。定レイヤーを理解していれば上位レイヤーの理解が早い、と言われているようなことにも通じるのかなと思いました。
なぜ同僚は記憶力がいいのか コードを書いても理解が浅いことがある。自分がやったことをクリアに説明出来るように言語化してみる
人に説明ができる程度の理解をすべき、というのは完全同意です。
第４章 コミュニケーションの極意
情報量を減らす大切さ アメリカでは情報が少ない方が喜ばれる 付加的な情報は聞かれたら答える
これはこの本の中でも特に印象深い内容でした。
日本だとなるべく多くの情報を伝えることが大事だという文化があるのですが、欧米は完全に逆だということを初めて知りました。
確かに職場の同僚の欧米系の人は最初の情報が少ないように思っていたのですが、文化の違いだということがわかりました。
クイックコールを使う メンタルモデルやコンテキストがなければすぐさまエキスパートに聞いた方が良い
これも重要ですね。
クイックコールされる側もいいことがある 聞かれた側も将来の時間が節約できる 知らなかった場合に学べる
これも同意です。一人で考えているのと人に聞かれるのでは視点が変わって一人で考えていた時では思いつかなかったことが思いついたりします。
気軽に聞ける空気の大切さ 気軽に聞ける仕組みは気軽に断れる空気とセットになってる 助けにならない場合に抱え込まないで、知らないごめんと答えた方が聞く側も楽
これは確かにな、と思いました。日々気軽に聞ける空気作りというのは意識していますが、なかなかうまく効果が出てないように感じていました。
聞かれた側も知らないことを調べてまで答えるのではなく、知らない場合は知らないよごめん、と言えることが気軽に聞けることに繋がる、というのはとても納得感がありました。
第５章 生産性を高めるチームビルディング
「コマンドアンドコントロール」ではなく「サーバントリーダーシップ」
現在私が働いている環境もサーバントリーダーシップ型の組織なのでこの章で書かれていることには共感できました。
突き詰めるとティール組織みたいなことなのかな、と思いながら読んでいました。
仕事は楽しむもの、というカルチャーがある
日本だと仕事は辛いもの、というようなイメージがありますが欧米は真逆で楽しい仕事しかしない、つまらなくなったら別の楽しい仕事を探す、という文化だそうです。
これはとてもいい考え方です。日本でもそのような思考法で仕事ができれば色々な悩みがなくなりそうです。
ただ、このような働き方をするためには自身が職場を選択できる必要があって、そのためには技術力などを日々磨く必要があるな、と改めて思いました。
他の人の脳みそを借りて最適なアイデアを選択しようという姿勢
日本では議論をしていても既に答えは決定している、ということが良くありました。 ここでは議論は議論で他の人のアイデアを借りてよりよいものを選択しようという姿勢で議論をすることが重要というようなことが書かれていました。 私も議論をする時にはこのような考え方で行うことが多いので、間違ってなかったんだと自信になりました。
失敗してもポジティブでいる
失敗すると終わり、ではなく失敗してもポジティブに捉えてフィードバックを次に活かすのが大事だと書かれていました。 私は失敗するととても落ち込んでしまうので、もっとポジティブに考えないとなと思いました。
第６章 仕事と人生の質を高める生活習慣
生産性を上げるには勉強 そのために仕事は定時で終わらせる
ホントその通りだようなぁと思いました。仕事だけだとどうしても視野が狭くなってしまうので、仕事以外の分野の勉強は大事だと思います。
仕事外のプログラミングはリラックスして出来る
これも本当にその通りだと思いました。先日職場でこのような話になった時にプライベートでのプログラミングと仕事のプラグラミングの違いをうまく説明できなかったのですが、まさにこれだと思いました。 仕事でのプログラミングも嫌なわけでは無いのですがやはりプライベートでコードを書くのとは何か違いますよね。
ナッツにはテストステロンを高める亜鉛が入っているので間食にオススメ
仕事中によく間食をしてしまうのでこれは覚えておきたいです、早速ナッツを買ってきました。
第７章 AI時代をどう生きるか
AIが出ても専門性を高く保っていればしばらく仕事を奪われることは無いだろう、といったことが書かれていました。
面倒なことをやりたくないから自分でできない選択をしている
これはありがちだよな、と思いました。自分も面倒なことを避けてしまうことが多いので、これは改めて意識していきたいです。
まとめ
この本を読むことで色々な気づきが得られました。本を読んで終わりにしないでちゃんと実践して経験に生かしていきたいです。
Author ken-aio
LastMod 2024-03-09