ハッカーと画家 | Paul Grahamのエッセイ

2003年5月

(本稿は、ハーバード大学でのゲスト講義と、ノースイースタン大学での以前の講演を基にしています。)

コンピュータサイエンスの大学院を修了した時、私は絵画を学ぶために美術学校へ行きました。コンピュータに興味がある人間が絵画にも興味を持つことに、多くの人が驚いているようでした。彼らは、ハッキングと絵画は全く異なる種類の仕事だと考えているようでした――ハッキングは冷徹で、正確で、計画的であり、絵画は原始的な衝動の狂乱的な表現であると。

これらのイメージはどちらも間違っています。ハッキングと絵画には多くの共通点があります。実際、私が知っている様々なタイプの人々の中で、ハッカーと画家は最も似ている部類に入ります。

ハッカーと画家が共通して持っているのは、彼らがどちらも「作り手」であるという点です。作曲家、建築家、作家と同様に、ハッカーと画家がやろうとしているのは、良いものを作ることです。彼らはそれ自体が研究をしているわけではありませんが、良いものを作ろうとする過程で新しい技術を発見すれば、それに越したことはありません。

私は「コンピュータサイエンス」という言葉が好きではありません。その主な理由は、そんなものは存在しないからです。コンピュータサイエンスは、ユーゴスラビアのように、歴史の偶然によってかろうじて関連する分野がごちゃ混ぜにされたものです。一方の端には、実際には数学者であるにもかかわらず、DARPAの助成金を得るために自分たちのやっていることをコンピュータサイエンスと呼ぶ人々がいます。中央には、コンピュータの自然史のようなものに取り組む人々がいます――例えば、ネットワークを介してデータをルーティングするアルゴリズムの動作を研究する人々です。そしてもう一方の極端な端には、面白いソフトウェアを書こうとしているハッカーたちがいます。彼らにとってコンピュータは、建築家にとってのコンクリートや画家にとっての絵の具のように、単なる表現媒体なのです。それはまるで、数学者、物理学者、建築家が皆同じ学科にいなければならないようなものです。

ハッカーたちがやっていることが「ソフトウェアエンジニアリング」と呼ばれることもありますが、この言葉も同様に誤解を招きます。優れたソフトウェアデザイナーは、建築家がエンジニアではないのと同じくらい、エンジニアではありません。建築とエンジニアリングの境界は明確ではありませんが、確かに存在します。それは「何を」と「どのように」の間にあります。建築家は「何をすべきか」を決め、エンジニアは「どのようにそれを行うか」を考え出します。

「何を」と「どのように」をあまりにも切り離すべきではありません。どのように行うかを理解せずに何をすべきかを決めようとすれば、問題を引き起こすことになります。しかし、ハッキングは、単に何らかの仕様をどう実装するかを決める以上のものです。最高の状態では、それは仕様そのものを作り出すことです――ただし、それを行う最善の方法は、実際に実装することだと判明するのですが。

おそらくいつか、「コンピュータサイエンス」はユーゴスラビアのように、その構成要素に分解されるでしょう。それは良いことかもしれません。特に、それが私の故郷であるハッキングの独立を意味するならば。

これら異なる種類の仕事を一つの学科にまとめるのは、管理上は便利かもしれませんが、知的には混乱を招きます。それが私が「コンピュータサイエンス」という名称を好まないもう一つの理由です。おそらく中央の人々は実験科学のようなことをしていると言えるでしょう。しかし、両端の人々、つまりハッカーと数学者は、実際には科学を行っていません。

数学者たちはこのことを気にしていないようです。彼らは数学科の他の数学者たちと同じように、喜んで定理の証明に取り組み、おそらくすぐに自分たちが働く建物の外壁に「コンピュータサイエンス」と書かれていることに気づかなくなるでしょう。しかし、ハッカーにとってこのレッテルは問題です。自分たちのやっていることが科学と呼ばれると、科学的に振る舞うべきだと感じてしまいます。そのため、本当にやりたいこと、つまり美しいソフトウェアを設計する代わりに、大学や研究機関のハッカーたちは研究論文を書くべきだと感じています。

