# 素晴らしきハッカー（原題: Great Hackers） Paul Graham, July 2004（OSCON 2004 での基調講演がもと） **中心主張**: プログラミングでは個人の生産性の差が極端に大きく、技術はその差を梃子のように拡大し続けている。だから会社の成否は「最も生産的な少数から何を引き出せるか」に大きく依存する。ところが偉大なハッカーは、金ではなく良い道具・面白い問題・静かな仕事場・優秀な同僚に動かされ、しかも誰が偉大かは一緒に働くまで判別できない。 **実践指針** - 優秀な人を集めたい場面では、給与ではなく道具と問題を用意せよ。良いハッカーは悪い道具に耐えられず、間違ったインフラを使うプロジェクトで働くことを単に拒絶する。 - 技術スタックを選ぶ場面では、それが技術的決定であると同時に**社会的決定**であると理解せよ。言語を選ぶことは同時にコミュニティを選ぶことでもあり、雇えるハッカーの質は言語選択よりずっと重要である。 - 最良の道具を知りたい場面では、統計上の人気ではなく「ハッカーが自由に選べる時（自分自身のプロジェクト）に何を選ぶか」を見よ。 - 仕事場を設計する場面では、ハッカーが家でどう働いているかを見て真似よ。ドア付きの部屋、こじんまりして人が近くにいる場所。オフィス空間を階級バッジとして扱う会社は、実際には社内で開発ができなくなる。 - プロジェクトを魅力的にしたい場面では、問題そのものを**再定義**せよ。ITA は退屈な航空料金検索を、Google は退屈とされた検索を、ジョブズは安いコンピュータを「美しいコンピュータを作る」問題に再定義した。良いマネージャーの差はここに出る。 - 嫌な細かい問題（バグだらけのソフトのインタフェース、顧客ごとの曖昧な要求へのカスタマイズ）を避けよ。そこから学べることは何もなく、関わっているとバカになる。これは気短さではなく自己防衛である。 - 大企業で優秀な人を守る場面では、会社を分割して研究部門を作るより、**ボトムアッププログラミング**を使え。優秀な人々に道具（そのソフトを書くのに適した言語）を作らせ、別のグループにそれでアプリケーションを作らせる。道具の製作者にもユーザーがいる状態を保てる。 - 良いハッカーを見分けたい場面では、履歴書や面接に頼るな。唯一の方法は何かのプロジェクトで一緒に働いてみることだ。だからハイテク企業の集積は大学の周辺にできる。 - 自分が素晴らしいハッカーになりたい場面では、「自分に対して次の契約を結ぶ」——退屈なプロジェクトの仕事は一切しなくて良い、そのかわり絶対に中途半端な仕事は受けない。 **根拠となる事例・考え方** - 富の格差は生産性の格差を示すサインであり得る。技術の低い社会（薪集め）では上手と下手の差はせいぜい2倍だが、コンピュータのような複雑な道具では差は極めて大きくなる。「皆がトーマス・エジソンである社会」より「エジソンがいない社会」の方が、格差ゼロの説明としてありそうだ。 - Fred Brooks が1974年に引用した1968年の研究では、最速のプログラマは与えられた問題を10分の1の時間で解いた。だが著者は、真の差は「問題を解く速さ」ではなく「どの問題を解くかを決めること」＝想像力にあるため、これは過小評価だと見る。 - 凄腕は普通のプログラマの10〜100倍生産的かもしれないが、3倍の給料でラッキーだと思う。彼らが欲しいのは金ではなく面白い仕事だから。 - 著者が思いつく偉大なプログラマのうち、進んで Java を書いている人物は一人しかおらず、Sun 以外で Java を書いている人は一人もいない。Google は Java の求人広告に賢明にも Python の経験を要求している。 - Windows NT 上で開発すると決め、経験豊かな NT 開発者を CTO に据えたベンチャーの運命は決まっていた（数ヶ月後に会社をたたんだ）。偉大なハッカーは NT を何度も自分から使わない。 - ハッカーは寄り集まる傾向があるため、環境の良さに比例してではなく**二乗に比例して**良いハッカーが集まる＝勝者総取りになる。ハッカーが是非働きたいと思う場所はせいぜい10か20しかない。 - Google と ITA はハッカーを集めて成功したが、Thinking Machines や Xerox は集めても失敗した。優秀な人材は必要条件であって十分条件ではない。 - ベンチャーキャピタルが「次のマイクロソフト」を探すのは間違い。マイクロソフトはデータ上の特異点であり、その文化は幸運なチャンス（IBM との取引）から始まっている。探すべきは次の Apple、次の Google。 - 良いハッカーかどうかは本人にもわからない。偉大な仕事を為した人はたいてい自分を「まぬけで怠け者で、頭がまともに動くのは10日に1日」だと思っている。作品を比較するのが小説のように難しいため、ハッカー界には「我々のヒーローが誰か誰にもわからない」という奇妙な状況が生じる。 - 資質として挙がるのは**好奇心**（特にものが動くしくみへの）と**巨大なコンテキストを頭にロードできる集中力**。ジョン・マクフィーはビル・ブラッドレイの成功が70度の並外れた周辺視野（通常は47度）にあったと書いたが、素晴らしいハッカーもそのような生まれつきの能力を持つのかもしれない。著者は「密度の高い言語を使うことでずるをしている（実質的にコートを狭める効果がある）」と述べる。 - ハッカーは一般に賢い人々より「政治的に正しくない」。前提を常に疑う習慣がプログラミングでは有用な資質になるためだ。 **キーワード** - **デザインのパラドックス**: 自分自身が良いセンスを持っていなければ、素晴らしいデザイナーを見分けられない。だから美を知らずに美を生み出すプロセスを管理することはできない（アメリカ車が醜い理由もこれ）。 - **嫌な細かい問題 (schlep)**: バグだらけのインタフェース、顧客ごとの曖昧なカスタマイズなど、解いても何も学べない問題群。ノイズであってシグナルではない。 - **ボトムアッププログラミング**: 優秀な人に道具（言語・部品）を作らせ、別グループがそれでアプリを作る分業。研究部門を切り離すより優れた「優秀な人の守り方」。 - **問題の再定義**: 退屈に見える問題を面白い問題に作り替えるマネージャーの技（ITA の料金検索、Google の検索、ジョブズの Mac）。 - **勝者総取り（二乗の法則）**: ハッカーは互いに引き寄せ合うため、環境の良さの二乗に比例して集まる。 - **ハッカーの契約**: 「退屈な仕事は一切しない。かわりに中途半端な仕事は絶対に受けない」という自分自身との約束。