書物の紹介

世界一流エンジニアの思考法

ITエンジニア本大賞2024でビジネス書部門ベスト10に選ばれた本です（大賞はまだ未決定）
感想としては、エンジニアだけでなくすべての社会人に読んでほしい良書です。
重要ポイントのみをまとめましたが、実体験が面白くとても読みやすいので購入することもおすすめです。

はじめに

三流エンジニアで大人になってからADHDと診断されたがアメリカのマイクロソフトで働くことになり、どうやったら不得意なことが効率よく人並みにできるのか、仕事の生産性を上げる方法を意識的に研究する話

世界一流のエンジニアたちは著しく頭の回転が速いわけでも、天才的記憶力があるわけでもなく「思考法」（マインドセット）が高い生産性を形作っていることに気づく

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

問題が起きたときは手を動かさずに仮説を立てる
- 試行錯誤は悪
- 事実（データ）を１つみつける -> いくつかの仮説を立てる -> その仮説を証明するための行動をとる
- メンタルモデルの構築が大事
- 思い付きで色んなパターンを試して正解を探しているだけで時間がかかり、新しい知識を何も学んでない状態を避ける

「理解には時間がかかるもの」急がず徹底的に理解する習慣
- 優秀なエンジニアも繰り返し同じものをみたりして理解に時間をかけている
- 「早くできるようにがんばる」が将来の生産性を下げてしまう
- 理解の３要素
  - その構造をつかんで、人に説明できること
  - いつでもどこでも即座に取り出して使えること
  - 知見を踏まえて応用がきくこと
- コードの意図とその背後のアーキテクチャを理解するなど理解にしっかりと時間をかけることを恐れない
  - そうしないとGoogle検索してコーディングするGoogleプログラマになってしまう
- 「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」もの
- 作者が行った３つの作戦
  - 定時後や週末に、プログラミングの基礎を学ぶ
  - 言語の仕様を勉強する
  - 学習サイトの一番簡単なレベルから毎日やる
- 初歩学習を簡単だとバカにせず、１から様々なアプローチで勉強する
  - 徐々にかける時間がすくなくなり、理解がクリアになっていく

「感覚」でこれが問題だろうと決めつけず、ファクトを積み重ねるべき
- 自分でログなどを検証して問題解決しないと「思い込み」の穴に落ちてしまう

デザインドキュメント（小さなドキュメント）をコードの前に書く
- ドキュメントを書くことで自分の頭が整理され、抜け落ち等に気づく
- 考えているときに書けば、自動的にドキュメントになるのでそれをシェアするだけで済む
- ドキュメントの内容
  - Scope デザインドキュメントの範囲を書く
  - Background なぜこの提案を行っているのか背景を書く
  - Problem Statement 解決したい問題を書く
  - Proposal どういうデザインにするか、またその選択肢を選んだ理由をロジカルに書く、分量は2~10ページぐらいの簡潔なものにする

メンタルモデルを作る
- フローをビジュアル図としてイメージし、各パートの関係性を当てはめていく思考法
- 頭の中で考えを整理したり、問題発見に至るプロセスが大幅に高速化する

まずエキスパートに頼る
- 一つのことで2時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をするほうが断然生産性が高い
- 既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」のはベストプラクティス

「偉大な習慣を身に着けたプログラマ」になる
- どんな人も最初は難しく、理解には時間がかかる
- 自分が仕事をコントロールできているという感覚、何かわからないことがあっても「自分ならやれる」と覚える感覚を手に入れる

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

「Be Lazy」怠惰であれ
- より少ない時間で価値を最大化するという考え方
  - 望んでいる結果を達成するために、最低限の努力をする
  - 不必要なものや付加価値のない仕事（過剰準備含む）をなくす
  - 簡潔さを目指す
  - 優先順位を付ける
  - 時間や費やした努力より、アウトプットと生産性に重点を置く
  - 長時間労働しないように推奨する
  - 会議は会議の時間内で効率的かつ生産的に価値を提供する
- 最初に一つをピックアップしたら他はやらない
- 2-8の法則 20%の仕事が80%の価値を生む 100%までやるのは非効率
- 時間を固定してその中で価値を最大化する
- 準備や持ち帰りをやめてその場で完結する
  - 会議など準備や持ち帰りに時間をかけない