最良の場合、論文は単なる形式に過ぎません。ハッカーは素晴らしいソフトウェアを書き、それについて論文を書き、その論文がソフトウェアによって表される成果の代理となります。しかし、この不一致が問題を引き起こすことがよくあります。美しいものを作ることから、研究論文により適した醜いものを作る方向へと簡単に流されてしまうのです。

残念ながら、美しいものが常に論文の最適な主題となるわけではありません。第一に、研究は独創的でなければなりません――そして博士論文を書いたことがある人なら誰でも知っているように、未開の領域を探求していることを確実にする方法は、誰も欲しがらない土地を確保することです。第二に、研究は実質的でなければなりません――そして扱いにくいシステムは、より内容の濃い論文を生み出します。なぜなら、物事を成し遂げるために克服しなければならない障害について書くことができるからです。間違った仮定から始めることほど、内容の濃い問題を生み出すものはありません。AIのほとんどがこのルールの例です。もし知識が抽象概念を表す引数を持つ述語論理式のリストとして表現できると仮定するなら、それを機能させる方法についてたくさんの論文を書くことになるでしょう。リッキー・リカルドがよく言っていたように、「ルーシー、説明することが山ほどあるぞ」というわけです。

美しいものを作る方法は、しばしば既存のものに微妙な調整を加えるか、既存のアイデアを少し新しい方法で組み合わせることです。この種の仕事は、研究論文で伝えるのが難しいものです。

では、なぜ大学や研究機関は、ハッカーを出版物で評価し続けるのでしょうか？それは、「学力」が単純な標準テストで測られたり、プログラマーの生産性がコード行数で測られたりするのと同じ理由です。これらのテストは適用が容易であり、ある程度機能する簡単なテストほど魅力的なものはありません。

ハッカーが実際にやろうとしていること、つまり美しいソフトウェアを設計することを測るのは、はるかに難しいでしょう。良いデザインを判断するには、優れたデザインセンスが必要です。そして、良いデザインを認識する能力と、それができるという自信の間には、おそらく負の相関がある以外、相関関係はありません。

唯一の外部テストは時間です。時間が経つにつれて、美しいものは繁栄し、醜いものは捨てられる傾向があります。残念ながら、これにかかる時間は人間の寿命よりも長い場合があります。サミュエル・ジョンソンは、作家の評判が定まるには100年かかると言いました。作家の影響力のある友人が死に、そして彼らのすべての追随者が死ぬのを待たなければなりません。

ハッカーは、自分たちの評判に大きなランダムな要素があることを受け入れるしかないと思います。この点では、彼らは他の作り手と何ら変わりません。実際、比較すれば彼らは幸運です。ハッキングにおける流行の影響は、絵画ほど大きくありません。

自分の仕事が人々に誤解されることよりも悪いことがあります。さらに悪い危険は、自分自身が自分の仕事を誤解してしまうことです。関連分野は、アイデアを探しに行く場所です。もし自分がコンピュータサイエンス学科にいると、例えばハッキングは理論コンピュータサイエンスの理論の応用版であると信じたくなる自然な誘惑があります。大学院にいた間ずっと、私はもっと理論を知るべきだという不快な感覚が心の奥底にあり、期末試験から3週間以内にそのすべてを忘れてしまったのは非常に怠慢だと感じていました。

今、私は自分が間違っていたことに気づきました。ハッカーが計算理論を理解する必要があるのは、画家が絵の具の化学を理解する必要があるのと同じくらいです。時間計算量と空間計算量、そしてチューリング完全性について知る必要があります。また、パーサーや正規表現ライブラリを書く必要がある場合に備えて、少なくとも状態機械の概念は覚えておきたいと思うかもしれません。実際、画家は絵の具の化学について、それよりもはるかに多くのことを覚えていなければなりません。

アイデアの最良の源は、「コンピュータ」という言葉が名前に入っている他の分野ではなく、作り手が住む他の分野であることに気づきました。絵画は、計算理論よりもはるかに豊かなアイデアの源でした。

例えば、大学では、コンピュータに触れる前にプログラムを紙の上で完全に考案すべきだと教わりました。しかし、私はそのようにはプログラミングしませんでした。私は紙ではなく、コンピュータの前に座ってプログラミングするのが好きだと気づきました。さらに悪いことに、完全なプログラムを辛抱強く書き出し、それが正しいことを確認する代わりに、私はどうしようもなく壊れたコードをただ吐き出し、徐々に形を整えていく傾向がありました。デバッグは、タイプミスや見落としを修正する最終段階だと教わりました。私のやり方では、プログラミングはデバッグで構成されているように思えました。

