【本要約】世界一流エンジニアの思考法〜深い理解と情報をシンプルに見える化しよう

仕事やビジネスで圧倒的に成功するには、高度なスキルと知識が必要だと多くの人は考えています。
そうやって、人はスキルを身に着けようと苦手なプログラムやマーケティングノウハウを身に着けようと必死になります。

しかし、スキルはどれだけ磨いても新人とベテランでは、せいぜい1〜3倍くらいしか差がつきません。

ではどこで圧倒的な差が生まれるのでしょうか。
それは思考法です。
思考法は人によって1〜50倍の差が生まれます。
生産性＝スキル×思考法という公算が成り立ち、1〜150倍の差が生まれます。
ビジネスやプライベートなど全ての土台となる思考法を学ぶことで人生で圧倒的なパフォーマンスを発揮することが可能です。

今回ご紹介するのはマイクロソフト本社でシニアソフトウェアエンジニアとして活躍されている牛尾剛さんが書かれた「世界一流エンジニアの思考法」です。

僕自身、この本を読んだのは2024年1月でしたが、今年読んだビジネス書籍の中でも非常に学びが多かったので、今回本腰を入れて要約してみました。
特にエンジニア視点での思考法というのが、本書の魅力です。
プログラミングに無縁の人でも、プログラムを自分自身の仕事やビジネスに置き換えて考えることで自分ごと化できます。

本書が伝えたいのは「生産性向上の要はツールのTipsなどの小手先テクニック（HOW）ではなく思考法（マインドセット）」というメッセージです。

全248ページの中から、僕が特に大切だと感じた部分をお伝えします。

世界一流エンジニアの思考法 (文春e-book)

理解に時間をかける

なんとなく分かるようなコードやプログラムでも背景など深く理解する。
人にいつでもシンプルに説明できるレベルで。
早く調べて正解を出して仕事を片付けようではなく、しっかり理解する事に対して時間をかけることを恐れない。
一流エンジニアでも理解には時間がかかる。
しかし、理解してる事が多いので結果、新しい事を学んでも理解してる事同士が繋がり、理解度が深くなる。

逆にプログラムなどで問題が起こった時、やってはいけない対処方法としては、思いつきで手当たり次第に手を動かすこと。
手を動かして試行錯誤することは悪である。
まずやるべきは、事実（データ）を一つ見つける→仮説を立てる→仮説を証明するために行動する（アプローチを選定してから動く）ということ。

また今、自分にあるスキルだけで対応はせず、未来の生産性をあげるために、問題や課題が起きたタイミングで新しいスキルを学ぶ機会として考え、学びながら新しいアプローチ方法も検討する。

感覚で判断せずファクトを積み重ねる

何か問題が起こった際、感覚で判断しない。
実装方法としてA〜C案を考えてA案から順に動かしてファクトを重ねる。
最初のA案が動作しなかった場合、その原因を正確にログから分析し、なぜ動作しなかったのだろうか？と理解に十分時間をかける。
同様に上司や顧客からの指摘や意見についても、人間の言うことは間違っている可能性もあることを念頭に、感覚で判断せずファクトを追求する。
思い込みバイアスにかからない。

バリューストリームマップ（VSM）で見える化する

バリューストリームマップ（VSM）とは、開発からリリースまで各工程を全て洗い出して、どこに時間がかかっているかを図に見える化したもの。

業務には無駄と思えるプロセスが多く含まれているが、普段それにどれくらいの時間がとられているか気が付きにくい。
（上司やクライアントに提出する必要以上に細かなレポート作成、承認までのウェイトタイムなど）
大抵の上司やクライアントは細かなレポートよりもシンプルで見やすいレポート、そしてなるべく早くリリースしてもらいたいと考えている。
だから一度、バリューストリームマップを作り、ここのプロセスをカットすればスピードがあがるなど上席に対して説明をして承認を得ることで開発やリードタイムなど短縮に繋がる。

