Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

プロローグ — AIがコードを書く時代に、なぜ本か

2026年に本の話を持ち出すと、反応は二つに分かれる。一つ目は「今どき誰が本なんて読むの。モデルが全部やってくれるのに」。二つ目は「そう、根本に立ち返るべきだ」。

どちらも一面では正しい。モデルは本当に多くのコードを書いてくれる。だからこそ、より重要になったものがある。判定である。モデルが生成した200行のパッチは正しいか。速いか。安全か。その判断はどこから来るのか。本から最もよく育つ。

ブログ記事は 出来事 を教える — 昨日誰が何をしたか。
チュートリアルは方法を教える — このライブラリをどう使うか。
本は原則を教える — なぜこうするのか、そしてそれが変わらない理由は何か。

AIの時代、本の重要性が増した理由は単純だ。モデルは方法のほとんどを代行できる。しかし原則と判断は今も人の頭の中にあるべきだ。その判断の素材が本である。

この記事は、2026年にもう一度読む・初めて読む価値のあるコンピュータサイエンス/ソフトウェア工学の古典12冊をキュレーションする。各書について:

何を学べるか — 一行で核心
誰が読むべきか — 新人・中堅・シニアのうち誰か
2026年に読み直す理由 — なぜほかでもなく今なのか

リスト自体は新しくない。どれも一度は耳にした本ばかりだ。この記事の価値は どの本か ではなく、なぜ今か にある。本に匹敵する密度を持つエッセイ・論文も追加でまとめ、最後に無料PDF・出版社リンク・読む順を置く。

本棚は誇りではなく作業道具だ。読んでいない本は、本棚にあっても頭の中にはない。12冊に絞る理由はそこにある — 全部読み切るためだ。

12冊マトリクス(一覧)

#	書名	著者	初版	難易度	投資時間	2026年に読む理由
1	SICP	Abelson and Sussman	1985	高	3–6ヶ月	50周年。AIなしの抽象化階梯の訓練
2	The Pragmatic Programmer (20周年)	Hunt and Thomas	1999	中	2–4週	開発者の職業倫理。AI時代でも有効
3	Designing Data-Intensive Applications	Kleppmann	2017	高	1–3ヶ月	分散システムの標準教科書。第2版進行中
4	Code (第2版)	Petzold	1999 / 2022	中	2週	シリコンからソフトウェアまでの地図
5	Crafting Interpreters	Nystrom	2021	中	1–2ヶ月	オンライン無料。コンパイラ恐怖症を治す
6	The Mythical Man-Month	Brooks	1975 / 1995	低	1週	人とソフトの非合理性は50年動かない
7	A Philosophy of Software Design (第2版)	Ousterhout	2018 / 2021	中	1–2週	複雑性という敵、deep moduleの美徳
8	Software Engineering at Google	Winters et al.	2020	中	1ヶ月	大規模コードベースで生き残る技術
9	Refactoring (第2版)	Fowler	2018	中	3–4週	AIリファクタの時代の人間側の物差し
10	OSTEP (Three Easy Pieces)	Arpaci-Dusseau	2018	中	1–2ヶ月	無料。OSの直感を作る金字塔
11	CSAPP (第3版)	Bryant and O'Hallaron	2002 / 2015	高	2–4ヶ月	プログラマ視点で見るコンピュータシステム
12	The C Programming Language (K&R)	Kernighan and Ritchie	1978 / 1988	低	1–2週	明晰さの手本、短い本の威厳
Bonus A	Build a Large Language Model (from Scratch)	Raschka	2024	中	1ヶ月	LLMを手で作ってみる
Bonus B	Designing Machine Learning Systems	Huyen	2022	中	3–4週	ML版DDIA。2026年MLエンジニアの基本書

「投資時間」は、本気で読みつつ演習を一部こなす前提。流し読みなら1/3程度でよい。

1章 · SICP — Structure and Interpretation of Computer Programs