長い間、私はこのことについて罪悪感を感じていました。小学校で教わった鉛筆の持ち方をしなかった時に感じたのと同じように。もし私が他の作り手、画家や建築家を見ていれば、自分のやっていることには「スケッチ」という名前があることに気づいていたでしょう。私が知る限り、大学で教わったプログラミングの方法は全く間違っていました。作家や画家や建築家がそうするように、プログラムは書きながら考えるべきなのです。

このことに気づいたことは、ソフトウェア設計に実際的な影響を与えます。それは、プログラミング言語は何よりもまず、柔軟であるべきだということです。プログラミング言語は、すでに考えたプログラムを表現するためのものではなく、プログラムを考えるためのものです。それはペンではなく、鉛筆であるべきです。もし人々が大学で教わった通りにプログラムを書いていたなら、静的型付けは素晴らしいアイデアだったでしょう。しかし、私が知っているハッカーの誰も、そのようにはプログラムを書きません。私たちは、膝の上に型のティーカップを乗せて、厳格なコンパイラの老婦人と丁寧な会話をしなければならないような言語ではなく、走り書きしたり、汚したり、塗りつけたりできる言語を必要としています。

静的型付けの話をしている間に、作り手と同一視することは、科学を悩ませるもう一つの問題、つまり「数学への羨望」から私たちを救ってくれるでしょう。科学者たちは皆、数学者の方が自分たちより賢いと密かに信じています。数学者たちもそう信じていると思います。いずれにせよ、その結果、科学者たちは自分たちの仕事をできるだけ数学的に見せようとする傾向があります。物理学のような分野では、これはおそらく大きな害にはなりませんが、自然科学から離れれば離れるほど、問題は大きくなります。

数式が並んだページは、ただただ印象的です。（ヒント：さらに印象的にするには、ギリシャ文字を使いましょう。）そのため、例えば重要な問題ではなく、形式的に扱える問題に取り組むという大きな誘惑があります。

もしハッカーが作家や画家のような他の作り手と同一視していれば、このような誘惑に駆られることはないでしょう。作家や画家は数学への羨望に苦しむことはありません。彼らは全く関係のないことをしていると感じています。ハッカーもそうだと私は思います。

もし大学や研究機関がハッカーに彼らがやりたい種類の仕事をさせないのなら、彼らの居場所は企業にあるのかもしれません。残念ながら、ほとんどの企業もハッカーに彼らがやりたいことをさせません。大学や研究機関はハッカーに科学者になることを強制し、企業は彼らにエンジニアになることを強制します。

このことを私自身が発見したのはごく最近のことです。YahooがViawebを買収した時、彼らは私に何をしたいかと尋ねました。私はビジネス面があまり好きではなかったので、ただハッキングをしたいと答えました。Yahooに入ってみると、彼らにとってハッキングとはソフトウェアを設計することではなく、実装することだと分かりました。プログラマーは、プロダクトマネージャーのビジョン（もしそれが適切な言葉なら）をコードに翻訳する技術者と見なされていました。

これは大企業におけるデフォルトの計画のようです。彼らがそうするのは、結果の標準偏差を減らすためです。実際にソフトウェアを設計できるハッカーはごく一部であり、会社を経営する人々が彼らを選び出すのは困難です。そのため、ソフトウェアの未来を一人の優れたハッカーに委ねる代わりに、ほとんどの企業は委員会によって設計され、ハッカーは単にその設計を実装するだけという体制を整えます。

もしどこかの時点で稼ぎたいなら、このことを覚えておいてください。なぜなら、これがスタートアップが勝つ理由の一つだからです。大企業は、災害を避けるために設計結果の標準偏差を減らしたいと考えます。しかし、変動を抑えると、低い点だけでなく高い点も失われます。これは大企業にとって問題ではありません。なぜなら、彼らは素晴らしい製品を作ることで勝つわけではないからです。大企業は、他の大企業よりも「まし」であることで勝つのです。

