技術書だけでは足りない理由
一流のエンジニアは技術書だけを読んでいるわけではない。 この事実に気づくまで、多くのエンジニアはかなりの時間を要する。
もちろん、技術書は重要だ。 新しいフレームワークのドキュメントを読み、アルゴリズムの教科書をめくり、設計パターンを学ぶ。 これらはエンジニアとしての「基礎体力」をつけるのに欠かせない。
だが、技術書が教えてくれるのは「どうやるか（How）」までだ。 「なぜやるか（Why）」と「何をやるべきか（What）」は、技術書の外にある。 そして、キャリアのある地点から、この「Why」と「What」の比重が急激に増す。
ポール・グレアムは何を読んでいるか
Y Combinator創業者のポール・グレアムは、プログラマーであると同時に卓越したエッセイストだ。 彼の文章が鋭いのは、コンピュータサイエンスの知識だけでなく、哲学、歴史、美術にわたる幅広い読書量が土台にあるからだ。
グレアムは過去のエッセイで、プログラミングの本質は「問題を正しく定義すること」だと書いている。 問題定義の精度は、技術知識だけでは上がらない。 世界をどれだけ多角的に見られるかに依存する。
Ruby on Railsの生みの親、David Heinemeier Hansson（DHH）も読書家として知られる。 彼のブックリストには経営書はもちろん、ストア哲学の古典であるセネカの著作やライアン・ホリデイの著作が並ぶ。 DHHがBasecamp（現37signals）で推進してきた「Shape Up」という開発手法は、ストア哲学の「コントロールできるものに集中せよ」という思想の応用にも見える。
テスラのイーロン・マスクがSFの愛読家であることもよく知られている。 アイザック・アシモフの「ファウンデーション」シリーズ、ダグラス・アダムスの「銀河ヒッチハイク・ガイド」。 SFが描く未来像が、彼のプロダクトビジョンに影響を与えているのは間違いない。
異分野の読書がコードを変える
「技術書の外」の読書がエンジニアリングにどう活きるのか。 いくつかの実例を挙げてみたい。
哲学。 ソフトウェア設計において「抽象化」は最重要の概念のひとつだ。 哲学はこの抽象化のトレーニングに最適な分野だ。 プラトンの「イデア論」は、インターフェースと実装の関係にそのまま重なる。 ウィトゲンシュタインの言語哲学は、API設計における命名規則の重要性を再認識させてくれる。
経済学。 システム設計にはトレードオフの判断がつきまとう。 パフォーマンスと保守性。スケーラビリティと開発速度。 こうしたトレードオフを構造的に考える力は、経済学の「機会費用」や「限界効用」の概念を知ることで磨かれる。
心理学・認知科学。 ユーザーインターフェースの設計はもちろん、チームマネジメントにおいても認知科学の知識は武器になる。 ダニエル・カーネマンの「ファスト&スロー」は、ユーザーの直感的判断（システム1）と論理的判断（システム2）の違いを理解するうえで、エンジニアにとって必読書と言っていい。
SF。 SFは「技術が社会をどう変えるか」のシミュレーションだ。 テッド・チャンの短編集「あなたの人生の物語」、ケン・リュウの「紙の動物園」。 技術と人間の関係を物語として体験することで、自分が作るプロダクトの社会的影響を想像する力が養われる。
歴史。 過去のテクノロジー転換期に何が起きたかを知ることは、現在の変化を相対化する力を与えてくれる。 ジェームズ・グリックの「インフォメーション」、ウォルター・アイザックソンの「イノベーターズ」。 技術革新と社会の関係は、驚くほど同じパターンを繰り返している。 鉄道、電話、インターネット、そしてAI。 歴史を知るエンジニアは、ハイプサイクルに踊らされない冷静さを手にする。
ノンフィクション・ルポルタージュ。 現場の空気を伝える書籍は、データだけでは見えないリアリティを教えてくれる。 マシュー・クロフォードの「マインド・オブ・ハンド」は、知的労働と手仕事の関係を問い直す名著だ。 エンジニアリングが「手を動かす仕事」なのか「頭だけの仕事」なのか、その境界を揺さぶられる。
実践的な読書法——エンジニアのための5つのアプローチ
「読書が大事なのは分かった。でも時間がない」。 多くのエンジニアがこう言う。 実務と並行して読書を続けるための具体的な方法を提案したい。
1. 並行読み。 技術書1冊と非技術書1冊を同時に読み進める。 脳の異なる領域を使うため、意外と疲れない。 技術書に飽きたら小説に切り替える。この交互読みが習慣化のコツだ。
2. 音声読書の活用。 通勤時間やランニング中にオーディオブックを聴く。 Audibleや audiobook.jpには、ビジネス書や教養書が豊富にある。 技術書は目で読む必要があるが、歴史や哲学の本は耳からでも十分に吸収できる。
3. 読書メモをコードのように管理する。 GitHubのプライベートリポジトリやObsidianに読書メモを蓄積する。 気になったフレーズを引用し、自分の仕事との接点をメモする。 この「仕事との接続」が、知識の定着率を劇的に高める。
4. 読書会を開く。 チーム内で月1回の読書会を開催する。 技術書に限定せず、ビジネス書やノンフィクションも対象にする。 異なる職種のメンバーが同じ本を読むことで、予想外の解釈が飛び出す。
5. 「最初の30ページ」ルール。 気になった本は迷わず買い、最初の30ページだけ読む。 面白くなければ閉じていい。 読書を完読の義務にすると続かない。乱読こそが教養の源泉だ。
アウトプットが読書の質を変える
読んだだけでは、知識は流れていく。 アウトプットと組み合わせて初めて、読書は「資産」になる。
最も効果的なのはブログやZenn、noteへの書評だ。 ただし、本の要約を書くのではない。 「この本の内容は、自分の仕事の〇〇にどう接続するか」を書く。 このフレーミングが重要だ。
たとえば、ハンナ・アーレントの「人間の条件」を読んだエンジニアが「労働・仕事・活動の区分は、プログラミングのどの部分に対応するか」と問い直す。 定型的なバグ修正は「労働」、アーキテクチャ設計は「仕事」、オープンソースへのコントリビューションは「活動」かもしれない。
こうした異分野の概念を自分のフィールドに引き寄せる作業が、読書をただの消費から生産へと変換する。
社内のLT（ライトニングトーク）で紹介するのも効果的だ。 5分で1冊の本のエッセンスを伝える。 聴く側にとっても「読んでみたい」のきっかけになり、チーム全体の知的水準が底上げされる。
教養は「遠回り」ではない
「教養なんて暇な人の趣味だろう」。 そう思うエンジニアもいるかもしれない。
だが、AIがコードを書く時代に、エンジニアに求められるのは何か。 それは「何を作るべきか」を判断する力、異なる文脈をつなぐ力、技術の社会的影響を予見する力だ。 これらはすべて、技術書の外にある知識から養われる。
リベラルアーツは「自由になるための技術」という意味だ。 哲学、歴史、文学、経済学。 これらの知識は、技術に閉じこもったエンジニアを、より広い視野を持つ「つくり手」へと解放する。
Googleのピーター・ノーヴィグは「プログラミングを独習するには10年かかる」と書いた。 だが10年間プログラミングだけをやっていても、それは「10年の経験」ではなく「1年の経験を10回繰り返した」だけかもしれない。 技術書の外の世界に触れることが、螺旋階段のように視座を上げていく。
次に書店に行ったとき、技術書コーナーを通り過ぎて、哲学や歴史のコーナーに足を向けてみてほしい。 あなたのコードを変えるヒントは、意外なところに転がっているかもしれない。
最近、技術書以外で心に残った一冊はあるだろうか。