著者 — Harold Abelson, Gerald Jay Sussman, with Julie Sussman
何を学べるか — 抽象化の階梯。手続き抽象からデータ抽象、そしてメタ循環評価器・レジスタマシンまで。言語ではなく、思考の骨組みを作る本。
誰が読むべきか — 新人からシニアまで。ただし時間があるとき。SICPは一気に読む本ではなく、ゆっくり共に暮らす本だ。
2026年に読む理由 — 50周年。1985年初版、1996年第2版。抽象化の力は2026年にむしろ重みを増した。AIがコード生成を代行しても、「このコードはどの抽象のどの層にあるか」を見抜く目は人が持っていなければならない。SICPはその目を作るのに最も効率的な本だ。
読み方 — 1・2・3章は必須。4章(メタ循環評価器)を終えるとインタプリタへの恐怖が消える。SICP JS版もあるのでSchemeが負担なら代替に。
罠 — Scheme構文ではなく概念が核心。構文に詰まって諦めないこと。

2章 · The Pragmatic Programmer (20周年記念版)

著者 — David Thomas, Andrew Hunt
何を学べるか — 開発者の職業倫理。DRY、直交性、割れ窓理論、信頼できる見積もり、早めに頻繁にリファクタ。一章につき一原則・一比喩。
誰が読むべきか — 全員。特に1–3年目で読むと次の5年が変わる。
2026年に読む理由 — 1999年初版、20周年改訂版(2019)が出ている。AI関連の章はないが、それでもほぼ全章がいまだに有効だ。「コード生成ツールの出力に責任を持つ」という姿勢は、まさにこの本の精神そのもの。
読み方 — 最初から最後まで一回通読、1年後にもう一度通読。章が短いので枕元用に最適。
罠 — 原則が美しく見えてもコードに触れなければ意味がない。各章の演習を、自分のコードベースに一度は適用すること。

3章 · Designing Data-Intensive Applications (DDIA)

著者 — Martin Kleppmann
何を学べるか — 分散システムの全て。レプリケーション・パーティショニング・トランザクション・整合性・合意・ストリーム処理。Kafka/Cassandraではなく、それらの下の原理。
誰が読むべきか — バックエンド・インフラ・データエンジニア全員。2年目から。
2026年に読む理由 — 2017年刊行だが今も分散システムの標準教科書。Kleppmannが第2版を進行中という情報があり、2026年時点で第1版を読み終えておくのは資産になる。データベース移行、イベントストリーミング、合意アルゴリズム(Raft)が日常業務になった現代、この本は 共通語彙 になる。
読み方 — 1・2・3章(データモデル・エンコーディング・ストレージ)は初読で。5・7・9章(レプリケーション・トランザクション・整合性)は理解できるまで繰り返し。12章(未来)は軽く。
罠 — 厚い。1年に一章でも進める方が、通読を試みて挫折するよりよい。

4章 · Code: The Hidden Language of Computer Hardware and Software (第2版)

著者 — Charles Petzold
何を学べるか — モールス信号から懐中電灯 → リレー → トランジスタ → 論理ゲート → CPU → アセンブリ → 高級言語まで、抽象化スタックの全行程。
誰が読むべきか — 新人・文系出身の開発者に特に。シニアも楽しい復習になる。
2026年に読む理由 — 2022年に第2版が出た。第2版はGUI・インターネットまで扱う。我々はLLM・GPU・Kubernetesの上で生きているが、その下にあるものを忘れてはいけない。抽象化の漏れ(leaky abstraction)は結局、その下を見に降りる必要がある。
読み方 — 最初から最後まで。図が多く、読む速度が速い。
罠 — 親しみやすすぎて軽く感じるが、その親しみやすさが本書の核だ。同じ内容を別の本で読むとたいてい遥かに難しい。

5章 · Crafting Interpreters