ですから、もしプロダクトマネージャーによってソフトウェアが設計されているような大企業とデザイン戦争を仕掛ける方法を見つけられれば、彼らは決してあなたに追いつくことはできないでしょう。ただし、このような機会を見つけるのは簡単ではありません。城の中にいる敵と白兵戦を挑むのが難しいのと同じように、大企業とデザイン戦争を仕掛けるのは困難です。例えば、Microsoft Wordよりも優れたワープロソフトを書くのはかなり簡単でしょうが、Microsoftはオペレーティングシステムの独占という城の中にいるため、たとえあなたがそうしたとしても、おそらく気づきもしないでしょう。

デザイン戦争を戦うべき場所は、まだ誰も要塞を築いていない新しい市場です。そこで大胆なデザインアプローチを取り、同じ人々が製品を設計し、実装することで大勝することができます。Microsoft自身も創業当初はそうしていました。Appleもそうです。そしてHewlett-Packardも。ほとんどすべての成功したスタートアップがそうだったと私は思います。

ですから、素晴らしいソフトウェアを構築する一つの方法は、自分のスタートアップを始めることです。しかし、これには二つの問題があります。一つは、スタートアップではソフトウェアを書く以外にも非常に多くのことをしなければならないということです。Viawebでは、時間の4分の1でもハッキングできれば幸運だと考えていました。そして残りの4分の3の時間は、退屈なものから恐ろしいものまで多岐にわたることをしなければなりませんでした。これには基準があります。かつて私は虫歯の治療のために取締役会を途中で抜け出さなければならなかったからです。歯医者の椅子に座って、ドリルを待っている間、まるで休暇中のように感じたのを覚えています。

スタートアップのもう一つの問題は、お金になる種類のソフトウェアと、書くのが面白い種類のソフトウェアとの間に、あまり重なりがないことです。プログラミング言語は書くのが面白いものであり、実際Microsoftの最初の製品もそうでしたが、今では誰もプログラミング言語にお金を払いません。もしお金を稼ぎたいなら、誰も無料で解決したがらないような、あまりにも厄介な問題に取り組まざるを得なくなる傾向があります。

すべての作り手がこの問題に直面します。価格は需要と供給によって決まり、作業していて楽しいものに対する需要は、個々の顧客のありふれた問題を解決するものに対する需要ほど多くありません。オフブロードウェイの演劇に出演しても、展示会で誰かのブースでゴリラの着ぐるみを着るほど稼げません。小説を書くことは、生ごみ処理機の広告コピーを書くほど稼げません。そして、プログラミング言語をハッキングすることは、ある会社のレガシーデータベースをウェブサーバーに接続する方法を解明するほど稼げません。

ソフトウェアの場合、この問題の答えは、ほとんどすべての作り手が知っている概念、「昼の仕事（day job）」だと思います。この言葉は、夜に演奏するミュージシャンから始まりました。より一般的には、お金のためにする仕事と、好きでやる仕事の二種類を持つことを意味します。

ほとんどすべての作り手は、キャリアの初期に昼の仕事を持っています。画家や作家は特にそうです。運が良ければ、自分の本業に密接に関連する昼の仕事を見つけることができます。ミュージシャンはよくレコード店で働いているようです。プログラミング言語やオペレーティングシステムに取り組むハッカーも同様に、それらを使う昼の仕事を得ることができるかもしれません。[1]

ハッカーが昼の仕事を持ち、傍らで美しいソフトウェアに取り組むのが答えだと言う時、私はこれを新しいアイデアとして提案しているわけではありません。これこそがオープンソースハッキングのすべてです。私が言いたいのは、オープンソースはおそらく正しいモデルであるということです。なぜなら、それは他のすべての作り手によって独立して確認されているからです。

どんな雇用主でも、ハッカーがオープンソースプロジェクトに取り組むことをためらうのは私には驚きです。Viawebでは、そうしない人を雇うことにはためらいがありました。プログラマーを面接する際、私たちが最も重視したのは、彼らが余暇にどのようなソフトウェアを書いているかでした。本当に好きでなければ、どんなことも本当にうまくはできませんし、ハッキングが好きなら、必然的に自分のプロジェクトに取り組むことになるでしょう。[2]

ハッカーは科学者ではなく作り手であるため、比喩を探すべき場所は科学ではなく、他の種類の作り手の中にあります。絵画はハッキングについて他に何を教えてくれるでしょうか？

