英語の技術書、食わず嫌いだった
正直に言うと、3年前まで英語の技術書を1冊も読んだことがなかった。
日本語の入門書やQiita記事で十分だと思っていたし、洋書は分厚くて、英語を読むだけで疲れて、内容が頭に入らないだろうと決めつけていた。
きっかけは些細なことだった。コードレビューで先輩に「Clean Codeに書いてあるやつだね」と言われて、読んでいないことが恥ずかしくなった。それだけだ。
1冊読んでみたら、意外なことに気づいた。技術書の英語は小説より簡単だ。語彙が限られているし、コード例が文脈を補ってくれる。そして何より、日本語に翻訳される過程で抜け落ちるニュアンスや、そもそも翻訳されない名著が山ほどあった。
この記事では、自分が実際に読んで「考え方が変わった」と思えた7冊を紹介する。全部読む必要はない。今の自分に足りないと感じるカテゴリから1冊選んでもらえれば十分だ。
コードの書き方を変える本
1. Clean Code — Robert C. Martin
Don't comment bad code — rewrite it.
（悪いコードにコメントを書くな。書き直せ。）
ソフトウェアの仕事の80%以上は「保守」だと著者は言う。新しいコードを書く時間より、既存のコードを読んで理解して直す時間のほうが圧倒的に長い。だったら「読みやすいコード」を書くことが、チーム全体の生産性を上げる最短ルートだ。
この本が良いのは、原則論だけで終わらないところだ。実際のコードを「悪い例 → 良い例」に書き換えるプロセスを何十ページも使って見せてくれる。命名規則、関数の長さ、エラーハンドリング、テスト——どれも「明日のプルリクから変えられる」レベルの具体性がある。
日本語版（『Clean Code：アジャイルソフトウェア達人の技』）もあるが、原著のほうがコード例と地の文の距離が近く、読みやすい。
2. The Pragmatic Programmer (20th Anniversary Edition) — David Thomas & Andrew Hunt
Kaizen — continuously make small improvements.
（カイゼン——小さな改善を継続せよ。）
日本語版『達人プログラマー』として有名だが、2019年に出た20周年記念版を読んだ人は意外と少ない。初版から内容が大幅に書き換えられていて、クラウド、CI/CD、並行処理など現代の開発環境に合わせたアドバイスが追加されている。
この本の核心は「自分の技術に責任を持て」というメッセージだ。コードの設計だけでなく、見積もりの出し方、チームとのコミュニケーション、キャリアの選び方まで扱っている。「プログラミングの本」というより「プログラマーとして生きていくための本」に近い。
特に印象に残ったのは"DRY原則"の再定義。単に「コードを重複させるな」ではなく、「知識を重複させるな」という、より広い意味で語り直されている。
CS・アルゴリズムの見え方を変える本
3. Grokking Algorithms — Aditya Bhargava
図解とイラストでアルゴリズムの「なぜ」を直感的に理解する。
アルゴリズムの本は「数学が得意な人向け」という先入観があった。この本はそれを完全に壊してくれた。
すべての概念がイラストと具体例で説明される。二分探索を「電話帳から名前を探す」で説明し、ダイクストラ法を「最短ルートで友人の家に行く」で説明する。擬似コードではなくPythonで書かれたコードがすぐ動くのもありがたい。
200ページ強と薄いので、週末2日で読み切れる。「アルゴリズムを勉強しなきゃ」と思いながら分厚い教科書に挫折した経験がある人にこそ読んでほしい。
4. Code: The Hidden Language of Computer Hardware and Software — Charles Petzold
コンピュータが「なぜ動くのか」を、モールス信号から積み上げて理解する。
懐中電灯の点滅（モールス信号）から始まって、リレー、論理ゲート、加算器、メモリ、CPU、OSと、コンピュータの全レイヤーを1冊で積み上げていく。CS学位を持っていない人が「コンピュータの仕組み」を本当に理解するには、これ以上の本を知らない。
2022年に改訂版が出て、現代のプロセッサアーキテクチャやWebの話も追加された。日本語版（『CODE：コードから見たコンピュータのからくり』）もあるが、改訂版は未翻訳のため原著を推奨する。
情報系の学部を出ていないエンジニアが増えている今、「なんとなくフレームワークを使えるが、その下で何が起きているか説明できない」という不安を感じている人には特に刺さるはずだ。
プロダクト思考を変える本
5. The Design of Everyday Things — Don Norman
Good designs fit our needs so well that the design is invisible.
（良いデザインは、あまりにも自然にニーズを満たすので、存在に気づかない。）
「デザインはデザイナーの仕事だろう」と思っているエンジニアにこそ読んでほしい。
この本でいう「デザイン」はビジュアルの話ではない。ドアの取っ手を引くべきか押すべきか、一目で分かるか。スイッチとライトの対応が直感的か。——そういう「人間とモノの関係性の設計」の話だ。
読み終えると、自分が作っているAPIのインターフェース、CLIのオプション設計、エラーメッセージの書き方、すべてが「デザイン」だったと気づく。技術者がこの視点を持つと、ユーザーからの問い合わせが目に見えて減る。
6. Don't Make Me Think — Steve Krug
We don't read pages. We scan them.
（人はページを読まない。スキャンする。）
上のNorman本が「デザイン思考の哲学」だとすれば、こちらは「明日から使えるWebユーザビリティの実践」だ。
200ページ弱で、2〜3時間で読み切れる。にもかかわらず、ユーザーがWebサイトをどう使っているか——読んでいるのではなくスキャンしていること、選択肢が多いと思考停止すること、「戻る」ボタンが最大の安全網であること——を鮮やかに示してくれる。
エンジニアは「機能が正しく動く」ことに集中しがちだが、この本を読むと「正しく動いていても、使い方が分からなければ壊れているのと同じ」だと実感する。フロントエンドに限らず、管理画面やドキュメントを作るすべての人に関係がある。
手を動かして学ぶ本
7. Automate the Boring Stuff with Python — Al Sweigart
Practical programming for total beginners.
（完全な初心者のための実践プログラミング。）
この本の最大の特徴は、全文が無料で読めることだ（automatetheboringstuff.com）。
扱うのは「退屈な作業の自動化」。ファイルのリネーム、Excel操作、Web上のデータ収集、メール送信、PDF加工——どれも実務で発生する雑務ばかりだ。Pythonの文法を体系的に教えるのではなく、「この作業を自動化するにはどう書くか」から逆算して必要な知識を教えてくれる。
プログラミング経験ゼロの人にも勧められるし、「Pythonは書けるけど実務で使いこなせていない」という人が読んでも、自動化のアイデアが湧いてくる。チームの非エンジニアメンバーに最初の1冊として渡すのにも良い。
まとめ：1冊だけ選ぶなら
| 今の課題 | 読むべき1冊 |
|---|---|
| コードレビューで指摘が多い | Clean Code |
| エンジニアとしての方向性に迷っている | The Pragmatic Programmer |
| アルゴリズムに苦手意識がある | Grokking Algorithms |
| CSの基礎に自信がない | Code |
| 「使いにくい」と言われるUIを作りがち | Don't Make Me Think |
| 設計の「なぜ」を考えたい | The Design of Everyday Things |
| プログラミング自体がこれから | Automate the Boring Stuff |
全部読む必要はない。自分が今一番引っかかる1行を見つけて、その1冊から始めればいい。
洋書に抵抗があるなら、まず薄い本（Grokking AlgorithmsかDon't Make Me Think）から試すのを勧める。図やコードが多い本は、英語力に関係なく読み進められる。1冊読み切れば、次からのハードルは驚くほど下がる。