# ハッカーと画家 原題: Hackers and Painters（Paul Graham, 2003年5月／ハーバード大学での特別講義と、それに先立つノースイースタン大学での講演を基にしたもの）／進捗 9%〜16% **中心主張**: ハッカーは科学者ではなく、画家・作曲家・建築家と同じ「ものを創る人」である。にもかかわらず大学はハッカーに科学者であることを強要し（論文数で評価する）、企業はエンジニアであることを強要する（仕様は委員会が決め、ハッカーは実装するだけ）。ハッキングを絵画と同列に置き直すと、書きながら設計する・スケッチから始める・仕様の変更を前提にする・共感能力を磨く、といった正しい作法が見えてくる。 **実践指針**: - プログラムを設計する場面では、紙の上で完全に理解してから書こうとするな。書きながら理解せよ。作家や画家が創りながら作品を理解していくのと同じで、プログラミングそのものがスケッチである。 - 言語やツールを選ぶ場面では、落書き・ぼかし・塗りつぶしができる柔軟なものを選べ。「ペンではなく鉛筆であるべき」。動的な型付けが有利なのは、最初から特定のデータ表現にコミットせずに済むから。柔軟性で最も重要なのは言語をなるべく抽象的にしておくこと。 - 仕様が固まっていないと不安になる場面では、「プログラムの仕様が完璧であると期待するのは非現実的だ」と最初に認め、書いている最中に仕様が変わっても受け入れられる書き方をせよ。早過ぎる最適化と同じく、早過ぎる設計を警戒せよ。 - 学ぶ場面では、良いプログラムを読め。画家が美術館で名画を模写するように、ソースコードを読んでプログラムを学べ（フランクリンはアディソンとスティールのエッセイを要約・再現して文章を学んだ）。 - ものを創る仕事に飽きた／気が乗らない場面では、周期があることを前提に予定を組め。1日16時間やり続ける時期と何も面白く感じない時期がある。乗らない時のために、楽な作業（デバッグなど）を取っておけ。 - 大企業とデザインで勝負する場面では、誰も防衛を確立していない新しいマーケットを選べ。城の中にいる相手に一対一の勝負を承知させるのは不可能に近い。 - 金にならないが面白いものを書きたい場面では、「昼間の仕事」を持て。ミュージシャンがレコード店で働くように、金のための仕事と愛のための仕事を分けろ。オープンソースのハッキングはまさにこれ。 - ハッカーを採用する場面では、応募者が余暇にどんなプログラムを書いているかを聞け（Viaweb の面接方針）。愛がなければ本当にうまくはできない。 - 良い仕事をしたい場面では、誰も見ない箇所まで妥協するな。ダ・ヴィンチは『ジネヴラ・ベンチ』の背景の杜松を一枚一枚描いた。見えない細部が組み合わさると、全体として「圧倒される何か」になる。 - ユーザ向けのものを作る場面では、共感能力を磨け。技術的知識のない人に技術的な問題を説明させてみれば、その人の共感能力が測れる。 **根拠となる事例・考え方**: - 著者は大学院で計算機科学を専攻した後、絵画を学ぶためアートスクールに入った。両者は正反対に見られているが、実際は最も似ている。 - 「計算機科学」という用語への嫌悪。数学者・コンピュータの博物学者・ハッカーという無関係な三者を、歴史的偶然でひとつの学科に押し込んだ「ユーゴスラビアみたいなもの」。いずれ構成部分ごとにばらばらになるだろうし、それは良いことだ。 - 「何を」と「どうやって」の間に建築家とエンジニアの境界がある。ハッカーは「何を」の側にいるべきで、仕様を創ることこそハッキングの最良の形態。ただし仕様を創るいちばんの方法はそれを実装することだ。 - 論文数による評価が生む歪み: 研究は独創的でなければならない→誰もやりたがらない場所へ向かう。研究は量がなければならない→妙ちきりんなシステムほど論文が書ける。AI研究の多くは「知識は述語論理式のリストで表現できる」という間違った仮定から出発して大量の論文を生んだ良い例。 - Yahoo に Viaweb を買収されたとき、「ハックする」がYahooでは「ソフトウェアを実装する」を意味し、デザインすることではなかった。プログラマは「プロダクトマネージャのビジョンをコードへ翻訳する技師」と見なされていた。 - 大企業が出力のばらつきを抑えたがるのは被害を避けるためだが、振動を抑制すれば低い点は消えても高い点も消える。これがベンチャーが勝てる理由のひとつ。マイクロソフトもアップルもヒューレットパッカードもそこから始まった。 - 科学者は完璧な仕事（誰かがすでにやったことの再現）から始めて独自に達する。ハッカーは最初から独自の仕事をし、最初はへたくそだが上手くなってゆく。「ハッカーはオリジナルから始め、上手になってゆく。科学者は上手になることから始め、オリジナルになってゆく」。 - 複数の画家が一枚の絵に取り組むとき、二人以上が同じ箇所を描くことはない（親方が主要人物、助手が背景）。ソフトウェアの協調開発も同じで、明快に定義されたモジュールに分割し、各モジュールの所有者を決めるべき。3〜4人が所有者不明のままハックしたコードは「共有部屋のように埃が積もる」。 - 共感の応用例（Viaweb）: 二つの選択肢で迷ったら「競争相手にとってどっちがより嫌だろうか」を考えた。ある競合が基本的に使えない機能を追加してマスコミに宣伝したとき、その機能が使い物にならないと説明する代わりに、同じ機能をその日の午後のうちに追加した。 - 名声は遅れて来る。絵画は500年前の巨匠のおかげで今こそ重視されているが、当時は誰もそれほど重要と思っていなかった。1430年〜1500年の絵画は未だに他の追随を許さない。シェークスピアは職業としての芝居が生まれつつある時期に現れた。新しいメディアは最初の2世代でその可能性のほとんどが探り尽くされる——ハッキングはまさにその段階にある。 - SICP（『計算機プログラムの構造と解釈』）冒頭の引用: 「プログラムは、人々がそれを読むために書かれるべきである。たまたま、それが計算機で実行できるにすぎない」。 - 原註: コメントを詰め込むよりも、コメントが要らないコードを書く方が読みやすくする方法。コメントは「読者が特に気を付けなければならないツギハギを警告するため」にだけ必要——急カーブを警告する道路標識のように。 **キーワード**: - **ものを創る人（makers）**: ハッカー・画家・建築家・作家・作曲家。良いものを創ることが目的で、その過程で新技術を発見することはあっても、研究活動そのものではない。 - **スケッチとしてのプログラミング**: コードを書く行為が設計・理解の過程そのものであるという捉え方。デバッグは最終工程ではなく、プログラミングと不可分な行為。 - **昼間の仕事（day job）**: ミュージシャン由来の言葉。金のための仕事と、愛のための仕事を分けること。オープンソースの経済モデルの原型。 - **共感能力（empathy）**: 良いハッカーと偉大なハッカーを分ける唯一最大の違い。自己犠牲ではなく、他人のものの見方を理解する能力。 - **早過ぎる設計**: 早過ぎる最適化と対になる危険。プログラムが何をすべきかを早く決めすぎること。