メンタルモデルとシステム思考

ここでいうメンタルモデルとシステム思考とは、事業やサービスなど複雑な全体システムを自分自身とメンバーが理解できるようにしたフレームワーク。

全体システムの相関図をシンプルにイメージ＆ビジュアル化して、それぞれがどう関係し影響しているかを全体俯瞰できると、複雑なシステムを自分は理解しているという感覚になり、全体から細部に至るまで、「これはどこに影響をしているか？問題が起こったときの原因はどこか？」など早期究明につながる。
（システム内の一部を最適化するときも同様）

システム思考をベースに組織全体の把握と課題発見、目標達成におけるボトルネック、改革を推進することも可能。

デザインドキュメント

コードを書く前に小さなドキュメントを書くことで思考が整理される。
デザインドキュメントとは要件定義書とは違い、自分自身でその要件定義から実装までをスムーズに作業できるようにまとめた小さくシンプルな設計書。
（長文ではなく、誰がみてもすぐに理解できるもの）
デザインドキュメントはGoogleやマイクロソフトで採用されている。
プロジェクト開始時に方向性を明確化し、チームメンバー間の認識を共有するためにも用いられる。

デザインドキュメントのフォーマット

1. 背景と目的

• 概要: このプロジェクトの背景、なぜ必要か。
• 目標: 具体的に解決したい問題や達成したい結果を明記。

2. スコープ

• 対象範囲: プロジェクトがカバーする範囲を定義。
• 除外範囲: 意図的に取り組まない領域を明記。

3. 提案するソリューション

• アプローチ: 解決策の概要を簡潔に記述。
• 技術的な選択肢: 他の候補がある場合、それらと選択理由。

4. 技術仕様

• システム構成: 図やフローを使い、全体構成を視覚的に説明。
• 依存関係: 他のシステムやサービスとの関連性。
• 制約: 技術的・時間的制約を明記。

5. リスクと課題

• 想定されるリスク: 予想される問題点。
• 緩和策: リスクを減らすためのアプローチ。

6. 目標・成功基準

• 定量的指標: 測定可能な目標達成の基準。
• 定性的基準: ユーザーや関係者の満足度など。

7. スケジュール

• マイルストーン: 主なタスクとそれにかかる期間。
• リリース日など: いつ何をリリースするか。

8. レビューと承認

• レビュープロセス: 誰が何を確認し、承認するか。

デザインドキュメントは仕事以外でもプライベート含めて広く応用できる。
まずいきなり手を動かさずに、小さなドキュメントを書くという習慣を身につけよう。

アジャイルとスクラム

アジャイルとは機能ごとに小さく分類し、優先順位の高いものから要件定義→設計→実装→テスト→リリースという一つのサイクルを短いスパンで頻繁に繰り返す開発手法。
従来のウォーターフォールのように、上流から下流に向けて時間と大人数をかけて実施するものではない。
スクラムとはアジャイルの手法の一つで、メンバー全員がオーナーシップをもって開発にあたる。
（コミュニケーションが重要になる）

Amazonやマイクロソフトなど米国企業を中心に現在、ウォーターフォール開発ではなくアジャイル開発にシフトしている。
アジャイル開発は計画重視でなく、改善を前提としているため意思決定のスピードが早く、そのためトップダウンでなく現場に一定の権限を与える必要性がある。
デメリットはスケジュールのコントロールが難しい（開発をの区切りをどこに持たせるかなど）

be Lazy〜怠惰であれ

be Lazyとは、より少ない時間で価値を最大化するという考え方。

• 優先順位をつける。
• シンプル簡素さを目指す。
• 残業や長時間労働を前提として働かない。
• 会議は会議の中で完結させる。
• 時間や労力よりもアウトプットと生産性を重点におく。