- インパクトの少ないものは物理的にどんどん作業を減らす

リスクや間違いを快く受け入れる
- 間違いを厳しく批判したり懲罰したりしない
- 失敗から学ぶ態度
- Fail Fast（早く失敗する）
- 実験が推奨されている
- 全員に「現状維持」や「標準」を要求せず、「臨機応変」が推奨される
- 非難や恐怖感のない環境
挑戦 -> 失敗 -> フィードバック -> 修正のサイクルが速いほど価値がある
検討ばかりしてさっさと「やらない」ほうが最大のリスク
失敗を受け入れる具体的な実践方法
- 「フィードバック」を歓迎するムードを作る
- 「検討」をやめて「検証」をする
- 「早く失敗」できるようにかんがえる
「納期は絶対」の神話は捨てる

Q（品質）C（コスト）D（納期）S（スコープ）はトレードオフ
- 進捗の「実績」だけで状況判断し、「納期」を固定したまま「スコープ」を出し入れするのが現実的
火急の依頼はマネジメント能力の欠如
「無理・断る」を練習する
- 無理を承知でのお願いは、みんなの疲弊を生み、チームや組織の改善に全くつながらない
現実を見て、フィードバックを受けて納期や仕事が変わるのはむしろ「善」
KPIは定時で無理なく楽に程度のものにする

進捗状況なんて聞かれず「やってみて実際どうだったか？改善ポイントやベストプラクティスは？」が聞かれる
取り組みの中で得た学びのシェアこそが十分バリューであり、会社にとっての財産

第3章脳に余裕を生む情報整理・記憶術 - ガチで才能のある同僚たちの極意

コードリーディングのコツ
- デベロッパーを信じて極力読まないこと
- 読む量を減らして脳に余裕を生む
自分にとって難しすぎると感じるときは、たいてい脳の使い方が間違っているサイン

仕事の難易度別で考える
- レベル１：何もググらずに即座に実装できる
- レベル２：どう解決するかはすぐに思いつくが、具体的な方法は忘れているのでググる必要がある
- レベル３：自分は解放を知らないが、スパイクソリューション（課題は悪のための大まかなプログラム）をしたらできそうなもの
- レベル４：自分だけでは解決が難しい、もしくはものすごいじかんがかかるもの
自分がしんどいと思う努力は一切やめてしまう
重要なのは今の自分にできないと見極めること
技術を徹底的に理解し、理解した情報の整理をして、すぐに取り出せるレベル１の状態にした時に生産性があがる

マルチタスクはやらない
- タスクを中断するときは記録などをしてすぐに戻れるようにする
- 1日4時間自分だけの時間を確保
自分のやったことをクリアに説明できるように時間をかけて言語化してみる
説明するということは、構造を整理して把握して、自分の脳のメモリに載せる必要がある
ブログを書くことが有効
人に説明できるようになったか？が記憶したかのチェックポイント
1日後、1週間後など適度に復習の習慣をつける

頭の中だけで整理する
- 訓練方法
  - ミーティングの議事をその場で書かない
  - 人の話を聞くときは、他人に説明することを想定して、聞きながら頭の中で整理する
  - 文章を書き出して考えるのではなく、頭の中で考えて、完全に整理し終えてから文章に書く
- 後で人に説明することを意識するだけでも、相当集中力や記憶力がが向上する
- 話を聞きながらビジュアルのイメージを作ったりメンタルモデルを脳の中で視覚化したりする

物事をできるようになる3つのファクター
- 理解
- 記憶
- 反復

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

「情報量を減らす」大切さ
- たくさん情報があっても消化できないだろう？という感覚
- 深的な情報は聞かれた時でいい
- 最初から全部説明せず、情報量を減らすコミュニケーションの仕方がすごく重要
- 情報を最小にし、「簡単なこと」をしっかり説明する
- 理解してもらうことに丁寧に時間をかける
- 相手が欲しい情報は何か？の感覚を研ぎ澄ます
メモを記録する時は日頃から人に伝えることを前提とした準備をしておくと、何か聞かれた際の工数削減に直結する
コードを書くときは「読んだ人がどう感じるか？」を意識しながら書く必要がある
ミスコミュニケーションのサインが現れた時点で、手を動かす前に「何かおかしいぞ」と気づいて、すぐにオフラインで話す機会を設ける
自分が知らないことほどリプロ（ソフトウェアの問題再現をする）ことで時間をかけても勉強をする