著者 — Robert Nystrom
何を学べるか — Loxという小さな言語のインタプリタを二回作る — 一度はツリーウォーキング(Java)、一度はバイトコードVM(C)。字句解析・構文解析・環境・クロージャ・クラス・GC・ハッシュテーブルまで自作。
誰が読むべきか — コンパイラが怖い全ての人。新人からシニアまで。
2026年に読む理由 — 2021年刊行だが、オンラインで全文無料公開されており、毎年更新されている。AIがコードを書く時代でも、「この言語が内部でどう動くか」を知ることはデバッグ能力の根本である。さらにLLM駆動のDSLや独自の構成言語を作る仕事が増えた2026年、この本は実用的でもある。
読み方 — craftinginterpreters.comで最初から追う。コードは自分で打つこと。Part 1(Java)が終わると大きな山を越えた感覚、Part 2(C VM)が終わると小さな英雄になる。
罠 — 本書を終える前に高価なコンパイラ本を買わないこと。Dragon Bookよりずっと近道だ。

6章 · The Mythical Man-Month

著者 — Frederick P. Brooks Jr.
何を学べるか — 人を投入してもスケジュールは縮まない(Brooks法則)。銀の弾丸は存在しない。第2システム症候群。外科チームモデル。1975年にIBM OS/360を作った人の回想録。
誰が読むべきか — チームをリードする、または近くリードする人全員。1週間で読める。
2026年に読む理由 — 1975年に書かれた本が2026年でも正確だという事実そのものがメッセージだ。人とソフトウェアの非合理性は変わらない。AIコーディングエージェントが入っても「エージェントを増やせば早くなる」という単純な仮定は同じ理由で崩れる。1995年20周年版には「銀の弾丸はない」エッセイが付録として入っている — 必読。
読み方 — 短い。1週間で十分。
罠 — 一部の例(OS/360、IBMの帳票など)は古いが、原理は古くない。表面だけで切り捨てないこと。

7章 · A Philosophy of Software Design (第2版)

著者 — John Ousterhout
何を学べるか — 複雑性こそがソフトウェア設計の敵だ。Deep module(狭いインタフェース+豊かな機能)、情報隠蔽、汎用モジュール、「戦略的プログラミング」。短いが密度が高い。
誰が読むべきか — 3年目以上。自分が書いたコードを1年後に見てため息をついた経験のある全員。
2026年に読む理由 — OusterhoutはTcl・Log-Structured File Systemの著者で、Stanfordでソフトウェア設計を教えた人。第2版(2021)では学生のコードレビュー事例が増強された。2026年、AIが書くコードは 浅いモジュール(thin wrapper)を量産しやすい。本書の「deep module」基準は、AIコードの良いレビュー指標になる。
読み方 — 短い(約200ページ)。一度通読、自分のコードレビュー時に隣に置く。
罠 — 一部の主張(コメント擁護など)は本の外で議論がある。その議論を追うとさらに面白い。

8章 · Software Engineering at Google

編者 — Titus Winters, Tom Manshreck, Hyrum Wright
何を学べるか — コードではなく ソフトウェア工学 とは何か。「プログラミングとは時間軸に統合された営みだ」。コードレビュー・テスト・静的解析・依存関係・大規模変更(LSC)・ビルドシステム — 巨大コードベースで生き残る方法。
誰が読むべきか — 中〜大規模企業で働くエンジニア全員。シニア候補生にはほぼ必須。
2026年に読む理由 — 2020年の本。AIコーディングエージェントが大規模変更(LSC)を作れるようになった2026年、本書はより実用的になった。「コードを安全に変える方法」はモデルが答えてくれない — 人がポリシーで決めなければならない。
読み方 — 5章(Code Review)・11章(Testing Overview)・17章(Static Analysis)・22章(Large-Scale Changes)を先に。全部読まなくてよい。
罠 — 厚いので通読を試みると挫折する。章単位で必要なときに読む。

9章 · Refactoring (第2版)