例えば日本と海外では優先順位の付け方について根本的な考え方の違いがある。
日本は優先順位をつけて1番重要なことから順番に全てを実施するというのが一般的だが、海外は1番重要なことを決めたら、ほかは捨てる。
実施する物量が少ないので生産性が高まるし、20:80の法則が示す通り、20%の仕事が80%の価値や成果を生み出す。
コアとなるタスクだけに注力できる。

いかにやることを減らすか？

減らすこと自体に価値がある。
タスクの中から一番重要なことだけを一つピックアップするという思考を身につける。
「時間」「物量」「常識」を見直して複雑なものをシンプルにする。

時間に制約をつける

仕事をする時間を固定したり、時間に制約をつけることで、やるべきとが削ぎ落とされて重要なことに集中できる。
例：締め切りを自分自身で短く設定することで、余計な仕事（社内向けプレゼン資料のデザインに拘るなど）は物理的にできなくなり、本当に重要な要点のみフォーカスできる。

物理的にやることを減らす

統計ではユーザーはソフトウェアの4割の機能しか使わない。多すぎる機能があっても使わない（使えない）。であるなら6割は不要として4割に注力した方がいいという考え方。
マイクロソフトのマネージャーはそのようにスコープ（予定していた機能）について、2週間に1回の定例Mtでエンジニアの作業進捗と優先順位を鑑みて、どんどん省く。

Fail Fast〜いかに早く失敗するか？

失敗→フィードバック→修正→挑戦という風土が大切になる。
検討に時間をかけて結局やらないという結論に至ることで生み出される成果はかけた時間分ー100点。
しかし、すぐにその場でやって失敗を発見しても、修正して形にできれば、両者には大きな成果の差となる。
もちろん、失敗ばかりして進捗がなければ、それは評価として跳ね返ってくる。
米国ではKPIが達成できなければ減給、クビという厳しい労働環境の中にある。
だからこそ、成果を出すために途中の無駄なことを削ぎ落とす必要性がある。

「納期」という絶対神話を捨てる

日本では納期（デッドライン）が絶対厳守だが、アメリカでは少し違う。
多くは納期通り納品はするが、中身は想定よりもシンプルになったり機能が削がれていたりする。
Q（品質）＋C（コスト）＋D（デッドライン/納期）＋S（スコープ/物量）は全てトレードオフ。
Dを守るには、QかS、またはいずれかを落とすか、Cを上げるかになる。
QとCを維持したままDも取るのであればSを捨てるしかない。
リリース日になくても、まずはリリースをしてから後から機能追加や改善をした方がより良い。
失敗を早くして、早くフィードバックを得る方が良いからだ。

コードリーディングのコツは極力読まないこと

コードリーディングを端から端まで理解しようと読むことはコード自体に圧倒されて脳疲労し理解できない。
コツは要所だけを絞って細かい部分は読まないこと。
メソッドやクラスのインターフェイスの役割やパラメーターのみしぼって読む。
自分にとって難しすぎると感じるときは脳の使い方を間違っていると認識する。

結果を出すからバリューを出すへ

納期通りに完了させるという結果より、その結果からターゲットやチームの成果や効果などの貢献につながるアウトカム（バリュー）を出すことをフォーカスする。
納期厳守はバリューを構成するその一つでしかない。

仕事を難易度別で考える

• レベル1：ググらずにできること
• レベル2：ググればできること
• レベル3：今の自分にはそもそも理解できないこと（課題把握から必要など）

生産性を上げる時、圧倒的にスピードが上がるのはレベル2の難易度の仕事をレベル1に落とすこと。
今取り組んでいる仕事はレベルはいくつか？を意識してみる。

WIP=1〜マルチタスクはしない

WIPとはWork in progress（現在取り組んでいる仕事）のこと。
会議をしているなら会議のみに集中して、その場で結論や進捗を促す。
メール対応ならメール対応のみ集中する。
他の作業はそれが終わってからにする。
人間の脳はマルチタスクには向いていない。
途中で作業から離れるときは、すぐに再開できるようにウィンドウやタブなどは開っぱなしにしておく。
作業復帰するまで時間を最短にする。