絵画の例から学べること、あるいは少なくとも確認できることの一つは、ハッキングの学び方です。絵画はほとんど実践することで学びます。ハッキングも同様です。ほとんどのハッカーは、大学のプログラミングコースを受講してハッキングを学ぶわけではありません。彼らは13歳で自分のプログラムを書きながらハッキングを学びます。大学の授業でさえ、ハッキングはほとんどハッキングすることで学びます。[3]

画家は作品の足跡を残すため、彼らが実践を通じて学ぶ様子を見ることができます。画家の作品を年代順に見ると、それぞれの絵画が以前の作品で学んだことを基にしていることがわかります。絵画の中に非常にうまく機能しているものがあれば、通常、そのバージョン1が以前の絵画に小さな形で存在しているのを見つけることができます。

ほとんどの作り手はこのように仕事をしていると思います。作家や建築家も同様のようです。ハッカーも画家のように振る舞い、一つのプロジェクトに何年も取り組み続け、後からのアイデアをすべて修正として組み込もうとするのではなく、定期的にゼロからやり直すのが良いかもしれません。

ハッカーが実践を通じてハッキングを学ぶという事実は、ハッキングが科学とどれほど異なるかを示すもう一つの兆候です。科学者は実践によって科学を学ぶのではなく、実験や問題演習を行うことで学びます。科学者は、誰かがすでにやった仕事を再現しようとするという意味で、完璧な仕事から始めます。最終的に、彼らは独創的な仕事ができるようになります。一方、ハッカーは最初から独創的な仕事をしていますが、それは非常にひどいものです。つまり、ハッカーは独創的に始め、上達し、科学者はうまく始め、独創的になるのです。

作り手が学ぶもう一つの方法は、例から学ぶことです。画家にとって、美術館は技術の参考書です。何百年もの間、偉大な巨匠の作品を模写することは、画家の伝統的な教育の一部でした。なぜなら、模写することで絵画がどのように作られているかを注意深く見つめることを強制されるからです。

作家もこれを行います。ベンジャミン・フランクリンは、アディソンとスティールのエッセイの要点を要約し、それを再現しようとすることで文章を学びました。レイモンド・チャンドラーも探偵小説で同じことをしました。

ハッカーも同様に、良いプログラムを見ることでプログラミングを学ぶことができます――それが何をするかだけでなく、ソースコードもです。オープンソース運動のあまり知られていない利点の一つは、プログラミングを学ぶのが容易になったことです。私がプログラミングを学んだ頃は、ほとんど本の中の例に頼るしかありませんでした。当時利用できた大きなコードの塊はUnixでしたが、これもオープンソースではありませんでした。ソースを読んだほとんどの人々は、1977年に書かれたにもかかわらず1996年まで出版が許可されなかったジョン・ライオンズの本の違法なコピーでそれを読んでいました。

絵画から得られるもう一つの例は、絵画が段階的な洗練によって制作される方法です。絵画は通常、スケッチから始まります。徐々に細部が描き込まれていきます。しかし、それは単に埋めていく過程ではありません。時には、元の計画が間違っていたと判明することもあります。無数の絵画が、X線で見ると、手足が動かされていたり、顔の表情が修正されていたりすることが判明します。

これは絵画から学べるケースです。ハッキングもこの方法で進めるべきだと思います。プログラムの仕様が完璧であると期待するのは非現実的です。最初からこのことを認め、仕様がその場で変更できるような方法でプログラムを書く方が良いでしょう。

（大企業の構造はこれを困難にするため、ここでもスタートアップが有利な点があります。）

今や誰もが時期尚早な最適化の危険性については知っているでしょう。私は、時期尚早な設計――プログラムが何をすべきかを早すぎる段階で決定すること――についても同様に心配すべきだと思います。

適切なツールは、この危険を避けるのに役立ちます。良いプログラミング言語は、油絵の具のように、考えを変えるのを容易にするべきです。動的型付けは、事前に特定のデータ表現にコミットする必要がないため、ここで有利です。しかし、柔軟性の鍵は、言語を非常に抽象的にすることだと私は思います。最も変更しやすいプログラムは、非常に短いものです。