気軽に聞ける空気の大切さ
- 気軽に聞ける仕組みは、気軽に断れる空気とセットになっている
- すぐに助けになれない場合はクールに「ごめん」で断った方が、お互い気が楽

ディスカッションで鍛えられること
- その場でフィードバックがもらえるディスカッションは理解が深まる
- 間違えたら恥ずかしいという感覚は一切捨てる
- どちらが正しいとか間違っているとかではなく相手のことを理解して認めることが大事

意見が対立しても「否定」しない

ディスカッションのコツ
- 間違えたら恥ずかしいとは思わない
- 初心者こそ遠慮なく参加する
- 相手のことを理解して尊重する
- 切り出し「自分の意見では〜」
- 感謝の気持ちを忘れない
- 楽しんだもの勝ち

「会話力」を育てよう
- 会話力は「気合い」と「慣れ」の要素が大きい
- 互いが知識をシェアして高め合うことを助け合い、エンジョイすることに集中する

第5章生産性を高めるチームビルディング - 「サーバントリーダーシップ」「自己組織型チーム」へ

サーバントリーダーシップとはリーダーはビジョンとKPIを示すがチームが主体的に意思決定をしていく
チームメンバーを社員ではなくステークスホルダーとして扱う
インターナショナルな職場では、「自分で自分の考え方や人生に責任を持つのが大人」
マネージャーはいかにメンバーが幸せに働けているかに高い関心を持つ
仕事は楽しむもの
新人はできないものとして簡単な作業を任せるのではなく、できるものとして大人扱いして周囲の力を借りて仕事を任せることが大事
ボスの役割はサポートすることで命令することではない、困っているメンバーの障害を取り除くこと
周りが中長期的にどうキャリアアップすべきか相談に乗って、支援もしてくれる環境が大事

チームの上下関係をなくす
- チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな仲間として振る舞うのが大事
- 困ったら気軽に助けを求めて、他の人がすぐに助ける

失敗に寛容な職場がチャレンジ精神を生む
未知のものに挑むときは失敗が当たり前
仕事量を減らしてインパクトがあるものに注力する
できる人たちにパフォーマンスを発揮して欲しいのであれば、チームメンバーが仕事を楽しめる環境を作ることが大事
失敗してもポジティブな態度の方が良い

第6章仕事と人生の質を高める生活習慣術 - 「タイムボックス」制から身体作りまで

生産性を上げたければ定時上がりの方が効率が良い
時間を区切るタイムボックス制でスケジュールを組むと生産性が上がった

「脳の酷使をやめる」３つの工夫
- 瞑想をする（マインドフルネス）
- ディスプレイから意識的に離れる
- しっかり睡眠時間をとる

掃除により人生をコントロールする感覚を手に入れる
何かをしたら完了までやり切る
- 仕事でも整理されてすぐに取り出せる状況にして完了
コンピュータの掃除はいかに情報を取り出しやすいか
自分がどこに情報を置いたか記憶する癖をつける
物理的に整理がされると、細かいことへ目配りができる
筋トレによってテストステロンを増やす
肉類、玉ねぎ、加熱したニンニクもテストステロンを増やす

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

AIにより仕事が面白くなくなったら挑戦的なものを探すだけ
自分が何年も頑張ってきた分野のコンテキストで、どうしたらAIとアラインできるかを見つけ出す
専門性を追求する姿勢こそが強い
ソフトウェアエンジニアは今後もインテグレーションの主役

日本とアメリカのエンジニアの違い
- 日本は専門性を高めることが重視され、効率化は重要視されない
- 日本には批判文化があり大成しづらい状況にある
- 日本は完璧主義でメンツ重視、出来もしないことを精神論でやらせる
- ポジティブフィードバックによる好循環がない

自分の人生や幸せに責任を持って、自分でコントロールする

書物の紹介

はじめに

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

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

第3章 脳に余裕を生む情報整理・記憶術 - ガチで才能のある同僚たちの極意

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

第5章 生産性を高めるチームビルディング - 「サーバントリーダーシップ」「自己組織型チーム」へ