記憶力は理解度の差

理解していると思っても実は深く理解していない場合が多い。
そうなるとその物事自体の記憶力にも影響する。
理解しているかどうかは、自分自身でその概要についてコトバに発して言語化してみること。

そこで話が詰まるようだったり、説明しにくいということであれば十分な理解ができておらず、その事についても記憶力が曖昧である可能性がある。
人に説明できるレベル、ある程度想定される質問に対しては答えられる程度にしておくことで理解が深まる。

コーネルメソッドノート

頭の中だけで情報を整理するを意識してみる。
（議事録をとることに徹するのを辞める）
会議中は記憶にとどめて整理をして理解できないところは聞くに徹する。
要点などのメモくらいは書き残しつつ、議題に対してディスカッションすることに集中する。

相手が求めている情報の感度を研ぎ澄ます

情報を与える場合、1〜100まで盛り込みすぎず、相手が必要としている情報は何かを突き止める。
なるべく相手の脳の負荷を落としてあげるような簡潔さをもって情報を伝える。

自分メモではなく、他人が見て役に立つメモとして残す

議事録や課題、改善に関するメモについては、他人にとって約立つフォーマットで整える。
「チームにはじめて配属された人向けにまず読んでもらうもの」などレイヤーによって替えてもいい。

クイックコール

リモートワークの場合、気軽に聞けなかったり、オンライン会議では、なかなか話の中に入っていけない。
プロジェクトやタスクの進捗が遅かったり、不明点があれば一対一ですぐにビデオチャットなどをする（クイックコール）のも手。
クイックコールされる側も数分で状況がより理解できたり、進捗が進むので有難られるし、相互理解にもつながる。
だから奥せず、クイックコールを活用する。
そっちのほうが生産性やスピードは高まる。

気軽に人に聞ける空気の大切さ

技術イケメンでも知らないことを恥とも思わず気軽に隣の人に聞いている。
聞かれた側も力になれないと分かれば、すぐに他人にサポートを協力するよう助言する。

面白いエピソードとしてAppleのスティーブ・ジョブズはiPhone発表のプレゼン後に、聴衆から新しいiPhoneの新機能について教えてほしいと質問した。
ジョブズは「Good Question!」と答えて、また同じ説明をした。
ジョブズ自身、聴衆にプレゼン内容が伝わっていないと理解できたし、聴衆も聞いたがよく分からないことを奥せず質問した。

これは会議中など自分が理解できていないと感じる場合、周囲も同様に理解できていない人がいる可能性が極めて高い。
こういった質問は自分だけではなく、周囲の人々にも役立つし、質問が活発となるし、心理的安全性にも貢献する。

ディスカッション・意見の対立を楽しむ

インターナショナルチームは国籍、文化などバックグラウンドが全く異なり、多様性に富んでいる。
全員の意見を一致させることはほぼ不可能。
お互いそれは認識しており、それを前提にディスカッションする。
ディスカッションとは正解・不正解、賛同する・しないを選ぶための場ではなく、「理解を深める場」である。

自分の考えをアウトプットして、他人のフィードバックから自分では気がつけなかったポイントを知ることで成長もできる。
参加者は自分の意見を採用してほしいというスタンスではなく、あくまでも「In my opinion（私の意見としては〜）」という前置きをして話す。
「私の意見なんて無視してもいいし、決めるのはあなた次第で良いよ」という空気感であれば、話す方も聞く方も精神的なプレッシャーは少なくなり、ディスカッションしやすい空気感になる。

ディスカッションは相手のことを尊重、理解して、それを認める力が必要になる。
意見をもらえたことに感謝しよう。
ディスカッションに必要なのは伝え方や会話力だ。

サーバントリーダーシップ