これは逆説のように聞こえるかもしれませんが、素晴らしい絵画は、必要とされる以上に優れていなければなりません。例えば、レオナルドがナショナル・ギャラリーにあるジネヴラ・デ・ベンチの肖像画を描いた時、彼女の頭の後ろにジュニパーの茂みを配置しました。その中に、彼は個々の葉を一本一本丁寧に描きました。多くの画家は、「これは彼女の頭を縁取るための背景に過ぎない。誰もそんなに細かく見ないだろう」と思ったかもしれません。

レオナルドは違いました。彼が絵画の一部にどれだけ熱心に取り組んだかは、誰かがそれをどれだけ注意深く見るかという期待には全く依存していませんでした。彼はマイケル・ジョーダンのようでした。容赦ないほどに。

容赦ない努力が勝利をもたらすのは、全体として、見えない細部が目に見えるようになるからです。人々がジネヴラ・デ・ベンチの肖像画のそばを通り過ぎる時、彼らの注意はしばしばすぐにそれに引きつけられます。ラベルを見てレオナルド・ダ・ヴィンチの作品だと気づくよりも前にです。それらすべての見えない細部が組み合わさって、まるで千のほとんど聞こえない声がすべて調和して歌っているかのように、ただただ見事なものを生み出します。

素晴らしいソフトウェアも同様に、美しさへの狂信的な献身を必要とします。良いソフトウェアの中を見ると、誰も見るはずのない部分も美しいことがわかります。私が素晴らしいソフトウェアを書いていると主張するつもりはありませんが、コードに関しては、もし私が日常生活でも同じように振る舞ったら、処方薬が必要になるような行動をとっていると自覚しています。インデントがひどいコードや、醜い変数名を使っているコードを見ると、気が狂いそうになります。

もしハッカーが単なる実装者で、仕様をコードに変えるだけなら、溝を掘る人のように端から端まで作業を進めることができるでしょう。しかし、ハッカーが創造者であるならば、私たちはインスピレーションを考慮に入れなければなりません。

ハッキングも絵画と同様に、仕事にはサイクルがあります。時には新しいプロジェクトに興奮して、一日16時間も働きたくなることがあります。他の時には、何も面白く感じられないこともあります。

良い仕事をするためには、これらのサイクルを考慮に入れる必要があります。なぜなら、それらはあなたの反応によって影響を受けるからです。マニュアル車の運転で坂道を上る時、エンストを避けるために時々クラッチを緩める必要があります。同様に、緩めることで野心が停滞するのを防ぐことができます。絵画とハッキングの両方において、恐ろしいほど野心的なタスクもあれば、安心できるほどルーチンなタスクもあります。行き詰まりそうな時のために、簡単なタスクをいくつか残しておくのは良い考えです。

ハッキングにおいて、これは文字通りバグを貯めておくことを意味するかもしれません。私はデバッグが好きです。ハッキングが人々が思うほど単純明快なのは、この時だけだからです。完全に制約された問題があり、それを解決するだけです。あなたのプログラムはXをするはずなのに、Yをしてしまう。どこが間違っているのか？最終的には勝つと分かっています。それは壁を塗るのと同じくらいリラックスできます。

絵画の例は、私たち自身の仕事を管理する方法だけでなく、協力する方法も教えてくれます。過去の偉大な芸術作品の多くは、美術館の壁に一つの名前しか書かれていないかもしれませんが、複数の手によるものです。レオナルドはヴェロッキオの工房の弟子であり、彼のキリストの洗礼の中の天使の一人を描きました。このようなことは例外ではなく、むしろ常識でした。ミケランジェロは、システィーナ礼拝堂の天井のすべての人物を自分で描くことに固執したため、特に献身的だと見なされました。

私の知る限り、画家たちが共同で絵画に取り組む際、彼らは決して同じ部分を制作することはありませんでした。師匠が主要な人物を描き、助手が他の部分や背景を描くのが一般的でした。しかし、ある人物が別の人物の作品の上に描き直すということは決してありませんでした。