著者 — Martin Fowler (with Kent Beck)
何を学べるか — リファクタリングを日常にする方法。コードの臭いのカタログ、安全な変換のカタログ、テストがどうリファクタを可能にするか。第2版はJavaScriptで例を更新。
誰が読むべきか — 全ての開発者。特に「このコードは一行も触れない」というコードベースで働く人。
2026年に読む理由 — AIツールはリファクタ自体は得意だ。だが 何をリファクタすべきか の判断は人が行う。Fowlerのコードの臭いリストは、その判断の語彙である。モデルが生んだ250行のパッチを見て「ここはExtract Functionが必要」と一言で言える人は価値が高い。
読み方 — 1・2章は通読、カタログ(3章以降)は辞書のように参照。
罠 — カタログ暗記が目的ではない。名前を知っている ことが核心 — Extract Functionという名前を知っていれば、次にそのパターンを見たときに気づける。

10章 · Operating Systems: Three Easy Pieces (OSTEP)

著者 — Remzi H. and Andrea C. Arpaci-Dusseau
何を学べるか — OSの三つの大きなピース — 仮想化(CPU・メモリ)、並行性、永続性(ファイルシステム)。短い章、豊富な例、親切な語り口。
誰が読むべきか — システムプログラミング・インフラ・DB・OS関連の仕事をする全員。CS非専攻で入社した開発者には特に。
2026年に読む理由 — 完全無料。PDF・HTMLで公開。2018年版が安定版で、毎年小さな修正が入る。コンテナ・VM・eBPF・サーバーレスが日常になった2026年、OS抽象化はより重要になった。「なぜ遅いのか」の答えがOSのどこかにあるケースが増えた。
読み方 — 仮想化から。章ごとに短いので通勤時間でも可能。最後に並行性・ファイルシステム。
罠 — 無料なので「いつか読もう」になりがち。最初の1週間で最初の3章を強制的に終わらせると加速する。

11章 · Computer Systems: A Programmer's Perspective (CSAPP, 第3版)

著者 — Randal E. Bryant, David R. O'Hallaron
何を学べるか — プログラマ視点でのハードウェア・OS・ネットワーク。ビット・バイト・メモリ階層・キャッシュ・仮想メモリ・システムコール・ネットワーキングまで。カーネギーメロン入門システム科目の教科書。
誰が読むべきか — システム・性能・インフラに関心ある全員。新人から。
2026年に読む理由 — 2015年第3版が今も標準。2026年、AIの学習/推論は結局 ハードウェア効率 の問題に収斂する。キャッシュ・ページ・メモリ帯域を知らずにGPUクラスタは扱えない。CSAPPはその基礎の硬さを作る。CMUの無料講義(15-213/15-513)と併せて読むとさらに良い。
読み方 — 2章(データ表現)・3章(アセンブリ)・6章(メモリ階層)・9章(仮想メモリ)は必須。11・12章(ネットワーキング・並行性)は選択。
罠 — 重い。一気に全部を試みると壊れる。必要な章から。

12章 · The C Programming Language (K&R)

著者 — Brian W. Kernighan, Dennis M. Ritchie
何を学べるか — C言語そのもの。そして 明晰さ という美徳。250ページに一つの言語とその標準ライブラリ、そして教える人の節制された文体。
誰が読むべきか — 全ての開発者。特にCを使わない人ほど — 短い本の威厳とは何かを見るために。
2026年に読む理由 — 1978年初版、1988年第2版。約50年前の本だ。それでもなお良い文章の手本である。コードはどこまで短く書けるか、ドキュメントはどこまで贅肉なく書けるか — モデルが冗長な文章を無限に生み出す時代、本書の節制はほとんど道徳的なメッセージに近い。
読み方 — 1・5章は必読(ポインタ・配列)。残りは軽く。
罠 — Cで仕事を始めるための本ではない。明晰さを学ぶ ための本だ。

ボーナスA · Build a Large Language Model (from Scratch)

著者 — Sebastian Raschka
何を学べるか — トークン化・アテンション・トランスフォーマー・事前学習・微調整・指示調整まで、LLMを 手で作る。PyTorchのみ、外部ライブラリは最小限。
誰が読むべきか — LLMを使うが内部が気になるML/AIエンジニア。応用開発者にも勧める。
2026年に読む理由 — 2024年刊。2026年時点でLLMは日常道具 になり、もう「OpenAIの魔法」ではない。内部を一度手で作った人と作らなかった人のデバッグ・チューニング直感は違う。GitHubの付属コードと一緒に追えば1ヶ月で読み終わる。
読み方 — GitHubリポのノートブックを章順に。実際に小さなGPTを自分で学習させてみること。
罠 — 「LLMの使い方」本ではない。内部メカニズムの本だ。

