# 第1章 世界一流エンジニアは何が違うのだろう？――生産性の高さの秘密 ## 中心主張 世界一流エンジニアの生産性の高さは、頭の回転の速さや記憶力といった生まれつきの才能ではなく、「試行錯誤をせず、まず理解に時間をかける」という一貫した思考習慣によるものである。手を動かす前に事実(データ)を集めて仮説を立て検証するというループを徹底し、コードやアーキテクチャを頭の中で再現できる「メンタルモデル」を構築することが、生産性を根本から底上げする。 ## 論の展開 - 著者はマイクロソフトのAzure Functionsチームに配属され(2020年4月)、開発チームの生産性の高さが「一部の優秀な人が突出して頑張っている」わけではなく、「全員がコンピュータサイエンスの標準的な判断・行動をとっていく体制」によって異様に高いことに驚く。Azure FunctionsはGitHubで公開されるほど巨大で複雑なマイクロサービス群として構築されており、世界中の大企業に影響を与えるプラットフォームである。 - 同僚ポール(著者のスキップマネージャー、つまり2つ上の上司でありながら現場でコードレビューも行う人物)とのペアプログラミングで、Paulが障害対応時に「いきなり手を動かさない」ことに衝撃を受けた。ペアプログラミングとは2人1組で1台のPCを共有し、互いの技術を学んだりコードのコンテキスト(背景)を理解・共有しながら一緒に思考するセッションである。 - Paulは「まず事実(データ)を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる」というループを回し、ログを15分程度チェックして「ここが原因かもしれない」と反応が返されるまで動かして仮説を検証していった。著者はこの様子に「雷に打たれたような気分」「魔法のように解いてみせた」と衝撃を受けている(図1「手を動かす前に仮説を検証する」: 情報収集→仮説を立てる→仮説の検証→実行、不十分なら情報収集に戻る)。 - 著者はこの経験から「試行錯誤は『悪』である」という認識に至る。ソフトウェアの世界では「できるプログラマとできないプログラマの差は25倍ある」と言われることがあるが、それは記憶力や頭の回転の速さの差ではなく、頭脳労働を「まず自分の頭の中に仮説を立て、それを検証する」という手順で進めるか、「手当たり次第に試す」かという頭の使い方の差なのだと著者は結論づける。 - 著者自身がFiddler(ネットワーク通信をキャプチャ・分析するツール)やWSL2、Application Insights(監視ツール)を使ってテレメトリ(監視データ)の原因を追跡した際の苦労も語られる。当初はクラウドのポータルで様々なアイデアを試しては失敗し、丸一日つぶして試行錯誤したものの、結局「試行錯誤はすべて失敗に終わった」。若い同僚から「Fiddlerで分析したら?」と助言をもらい、初めて問題の正体を特定できた。著者はこの経験を「単に思いつきで新しい知識を何も学んでいなかった」と反省している。 - 「頭がよくても『理解』には時間がかかる」という鉄則も紹介される。著者は複雑なアーキテクチャに取り組む若い同僚2人を観察し、ランチで「何を考えているのか」を尋ねたところ、彼らも一発で理解できるわけではなく、何度もビデオや資料を見直し、じっくり時間をかけて内部の状態を一つひとつ理解していることがわかった。「早くできるように頑張る」ことがかえって最終的な生産性を下げてしまう、という逆説を著者は指摘する。 - 「理解」とは「人に説明できること」であり、「理解の3要素」として①説明可能(explainable)②いつでも使える(anytime usable)③応用可能(applicable)を挙げる(図2)。マイクロサービスを例に、表面的な暗記ではなく構造としての仕組みを把握すれば、別の角度から解釈したり例え話で説明したり、他の業界の課題にも応用したりできると説明する。 - 著者はギター練習の経験を引き合いに出す。長年趣味でギターを弾いてきたが、リズム感の悪さに気づき、バークリー音楽大学出身のトップギタリストのレッスン動画で「ゆっくりしたテンポからメトロノームで正確に弾けるようにする」練習法を知った。誰でもできる基礎の習得には時間がかかるものだという「ああ、これだ!」という衝撃的な感覚を得て、三連符の頭・真ん中・お尻を意識する基礎練習に立ち返ったことで長年の悩みが解消した。 - コーディング面接対策としてLeetCode(コーディング面接の準備のための学習サイト)を使い、初歩の学習を「簡単だ」と馬鹿にせず一からやり直した実体験を語る。1日は誰にとっても24時間しかないという前提のもと、有限のリソースの割り当てを変え、定時後・週末にC#の言語仕様の基礎学習を最優先事項として毎日取り組んだ。 - コードを読む際も「ここはだいたいこんな感じ?」という感覚的判断をやめ、ファクトを積み重ねて理解する習慣に転換したところ、試行錯誤が圧倒的に減り問題を一直線に解決できるようになった。あわせて「コードを捨て去る勇気」も重要だと述べ(COLUMN参照)、最初にローカルで動かした試作(アイデア1)から少し複雑な実装(アイデア2)を経て本番実装に至った経験を紹介する。 - 手を動かす前に小さなデザインドキュメント(Scope・Background・Problem Statement・Proposalの数ページ、図3「Azure Functions XXX redesign」参照)を書く習慣により、理解を先に深めてから実装に入るスタイルが定着している。これはメンターのクリスに教わったやり方で、著者の部署ではドキュメントをコードの前に書くのが慣習になっている。 - 世界一流の思考法を一言で言えば「頭の中にメンタルモデルをつくる」ことである。メンタルモデルとは、人々が世界を理解・予測・解釈し、新しい状況に適用するための脳内イメージや理論のこと(図4「牛尾流『システム思考』のイメージ」)。ソフトウェアは目に見えないため、頭の中で「どういう状況でどう動作するか」をシミュレーションできるイメージを構築しておく必要があると説く。スキップマネージャーのジョンは、複雑なシステム全体を頭の中に構築しているからこそ誰よりも早く的確な回答ができると評される。 - 自分で試行錯誤するより、エキスパートに直接聞いた方が生産性が高い。Pull Requestを送って質問・相談し、「一つのことで2時間以上ブロックされたら質問するなり相談するなりして寝かせておいて」他の作業を進めるという時間の使い方が合理的だと述べる。 - 章の結びとして、ケント・ベックの「私は偉大なプログラマではなく、偉大な習慣を身につけたプログラマだ」という言葉を引用し、生産性の高さは才能ではなく「思考の習慣」によって獲得されるものだと結論づける。 ## 実践指針 - 障害調査やバグ対応では、いきなり手を動かさず「事実(データ)を一つ見つける→仮説を立てる→検証する」というループを回せ。 - 「できるプログラマとできないプログラマの差は25倍」という言説を才能の差と捉えず、頭の使い方(仮説検証か手当たり次第の試行錯誤か)の差として捉え直せ。 - 問題解決の道具(ログ収集ツール・ネットワーク分析ツールなど)は感覚で選ばず、まず適切な観測手段(Fiddlerのようなツール)を早い段階で導入し、推測ではなく実データで原因を追え。 - コードやドキュメントを読むときは「わかった気になる」で済ませず、サンプルの数値を実際に書き出すなどして正確に理解するまで時間をかけよ。「早くできるように頑張る」ことがかえって生産性を下げる逆説を意識せよ。 - 新しい技術や基礎を学ぶときは、感覚に頼らず基礎練習(コーディング問題を一から解き直す等)に立ち返り、時間をかけて「誰でもできる」基礎を体得せよ。 - 複雑な機能をいきなり実装する前に、数ページ程度の小さなデザインドキュメントを書き、Scope・Background・Problem Statement・Proposalを整理してから着手せよ。 - 一度採用した実装やアイデアであっても、より良い方法が見つかったら大胆に捨てて作り直す勇気を持て。 - 自力で悩み続けるより、2時間以上一つのことでブロックされたらエキスパートに早めに質問・相談し、回答を待つ間に他のタスクを並行して進めよ。 - 頭の中に対象システムの「メンタルモデル」を意識的に構築し、コードを読むだけでなく「どう動作するか」を脳内でシミュレーションできる状態を目指せ。 ## 根拠となる研究・事例 - 同僚ポール(著者のスキップマネージャー、Azure Functionsチームの初期からアーキテクチャを構築してきた人物)とのペアプログラミング: 障害調査で、Paulはいきなり手を動かさず「事実を一つ見つける→仮説を立てる→検証する」というループを回し、ログを見て15分程度で原因を特定した。著者はこれを「雷に打たれたような気分」「魔法のように解いてみせた」と表現している。→示唆: 頭脳労働は闇雲な試行錯誤ではなく仮説検証のプロセスであるべき。 - 「25倍の生産性差」という言説の引用: できるプログラマとできないプログラマの差は25倍あると言われることがあるが、著者はこれを才能の差ではなく頭の使い方の差だと再解釈する。→示唆: 生産性の差は先天的なものではなく学習可能な思考習慣の差である。 - 著者自身のFiddler学習・テレメトリ調査の経験: WSL2やApplication Insightsを使った原因追跡で丸一日試行錯誤したがすべて失敗に終わり、若い同僚から「Fiddlerで分析したら?」と助言を受けて初めて特定できた。→示唆: 適切なツールと理解への投資を怠ると、どれだけ時間をかけても試行錯誤は実らない。 - 複雑なアーキテクチャに取り組む若い同僚2人の観察: ランチで思考プロセスを尋ねると、彼らも一発で理解できるわけではなく、何度もビデオや資料を見直しながらじっくり時間をかけて理解していた。→示唆: 頭の良い人ほど「理解に時間をかける」ことを厭わない。 - ギター練習との比較: 著者は長年趣味でギターを弾いてきたが、バークリー音楽大学出身のトップギタリストのレッスン動画で「ゆっくりしたテンポからメトロノームで正確に弾く」基礎練習を知り、長年の悩みが解消した。→示唆: 「誰でもできる」ことほど基礎の習得に時間がかかり、それを飛ばさないことが上達の鍵。 - コーディング面接対策(LeetCode): 著者はLeetCodeやC#の言語仕様を使い、初歩の学習を「簡単だ」と馬鹿にせず一からやり直した。定時後・週末に毎日プログラミング基礎を学習する習慣をつくった。→示唆: 基礎の反復練習によって理解の土台が固まり、応用の速度が上がる。 - コードを捨てる勇気の実例: 最初にローカルで動かした試作(アイデア1)から少し複雑な実装(アイデア2)を経て本番実装に至った経験を振り返り、既存のソリューションに大胆に改造を加えることを恐れない姿勢の重要性を語る。→示唆: 一度書いたコードへの執着が、より良い解決策への到達を妨げる。 - デザインドキュメントの実例(Azure Functions XXX redesign、メンターのクリスから学んだ習慣): Scope・Background・Problem Statement・Proposalの4項目からなる数ページの簡潔なドキュメントで、実装前に設計思想を共有する。→示唆: ドキュメントを先に書くことで自分の頭の整理にもなり、後の手戻りを減らせる。 - スキップマネージャーのジョンの事例: 複雑なシステム全体を頭の中に構築しているため、誰よりも早く的確な回答ができる。→示唆: メンタルモデルの構築がエキスパートたる所以である。 - ケント・ベックの言葉「私は偉大なプログラマではなく、偉大な習慣を身につけたプログラマだ」。→示唆: 卓越した成果は才能ではなく習慣の産物である。 ## COLUMN アジャイルとは何か? 2001年、17人のソフトウェア開発の専門家が「アジャイルソフトウェア開発宣言」を作成した。アジャイル(agile)とは「素早い」「機敏な」という英単語が示す通り、包括的なドキュメントよりも変化に対応するソフトウェアを重視する開発手法で、優先順位の高いものから小さく分割し、動くソフトウェアを頻繁にリリースしながら「要件定義・設計・実装・テスト」を短いスパンで繰り返す。ウォーターフォールが上流から下流へ一方向に工程を進めるのに対し(図5)、アジャイルは要件定義・設計・実装・テストを行き来しながら短い期間でリリースを繰り返す。代表的な手法の一つがスクラムで、メンバー全員がオーナーシップを持って開発を進める「スクラムマスター」という役割が現場に存在する。日本ではDevOpsやアジャイルの導入がまだ本格化していない現場も多いが、開発(Development)と運用(Operations)の役割が対立しやすいため、両者を統合するDevOpsという考え方が重視されている。 ## キーワード - **メンタルモデル**: 人が世界を理解・予測・解釈し、新しい状況に適用するための脳内イメージや理論。ソフトウェアという目に見えない対象を頭の中でシミュレーションできる状態を指す、本書の中核概念。 - **理解の3要素**: 説明可能(explainable)・いつでも使える(anytime usable)・応用可能(applicable)。表面的な暗記と区別される「本当の理解」の判定基準。 - **試行錯誤は「悪」**: 手を動かす前に仮説を立てず闇雲に試すアプローチを戒める著者の造語的フレーズ。頭脳労働の効率を著しく下げるとされる。 - **デザインドキュメント(Design Document)**: 実装前にScope・Background・Problem Statement・Proposalを数ページでまとめる軽量ドキュメント。手を動かす前に理解を深めるための実践手法。 - **システム思考**: ソフトウェア全体をアーキテクチャ・クラスの構造・相互作用として俯瞰的に把握する考え方。フレームワークの偏りをなくし、独自にアレンジできる力の土台となる。 - **アジャイル/スクラム**: 2001年のアジャイルソフトウェア開発宣言に端を発する開発手法。ウォーターフォールとの対比で語られ、短いサイクルでのリリースとチームのオーナーシップを特徴とする。