有名プログラマの読書習慣 - 天才たちは何を読んできたのか

4 分で読めます
雑学エンジニア文化技術書

この記事は約 5 分で読めます。

天才たちの本棚を覗いてみる

優れたプログラマは何を読んでいるのか。この問いは、多くのエンジニアが一度は抱く好奇心です。

プログラミングの世界で名を残した人物たちの読書習慣を調べてみると、意外な共通点が浮かび上がります。彼らは技術書だけを読んでいるわけではなく、むしろ幅広いジャンルの本から着想を得ていることが多い。天才たちの読書スタイルから、私たちが学べることを探ってみましょう。

ビル・ゲイツ - 年間 50 冊の読書家

マイクロソフトの共同創業者であるビル・ゲイツは、世界で最も有名な読書家の 1 人です。

ゲイツは年間約 50 冊の本を読むと公言しています。1 週間に 1 冊のペースです。しかも、ただ読むだけではありません。本にメモを書き込み、余白に自分の考えを記し、読後には要約を作成する。この「アクティブ・リーディング」のスタイルが、ゲイツの読書の特徴です。

ゲイツの読書ジャンルは驚くほど幅広い。テクノロジーはもちろん、公衆衛生、エネルギー問題、歴史、科学、小説まで。彼のブログ「Gates Notes」では定期的に書評が公開されており、その推薦リストは毎年話題になります。

注目すべきは、ゲイツが「技術書だけ」を読んでいるわけではないという点です。むしろ、技術以外の分野の本から得た知見を、テクノロジーの課題解決に応用するのがゲイツのスタイルです。公衆衛生の本を読んでワクチン普及の戦略を考え、エネルギーの本を読んで気候変動対策の技術投資を判断する。読書が意思決定の基盤になっています。

リーナス・トーバルズ - OS の教科書に触発された男

Linux の生みの親であるリーナス・トーバルズの読書体験は、ソフトウェアの歴史を変えました。

トーバルズが Linux の開発を始めたきっかけは、アンドリュー・タネンバウムの教科書「Operating Systems: Design and Implementation」を読んだことでした。この本に掲載されていた教育用 OS「MINIX」に触発され、自分でも OS を作ってみようと思い立った。1 冊の教科書が、世界で最も広く使われる OS カーネルの誕生につながったのです。

トーバルズ自身も著書「Just for Fun」の中で、読書と実践の関係について語っています。本を読んで理論を学び、それを実際にコードとして実装する。このサイクルが、トーバルズの技術力を磨いた原動力でした。

トーバルズの読書スタイルは実践志向です。理論書を読んだら、すぐに手を動かして試す。本の内容を「知識」として蓄えるのではなく、「実装」として形にする。この姿勢は、多くのエンジニアにとって参考になるでしょう。

まつもとゆきひろ (Matz) - 言語設計者の読書

Ruby の作者であるまつもとゆきひろ氏 (Matz) は、プログラミング言語の歴史と設計に関する本を愛読していることで知られています。

Matz が Ruby を設計する際に参考にしたのは、Perl、Smalltalk、Lisp、Eiffel など、複数のプログラミング言語の設計思想でした。これらの言語に関する書籍や論文を読み込み、それぞれの良い部分を取り入れて Ruby を作り上げた。

Matz の読書の特徴は、「比較」の視点です。1 つの言語の本だけを読むのではなく、複数の言語の設計思想を比較しながら読む。この比較の中から、Ruby の「プログラマの幸福を最大化する」という設計哲学が生まれました。

言語設計者の読書は、単なる知識の吸収ではなく、異なるアプローチの比較と統合です。この姿勢は、アーキテクチャ設計やフレームワーク選定など、エンジニアの日常的な意思決定にも応用できます。

ジェフ・ディーン - 論文を大量に読む

Google のシニアフェローであるジェフ・ディーンは、技術書よりも論文を大量に読むことで知られています。MapReduce、BigTable、TensorFlow など Google の基盤技術に関わってきた彼の学習の中心は学術論文です。最新の研究成果をいち早くキャッチし、実際のシステムに応用する。プログラマの自伝や回顧録を読むと、こうした天才たちの思考プロセスをより深く知ることができます。

論文は技術書より凝縮された情報を含み、前提知識を多く要求しますが、最先端の技術動向を把握するには最も速い情報源です。「技術書だけが学習手段ではない」という視点は重要でしょう。