ボーナスB · Designing Machine Learning Systems

著者 — Chip Huyen
何を学べるか — ML版DDIA。データパイプライン、特徴量、学習・サービング・モニタリング、データ/モデルドリフト、MLインフラ。モデルではなく システム。
誰が読むべきか — 本番でMLを運用する全エンジニア。
2026年に読む理由 — 2022年刊だが、LLM時代でも核心原理は同じだ。RAG・微調整・オンライン学習が日常になった2026年、「このモデルが実サービスでどう生きるか」の問いはより重要になった。
読み方 — 1・2・8・9章を優先。コードよりシステム図を描きながら。
罠 — Chip Huyenの続編(AI Engineering, 2024)も良いが、MLシステム基礎としては本書が先だ。

ボーナス節 · 本に匹敵する重さのエッセイ・論文

12冊で足りないとき、一篇が一冊を代替する ことがある。分量は小さいが密度は本級のエッセイ/論文集。

Joel Spolsky — Joel on Software

The Joel Test (2000) — 12の質問でチームのエンジニアリング成熟度を測る。2026年でも半分以上が有効。
The Law of Leaky Abstractions (2002) — 全ての抽象化は漏れる。それを知らないとより傷つく。
Things You Should Never Do, Part I (2000) — 最初から書き直すな。全てのリライト推進者が読むべき。

Steve Yegge

Practical Magic (2007) — 抽象化についての最も人間的な文章の一つ。
Have You Ever Legalized Marijuana? / Get That Job at Google — 面接・キャリアについての率直な文章。時を経ても生き残る。
Notes from the Mystery Machine Bus — 保守派対自由派プログラマの分類。一度読めば忘れない。

Dijkstra EWDs

EWD 1036 — On the Cruelty of Really Teaching Computer Science (1988) — CSを教えるのがなぜ慈悲に欠けるか。短く残酷で正しい。
EWD 215 — A Case against the GOTO Statement (1968) — 一通の手紙が業界のコードスタイルを変えた。

Paul Graham

Beating the Averages (2003) — Lispの話だが本質は道具選びと平均からの距離。
Maker's Schedule, Manager's Schedule (2009) — 作る人の時間と管理する人の時間。カレンダーの暴力に対する最良のエッセイ。

Hamming — You and Your Research (1986)

「なぜある人は大きな研究をして、ある人はできないのか」。HammingのBell Labs講演。シニアは一度は聞くべき。

Bret Victor

Up and Down the Ladder of Abstraction (2011) — インタラクティブエッセイ。抽象化の段階をメディアで見せる。
Inventing on Principle (2012) — 講演だが本文と同じくらい引用される。道具を作る人の原則について。

Lamport — Time, Clocks, and the Ordering of Events (1978)

分散システムにおける時間概念の出発点。短く・難しく・美しい。一度は自分で追ってみる価値がある。

本1冊が遠く感じるとき、上記のエッセイ一篇を読む。一篇でその一週間が変わる。

読む順番の推奨

12冊を全部読むのが目的ではないが、出発点はあるほどよい。

0–2年目の開発者

The Pragmatic Programmer — 職業倫理の基礎
Code (Petzold) — 抽象化スタックの地図
The Mythical Man-Month — チームと工程の真実
K&R — 明晰さの手本

ここまで1年で十分。職業観と語彙が育つ。

2–5年目の開発者

A Philosophy of Software Design — モジュール設計の感覚
Refactoring — 変更可能性を維持する技術
Crafting Interpreters — コンパイラ恐怖の除去
OSTEP — OSの直感

ここまで1–2年。技術の深さが伸び始める。

5–10年目の開発者