これはソフトウェアにおけるコラボレーションの正しいモデルでもあると思います。やりすぎないことです。3人か4人の異なる人々によってハッキングされ、誰も真に所有していないコードは、共同部屋のようになってしまいます。それは荒涼として見捨てられたように感じられ、不要なものが蓄積される傾向があります。コラボレーションの正しい方法は、プロジェクトを明確に定義されたモジュールに分割し、それぞれに明確な所有者を設け、それらの間のインターフェースを、プログラミング言語と同じくらい注意深く設計し、可能であれば明確にすることだと私は思います。

絵画と同様に、ほとんどのソフトウェアは人間の聴衆を対象としています。そのため、ハッカーも画家と同様に、本当に素晴らしい仕事をするためには共感力を持たなければなりません。ユーザーの視点から物事を見ることができなければなりません。

子供の頃、私はいつも「他人の視点から物事を見なさい」と言われていました。しかし、実際にはこれは常に、自分が望むことではなく、他人が望むことをするという意味でした。もちろん、このせいで共感力は悪い評判を得てしまい、私はそれを培わないようにしていました。

いやはや、私は間違っていました。他人の視点から物事を見ることが、実質的に成功の秘訣であることが判明したのです。それは必ずしも自己犠牲を意味するものではありません。むしろ逆です。他人が物事をどう見ているかを理解したからといって、その人の利益のために行動するとは限りません。例えば戦争のような状況では、全く逆のことをしたいと思うでしょう。[4]

ほとんどの作り手は、人間の聴衆のために物を作ります。そして聴衆を引き込むには、彼らが何を必要としているかを理解しなければなりません。例えば、ほとんどすべての偉大な絵画は人物画です。なぜなら、人々が興味を持つのは人々だからです。

共感力は、おそらく良いハッカーと偉大なハッカーを分ける最も重要な違いです。一部のハッカーは非常に賢いですが、共感力に関しては実質的に独我論者です。そのような人々が素晴らしいソフトウェアを設計するのは困難です[5]。なぜなら、彼らはユーザーの視点から物事を見ることができないからです。

人々がどれだけ共感力に優れているかを知る一つの方法は、技術的な背景を持たない人に技術的な質問を説明する様子を見ることです。私たちはおそらく皆、他の点では賢いのに、この点では滑稽なほど下手な人々を知っているでしょう。もし誰かがディナーパーティーでプログラミング言語とは何かと尋ねたら、彼らは「ああ、高水準言語はコンパイラがオブジェクトコードを生成するための入力として使うものだよ」などと言うでしょう。高水準言語？コンパイラ？オブジェクトコード？プログラミング言語が何であるかを知らない人は、これらのものが何であるかも当然知りません。

ソフトウェアがしなければならないことの一部は、それ自身を説明することです。したがって、良いソフトウェアを書くには、ユーザーがどれほど理解していないかを理解する必要があります。彼らは何の準備もなくソフトウェアに近づいてくるでしょうし、マニュアルを読むつもりはないので、彼らが推測する通りに動作するべきです。この点で私がこれまで見た中で最高のシステムは、1985年の初代Macintoshでした。それはソフトウェアがほとんどしないことをしました。ただ、動作したのです。[6]

ソースコードもまた、それ自身を説明すべきです。もし私がプログラミングについてたった一つの引用だけを人々に覚えてもらえるとしたら、それは『計算機プログラムの構造と解釈』の冒頭にあるものです。

プログラムは人が読むために書かれるべきであり、機械が実行するのは付随的なことである。

ユーザーだけでなく、読者に対しても共感力を持つ必要があります。それはあなた自身の利益になります。なぜなら、あなたもその一人になるからです。多くのハッカーがプログラムを書き、半年後に戻ってみると、それがどう動くのか全く分からなくなっていることがあります。私はそのような経験の後、Perlをきっぱりやめた人を何人か知っています。[7]

共感力の欠如は知性と関連付けられ、一部の場所ではそれが流行のようになっているほどです。しかし、私は相関関係があるとは思いません。数学や自然科学では共感力を学ぶ必要なく良い成績を収めることができ、これらの分野の人々は賢い傾向があるため、二つの特性が関連付けられるようになりました。しかし、共感力が苦手な愚かな人々もたくさんいます。トークショーに質問の電話をかけてくる人々の話を聞いてみてください。彼らは尋ねたいことを非常に遠回しに尋ねるため、司会者が彼らのために質問を言い換えなければならないことがよくあります。

