ハッカーと画家を比較しながら、創作、デザイン、ソフトウェア開発の本質について考察するエッセイ。
2003年5月
（本エッセイはハーバード大学でのゲスト講義から派生し、以前のノースイースタン大学での講演も組み込まれています）
大学院でコンピュータサイエンスを修了した後、私は絵画を学ぶために美術学校へ行きました。コンピュータに興味がある人が絵画にも関心を持つことに、多くの人は驚いていたようです。彼らはハッキングと絵画が全く異なる仕事のように考えていたのです—ハッキングは冷静で、正確で、体系的であり、絵画は何か原始的な衝動の熱狂的な表現だと。
しかし、どちらのイメージも誤りです。ハッキングと絵画には多くの共通点があります。実際、私が今まで知ってきた様々なタイプの人の中で、ハッカーと画家は非常によく似ています。
ハッカーと画家の共通点は、どちらも「作り手」だということです。作曲家、建築家、作家と同様に、ハッカーと画家が目指しているのは「良いもの」を作ることです。彼らは必ずしも研究をしているわけではありませんが、もし良いものを作ろうとする過程で新しい技法を発見できれば、それに越したことはありません。
私は「コンピュータサイエンス」という言葉が昔から好きではありません。主な理由は、そんなものは本当は存在しないからです。コンピュータサイエンスとは、歴史の偶然によって寄せ集められたいくつかの分野をまとめたものに過ぎず、ユーゴスラビアのようなものです。一方の端には、実際には数学者なのに、コンピュータサイエンスと称してDARPAの助成金を得ている人たちがいます。真ん中には、アルゴリズムがネットワーク上でデータをルーティングする方法など、コンピュータの自然史のようなことをやっている人たちがいます。そして反対の端には、面白いソフトウェアを書こうとするハッカーたちがいて、彼らにとってコンピュータはあくまで表現のメディアであり、建築家にとってのコンクリートや画家にとっての絵の具と同じです。まるで、数学者・物理学者・建築家が皆、同じ学科に所属しているかのようです。
ハッカーのすることは時に「ソフトウェア工学」と呼ばれますが、この用語もまた誤解を招きます。優れたソフトウェアデザイナーはエンジニアというより建築家に近いのです。建築と工学の境界ははっきりとは定義できませんが、確かに存在します。それは「何をするか」と「どうやってやるか」の違いです。建築家は「何をするか」を決め、エンジニアは「どうやってやるか」を考えます。
「何」と「どうやって」をあまりにも分離しすぎるのはよくありません。「どうやってやるか」を理解せずに「何をするか」を決めようとするのは危険です。しかしハッキングとは、仕様の実装方法を決めるだけではありません。最善の形では、まず仕様を「作り出す」ことだと言えるでしょう—そして、それを実現する最良の方法は実装しながら考えることなのです。
おそらく「コンピュータサイエンス」も、ユーゴスラビアのように、いつか各構成要素ごとに分割されるでしょう。その方が良いかもしれません。特に私の出身地、つまりハッキングにとって独立が保証されるのなら。
これら全ての異なるタイプの仕事を一つの部門に束ねることは、管理上は便利ですが、知的には混乱を招きます。これが「コンピュータサイエンス」という名前が気に入らないもう一つの理由です。真ん中の人たちは、実験科学のようなことをやっていますが、両端、すなわちハッカーと数学者は、実際には科学をしているわけではありません。
数学者はこのことを気にしていないようです。彼らは他の数学者と同じように定理を証明する作業に精を出し、恐らくそのうち自分たちが「コンピュータサイエンス」と書かれた建物にいることも気にならなくなるでしょう。しかしハッカーにとっては、このラベルが問題になる場合があります。自分達のやっていることが「サイエンス」と呼ばれると、科学的に振る舞わなければならない気がしてしまいます。本当は美しいソフトウェアをデザインしたいのに、大学や研究所のハッカーたちは研究論文を書かなければならないと感じてしまいがちです。
最良の場合、論文執筆は単なる形式だけです。ハッカーはクールなソフトウェアを作り、その後論文を書く。そして論文はそのソフトウェアの達成を代理するものになります。しかししばしば、このミスマッチが問題を引き起こします。美しいものを作るという目標から逸れて、論文として扱いやすい、醜いものを作る方向へ流されやすいのです。
残念ながら、美しいものが必ずしも論文の題材に最適とは限りません。まず、研究には独創性が必要です—そして（博士論文を書いた人なら皆知っていることですが）、未開拓の分野だと保証する唯一の方法は、誰も欲しがらない分野を選ぶことです。次に、研究は「重厚」でなければならず、ぎこちないシステムは論文向きの「お肉」をもたらします。なぜなら、目的を果たすために乗り越えなければならない障害が多いからです。誤った前提から始めるほど、扱うべき問題も増えます。AI研究の多くがその典型例です。
美しいものを作り出す方法の一つは、すでに存在するものに微妙な調整を加えたり、既存のアイデアをわずかに新しい形で組み合わせたりすることです。しかしこのような作業は、研究論文で表現するのが困難です。
ではなぜ大学や研究所は、論文の数でハッカーを評価し続けるのでしょうか？それは「学力」を単純な標準テストで測ったり、プログラマーの生産性をコード行数で測ったりするのと同じ理由です。これらのテストは適用しやすく、「ある程度機能する使いやすいテスト」の誘惑には勝てません。
ハッカーが実際に目指している「美しいソフトウェアの設計」を測定するのは、ずっと難しいことです。良いデザインを評価するには優れたデザインセンスが必要ですが、人が優れたデザインを認識できる能力と、その自信には実際にはほぼ【負の相関関係】があります。
唯一、外部的な試験基準は「時間」です。時が経つにつれて、美しいものは生き残り、醜いものは捨てられていきます。残念ながら、そのサイクルには人間の寿命を超えるくらい長い時間がかかる場合もあります。サミュエル・ジョンソンは作家の名声が収束するには百年かかると言いました。作家の影響力のある友人が亡くなり、そのフォロワーもいなくなるまで待たなければならないのです。
ハッカーは自身の評価に大きなランダム成分が入ることを受け入れるほかありません。これは他の「作り手」と同じです。むしろ、比べればハッカーは幸運です。ハッキング界では流行の影響は、絵画に比べれば遥かに小さいからです。
自分の仕事が誤解されることよりもっと危険なのは、自分自身が自分の仕事を誤解してしまうことです。関連分野は、アイデアを探しに行く場所です。もし「コンピュータサイエンス学科」にいると、ハッキングが理論計算機科学の応用版だと誤って信じやすくなります。大学院時代、私はもっと理論を学ぶべきか、卒業試験の三週間後にはすっかり忘れてしまったことを大きな過失だと思い込んでいました。
今は間違いだったと分かります。ハッカーに理論計算の知識が必要なのは、画家に絵の具の化学が必要な程度です。計算時間や空間の複雑さ、チューリング完全性くらいは知っておいた方がいいでしょう。「状態機械」の概念も覚えておくと、パーサや正規表現ライブラリを書く必要が生じたときに役立ちます。しかし実際、画家の方がもっと多くの「絵の具の化学」について知っているものです。
私の経験では、アイデアの最良の源は「コンピュータ」と名のつく他分野ではなく、「作り手」が活躍する分野です。絵画は計算理論よりはるかに豊かなアイデアの源になっています。
例えば、私は大学で「プログラムは紙の上で完全に設計してからPCに触れなさい」と教えられました。でも実際、私はそんなやり方をしていませんでした。むしろコンピュータの前に座って、考えながらプログラムを書いたり、壊れたコードをとりあえず書き殴って、だんだん形に整えていくのが好きでした。デバッグは単なる最終チェックだと教えられましたが、私自身のやり方では「プログラミングはデバッグそのものであるかのよう」でした。
ずっとこのやり方に罪悪感を覚えていました。ちょうど、鉛筆の持ち方が小学校で教わったのと違っていたのを気にしていたのと同じです。もし他の「作り手」—画家や建築家—のやり方に注目していれば、自分のやっていたことが「スケッチ」と呼ばれるものだと気づけたでしょう。どうやら大学で教わったプログラミング手法は間違いだったようです。作家や画家や建築家がやるように、書きながら考えるべきなのです。
このことに気づくと、ソフトウェア設計にも大きな影響があります。すなわち、プログラミング言語は何より「柔軟であること」が求められます。プログラミング言語とは「考える」ためのツールであって、「すでに考え抜かれたプログラムを表現するためのもの」ではありません。言語はペンではなく鉛筆であるべきなのです。静的型付けは、もし皆が大学で教わった通りにプログラミングしているなら優れたアイデアでしょう。しかし私が知っているハッカーたちは誰もそんな方法で書いていません。私たちに必要なのは、落書きや修正が気軽にできる言語であって、型というティーカップを膝にバランスよく載せて、厳格な伯母のようなコンパイラと丁寧に会話しながら開発しなければならないような言語ではありません。
静的型付けの話をしているうちに、もう一つ作り手の立場を意識する利点が浮かびます。それは「数学への羨望（Math Envy）」です。理系分野の人は内心、数学者のほうが自分たちより頭が良いと思っています。たぶん、数学者自身もそう思っているでしょう。そのため、科学者は自分の仕事をなるべく数学的に見せたくなるのです。物理学のような分野ではそれほど害はありませんが、自然科学から離れるほど問題が大きくなります。
数式で埋め尽くされたページは圧倒されます（追加の威厳を与えたいならギリシャ文字変数を使うとよいでしょう）。これが、正式に扱いやすい（≒数式化できる）問題ばかりに取り組みたくなる誘惑に繋がります。本当に重要な問題ではなくとも。
もしハッカーが作家や画家と共感して生きていれば、こうした誘惑に駆られずに済みます。作家や画家は数学への羨望を持ちません。彼らは自分たちが全く関係のないことをやっていると感じています。ハッカーもきっとそうでしょう。
もし大学や研究所がハッカーにやりたい仕事をさせてくれないなら、おそらくその場所は企業なのでしょう。けれども、ほとんどの企業もハッカーに本当に望む仕事をさせてくれません。大学や研究所はハッカーに科学者を求め、企業は彼らにエンジニアを求めます。
私がそれに気づいたのはつい最近です。YahooはViawebを買収した際、私に何をやりたいか尋ねました。私はビジネスサイドはあまり好きではなかったので「ただハックしたい」と答えました。けれどもYahooでハッキングとは「ソフトウェアを“実装する”こと」、つまりソフトウェアを設計することではありませんでした。プログラマーはプロダクトマネージャーの「ビジョン（と言えるものがあれば）」をコードに置き換える技術者として見なされていました。
これは大企業でのデフォルトです。アウトカムの標準偏差を減らすためにそうするのです。本当にソフトウェアを設計できるハッカーはごく一部であり、会社を運営する人々にとって彼らを見分けるのは難しい。だから、多くの企業は将来のソフトウェアを一人の天才ハッカーに任せるのではなく、委員会で設計し、ハッカーはただ実装する仕組みを作っています。
将来お金を稼ぎたいなら、これを覚えておくといいでしょう。なぜなら、スタートアップが勝つ理由の一つだからです。大企業は設計結果の標準偏差を下げて大失敗を避けます。けれども、「振幅」を抑えると良い面も悪い面も失います。大企業にとっては問題ではありません。なぜなら彼らは画期的な製品を作ることで勝つのではなく、他の大企業より「マシ」であることで勝つからです。
だから、もしプロダクトマネージャーが設計している大企業と「デザイン戦争」を仕掛けられるなら、彼らは絶対にあなたについていけません。もっとも、そのチャンスを見つけるのは簡単ではありません。大企業にデザイン戦争を仕掛けるのは、城塞の中の相手に肉弾戦を挑むのと同じくらい難しいのです。例えば、Microsoft Wordより優れたワープロを書くことは簡単ですが、マイクロソフトはOS独占という城砦の中にいるので、たとえそれを作っても気づきもしないでしょう。
デザイン戦争を仕掛けるべき場所は「誰もまだ要塞を築いていない新市場」です。そこでは、大胆なデザインに挑戦して設計と実装を同じ人が行うことで、大きく勝つことができます。マイクロソフトも最初はそうしていました。Appleもそう、ヒューレット・パッカードも然り。成功したスタートアップはほとんど例外なくそうでしょう。
ですから偉大なソフトウェアを作るにはスタートアップを始めるのが一つの方法です。とはいえ、問題が二つあります。一つは、スタートアップではプログラムを書く以外のことがたくさんあるということ。Viaweb時代、私は四分の一でもコードを書けたらラッキーでした。残りの四分の三は単調な作業から恐ろしいものまで色々でした。ある取締役会から抜け出して虫歯の治療に行ったことがあります。歯医者の椅子で「今日は休暇気分だな」と感じたのを覚えています。
もう一つの問題は、「儲かるソフトウェア」と「書いて面白いソフトウェア」の重なりが薄いことです。プログラミング言語を作るのは面白い。しかし今や誰もそんなもののためにお金を払いません。お金を稼ぎたいなら、誰も無料で解決したくない面倒な問題ばかりを扱うことになります。
これは全ての「作り手」の宿命です。価格は需給で決まり、「面白い仕事」への需要は、個々の顧客のありふれた問題を解決する需要よりずっと少ない。オフブロードウェイの舞台に立っても、展示会でゴリラスーツを着る方がずっと稼げる。小説を書くより、ゴミ処理機の広告文を書く方が稼げるし、言語ハックより企業の古いデータベースをWebに繋げる方法を考えるほうが儲かる。
この問題の答えは、ソフトウェアなら「本業(day job)」というコンセプトです。このフレーズは元々夜に演奏する音楽家から来たとされます。より一般的には「金のためにやる仕事と、愛のためにやる仕事」の両立を指します。
ほとんどの作り手はキャリアの初期に日中の本業を持つものです。画家や作家もそうです。運が良ければ本業が本当の仕事に関連していることもあります。ミュージシャンはレコード屋で働くことも多いですし、ハッカーも本当の目標に使うソフトウェアを本業で触ることができるかもしれません。[1]
私がハッカーには本業を持ち、余暇で美しいソフトウェアを書くべきだと言うのは、新しいアイデアとして言っているわけではありません。これはまさにオープンソース運動そのものです。私が言いたいのは、オープンソースがたぶん正しいモデルであり、そのことは他の全ての「作り手」が独立して証明してきたということです。
どんな雇用主でも、ハッカーにオープンソースプロジェクトへの参加を渋るのは不思議に思います。Viawebでは逆でした。むしろ独自プロジェクトに取り組まない人は採用を躊躇しました。なぜなら、本当に好きでなければ何かをうまく成し遂げることはできませんし、本当に「ハック」が好きなら、間違いなく自分のプロジェクトに取り組んでいるからです。[2]
ハッカーは科学者ではなく「作り手」なので、適切なメタファーは科学分野ではなく、他の作り手の中に求めるべきです。絵画からハッキングについて学べることは何でしょうか？
絵画の例から、あるいは少なくとも裏付けられるのは、「どうやってハックを学ぶか」です。絵画は主に描くことで学びます。ハッキングも同じ。ほとんどのハッカーは大学のプログラミング科目で学ぶのでなく、13歳頃に自作プログラムを書くことでハックを習得します。大学でも、授業より主に自主的にプログラムを書き続けることで上達します。[3]
画家は作品を積み重ねていくので、やりながら上達していく様子が観察できます。画家の作品を年代順に並べると、過去の学びを応用して作品が進化しているのが見て取れます。ある絵に抜きんでてよくできた箇所があれば、以前の作品の小さなスケッチ版がどこかにあるものです。
ほとんどの作り手がこのような方法で成長します。作家や建築家も同じでしょう。ハッカーもむしろ、何年も一つのプロジェクトを改良し続けるのではなく、画家のように定期的にゼロからやり直した方がよいのかもしれません。
ハッカーが「やりながら学ぶ」という事実も、科学とは大きく違う点です。科学者の場合は他人の仕事をラボや演習問題で再現するところから始まり、それが完璧で正しいことが求められます。やがて独自研究へ進みます。一方、ハッカーは最初から独自の仕事をします—ただし最初は下手くそなだけです。つまりハッカーは「最初は独自、次第に上手くなる」—科学者は「最初は上手い（既存の再現）、次第に独自になる」のです。
もう一つの学び方は「良い例から学ぶ」です。画家にとって美術館は技法の図書館です。何世紀にもわたって、偉大な巨匠の作品を模写することが伝統的な修業法でした。模写することで絵の構造を細部まで学べるからです。
作家も同じようにします。ベンジャミン・フランクリンはアディソンやスティールの随筆の要点を要約し、その再現を試みて書き方を学びました。レイモンド・チャンドラーも探偵小説でこれを実践したといいます。
ハッカーも良いプログラム—機能だけでなくソースコードも含めて—を見ることで学べます。オープンソースの普及によって、プログラミングを学びやすくなったのも一つの恩恵です。私がプログラミングを学んだ頃は、本のコード例くらいしか参考になりませんでした。当時唯一大きなソースコードはUnixでしたが、これさえオープンではなく、ジョン・ライオンズの本を内緒でコピーして皆読んでいました。[1977年執筆、1996年まで出版禁止]
もう一つ絵画から学べるのは、絵がだんだんと改良されていくということです。絵はたいていスケッチから始まり、徐々に細部が加えられます。そして、単なる穴埋めではありません。最初の設計が間違っていたり予想外の修正が重なったりします。X線で調べると、手足や顔のパーツに何度も手が加えられている名画は数知れません。
これはハッキングにも当てはまります。プログラム仕様が完璧であると期待するのは非現実的です。最初からその点を認めて、仕様変更に柔軟に対処できるようにプログラムを書く方が賢明でしょう。
（大企業では構造的にこれが困難なので、スタートアップにはこの点でも優位性があります）
「早すぎる最適化」だけでなく、「早すぎる設計」—プログラムの内容を早く決めすぎること—にも注意すべきです。
適切なツールはこの失敗を避けるのに役立ちます。良いプログラミング言語は油絵の具のように「後から気が変わっても調整しやすい」ものです。動的型付けは先にデータ表現を決めなくてもよい点で有利といえます。しかし鍵となるのは「非常に抽象的な言語」であることでしょう。最も修正しやすいプログラムは、非常に短いプログラムです。
これは逆説のようですが、偉大な絵画は「必要以上」に優れていなければなりません。例えば、レオナルドがナショナルギャラリーの『ジネーヴラ・デ・ベンチの肖像』の背景にジュニパー（ビャクシン）の藪を描いたとき、一枚一枚の葉まで細かく描き込みました。多くの画家なら背景をただ枠と見なして雑に済ませてしまうでしょう。
しかしレオナルドは違いました。どれだけ細かく描き込むかは「人がどれだけ注目するか」には依存しません。まるでマイケル・ジョーダンのような執念深さでした。
執念は勝利につながります。なぜなら、一つ一つは見えない細部でも、全体として輝き出すからです。人々がジネーヴラ・デ・ベンチの肖像を通り過ぎると、まずその輝きに心を奪われます。レオナルドの名前を見る前に、です。細部の積み重ねが圧倒的な魅力となるのです。
優れたソフトウェアもまた、美しさに対する狂信的な執念を要します。良いソフトウェアの内部を調べると、普通は見えない部分まで美しく作り込まれているのを見つけます。私自身が偉大なソフトウェアを書けているとは思いませんが、少なくともコードのインデントがずれていたり、変数名が醜かったりすると憂鬱になります。
もしハッカーが単なる仕様の実装者なのであれば、ただ黙々と仕様通りに作業すれば良いでしょう。しかしハッカーが「創造者」であるなら、「インスピレーション」という要素も考慮せねばなりません。
ハッキングも絵画同様、作業は周期的です。新しいプロジェクトに夢中になって16時間ぶっ通しで取り組むようなこともあれば、何も面白く感じない停滞期もあります。
良い仕事をするには、こうした波を考慮すべきです。車のマニュアルギアで坂を登るとき、クラッチを時に戻す必要があるように、後退することで情熱の空回りを防ぐのです。絵画やハッキングには恐ろしく野心的な作業と、安心してこなせる日課のような作業があります。停滞しそうなときのために簡単な仕事をいくつか取っておくのも良いアイデアです。
ハッキングにおいては、実際に「バグを取っておく」こともできます。私はデバッグが好きです。唯一、ハッキングが多くの人が思い描く通りに単純な作業になるときです。完全に制約された問題を解くだけ。プログラムがxをするはずなのにyしか返ってこない。どこが悪い？最後には必ず勝てる。まるで壁を塗るようにリラックスできます。
絵画の例は、自分の仕事管理だけでなく「協業」のヒントにもなります。偉大な美術作品の多くは複数人の手によるものですが、博物館の壁に飾られた名前は一人だけの場合が多いです。レオナルドはヴェロッキオ工房の徒弟として、『キリストの洗礼』の天使の一人を描きました。こうした分業は例外ではなく原則でした。ミケランジェロがシスティーナ礼拝堂の全ての人物を一人で描いたのは、特に「異例の献身」として有名です。
私の知る限り、画家が共同作業する場合でも、同じパーツを塗り重ねることはありません。主人が主役や人物を担当し、助手が背景や小物を担当することが多かったのです。しかし他人の上に別人が上書きで塗ることはなかったのです。
これがソフトウェアのコラボレーションの正しいモデルだと思います。やりすぎは禁物です。3人も4人もが一つのコード片をいじると、誰も所有意識を持たず、談話室のような無機的空間になり、「ゴミ」が溜まりやすくなります。最良の方法は、プロジェクトを明確なモジュールに分割し、それぞれ明確なオーナーと、できれば言語のインターフェースばりの「よく設計された接点」を設けることです。
絵画と同じく、多くのソフトウェアは「人間の観客」のために作られます。だからハッカーも画家と同じく、「共感力」を持たないと偉大な仕事はできません。ユーザー目線で考えられないといけません。
私は子供の頃、常に「他人の立場に立て」と言われてきましたが、実際には「他人の望み通りにしろ」という意味にしか受け取っていませんでした。そのため、共感力を養うことを軽視してきました。
大間違いでした。実は「他人の立場で見ること」こそが成功の秘訣なのです。自己犠牲の話とは違います。相手の見方を理解することは、その利益のために行動することを意味しません。場合によっては、その逆になることすらあります（戦争などではむしろ相手の動きを知って逆の行動を取るでしょう）。[4]
ほとんどの作り手は人間の観客のためにものを作ります。観客を引きつけるには、「何を求めているか」を理解しなければなりません。偉大な絵画のほとんどが人物画なのは、人が最も関心を抱くテーマだからです。
共感力は「良いハッカー」と「偉大なハッカー」の最も大きな違いかもしれません。中には頭は切れるが、共感力はほとんどないハッカーもいます。そのような人が素晴らしいソフトウェアをデザインするのは難しいでしょう。なぜならユーザーの視点で物事を見られないからです。[5]
共感力の有無を見るには、技術的知識のない人に技術を説明させてみると分かりやすいでしょう。他は賢いのに、全く説明ベタな人を私たちは皆知っています。例えば、夕食会で「プログラミング言語とは？」と質問され、「高水準言語はコンパイラがオブジェクトコードを生成する時の入力になるんだ」などと答えてしまう人。高水準言語？コンパイラ？オブジェクトコード？ そんな質問をする人は、それらの意味も知らないはずです。
ソフトウェアにも「自分自身で説明する力」が求められます。良いソフトウェアを書くには、ユーザーがどれだけ理解していないかを理解する必要があります。ユーザーは予習なしで突然ソフトに触れます。直感的に予想した通り動かなければ、説明書を読んでくれることはありません。初代Macintosh（1985年）はこの点で理想的に近かった。ソフトウェアとしては稀に、「ただ動く」存在でした。[6]
ソースコードも同様に「自分自身で説明できる」べきです。もしプログラミングについてひとつだけ覚えてもらえるなら、『計算機プログラムの構造と解釈』の冒頭の引用です。
プログラムは、人に読ませるために書かれ、ときに機械に実行させるものである。
ユーザーだけでなく、コードの読者にも共感力が必要です。それは自分自身の利益にもなります。なぜなら、6ヶ月後に自分で書いたプログラムの中身がさっぱり分からないといった苦い経験をしているハッカーが少なくないからです。こうしてPerlから足を洗ったという人も私の知人に何人かいます。[7]
共感力の欠如は、時に高い知性と結びつけられることすらあります（…が、実際は無関係）。数学や自然科学では共感力を養わなくてもやっていけるので、頭の良い人が多く、この二つが関連づけられてきたのでしょう。しかし、共感力が低いだけの人も世の中にはかなりいます。ラジオ番組の質問コーナーに寄せられる質問の大半は、主旨を見抜けない回りくどいものばかりで、司会者が要点を代弁する羽目になります。
さて、ハッキングが絵画や文学のような「クールな」ものになりうるでしょうか？人生は一度きり。どうせなら偉大なことに人生を使いたいものです。
残念ながら、この質問の答えは簡単には出ません。名声には必ず大きなタイムラグがつきものだからです。遠くの星の光のようなものです。絵画は今や偉大な芸術とされていますが、それは五百年前の偉大な作品があるから。レオナルド達の時代には、私たちが思うほど重大だとはみなされていませんでした。ウルビーノ公フェデリーコ・ダ・モンテフェルトロが、ピエロ・デッラ・フランチェスカの絵の「変わった鼻の男」として後世に知られるとは、当時の人は予想すらしなかったことでしょう。
ですから、もし今ハッキングが絵画ほど「クール」に思えないとしても、かつて絵画自体もその全盛期より後の時代にこそ高い評価を得てきたことを思い出すべきです。
確信をもって言えるのは、今がハッキングにとって「黄金時代」だということです。多くの分野では偉大な仕事は黎明期に集中します。1430-1500年の絵画はいまだに超えられていません。シェイクスピアはプロ劇場の誕生と同時に現れ、演劇というメディアをどこまでも引き上げて後続の全作家を影に葬りました。デューラーは版画で、オースティンは小説で同じことを成し遂げました。
まったく新しいメディアが現れると、人々はその可能性を一気に探求します。ハッキングはいま、まさにこの段階にあるのでしょう。
レオナルドの時代、絵画は今ほどクールではありませんでした。ハッキングが本当にクールなものになるかどうかは、私たちがこの新しいメディアで何を成し遂げるかにかかっています。
注釈
[1] 写真術が絵画にもたらした最も大きなダメージは、おそらく「最高の本業」だった肖像画家の職を奪ったことです。
[2] Microsoftは従業員のオープンソース貢献を抑制していると聞きますが、今や一流のハッカーは皆オープンソース開発に取り組んでおり、この方針の主な効果は「優れたプログラマーが採用できなくなること」かもしれません。
[3] 大学で学ぶプログラミングの知識とは、ファッションや書籍や恋愛の知識と似ていて「高校時代の自分のセンスの悪さを再発見するもの」かもしれません。
[4] これは応用された共感の例です。Viawebでは二つの選択肢で迷ったとき「どちらが競合相手にとって都合が悪いか」を考えました。ある競合がほとんど役に立たない機能を追加し、プレスでは「我々に勝る唯一の特徴」と誇張していました。私たちは「機能は無意味」と説明するよりも、それを自分たちでも即興で実装してしまう方が相手を困らせると判断し、その日のうちにバージョンを作りました。
[5] ただしエディタやコンパイラ等、ハッカー自身が標準的ユーザであるソフトの場合は共感不要。
[6] 「ほぼ」完璧。RAM容量が足りず頻繁なディスク交換が必要だったが、数ヶ月後にドライブ増設で対応できた。
[7] 読みやすいプログラムを作るにはコメントを書きまくるのではなく、アーベルソン＆サスマンの引用をさらに発展させ「プログラミング言語はアルゴリズムの説明に最適であるべきだ」と主張します。コメントはイレギュラーな事情で読者に注意喚起したい部分だけで十分です。ちょうど道路の曲がり角にしか矢印が描かれていないように。
謝辞: Trevor Blackwell, Robert Morris, Dan Giffin, Lisa Randall（本文草稿を校閲してくれました）、またHenry Leitner, Larry Finkelstein（講演に招いてくれました）に感謝します。
