これは、Paul Graham：Hackers and Painters を、原著者の許可を得て翻訳・公開するものです。
<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2003 by Paul Graham
原文: http://www.paulgraham.com/hp.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)
<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
邦訳版が出版されました。
出版社の案内ページ
Amazon.co.jp
サポートページ
2003/05/16 翻訳公開
2003/05/20 武井伸光氏より誤記の訂正を頂き、反映
(このエッセイはハーバード大学での特別講義と、 それに先立つノースイースタン大学での講演を基にしている)。
大学院で計算機科学を専攻した後、 私は絵画を学ぶためにアートスクールに入った。 コンピュータに興味を持つような人間が絵を描くことにも 興味を持つと聞いて、驚く人も多い。 どうやら、ハッキングと絵を描くことは全然違うものだと 思われているらしい。ハッキングは冷たく、精密で、几帳面なものであるのに対し、 絵を描くことは、なにか原始的な衝動に駆られた表現だと考えられているようだ。
そのイメージはどちらも正しくない。 ハッキングと絵を描くことにはたくさんの共通点がある。 実際、私が知っているあらゆる種類の人々のうちで、 ハッカーと画家が一番良く似ている。
ハッカーと画家に共通することは、どちらもものを創る人間だということだ。 作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、 良いものを創るということだ。 良いものを創ろうとする過程で新しいテクニックを発見することがあり、 それはそれで良いことだが、いわゆる研究活動とはちょっと違う。
私は「計算機科学」という用語がどうにも好きになれない。 いちばん大きな理由は、そもそもそんなものは存在しないからだ。 計算機科学とは、ほとんど関連のない分野が歴史的な偶然から いっしょくたに袋に放り込まれたもので、言ってみればユーゴスラビアみたいなものだ。 一方の端では、ほんとうは数学者である人々が、DARPAの研究費を得るために 計算機科学を名乗っている。 真ん中あたりでは、コンピュータの博物学みたいなことをやっている人々がいる。 ネットワークのルーティングアルゴリズムの振舞いを調べたりとか、そういうことだ。 そして、反対側の端っこには、ハッカー達がいる。 面白いソフトを書こうとしている者達だ。彼らにとっては、 コンピュータは単なる表現の媒体にすぎない。 建築家にとってのコンクリートが、また画家にとっての絵の具がそうであるように。 これはまるで、数学者と物理学者と建築家をひとつの学科に押し込めているみたいだ。
ハッカーがやっていることは「計算機工学」と呼ばれることもあるが、 この用語も誤解を助長するだけだ。 優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、 エンジニアではない。 もちろん建築とエンジニアリングの境界ははっきりと定められているわけじゃないけれど、 確かに存在する。それは、「何を」と「どうやって」の間にある。 建築家は何をするかを決め、エンジニアはそれをどうやってするかを考え出すのだ。
「何を」と「どうやって」をあまり分けすぎるのは良くない。 どうやれば出来るかを理解せずに何をするかを決めようとするのは、 間違いのもとだ。 でも、ハッキングには確かに、ある仕様をどうやって実装するか決めること以上の ものがある。ハッキングの最良の形態とは、仕様を創ることだ--- ただ、仕様を創るいちばんの方法はそれを実装することだ、ということに過ぎない。
たぶん「計算機科学」は、ユーゴスラビアがそうなったように、 いつかそれを構成している部分ごとにばらばらになるだろう。 それは良いことなんだろうと思う。特に、それが私の故郷でもある、ハッカー国の 独立を意味するのなら。
これらの全然違う業種を一つの学科にまとめておくのは、 管理する側にとっては便利なのかもしれないが、 知的な混乱をもたらす。 「計算機科学」という言葉を私が嫌うもうひとつの理由がそれだ。 真ん中にいる人々は、まあ実験科学をやっていると言えなくはないかもしれない。 しかし両端にいる人々、ハッカーと数学者は、科学をやっているわけじゃないんだ。
数学者はきっとそんなことは気にしないだろう。 彼らは、数学科の数学者達と同じように定理を証明することに夢中になって、 自分のいる建物に「計算機科学」の看板が付いていることなど たぶんすぐに忘れてしまう。でもハッカーにとってはこの看板は問題になる。 科学と呼ばれると、ハッカー達は科学的にふるまわなくちゃならないような 気になってしまう。そして、大学や研究所にいるハッカー達は、 彼らが本当にやりたいこと、つまり美しいソフトウェアをデザインすることではなしに、 研究論文を書かなくちゃいけないような気になってしまうんだ。
運がよければ、論文は形を整えるためだけのもので済むだろう。 ハッカーはクールなソフトを書いて、そしてそれについての論文を書く。 そういう論文は、ソフトウェアそのものによって示されるべき作品の、代理となる。 でも、このミスマッチは往々にして問題となる。 美しいものを創るのではなしに、 醜いけれど論文の題目にはなりやすいものを造るほうにひきこまれてしまうのはたやすい。
残念なことに、美しいものは論文になりやすいとは限らない。 第一に、研究は独創的でなければならない--- そして、博士論文を書いた経験のある人なら誰もが知っているように、 あなたが処女地を開拓していることを保証する一番良い方法は、 誰もやりたがらないような場所へ向かうことだ。 第二に、研究にはたっぷりとした量がなければならない--- そして、妙ちきりんなシステムであるほど、たくさんの論文が書ける。 そいつを動かすために乗り越えなければならなかったいろんな障害に ついて書けるからね。 論文の数を増やす最良の方法は、間違った仮定から出発することだ。 AI研究の多くはこの規則の良い例だ。 知識が、抽象概念を引数に取る述語論理式のリストで表現できる、 と仮定して始めれば、それを動かすためにたくさんの論文を書くことになるだろう。 リッキー・リカルドが言ったように、 「ルーシー、君はたくさん説明することがあるね」ってなわけだ。
何か美しいものを創るということは、 しばしば既にあるものに微妙な改良を加えたり、 既にある考えを少しだけ新しい方法で組み合わせたりすることによって なされる。この種の仕事を研究論文にするのはとても難しい。
じゃあ、大学や研究所はどうしてハッカーを論文数で判断しようとするんだろうか。 「学習への適性」が、考えの狭い、規格化されたテストで測られたり、 プログラマの生産性がコードの行数で測られるのと同じ理由だ。 これらのテストは簡単に適用できる。 そして、簡単に適用できてとりあえず使えるテストほど便利なものはない。
ハッカーが実際にやろうとしていること、すなわち美しいソフトウェアを デザインするということを測るのは、ずっと難しい。 良いデザインを判断するためには、 デザインに対する良いセンスが必要だ。 ある人が良いデザインを認識する能力と、 その人が良いデザインを認識できると考えている自信の間には、 何の相関もないか、あったとしても、負の相関しかないだろう。
唯一の外部のテストは時間だ。 時間がたてば、美しいものは生き残り、醜いものは次第に捨てられてゆくだろう。 それにかかる時間は、残念ながら、人間の一生よりも長い。 サミュエル・ジョンソンは、作家の評価が収束するまでには100年かかると言った。 作家の影響下にあった友人達が死に、さらにそれらの追従者達が死に絶えるのを 待たねばならないからだ。
ハッカーは、自分の評価の中にランダムな要素がたくさんまぎれこむことを甘受しなければ ならないだろう。その点では、他のもの創りの人々と変わらない。 むしろ、他のもの創りよりも幸運かもしれない。 ハッキングに対する流行の影響は、絵画に対するそれ程には大きくないからだ。
人々があなたの仕事を誤解するよりも悪いことがある。 より大きな危険は、あなた自身が自分の仕事を誤解することだ。 アイディアを探す時、人は関連した分野を見にゆく。 あなたが計算機科学科にいたとしたら、 ハッキングは理論計算機科学に対する応用だとか思ってしまうかもしれない。 私は大学院にいた頃ずっと、もっと理論を知らなくちゃならないという思いが 心の底にあって、居心地の悪い思いをしていた。 期末試験から3週間後にはすっかり全部忘れてしまうことをずいぶん後ろめたく思ったものだ。
でも、私は間違っていたんだ。 ハッカーは、画家が絵の具に関する化学を理解するのと同程度に 計算理論を理解していればいい。 時間的、および空間的な複雑度の計算法と、チューリング完全の概念については 知る必要があるだろう。それから、パーザや正規表現ライブラリを 書くことになった時のために、状態機械の概念は少なくとも覚えておいた方が いいかもしれない。 実は、画家はそんなことよりもっとずっとたくさんのことを、 絵の具に関する化学で覚えなければならないんだ。
私は、アイディアの最高の源は、「コンピュータ」が名前についている分野じゃなくて、 ものを創る人々が住んでいる他の分野にあるということを知った。 絵画は計算理論よりもずっと豊富なアイディアを提供してくれたんだ。
例えば、大学で私は、コンピュータに手を触れる前に 紙の上でプログラムを完全に理解しなければならないと教わった。 でも私はそういうふうにはプログラムできなかった。 私が好んだやりかたは、紙の前ではなく、コンピュータの前に座って プログラミングすることだった。もっと悪いことに、 辛抱強く全てのプログラムを書き上げて正しいことを確認するなんてことは せずに、私はめちゃくちゃなコードをおっぴろげて、 それを次第に形にしてゆくのだった。 私が教わったのは、デバッグとは書き間違いや見逃しをつかまえる 最終段階の工程だということだったが、 実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。
随分長い間、私はそのことを後ろめたく思っていたものだ。 ちょうど、小学校で教わった鉛筆の持ち方と違う持ち方をしていることを 後ろめたく思っていたのと同じように。 他のものを創る人々、画家や建築家がどうやっているかを見れば、 私は自分のやっていることにちゃんと名前がついていると気づいていただろう。 スケッチだ。 私が言えるのは、大学で教わったプログラミングのやりかたは全部間違っていた ということだ。 作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、 プログラマはプログラムを書きながら理解してゆくべきなんだ。
この気づきは、ソフトウェアの設計に大きな意味を持つ。 まず何よりも、これはプログラミング言語は柔軟でなければならないということを意味する。 プログラミング言語はプログラムを考えるためのものであって、 既に考えたプログラムを書き下すためのものじゃない。 それはペンではなく鉛筆であるべきなんだ。 静的な型付けは、私が大学で教わったようにプログラムするなら良い考えだと 思う。でも私の知るハッカー達はそんなふうにはプログラムしない。 我々に必要なのは、落書きしたりぼかしたり塗りつぶしたりできる 言語であって、型の紅茶茶碗を膝に置きながら 厳しいコンパイラおばさんと丁寧な会話をするような言語じゃない。
静的型付けの話が出たついでに、もうひとつ、 我々が科学から受けている問題で、 もの創りの人々を見ることで避け得るものを挙げておこう。 数学に対する妬みだ。 科学にかかわる人は誰しも、数学者は自分より賢いという思いを密かに抱いている。 数学者さえもそう信じているんじゃないかと思う。 結果として科学者達は、程度の差こそあれ、自分の仕事をなるべく 数学っぽく見せようとしがちだ。 物理学のような分野ではこのことはたいして悪影響を及ぼさないだろう。 しかし自然科学から離れれば離れるほど、これはより大きな問題となってくる。
数式で埋め尽くされたページは、それはそれはカッコ良く見える。 (ヒント：もっとカッコ良くしたければ、ギリシャ文字を使うといい)。 だから、重要な問題なんかよりも、形式的に扱える問題の方に 取り組みたいっていう誘惑はとても強い。
ハッカーを、作家や画家といった他のもの創りと同列に 並べて考えるなら、そんな誘惑は感じないだろう。 作家や画家は数学を妬んだりしない。 全然関係ないものだと感じるだろう。ハッカーもそう感じるべきだと、私は思う。
大学や研究所がハッカーに本当にやりたいことをやらせてくれないと したら、企業にゆくしかないのだろうか。 不幸なことに、多くの企業はやっぱりハッカーにやりたいことを やらせてはくれない。大学や研究所はハッカーに 科学者たることを強要するが、企業はハッカーに エンジニアたることを強要するからだ。
私はこのことにはごく最近になるまで気づかなかった。 YahooがViawebを買収した時、彼らは私に何をやりたいか尋ねた。 私はビジネスのことには全然興味がなかったので、ハックしたいんだと答えた。 Yahooに入ってみたら、彼らにとってハックするということは ソフトウェアを実装するということで、デザインするということではないということが わかった。プログラマは、プロダクトマネージャのビジョン とかいったものをコードへと翻訳する技師とみなされていたのだ。
どうも、大企業ではそれが普通らしい。 そういうふうにすれば、出力のばらつきを押えることができるからだ。 ハッカーのうち実際にソフトウェアをデザインできる能力のある人間はほんのひと握りであって、 企業を経営している人々が彼らを見つけ出すのはとても難しい。 だから多くの企業では、 ソフトウェアの未来を一人の素晴らしいハッカーに託すのではなく、 委員会によって設計し、ハッカーはそれをただ実装するだけという 仕組みを作るんだ。
あなたがいつか金持ちになりたいと思っているなら、このことを 覚えておくといい。何故ならこれは、ベンチャー企業が勝つ理由の一つだからだ。 大企業が出力のばらつきを押えたがるのは、被害を避けたいからだ。 でも振動を抑制すれば、低い点は消えるけれど高い点も消えてしまう。 大企業ではそれは問題じゃない。大企業はすごい製品を作ることで勝つわけじゃないからだ。 彼らは他の企業よりも下手を打たないことで勝つ。
だから、ソフトウェアがプロダクトマネージャ達によって設計されるような 大企業とデザインで勝負する方法を見付ければ、彼らは絶対あなたには勝てない。 でもそういう機会を見付けるのは簡単ではない。 大企業をデザインでの勝負の土俵に引っ張り出すのは、 城の中にいる相手に一対一の勝負を承知させるのと同じくらい難しい。 例えば、マイクロソフトのWordより良いワードプロセッサを書くのは たいして難しくないだろうが、 独占OSの城の中にいる彼らは、おそらくあなたがそれを書いたことに気づきさえしないだろう。
デザインで勝負する良い場所は、誰も防衛を確立していない 新しいマーケットだ。そこでならあなたは、 大胆なアプローチによるデザインと、 そして同一人物がデザインと実装を受け持つことで、 大きく勝つことができる。 マイクロソフトだって最初はそこから始まったんだ。 アップルもそうだし、ヒューレットパッカードもそうだ。 恐らくどんな成功したベンチャーもそうだと思う。
だから、すごいソフトを書く方法のひとつは、自分でベンチャーを作ることだ。 でもそれにはふたつ問題がある。 一つは、ベンチャーを作ると、ソフトを書く以外のことをたくさん やらなくちゃならないということだ。Viawebでは、私は1/4の時間をハッキングに 使えたらラッキーという始末だった。そして3/4の時間に私が しなくちゃならなかったことはといえば、うんざりするかぞっとするような ことばかりだった。これにはベンチマークがある。 一度私は虫歯を治すために取締役会を抜けなくちゃならなくて、 歯医者の椅子に座ってドリルが近付いてくるのを待ちながら、 なんて素晴らしい休暇だと感じたものだ。
ベンチャーの問題のもうひとつは、 書くのが面白いソフトが金になるソフトであるということが 滅多にないということだ。 プログラミング言語を書くのは面白いし、 実際、マイクロソフトの最初の製品はそれだったわけだが、 今となっては誰もプログラミング言語には金を出さない。 金を儲けようと思ったら、誰もただではやりたがらないような 危険な問題に取り組まざるを得なくなる。
実は、これはものを創る人なら誰しも直面する問題だ。 価格は需要と供給で決まる。やっていて面白い仕事には、 顧客のありふれた問題を解決するような仕事ほどには需要がない。 オフブロードウェイで役者をしていても、 トレードショウのブースでゴリラの着ぐるみを着るほどには稼げない。 小説を書くよりは、ゴミ箱の宣伝文句を書く方が金になる。 そして、プログラミング言語をハックしていても、 顧客企業の古いデータベースとそこのWebサーバをどうやってつなげるかを 考えるほどの金にはならないというわけだ。
ソフトウェアに関しての、この問題への解答は、 実は他のもの創りの人々には既に知られている。昼間の仕事というやつだ。 この言葉はミュージシャンの間から始まった。彼らは夜に演奏するからだ。 より一般的に言えば、金のために一つの仕事を、愛のためにもう一つの仕事をする ということだ。
ほとんど全ての、ものを創る人達は、駆け出しの頃には昼間の仕事を 持っていた。画家と小説家は特にそうだ。 運が良ければ、本当の仕事と関係が深い昼間の仕事を見付けることができるだろう。 ミュージシャンはよくレコード店で働いている。 プログラミング言語やOSをハックしているハッカーは、 それらを使う昼間の仕事を見付けることができるかもしれない[1]。
昼間の仕事を持ち、美しいソフトウェアを別の時間に書くということが ハッカーへの答えだ、というのは、別に新しいアイディアじゃない。 オープンソースのハッキングとはまさにこれだ。 私が言いたいのは、オープンソースのモデルは多分正しい、なぜなら そのモデルは他のもの創りの人々によって独立して確かめられているからだ、ということだ。
雇用しているハッカーがオープンソースプロジェクトに関わるのを いやがる企業があるというのは、私にとっては驚きだ。 Viawebでは、我々はむしろそういうプロジェクトに関わっていない 人を雇うのを避けたものだ。 プログラマを面接する時、我々が主に知りたかったのは、応募者が 余暇にどんなプログラムを書いているかということだった。 何かに愛がなければ、それを本当にうまくやることはできないし、 ハックに愛があれば、いずれ自分のプロジェクトを立ち上げずにはおれないからだ [2]。
ハッカーは科学者よりももの創りに似ているのだから、 メタファーを探すのは科学者よりも他のもの創りの分野からの方が良い。 絵を描くことは、ハッキングに対して他にどんなことを教えてくれるだろうか。
絵画の例からひとつ学べること、少なくとも確認できることは、 ハックをどうやって学んだら良いかということだ。 絵を描くことは、絵を描きながら学ぶ。 大抵のハッカーは、大学のプログラミングコースを履修してハックを 学ぶのではない。13歳の頃から自分でプログラムを書くことによって 学ぶのだ。大学の講義でだって、ハックを学ぶのはハックしながらだ[3]。
画家は自らの後に作品による足跡を残してゆくから、 彼らが絵を描きながら学んでゆく様子を観察することができる。 画家の作品を時間順に並べてみれば、それぞれの絵は その前の絵で学んだことの上に創られていることがわかるだろう。 絵画上でうまくいったものがある時、通常はそれより前の作品群の 中に、より小さな形での第1版を見て取ることができる。
多くのもの創りは同じだと思う。作家と建築家はそうだ。 ハッカーも、たぶん、画家と同じようにふるまうのがいいんじゃないかと思う。 一つのプロジェクトを何年も続けて、新しいアイディアを 新バージョンとして取り込むのではなしに、 時々はゼロから始めてみるんだ。
ハッカーがハックしながら学ぶという事実は、 ハッキングと科学がどれだけ違うかということを示すもう一つの手がかりだ。 科学者は科学をしながら学ぶのではない。 実験と課題をこなしながら学ぶのだ。 科学者は、まず完璧な仕事から始める；つまり、 誰か他の人が既にやったことを再現することから始める。 そうしているうちに、独自の仕事が出来るレベルに達するのだ。 一方、ハッカーは、最初から独自の仕事をする。 ただ、最初はへたくそだろう。ハッカーはオリジナルから始め、上手になってゆく。 科学者は上手になることから始め、オリジナルになってゆく。
もの創りが学ぶもうひとつの方法は例から学ぶことだ。 画家にとっては、美術館は技法の例の宝庫だ。 何百年もの間、偉大な画家の作品を模写することは、 画家の教育過程の一環となってきた。 模写することで、絵がどのように描かれているかを 詳しく見るようになるからだ。
作家も同じことをする。 ベンジャミン・フランクリンはアディスンとスティール[訳註1]の エッセイを要約し、それを再現しようとすることで書くことを学んだ。 レイモンド・チャンドラーは同じことを探偵小説でやった。
ハッカーも同じように、良いプログラムを見ることで プログラムを学ぶことができる。プログラムの動作を見るだけでなく、 ソースコードを見ることでもだ。 オープンソース運動の、あまり宣伝されないひとつの利点は、 プログラムを学ぶことを容易にするということだ。 私がプログラムを学んだ頃は、本にある例に頼るしかなかった。 当時、ソース見ることができた一つの大きなソフトウェアはUnixだったが、 それでさえオープンソースではなかった。 Unixのソースコードを読んだ人の多くはジョン・ライアンスの不正なコピー本[訳註2]で 読んだのではないか。その本は1977年に書かれたが、 1996年まで出版を許可されなかった。
絵画から学べるもうひとつの例は、 次第に詳細化しながら創ってゆく方法だ。 絵画はたいてい、スケッチから始まる。 そして次第に細かい部分が埋められてゆく。 だがそれは、単に隙間を埋めてゆくだけの過程ではない。 ときには元の計画が間違いだったことが分かることもある。 X線で見てみると、 手や足の位置が動かされたり表情が変えられたりしている絵画は 数え切れないくらいある。
この点で絵画から学ぶことができる。 私はハッキングもそうあるべきだと思う。 プログラムの仕様が完璧であるなんて期待するのは非現実的だ。 そのことをまず最初に認めて、 仕様がプログラムを書いている最中に変わっていっても、 それを受け入れられるような書き方をすべきなんだ。
(大企業の構造にはこれをやりにくくさせるものがあり、 これもベンチャー企業に利する点だ)。
今となっては誰もが、早過ぎる最適化の危険を承知しているだろう。 私は、同様に早過ぎる設計、つまりプログラムが何をすべきかを早く決めすぎること、 にも気をつけるべきだと思う。
正しい道具はこの危険を避けるのを助けてくれる。 良いプログラミング言語は、油絵のように、変更を簡単にしてくれる。 その点では動的な型付けの方が有利だ。 最初から特定のデータ表現にコミットする必要が無いからだ。 しかし、柔軟性について最も重要な点は、 言語をなるべく抽象的にしておくことだ。 プログラムが短ければ、変更もしやすかろう。
もうひとつ、これは矛盾しているように聞こえるかもしれないが、 偉大な絵画とは、それ自身があるべき姿よりも優れているはずだ。 例えば、レオナルド・ダ・ヴィンチがナショナルギャラリーにある ジネヴラ・ベンチ の肖像画を書いた時、彼は人物の後ろに杜松の潅木を配置した。 絵の中で彼は、松の葉を一枚一枚、注意深く描いた。 他の多くの画家だったら、これは単に人物の背景を埋めるだけのものだと 考えたかもしれない。誰もそんなにそれを注意深く見ることはしないだろうと。
レオナルド・ダ・ヴィンチは違った。 彼にとって、絵のある部分にどれだけ手間をかけるかは、誰かがそこを見るかどうかには 関係なかったのだ。彼はマイケル・ジョーダンと同じだ。妥協しないんだ。
見えない細部は、それが組合わさると、見えるようになる。 妥協しないことはこの点で重要だ。 ジネヴラ・ベンチの肖像画の横を通りかかった人々は、 すぐにその絵に気を止める。絵のラベルを見てそれが レオナルド・ダ・ヴィンチによるものだと知るより前からだ。 全ての見えない細部が組合わさることにより、 まるでほとんど聞こえないかぼそい声が幾千も合わさって一つの旋律を歌っているかのように、 ある種圧倒される何かが創られる。
偉大なソフトウェアも、同じように、美に対する熱狂的な没頭が必要だ。 良いソフトウェアの中身をみてみれば、誰も見ないような箇所でさえ 美しく創られていることがわかるだろう。 私は自分が偉大なソフトウェアを書いているなんていうつもりはないが、 少なくともコードを書く時には、それと同じ調子で日常生活を送ったら 医者から薬を支給されるだろうな、というような調子で書いている。 めちゃくちゃにインデントされたコードとか、ひどい変数名を見ると 気が狂いそうになる。
ハッカーが単なる実装者で、仕様をコードに直しているだけなら、 溝を掘る作業者みたいに端から別の端まで順番に仕上げてゆくだろう。 でもハッカーが創造者ならば、インスピレーションを考えに入れなければならない。
ハッキングには、絵を描く時と同じように、周期がある。 ある時は新しいプロジェクトに夢中になって、1日16時間それを やり続ける。別の時には何も面白いと感じられない。
良い仕事を為すには、この周期を勘定に入れておかなくてはならない。 そうすることによって、周期にどう対応すれば良いかがわかるからだ。 マニュアル車で坂を登る時は、時々クラッチを戻してやらないとエンストしてしまう。 同じように、時々引いてみることは、熱意が止まってしまうのを防ぐのに良い方法だ。 絵画にもハッキングにも、恐ろしいほど無謀な試みもあれば、 楽にこなせる作業もある。エンストしてしまいそうな時のために、 楽な作業を少し取っておくことは良いアイディアだろう。
ハッキングの場合は、バグを取っておくことでやってもいい。 私はデバッグが好きだ。デバッグは、普通の人がハッキングと聞いて連想するもの そのものだ。完全に制約された問題があり、やるべきはそれを解くことだけ。 プログラムはxをするはずなのに、yをしている。 どこでおかしくなっているんだろう? あなたは最終的に勝利を収めることを知っている。 これはまるで、壁を塗っている時くらい、気楽なことだ。
絵画の例は、自分の仕事をどう管理したら良いかを教えてくれるだけでなく、 どうやって他の人と一緒に仕事をしたら良いかも教えてくれる。 過去のたくさんの偉大な芸術は、たとえ美術館での展示には一人しか 名前を挙げられていなくても、実際は複数の人間によって創られた。 レオナルド・ダ・ヴィンチはヴェロッキオの工房の見習いであったことがあり、 彼のキリストの洗礼の 中の天使の一人を描いた。 こういったことは例外ではなく、むしろ慣例と見なされていた。 ミケランジェロがシスティーナ礼拝堂の天井画の全ての像を自分自身で描くと 主張した時、人々は彼のあまりの熱意に驚きさえしたのだ。
私の知る限り、複数の画家が一枚の絵に取り組む時、 決して二人以上が同じ箇所を描くことはない。 親方が主要人物を描き、助手が他の人物と背景を描くというのはよく行われていた。 しかし、ある画家が別の画家の描いた上に描き足すということは決して無かった。
ソフトウェアにおける協調開発でも、これは正しいモデルだと思う。 協調ということをあまり押し出しすぎないことだ。 あるコードが、特定の所有者を決めずに3人も4人もの人間にハックされると、 それは共有部屋のようになる。 雑然としていて見捨てられたような雰囲気がただよい、 埃が積もってゆく。 私が思うに、協調開発の正しい方法は、プロジェクトをはっきりと定義された モジュールに分割し、各モジュールの所有者を決め、 そして注意深く、できればプログラミング言語そのもの程に明快に 設計されたインタフェースをモジュール間に定めることだ。
絵画と同様、ソフトウェアも多くは人間が見て、使うものだ。 だからハッカーも、画家と同じように、ほんとうにすごい仕事を為すには、 共感する力が必要だ。 ユーザの視点からものを見られるようにならなくちゃいけない。
私は子供の頃、いつも、人の身になってものを考えなさいと教えられた。 実際にはそう言われる時はいつでも、自分のしたいことじゃなくて 他人の望むことをしなさい、という意味だった。 だから共感なんてつまらないものだと思って、私はそれを磨こうとはしなかった。
だが、なんてこった。私は間違っていたんだ。 他人の身になってものを見るというのは、本当は成功する秘密だったんだ。 それは自己犠牲を意味するとは限らない。他の人のものの見方を理解することは、 あなたがその人の利益のために行動しなくちゃならないということには 関係ないんだ。特定の状況では、例えば戦争をしている時は、 まったく逆の行動をしたいと思うだろう[4]。
多くのもの創り達は、人間に観られ、受け取ってもらえるものを創る。 観客をひきつけるには、観客が何を必要としているかを理解しなくちゃならない。 偉大な絵画作品はほとんど全て人物を描いているが、 それは人物こそ、人々が興味を持つものだからだ。
共感能力は、おそらく良いハッカーと偉大なハッカーの、 たった一つの最も重要な違いだろう。 ハッカーの中には非常に賢いが、共感するということにかけては 全く自己中心主義の人々がいる。 たぶんそういう人が偉大なソフトウェアをデザインするのは難しいだろう[5]。 ユーザの視点でものを観ることができないからだ。
共感能力の良さをみるひとつの方法は、その人が 技術的知識の無い誰かに技術的な問題を説明する様子を観ることだ。 たぶん、他の点では優れているのに、そういう説明になると滑稽なくらいへたくそな 人を、誰でも知っているんじゃないか。 ディナーパーティで、誰かにプログラミング言語って何なの、 と尋ねられると、そういう人はたとえばこんなふうに言うだろう。 「高級言語とは、コンパイラがそれを読んでオブジェクトコードを生成するような ものさ。」 高級言語? コンパイラ? オブジェクトコード? プログラミング言語とは何かを知らない人が、 こういう用語を知っているわけがないじゃないか。
ソフトウェアがやらなければならないことのひとつに、 自分自身を説明するということがある。 だから、良いソフトウェアを書くには、ユーザがどれだけ何も知らないかという ことを理解する必要がある。 ユーザは何の準備もなくやって来て、いきなりソフトウェアに向かい、 マニュアルなんか読もうともしないだろうから、 ソフトウェアはそういう人が期待するように振舞うのが良い。 この点で、私が知っている最高のシステムは、1985年当時の、オリジナルのMacintoshだ。 それは他のほとんどのソフトウェアが決して為し得なかったことを為した。 何もしないでも、ちゃんと動いたのだ[6]。
ソースコードもまた、自分自身を説明すべきだ。 プログラミングに関して皆に一つだけ引用文句を覚えてもらえるならば、 私は「計算機プログラムの構造と解釈」の冒頭のこの文を選ぶ。
プログラムは、人々がそれを読むために書かれるべきである。 たまたま、それが計算機で実行できるにすぎない。ユーザに対する共感だけでなく、コードを読む人に対する共感も必要だ。 それはあなた自身のためでもある。あなた自身もあなたのコードの読者だからだ。 6ヵ月前に自分の書いたプログラムを見て、それが何をするのか全くわからない という経験をした人も多いだろう。何人か、そういう経験を経て 断Perl宣言をした人を私は知っている[7]。
共感能力の欠如は知性と関連づけられることがある。 時にはそう振舞うことがひとつの流行とされることまである。 でも、私は共感能力の欠如と知性の間には何の相関も無いと思う。 共感能力が無くても数学や自然科学で高い能力を発揮することはできるし、 そういう分野にいる人は一般に賢いから、 知性が共感能力の欠如と関係あるかのように思われるのだろう。 実際は、賢くもなく、共感するのもうまくない人だってたくさんいる。 トークショーに電話をかけて質問してくる人々の会話を聞くだけでいい。 彼らは話をあっちこっちに飛ばして言いたいことを言うから、 ホストがわざわざそういう人のために質問を言い直してやらなくちゃ ならないことが往々にしてある。
さて、ハッキングが絵を描くことや小説を書くことと同じだとして、 それはクールだろうか。結局のところ、あなたには一回の人生しか与えられていない。 他のすごいことに人生を使った方がいいかもしれないじゃないか。
残念ながら、この問題に答えるのは難しい。 名声は大きく遅れてくるのが常だ。まるで遠くの星から届く光のように。 絵画は現在ではたいそう重く見られているが、 それは500年前に偉大な画家達が活躍したからだ。 彼らが活躍していた当時は、誰もそれを、今我々が考える程に重要だとは 思っていなかった。当時の人々は、 ウルビーノのフェデリーコ・ダ・モンテフェルトロ公が、 ピエロ・デッラ・フランチェスカの描いた 絵の 奇妙な鼻を持つ男、として知られる日が来ると聞いたら、ずいぶん変に思ったに違いない。
だから、ハッキングが現在、絵を描くことほどクールには思えないとしても、 絵画の栄光の時代に絵を描くことは今ほどクールに思われていなかったという ことを気に止めておく必要があるだろう。
いくばくかの自信を持って言えることは、 いつか、ハッキングの栄光の時代が来るだろうということだ。 多くの分野で、偉大な仕事は、早い時期になされた。 1430年から1500年の間に描かれた絵画は未だに他の追従を許さない。 シェークスピアは、職業としての芝居が生まれつつある時期に現れ、 そのメディアをあまりに深くまで追求したために、 その後の脚本家はすべて、彼の影の中に生きることを強いられた。 アルブレヒト・デュラーは版画で、 ジェーン・オーステンは小説で同じことをした。
繰り返し繰り返し、同じパターンが見られる。 新しいメディアが現れ、それに熱狂した人々が、 最初の2世代くらいの間にそのメディアの可能性のほとんどを探求し尽くしてしまう。 ハッキングはまさに、その段階にある。
レオナルド・ダ・ヴィンチの時代には、絵画はそれほどクールではなかったが、 彼の作品のおかげで後生ずっと重要視されるようになった。 ハッキングがどれだけクールになるかは、まさに我々がこの新しいメディアで 何ができるかにかかっている。 ある意味、クールさが遅れて来ることは利点だ。 今、コンパイラを書いていたりUnixカーネルをハックしている人に会ったとしたら、 その人が単にカワイ娘ちゃんにもてたくてやってるんじゃないことは確かだろう。
[1] 写真が絵画に及ぼした最悪の影響は、もしかすると それによって画家達の普段の仕事をなくしてしまったことかもしれない。 歴史の中の偉大な画家の多くは、肖像画を描くことで生計を支えていたからだ。
[2] マイクロソフトは、従業員がたとえ仕事以外の時間でも、 オープンソースプロジェクトへ貢献するのをよしとしていない、 という話を聞いたことがある。 だが、これほどたくさんの優秀なハッカー達がオープンソースプロジェクトに 参加するようになった今となっては、 そういった方針は、一流のプログラマを雇えないことを保証するにすぎないだろう。
[3] 大学でプログラミングについて学ぶということは、 読書や服装やデートについて学ぶことに似ている。 高校時代を振り返ってみたまえ。なんてセンスが無かったんだろう、って思わないか。
[4] 共感の応用例をひとつ挙げておこう。 Viawebで、二つの選択肢のどちらを選ぶか迷った時、 我々はいつも、競争相手にとってはどっちがより嫌だろうかを考えた。 ある時、ある競争相手が、基本的に使えない機能を彼らのソフトに付け足したことがあった。 ただ、その機能は彼らにあって我々に無い数少ないものだったから、 彼らはマスコミ相手にそれを盛んに宣伝した。 我々はその機能が使いものにならないということを説明することも出来ただろうが、 それよりむしろ、うちにも同じ機能をつけたほうが相手にダメージを与えられるだろうと 考え、その日の午後のうちに新しい機能を追加したんだ。
[5] テキストエディタとコンパイラは例外だ。 ハッカーはこれらを書くのに共感能力を必要としない。 典型的なユーザは自分自身だからだ。
[6] まあ、ほとんどは。時々はRAMを無駄使いして、 ディスクがスワップしつづけて不便な思いをした。 まあ、数ヵ月我慢して新しいディスクドライブを買えば解消できたが。
[7] プログラムを読みやすくする方法は、コメントを詰め込まないように することだ。私は、アーベルソンとサスマンの言葉をさらに進める。 プログラミング言語はアルゴリズムを表現するために設計されるべきで、 それがたまたま、コンピュータにとって実行できる形式になるにすぎない。 良いプログラミング言語は英語よりもうまくソフトウェアを説明することが できるべきだ。コメントは、読者が特に気を付けなければならない ある種のツギハギを警告するためだけに必要なはずだ。 ちょうど、道路で突然の急カーブを警告するためだけに矢印の標識が用いられるように。
この原稿の草稿に目を通してくれた Trevor Blackwell、Robert Morris、 Dan Giffin、 Lisa Randall、そして、私を講演に招いてくれた Henry LeitnerとLarry Finkelsteinに感謝します。
アディスンとスティール：Joseph AddisonとSir Richard Steele。 18世紀初頭の英国で、文芸雑誌"The Tatler" と "The Spectator" を発行した。 参考：Addison and Steele
John Lions' book: Lion's Commentary on UNIX 6th Edition, with Source Code