では、ハッキングが絵画や執筆のように機能するなら、それは同じくらいクールなのでしょうか？結局のところ、人生は一度きりです。どうせなら素晴らしいことに時間を費やすべきでしょう。

残念ながら、この質問に答えるのは難しいです。名声には常に大きな時間差があります。それは遠い星からの光のようなものです。絵画が今名声を得ているのは、500年前に人々が成し遂げた偉大な仕事のおかげです。当時、誰もこれらの絵画が今日私たちが考えるほど重要だとは思いませんでした。ウルビーノ公フェデリーコ・ダ・モンテフェルトロが、いつかピエロ・デラ・フランチェスカの絵画の中の奇妙な鼻の男として主に知られるようになるとは、当時の人々には非常に奇妙に思えたことでしょう。

ですから、ハッキングが今、絵画ほどクールに見えないことは認めますが、絵画自体もその全盛期には今ほどクールに見えなかったことを覚えておくべきです。

ある程度の確信を持って言えるのは、今はハッキングの全盛期であるということです。ほとんどの分野で、偉大な仕事は初期に行われます。1430年から1500年の間に描かれた絵画は、今なお比類がありません。シェイクスピアはプロの演劇が誕生したばかりの頃に現れ、その媒体を非常に遠くまで押し進めたため、それ以来すべての劇作家は彼の影に生きなければなりませんでした。アルブレヒト・デューラーは版画で、ジェーン・オースティンは小説で同じことをしました。

私たちは何度も同じパターンを目にします。新しい媒体が登場し、人々はそれに非常に興奮し、最初の数世代でその可能性のほとんどを探求します。ハッキングは今、この段階にあるようです。

レオナルドの時代、絵画は彼の作品がそれを助けたほどクールではありませんでした。ハッキングがどれほどクールになるかは、この新しい媒体で私たちが何ができるかにかかっています。

注釈

[1] 写真が絵画に与えた最大のダメージは、最高の昼の仕事を奪ったことかもしれません。歴史上の偉大な画家のほとんどは、肖像画を描くことで生計を立てていました。

[2] Microsoftは従業員が余暇であってもオープンソースプロジェクトに貢献することを推奨していないと聞きました。しかし、今では多くの最高のハッカーがオープンソースプロジェクトに取り組んでいるため、この方針の主な効果は、彼らが一流のプログラマーを雇えなくなることを確実にすることかもしれません。

[3] 大学でプログラミングについて学ぶことは、本や服やデートについて学ぶこととよく似ています。それは、高校時代にどれほどひどいセンスをしていたかということです。

[4] ここに応用された共感力の例があります。Viawebでは、二つの選択肢の間で決められない場合、「競合他社が最も嫌がることは何か？」と自問しました。ある時、競合他社が基本的に無用な機能をソフトウェアに追加しましたが、それが私たちにはない数少ない機能の一つだったので、彼らは業界誌でそれを大々的に宣伝しました。私たちはその機能が無用であることを説明しようとすることもできましたが、自分たちで実装した方が競合他社をより苛立たせるだろうと判断し、その日の午後に独自のバージョンを急いで作り上げました。

[5] テキストエディタとコンパイラは例外です。ハッカーはこれらを設計するのに共感力を必要としません。なぜなら、彼ら自身が典型的なユーザーだからです。

[6] まあ、ほとんどですが。利用可能なRAMをいくらか超えてしまい、不便なディスクスワッピングを多発させましたが、これは数ヶ月以内に外付けディスクドライブを購入することで解決できました。

[7] プログラムを読みやすくする方法は、コメントで埋め尽くすことではありません。私はアベルソンとサスマンの引用をさらに一歩進めたいと思います。プログラミング言語はアルゴリズムを表現するために設計されるべきであり、コンピュータにそれをどう実行するかを伝えるのは付随的なことです。良いプログラミング言語は、英語よりもソフトウェアを説明するのに優れているべきです。コメントが必要なのは、読者に警告する必要がある何らかの「ごまかし」がある場合だけです。ちょうど道路に、予期せぬ急カーブがある部分にだけ矢印があるように。

謝辞本稿の草稿を読んでくれたTrevor Blackwell、Robert Morris、Dan Giffin、Lisa Randall、そして講演に招いてくれたHenry Leitner、Larry Finkelsteinに感謝します。