DDIA — 分散システムの共通語彙
CSAPP — ハードウェアまで降りる視野
Software Engineering at Google — 大規模コードベースの政治学
SICP — 一度は最後まで登る山

MLトラック追加

Build a Large Language Model (from Scratch) — LLM内部を手で
Designing Machine Learning Systems — MLシステム原理

「順番」は強い指令ではなく弱い指針だ。会社で分散システム案件を始めたなら2年目でもDDIAから。仕事が本書を引っ張ってくれる。

本を上手く読むための小さな技術

これら12冊はおおむね厚いか難しい。上手く読むための小さな技術をいくつか。

1. 通読は1/3、精読は1/10

厚い技術書は1/3読めば十分読んだと数えてよい。精読は1/10。全体を精読しようとする試みが最も多い失敗原因だ。

2. 章ごとに一つだけメモ

各章から一つだけメモを残す。「この章は何を言うか」を一文で。本一冊のメモが30文以内に収まれば、よく読めた本だ。

3. コードは自分で打つ

特にSICP・Crafting Interpreters・OSTEP・CSAPP・LLM from Scratch — コードを自分で打つ。読むだけの章と打つ章で吸収率は5倍違う。

4. グループスタディは強力

会社で本の会を1年単位で回すと、普段は手が伸びない本も最後まで行く。DDIA・CSAPP・SICPは特にグループで強い。

5. 本の正解は出題者の意図ではない

技術書の本文より 演習問題 がよりよく教える本がある。SICP・CSAPP・OSTEP・LLM from Scratchがそうだ。問題を解かないとその本の半分しか読んでいない。

よくある罠

本棚だけ育って頭は育たない — 「買っておけばいつか」の発想は本棚しか満たさない。買う本を減らし、読み終える本を増やせ。
流行に揺れる — 毎週新しい推薦ツイートが流れる。12冊に入らないならとりあえず後回しでよい。古典が古典である理由は5年後も同じ位置にあるからだ。
翻訳と原書の間 — 翻訳がよい本は母国語で読む方が速い。K&R・Mythical Man-Month・Pragmatic Programmerは翻訳が良い。SICP・DDIA・CSAPPは原書推奨(または公式英語PDF無料版の活用)。
無料だから読まない — OSTEP・Crafting Interpretersは無料だからつい後回しになる。最初の週に最初の3章を強制的に終わらせよ。
読んで適用しない — 本の原則を一つでも自分のコードベースに適用しないなら、その本は頭の中にない。

エピローグ — 精髄だけが残る時代に

AIが毎日よくなっていく時代に本を読めという勧めは、時代に逆らうように見えるかもしれない。だが正反対だ。モデルが上手くなるほど、人の頭に残るべきものはより精髄だけになる。 その精髄は本から最もよく育つ。

この記事が勧めるのは12冊を全部読めという命令ではない。自分の場所で1冊 から始めよという誘いだ。1–2年目ならThe Pragmatic Programmer。3–5年目ならA Philosophy of Software Design。5–10年目ならDDIA。その1冊が終われば、次の1冊を決めることは自然になる。

読むのに時間はかかる。だが、モデルがコードを書く時代、その時間は 今までより余る。以前は5時間ずっとコードを打っていたなら、今は5時間のうち1時間がコード、2時間がレビュー、2時間が思考だ。その「思考」の素材はどこから来るのか。本から最もよく育つ。

12冊チェックリスト

読み終えた本にチェック。

次回予告

「オープンソース貢献ガイド — 初めてのPRからメンテナまで」 — 本で学んだことを実際のコードベースに適用する最良の方法。
「開発者の書く力 — ブログ・ニュースレター・技術文書で観客を作る」 — 読みの反対側、書きについて。
「AI時代の開発者の次のキャリア — コーダーではなくビルダーに」 — 本で強くなった判断をどこに使うか。

このシリーズの中で本棚は一章分に相当する。

参考 / References

「古典を読むことの最大の報酬は、その本そのものではなく、その本を通過したあとの自分の判断である。」

— 開発者の本棚 2026、終わり。