# ハッカーと画家
Paul Graham 著／Shiro Kawai（川合史朗）訳。2001〜2004年に発表された12本のエッセイを、訳者が原著者の許可を得て日本語訳し Web 公開したテキストを1冊にまとめたもの。書き下ろしの「はじめに」も編者による章立ても存在せず、各エッセイは相互に独立している。個人利用の学習ノート（Kindle蔵書から生成）。
**収録範囲**: 本ノートは、この Web 公開版12エッセイの**全編（進捗1%〜100%、全90ページ）を収録**している。ただし注意点が2つある。
1. **これは市販書籍（オーム社刊『ハッカーと画家』）の本文ではない**。訳者は同じ川合史朗氏だが版が異なるため、ページ番号での参照はできない。引用時の出典は「Paul Graham 著／Shiro Kawai 訳（Web公開版）」と書くこと。
2. **市販書籍の章立てとは収録エッセイが違う**。本PDFに含まれるのは下表の12本だけで、**富の作り方や経済格差を論じるエッセイ（"How to Make Wealth" 等）は含まれていない**。したがって「どうやって金持ちになるか」「富はゼロサムか」といった論点について、本ノートを根拠に答えることはできない。本ノートで扱える経済的な話題は、ベンチャーが大企業に勝つ構造（第4章）と、生産性の格差が富の格差を生むという指摘（第12章の一節）に限られる。
なお、第6章「ものつくりのセンス」だけは分冊の切れ目にかかっており、本文はpart1側、訳註の末尾4項目のみがpart2側にある。内容は統合済みなので、章ノートを読むときは片方だけで完結していると思わないこと。
## コアフレームワーク
### 1. ハッカーは科学者ではなく「ものを創る人」である（第2章）
ハッカーが最も似ているのは数学者でも物理学者でもなく、画家・作曲家・建築家である。にもかかわらず大学はハッカーに科学者であること（論文数で評価される）を強要し、企業はエンジニアであること（仕様は委員会が決め、ハッカーは実装するだけ）を強要する。この分類の誤りが、大学と企業の両方でハッカーを不幸にしている。ハッキングを絵画と同列に置き直すと、正しい作法が見えてくる——書きながら設計する、スケッチから始める、仕様変更を前提にする、良い作品を読んで学ぶ。
### 2. プログラミングはスケッチであり、設計は書きながら進む（第2章・第11章）
紙の上で完全に理解してからコードを書く、というのは絵画では成り立たないやり方だ。作家や画家が創りながら作品を理解していくのと同様、コードを書く行為そのものが設計と理解の過程である。だから道具は「ペンではなく鉛筆」——落書き・ぼかし・塗りつぶしができる柔軟なものを選ぶ。ここから「早過ぎる最適化」と対になる「**早過ぎる設計**」という警告が導かれ、第11章では「完成品を長時間かけて作り上げる作戦（マリア様万歳作戦）は惨劇への切符であり、できるだけ速くプロトタイプをユーザーの前に出せ」という形で再論される。
### 3. 良いデザインには学習可能な共通性質がある（第6章）
「センスは主観的なもの」という相対主義は、ものを作る人にとって有害な嘘である。良し悪しが存在すると認めなければ、良いデザインについて学び始めることすらできない。数学・絵画・建築・工学・文章を横断して洗い出すと、良いデザインは——単純である／永遠である／正しい問題を解決する／想像力を喚起する／しばしばちょっと滑稽だ／難しい／簡単に見える／対称性を使う／自然に似る／再デザインだ／模倣する／しばしば奇妙だ／集団で生まれる／しばしば大胆だ——という14の性質を繰り返し示す。締めの一文は「厳しい味覚と、それを満足させる能力。それが偉大な仕事のためのレシピだ」。
### 4. 言語にはパワーの差があり、その差はコードサイズと開発時間に直結する（第8章・第9章・第7章）
「全ての言語は等価だ」という信念は、安心できるから広まっているだけで事実ではない。パワーの差はコードサイズの差になり、コードサイズは開発時間になる。この差が広く認められない理由が「**ほげ言語のパラドックス**」——プログラマは自分の使う言語で思考するため、自分より下の言語は正しく見下せるが、上の言語は「ふわふわしたおまけが付いた同等の言語」にしか見えない。逆に言えば、競争の激しいベンチャーにとって、他が使っていない強力な言語は競合が理解できない秘密兵器になる。第7章はこれを時間軸に拡張し、百年後まで生き残るのは「公理（根源的オペレータ）が最小でクリーンなコアを持ち、残りをその言語自身で書ける言語」だと論じる。
### 5. Web 上のソフトウェアは、少人数が大企業に勝つ構造を作る（第4章）
サーバ上で走るソフトウェアは、ユーザに便利なだけでなく、開発者にとってリリース・バグ・サポート・士気・人数のすべてを作り変える。「バージョン」という考え方が消えて1日に3〜5回リリースでき、変更が小さいのでバグが新鮮なうちに死に、サポート部門が実質的に品質管理部門になる。そしてグループが小さくなるほど効率が指数的に増大する（**Brooks の逆転**）。Viaweb はプログラマ3人でミーティングをした記憶がないまま、20〜30社の競合を全て打ち負かした。2001年時点で「ASP」と呼ばれていたこの形態が、現在の SaaS である。
### 6. 順応性検査——考えたいことを考えられるか（第3章）
どの時代にも人々が信じているばかげた考えがあり、当事者にはそれが見えない。道徳にも流行があり、流行は本質的に見えないからだ。だから重要なのは現代の異端を暴くことではなく、「どの時代でも使える、口にできないことを見つける方法」を持つことである。検査は一問——**自分と同格の人が集まっているグループ内で、表明するのを憚る意見を持っているか**。No なら、あなたは言われたことをそのまま信じている。そして見つけた異端は、口にするのではなく考えるために使え。最重要なのは「言いたいことを言える」ことではなく「考えたいことを考えられる」ことである。
### 7. 偉大なハッカーは金では動かない（第12章）
プログラミングでは個人の生産性の差が極端に大きく、技術はその差を梃子のように拡大し続ける。だが凄腕は普通のプログラマの10〜100倍生産的でも、給料は3倍もらえればラッキーな程度だ。彼らが動かされるのは、良い道具・面白い問題・静かな仕事場・優秀な同僚である。しかも誰が偉大かは一緒に働くまで判別できず（履歴書も面接も効かない）、本人にすら分からない。加えて「**デザインのパラドックス**」——自分に良いセンスがなければ、素晴らしいデザイナーを見分けることもできない。
## 章インデックス
| 章 | エッセイ名（原題） | 主題 | ファイル |
| --- | --- | --- | --- |
| 0 | 書誌情報・目次 | 本PDFの成り立ち、版権表示、全12エッセイの目次 | `chapters/part1-ch0-intro.md` |
| 1 | オタクが人気者になれない理由（Why Nerds are Unpopular, 2003） | 頭のいい子が人気を得られない構造的理由と、学校という「待合室」 | `chapters/part1-ch1-why-nerds-are-unpopular.md` |
| 2 | ハッカーと画家（Hackers and Painters, 2003） | ハッカーは科学者ではなくものを創る人。スケッチとしてのプログラミング | `chapters/part1-ch2-hackers-and-painters.md` |
| 3 | 口にできないこと（What You Can't Say, 2004） | モラルの流行と順応性検査。異端の見つけ方と扱い方 | `chapters/part1-ch3-what-you-cant-say.md` |
| 4 | もうひとつの未来への道（The Other Road Ahead, 2001） | Web ベースソフトウェアが開発と競争を作り変える | `chapters/part1-ch4-the-other-road-ahead.md` |
| 5 | スパムへの対策（A Plan for Spam, 2002） | ベイジアンフィルタの設計と、統計的手法が手書きルールに勝つ理由 | `chapters/part1-ch5-a-plan-for-spam.md` |
| 6 | ものつくりのセンス（Taste for Makers, 2002） | 良いデザインの14の性質。センスは客観的で学習可能である | `chapters/part1-ch6-taste-for-makers.md`（訳註末尾は `chapters/part2-ch0-continuation-taste-for-makers.md`） |
| 7 | 百年の言語（The Hundred-Year Language, 2003） | 言語の進化の系統樹。百年後を予測して今の言語を選ぶ | `chapters/part2-ch1-hundred-year-language.md` |
| 8 | 普通のやつらの上を行け（Beating the Averages, 2001） | ほげ言語のパラドックスと、言語という秘密兵器 | `chapters/part2-ch2-beating-the-averages.md` |
| 9 | 技術野郎の復讐（Revenge of the Nerds, 2002） | Lisp の9つのアイディア。言語のパワー差が金儲けのレシピになる | `chapters/part2-ch3-revenge-of-the-nerds.md` |
| 10 | 人気の言語を作るには（Being Popular, 2001） | 言語はハッカーのもの。最初の20人とトロイの木馬 | `chapters/part2-ch4-being-popular.md` |
| 11 | デザインとリサーチ（Design and Research, 2003） | 「良さ」と「新しさ」の分岐。ユーザーが必要としているものを作る | `chapters/part2-ch5-design-and-research.md` |
| 12 | 素晴らしきハッカー（Great Hackers, 2004） | 生産性の格差、ハッカーを動かすもの、見分けられなさ | `chapters/part2-ch6-great-hackers.md` |
## 相談トピック → 参照先
- プログラミング言語を選びたい・技術スタックを決めたい → **第8章・第9章**（パワーの差と秘密兵器）、**第12章**（言語選択は同時に社会的決定＝コミュニティの選択）
- 長く生き残る技術・基盤に賭けたい → **第7章**（進化の系統樹の主要な枝にあるか）
- 設計をどう進めるか迷っている（仕様を固めてから書くべきか） → **第2章**（スケッチとしてのプログラミング、早過ぎる設計）、**第11章**（速くプロトタイプを出す）
- デザインの良し悪しを判断したい・自分の作ったものを評価したい → **第6章**（良いデザインの14の性質）
- 何を作るか、誰のために作るかを決めたい → **第11章**（欲しいものではなく必要としているものを。自分を含むグループを対象にせよ）
- 小さなチームで大きな競合と戦いたい → **第4章**（Brooks の逆転、Web ベースの構造的優位）、**第9章**（一番難しい問題に一番強い言語で）
- リリース戦略・バグ・カスタマーサポートの設計 → **第4章**（バージョンを捨てる、サポートを開発者から離さない）
- 常識を疑いたい・自分の考えが本当に自分のものか確かめたい → **第3章**（順応性検査、4つの探し方）
- 集団の空気やレッテル貼りに絡まれている → **第3章**（メタレッテル貼り、熱狂には与しない、pensieri stretti & viso sciolto）
- 良いエンジニアを採用したい・見分けたい → **第12章**（履歴書も面接も効かない、一緒に働くしかない）、**第2章**（余暇に何を書いているかを聞け）
- 優秀な人が辞めない環境を作りたい → **第12章**（道具・問題・仕事場・同僚。問題の再定義、ボトムアッププログラミング）
- 新しい道具やライブラリを広めたい → **第10章**（最初の20人、トロイの木馬、書き捨てのプログラム、有機的成長）
- 学校や組織で自分の評価が不当に低いと感じる → **第1章**（外部の尺度がない集団ではゼロサムの潰し合いになる）
- 統計的手法と手書きルールのどちらを取るか（分類問題全般） → **第5章**（統計はあなたより賢い。誤検出側にバイアスをかける）
## 回答時の注意
- **技術的前提が2001〜2004年のものである**。「Web ベースソフトウェア」は当時 ASP と呼ばれた新奇な提案であり、今の SaaS では前提が違う。Java への評価、Windows NT の話、マイクロソフトへの警戒、SSL を売る会社が Netscape だけという記述などは、そのまま現在に持ってこられない。**構造の主張（少人数の優位、リリースの粒度、道具とコミュニティの関係）は今も通用するが、固有名詞と具体的技術は歴史として扱うこと。**
- **著者の主張は意図的に挑発的で、異論が多い**。「委員会によるデザインは悪いデザインと同義」「Java は行き止まりの枝」「業界の最良慣行は上司を護るための選択」などは論争的な断定であり、著者の立場として提示すべきで、業界の合意として提示してはいけない。特に言語論は Lisp の擁護という利害関係の上に書かれている（著者は当時 Arc を設計中だった）。
- **収録されていない論点で答えない**。前述のとおり富・経済格差・起業による蓄財を正面から扱うエッセイは本PDFに含まれない。それらを聞かれたら、本ノートには無いと明示したうえで、隣接する第4章・第12章の範囲で答えること。
- **第6章の「良いデザインの14の性質」は列挙であって手順ではない**。チェックリストとして順に適用させると誤用になる。判断の物差しとして1〜2個を選んで使うのが本来の用途。