プログラマーとしてのキャリアを設計する：Andrew Hunt & David Thomas『達人プログラマー』

1999年に初版が出て以来、ソフトウェア開発者の定番書として読み継がれてきた。Andrew Hunt と David Thomas の『達人プログラマー』（第2版: 2019年）は、特定のプログラミング言語や技術に依存せず、「どう考え、どう行動するか」という姿勢の問題を扱っている。

1. DRYは「コードの重複禁止」ではない

Don't Repeat Yourself（DRY）原則は広く知られているが、本書の定義は単純なコードのコピペ禁止とは異なる。

本書でのDRYは「すべての知識は、システム内で唯一の、曖昧さのない、権威ある表現を持たなければならない」という原則だ。ここで言う「知識」は、コード、ドキュメント、設定ファイル、データベーススキーマなど、システムの意味を表す情報全般を指す。

例えば、同じビジネスルールがコードとコメントと仕様書の3箇所に書かれていると、一方を変更したとき他の2箇所との乖離が生まれる。DRYの違反は、変更のたびに複数箇所を修正する必要が生じるという形で現れる。

2. 曳光弾：動くものを素早く見せる

本書が提示する「曳光弾（Tracer Bullet）」の概念は、プロトタイプとは異なる実装スタイルだ。

プロトタイプは使い捨てを前提とした探索コードだが、曳光弾は「完成品と同じ素材で作った細い実装」だ。フロントエンドからバックエンドまで一貫して動く最小限の経路を、早期に本番環境のコードで通す。この経路を軸に、徐々に肉付けしていく。

曳光弾の価値は、要件が変わった場合に「軸」を早期に確認できる点にある。設計の大半が完了してから「方向が違った」と気づくリスクを下げる。

3. 壊れた窓と技術的負債

「壊れた窓」の比喩は本書の中でも特によく引用される節だ。

建物の窓が壊れたまま放置されると、周囲も荒廃していく——という社会心理学の観察を、ソフトウェア開発に適用している。品質の低いコードが一箇所残っていると、「どうせ汚いコードだから」という判断が周囲に広がり、品質の劣化が加速する。

逆に言えば、小さな問題を素早く修正することが、コードベース全体の品質を維持する習慣になる。技術的負債の蓄積に対する実践的な処方箋だ。

flowchart LR
    DRY["DRY\n知識は一箇所に集約\n（コード・ドキュメント・設定）"] --> ETC["ETC\n変更しやすいかどうかが\nすべての設計判断の軸"]
    TB["曳光弾\n動く最小経路を\n本番コードで早期に通す"] --> ETC
    WW["壊れた窓\n小さな問題を放置しない\n→ 品質劣化が連鎖する"] --> ETC
    style DRY fill:#e8f4fd,stroke:#4a9eda
    style TB fill:#e8f8e8,stroke:#4caf50
    style WW fill:#fff8e1,stroke:#f5a623
    style ETC fill:#f3e5f5,stroke:#9c27b0

4. ETC：変更しやすいかどうかを設計の軸にする

第2版で追加された「ETC（Easy To Change）」の概念は、本書全体の設計判断を貫くテーマだ。

SOLIDや他の設計原則が有用である理由は、それらが変更しやすいコードを作るからだ——という視点から、本書はすべての設計判断を「このコードは変更しやすくなるか？」という問いに統一する。

ETCは「良い設計とは何か」という複雑な問いに対して、実践的な判断軸を与える。特定の原則を暗記するより、この問いを習慣的に問い続ける方が長期的には有効だという主張だ。

5. この本が解決できる具体的な状況

「技術スタックを変えるたびに一からやり直している感覚がある」「5年コードを書いているのに、設計の判断に自信が持てない」——こういった停滞感は、特定技術の習得だけでは解消されない。本書が扱うのは、技術が変わっても変わらない「考え方と姿勢」だ。

プロジェクトの終盤に「最初から分かっていれば違う構造にしていた」という後悔が続く場合、曳光弾や破れた窓の概念がその原因を言語化してくれる。

6. 向いている人・向いていない人

向いている人：

• 3〜7年目で、技術の習得は順調だがキャリアや設計力の成長に手応えがない
• 現場の判断基準を言語化したいテックリードやシニアエンジニア
• 「なぜそうするのか」という原則レベルの話を整理したい人

向いていない人：

• 「今週使う技術」を調べたい人（本書は即効性のある技術書ではない）
• プログラミング初心者（前提となる開発経験がないと具体例が腹落ちしにくい）

7. 読み終えた後のステップ

本書で得た心構え——割れた窓を放置しない、DRY を徹底する——は、そのままでは抽象的な態度にとどまる。関数やクラス単位の具体的な品質基準に落とし込みたいなら、次は『Clean Code』へ進むとよい。個々のテクニックを「良いコードとは何か」という原則と実例の体系に束ねてくれる。

一方、既存のコードに手を入れる段になると、心構えだけでは足りない。「割れた窓を放置しない」を実際のコードで実行する手段としてリファクタリングがある。コードの臭いを手がかりに、振る舞いを変えないまま小さく構造を直していく段取りを学べる。

そして、道具を磨き自分の判断に責任を持つという達人の姿勢は、生成AIという新しい道具にもそのまま適用できる。AI の出力を鵜呑みにせず検証できる基礎力こそ、AI時代の達人性だ。この関心がある読者は、生成AI時代のソフトウェア開発を扱う書籍が次の一歩になる。

どれを選ぶかは、今向き合っている課題が「品質基準を言語化したい」のか「既存コードを直したい」のか「AIとの付き合い方を整えたい」のかで決まる。

筆者の体験から

Web系に移ってから技術は増える一方で、設計判断のたびに「これは自分の好みで決めていないか」という不安が消えなかった。レビューする側になっても、指摘の根拠が「なんとなく気持ち悪い」止まりで、理由を聞かれて答えに詰まることがあった。

実務で最も使ったのは曳光弾の考え方だ。要件が固まりきらないtoB向け業務システムの改修で、以前なら画面からDB更新まで完成形を一気に作ろうとしていたと思う。このときはまず絞り込み条件を一つだけ、フロントからAPI、DBまで細い経路で通してみた。項目名の表記ゆれなど細かい認識違いはその段階ですぐ見つかり、後日わかった業務側の想定違いも影響範囲は条件周りに限られた。完成形を先に作っていたら修正はもっと広い範囲に及んでいたはずだ。

その反面、契約による設計はそこまで厳密にはやっていない。TypeScriptの型でかなりの部分が担保されるため、事前条件・事後条件をコメントで書き下すところまでは実務で続かなかった。原則の適用度合いは、手を動かしながら決めている。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

📖 Amazon で購入する

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。