優秀なリーダーは細かな指示をメンバーにしない。
ビジョンや方針、KPIなど示した後はメンバーを信頼してメンバー自身が主体的に動ける環境を作る。
指示をすればするほど指示待ち人間になり、リーダー不在では組織が機能しなくなる。

優秀なマネージャーの仕事

優秀なマネージャーは作業の進捗管理ではなく、メンバーのメンタル面のサポートをする。
マイクロソフトの開発チームマネージャーは1on1で「仕事をエンジョイしているか？」という質問をかけてくる。
仕事が楽しい方がメンバーのパフォーマンスも発揮されて生産性も高い状態であるからだ。
もしメンバーが我慢をしていたり、楽しくないということであれば、必要なサポートをする。

質問の投げ方にも注意が必要だ。
なるべくポジティブシンキングできるような質問をしよう。
「困っていることない？課題はない？」と聞くとどうしてもネガティブ・マイナス面に目がいき、それが増長され、本人の潜在意識に刷り込まれる。
しかし、ポジティブな質問をすれば、プラス面に意識がいき、メンタル的にも安定する。

またメンバーのアンロックされているものを解除するのも仕事。
技術的なトラブル、人間関係のトラブルなど親身になって相談して、業務進捗をサポートする。
その上で、1on1などでスキルやキャリアアップの相談もできたら最高だ。

不確実だからこそ納期はない

新機能の実装が1週間遅れたところで重大な事態は起こり得ない。
不確実だからこそ、予定外に時間がかかったりするし、始めて触るコードは誰でも理解するまで時間がかかる。
まずは理解するところからしっかり時間をかける。
バックログによるタスクリストと戦略、大まかなスケジュールをもとに、マネージャーはメンバーに一度仕事を任せたら信頼をしてサポートをする。

上下関係はない。あるのは役割だけ

社長だろうが、マネージャーだろうが、メンバーだろうが上下関係はない。
あるのは役割の違いだけで偉いとか偉くないとかではない。
誰でもフラットに話し合える組織は強い。

自己組織チーム（スクラム）

マイクロソフトもアマゾンも2ピースピザ（2枚のピザを分けられるくらい）の小さなチームが複数あり、一人ひとりの裁量権が大きい。
ソフトウェア開発など、大勢のチームよりも小さなチームで意思決定＆共有した方が効率も良い。
そこで重要になるのが指示待ちではなく、自ら考えて行動できる人を増やすこと。

チーム内では質問をしやすい空気感を作るのが重要。
「◯◯さん、このタスクについてなにか懸念していることなど、小さなこともであれば遠慮なく共有してください」など、指名した上で意見を引き出す。
そうすると、意見がどんどん言い合えるチームとなり、チーム内での進捗も捗る。
基本的にはメンバー自信で考えて決めて動いてもらうのが理想。
マネージャーは求められるまで回答や指示はしない。

生産性向上のキーは学習

毎日、残業して仕事だけやっても生産性は向上しない。
生産性をあげるために必要なのは学習。

日常業務以外からの学びはマストであり、そのためには学習時間もセットで必要になる。
だから定時になったら強制退社をする。

これまで残業が当たり前の人にとって強制退社は意識や思考を変える必要がある。
定時退社後は学びの時間として30分確保すると強く自分自身に誓えば行動できる。
自分との約束を守ることで自己肯定感も高まる。

本物の休息とは？

本物の休息は何もしないことではなく、違うことをすること。
単純な手作業でもいい。
同じことをずっとやり続けると脳は飽きて疲労する。

深く思考せずに感覚的にできることなど、普段とは違うことをやるだけでも脳はリフレッシュする。
サウナやランニングで脳がリフレッシュするのも、思考ではなく感覚（気持ちいいなど）で行動できているから。

就寝前はディスプレイから離れるために瞑想をするのも有効的。
今日の出来事、明日の懸念など、何も考えず今この瞬間だけに集中して、雑念を捨てよう。

世界一流エンジニアの思考法 (文春e-book)

• Tweet