専門書からBig Historyまで：洋書多読の習慣化がエンジニアの視野をどう広げるか
社内の新規事業の検討会議に、初めて呼ばれた日のことを覚えている。
テーブルの向こうには、事業企画の人間、法務の人間、そして自分と同じエンジニアが数人いた。「このサービスが5年後の社会にどういう意味を持つか」という問いが出た瞬間、自分の頭の中で何かが止まった。
技術の話ならできる。アーキテクチャの議論も、パフォーマンス改善の話も、セキュリティの懸念点も。でもそのとき問われていたのは、技術の外側にある話だった。テクノロジーが社会に与える影響、歴史的な文脈、人間の意思決定の仕組み——そういう「技術ではない語彙」が、自分にはなかった。
隣に座っていた事業企画のKさんが言った。「ハラリが Sapiens で書いてることに近いんですよね、これ。農業革命のときの話と構造が似てて——」
その場の全員がうなずいた。自分だけがうなずけなかった。Sapiens を読んでいなかった。というより、そういうジャンルの本を英語で読もうと思ったことが、それまで一度もなかった。
技術書しか読んでいなかった、ということに気づいたのは、あの会議が終わってからだ。
正確に言うと、技術書と、ビジネス書の一部だけ。「エンジニアとして必要な知識」の範囲内で読んでいた。それ以外の本——歴史、哲学、生物学、人類学——は「自分には関係ない」というカテゴリーに無意識のうちに入れていた。
でも、あの会議でうなずけなかったときの感覚は、「知識が足りない」というより「言語が足りない」に近かった。世界を語るための別の言語が、自分には欠けていた。
Sapiens（Yuval Noah Harari）を英語で買ったのは、その週末だった。
この記事はこんな人向け
エンジニアとして仕事をしているが、技術書ばかりで視野が狭い気がしている
洋書多読を始めているが、同じジャンルの本ばかり選んでしまう
ビジネスや社会の議論で「語彙が足りない」と感じることがある
Big History や科学史、哲学など、技術の外側にある知識に興味がある
多読を「英語の練習」だけでなく、思考の武器として使いたい
エンジニアはなぜ「技術書の外」に出にくいのか
エンジニアが技術書しか読まない理由は、怠慢でも好奇心の欠如でもない。構造的な問題だ。
理由1：「役に立つか」が選書基準になっている
「この本を読んで仕事に役立つか」が無意識の判断基準になると、歴史書や哲学書は自動的に候補から外れる。でもこの判断は、「今の仕事」という狭い文脈で役立つかどうかしか見ていない。
理由2：技術の変化が速すぎる
フロントエンドのフレームワーク、クラウドの仕様、機械学習の最新手法——技術書だけで追いかけても追いつかない。その焦りが「技術以外の本を読む時間はない」という感覚を生む。
理由3：どこから入っていいかわからない
技術書なら「次に読むべき本」の推薦が豊富だ。でも「エンジニアが読むべき歴史書」「エンジニアにとっての哲学入門」という道案内は少ない。選択肢が多すぎて、結局いつもの本に戻る。
「視野を広げる」の正体
「視野が広がる」という言葉は漠然としている。具体的に何が変わるのかを整理しておく。
メンタルモデルが増える
物事を理解するための「型」のことを、メンタルモデルという。
エンジニアが持っているメンタルモデルは強力だ。「システムを抽象化する」「ボトルネックを特定する」「トレードオフを考える」——これらは技術の外でも使える。でも技術書だけ読んでいると、メンタルモデルの種類が偏る。
歴史書を読むと「構造的な変化と偶発的な出来事をどう分けて見るか」という視点が加わる。進化生物学を読むと「インセンティブと行動の関係」が見えてくる。認知科学を読むと「人間の意思決定の歪み」が腑に落ちる。
技術の問題は、技術だけで解けないことが多い。組織の動き方、ユーザーの行動、ビジネスの論理——それらを理解するメンタルモデルは、技術書からは得られない。
「なぜ」を考える語彙が増える
技術書は「何を」「どうやって」を教えてくれる。「なぜそれが問題なのか」「誰にとっての問題か」「歴史的にどういう文脈の中にあるか」——これらを考えるための語彙は、技術の外側にある本から来る。
Thinking, Fast and Slow（Daniel Kahneman）を読んでから、自分がなぜ特定のアーキテクチャ判断を好むのかが、少し見えるようになった。人間の認知の癖を知ることで、自分の技術判断の「なぜ」が問えるようになった。
ここから先は、エンジニアが多読の幅を広げるためのジャンル横断的な洋書セレクションと、習慣化のための読書ポートフォリオ設計を紹介します。