DHH - ビジネス書も読むプログラマ

Ruby on Rails の作者である DHH (デイヴィッド・ハイネマイヤー・ハンソン) は、技術書だけでなくビジネス書も積極的に読むプログラマです。

DHH は Basecamp (旧 37signals) の共同創業者でもあり、「Getting Real」「Rework」「Remote」など、自らビジネス書を執筆しています。彼の読書リストには、経営、マーケティング、組織論に関する本が多く含まれます。

DHH の読書スタイルが示唆するのは、優れたソフトウェアを作るには技術力だけでは不十分だということです。ユーザーのニーズを理解し、ビジネスの文脈でソフトウェアの価値を判断する。そのためには、技術以外の知識が不可欠です。

Rails の設計思想である「Convention over Configuration」(設定より規約) も、技術的な判断であると同時に、開発者の生産性というビジネス的な判断でもあります。技術とビジネスの両方の視点を持つことが、DHH の強みです。

天才たちの共通点

これらの著名プログラマたちの読書習慣には、いくつかの共通点があります。

幅広いジャンルを読んでいる: 技術書だけに閉じこもらず、歴史、科学、ビジネス、哲学など、多様なジャンルの本を読んでいます。異分野の知識が、技術的なブレイクスルーのヒントになることが多い。

読んだら実践する: 本を読んで「なるほど」で終わらせず、学んだことを実際のプロジェクトやコードに反映させています。知識を行動に変換するサイクルが、彼らの成長を加速させています。

メモを取る: ゲイツの余白メモに代表されるように、受動的に読むのではなく、自分の考えを書き留めながら読む「アクティブ・リーディング」を実践しています。

量より質、しかし量も多い: 1 冊 1 冊を丁寧に読みつつも、年間の読書量は一般的なエンジニアを大きく上回っています。質と量の両立が、知識の幅と深さを生んでいます。

「あの人が読んでいる本」を読みたくなる心理

有名プログラマの推薦書リストが話題になるのは、「社会的証明」の心理が働くからです。「あの天才が読んでいる本なら良い本に違いない」。この推論は本を選ぶ際の有力な手がかりになります。

ただし、天才たちが読んでいる本が自分に合うとは限りません。自分の現在のスキルレベルと学習目標に合った本を選ぶことが、最も重要です。

関連記事

まとめ

ビル・ゲイツは年間 50 冊をメモ付きで読み、リーナス・トーバルズは 1 冊の教科書から Linux を生み出し、Matz は複数言語の設計思想を比較して Ruby を作りました。天才プログラマたちの読書習慣に共通するのは、幅広いジャンルを読むこと、読んだら実践すること、メモを取りながら能動的に読むことです。彼らの読書リストをそのまま真似る必要はありませんが、読書に対する姿勢は大いに参考になります。

共有:Xはてブ

この記事は役に立ちましたか?

関連用語

関連記事

ソフトウェア開発の歴史を変えた 5 冊の技術書

アルゴリズムの学問化からコードの可読性革命まで、ソフトウェア開発の方向性を決定づけた 5 冊の技術書を、時代背景とエピソードとともに紹介します。

OS・低レイヤー本ガイド - コンピュータの仕組みを学ぶ技術書の選び方

OS、コンパイラ、ネットワークなど低レイヤーを学べる技術書の 4 ジャンルと、どこから始めるべきかの指針、賞味期限の見極め方を紹介します。

エンジニアが最初に読むべき 5 冊の選び方

新人エンジニアやキャリアチェンジした人が最初に読むべき技術書のジャンル配分と、5 冊の具体的な選び方チェックリストを紹介します。

本棚を見ればエンジニアのレベルがわかる

エンジニアの本棚に並ぶ本の構成は、その人のスキルレベルとキャリアの方向性を映し出します。本棚の変遷パターンから、自分の現在地と次のステップを読み解く方法を紹介します。

新人エンジニアに贈りたい技術書リスト - 先輩が選ぶ理由

新人エンジニアに技術書を贈るときの 3 つの選定基準と、ジャンル別のおすすめ、付箋やセットで贈る工夫を紹介します。

30 代エンジニアが読書で取り戻す「設計の言語化力」

経験年数は十分なのに設計意図を言葉にできない。30 代エンジニアが直面する「暗黙知の壁」を、技術書の読書で突破する方法を解説します。