ハッカーと画家
Original2003年5月
（このエッセイは、ノースイースタン大学での以前の講演を組み込んだハーバード大学での特別講義から抜粋したものです。）
コンピュータサイエンスの大学院を終えた後、私は絵画を学ぶために美術学校に通いました。コンピュータに興味がある人が絵画にも興味を持つということに、多くの人が驚いたようです。彼らは、ハッキングと絵画はまったく異なる種類の仕事だと思っていたようです。ハッキングは冷徹で、正確で、計画的であり、絵画は何らかの原始的な衝動の狂乱的な表現である、と。
これらのイメージはどちらも間違っています。ハッキングと絵画には多くの共通点があります。実際、私が知っているさまざまなタイプの人々の中で、ハッカーと画家は最もよく似ている人々の 1 つです。
ハッカーと画家の共通点は、どちらも作り手であるということです。作曲家、建築家、作家と同じく、ハッカーと画家がやろうとしているのは、良いものを作ることです。彼らは研究そのものを行っているわけではありませんが、良いものを作ろうとする過程で新しい技術を発見すれば、それはさらに良いことです。
私は「コンピュータ サイエンス」という用語が嫌いです。嫌いな主な理由は、そのような用語が存在しないからです。コンピュータ サイエンスは、ユーゴスラビアのように、歴史上の偶然によってまとめられた、関連性の薄い分野の寄せ集めです。一方の端には、実際には数学者であるが、DARPA の助成金を得るために自分のやっていることをコンピュータ サイエンスと呼んでいる人々がいます。中間には、コンピュータの自然史のような研究をしている人々がいます。たとえば、ネットワークを介してデータをルーティングするためのアルゴリズムの動作を研究しています。そしてもう一方の極端には、興味深いソフトウェアを書こうとしているハッカーがいます。彼らにとって、コンピュータは、建築家にとってのコンクリートや画家にとっての絵の具のように、表現の媒体にすぎません。まるで、数学者、物理学者、建築家がすべて同じ学部にいなければならないかのようです。
ハッカーが行うことは「ソフトウェア エンジニアリング」と呼ばれることもありますが、この用語も誤解を招きやすいものです。優れたソフトウェア デザイナーは、建築家と同じくらいエンジニアではありません。建築とエンジニアリングの境界は明確に定義されていませんが、存在します。それは「何を」と「どのように」の間にあります。建築家は「何を」するかを決定し、エンジニアは「どのように」するかを考えます。
何をするか、どのようにするかをあまり分けて考えるべきではありません。やり方を理解しないまま何をするかを決めようとすると、トラブルを招くことになります。しかし、ハッキングは、ある仕様をどのように実装するかを決める以上のものであることは確かです。最良の方法は、仕様を作成することですが、それを実装することが最善の方法であることが判明しています。
おそらくいつか、「コンピュータ サイエンス」は、ユーゴスラビアのように、構成要素に分割されるでしょう。それは良いことかもしれません。特に、それが私の故郷であるハッキングの独立を意味するのであれば。
これらすべての異なるタイプの仕事を 1 つの部門にまとめるのは、管理上は便利かもしれませんが、知識的には混乱を招きます。これが、私が「コンピュータ サイエンス」という名前を好まないもう 1 つの理由です。中間にいる人々は、おそらく実験科学のようなものを行っています。しかし、両端にいる人々、つまりハッカーや数学者は、実際には科学を行っていません。
数学者たちは、このことに困惑しているようには見えない。彼らは、数学科の他の数学者たちと同じように、定理を証明する仕事に喜んで取り組み、おそらく、自分たちが働いている建物の外側に「コンピュータサイエンス」と書かれていることにすぐに気付かなくなるだろう。しかし、ハッカーたちにとって、このラベルは問題だ。自分たちのやっていることが科学と呼ばれれば、彼らは科学的に行動しなければならないと感じてしまう。だから、大学や研究室のハッカーたちは、本当にやりたいこと、つまり美しいソフトウェアを設計する代わりに、研究論文を書くべきだと感じるのだ。
最良の場合、論文は単なる形式的なものです。ハッカーはクールなソフトウェアを作成し、それについて論文を書きます。そして、その論文はソフトウェアによって表される成果の代理となります。しかし、この不一致が問題を引き起こすことがよくあります。美しいものを構築することから、研究論文のテーマとしてより適した醜いものを構築することへと流れていくのは簡単です。
残念ながら、美しいものが必ずしも論文の最高の題材になるわけではありません。第一に、研究は独創的でなければなりません。博士論文を書いたことがある人なら誰でも知っているように、未開の領域を探索していることを確認する方法は、誰も望んでいない領域を確保することです。第二に、研究は実質的でなければなりません。扱いにくいシステムの方が、物事を成し遂げるために克服しなければならない障害について書くことができるため、より充実した論文になります。間違った仮定から始めることほど、充実した問題を生み出すものはありません。AI のほとんどはこのルールの例です。知識は、引数が抽象概念を表す述語論理式のリストとして表現できると仮定すると、これを機能させる方法について書く論文が大量に必要になります。リッキー・リカードがよく言っていたように、「ルーシー、説明することがたくさんあるよ」
美しいものを作り出すには、既存のものに微妙な調整を加えたり、既存のアイデアを少し新しい方法で組み合わせたりすることがほとんどです。このような作業は、研究論文では伝えるのが難しいものです。
では、なぜ大学や研究室はハッカーを出版物で評価し続けるのでしょうか? 「学力」が単純な標準テストで測定されたり、プログラマーの生産性がコード行数で測定されたりするのと同じ理由です。これらのテストは簡単に適用でき、ある程度機能する簡単なテストほど魅力的なものはありません。
ハッカーが実際に何をしようとしているのか、つまり美しいソフトウェアを設計しようとしているのかを測定するのは、はるかに困難です。優れたデザインを判断するには、優れたデザイン感覚が必要です。そして、優れたデザインを認識する能力と、それを認識できるという自信との間には、負の相関関係がある可能性を除いて、何の相関関係もありません。
唯一の外的なテストは時間です。時間が経つにつれて、美しいものは栄え、醜いものは捨てられていく傾向があります。残念ながら、かかる時間は人間の寿命よりも長くなることがあります。サミュエル・ジョンソンは、作家の評判が収束するには 100 年かかると言いました。作家の影響力のある友人が亡くなり、その後、彼らの支持者が全員亡くなるまで待たなければなりません。
ハッカーは、自分の評判にランダムな要素がかなりあることを覚悟しなければならないと思います。この点では、他のクリエイターと何ら変わりません。実際、比較すると、ハッカーは幸運です。ハッキングにおけるファッションの影響は、絵画ほど大きくありません。
自分の研究を他人に誤解されるより悪いことがあります。もっと悪い危険は、自分自身が自分の研究を誤解することです。関連分野は、アイデアを探す場所です。コンピュータサイエンスの学部にいると、たとえばハッキングは理論コンピュータサイエンスの理論の応用版であると信じたくなるのは自然なことです。大学院にいた間ずっと、もっと理論を知っておくべきで、期末試験の 3 週間以内にそのすべてを忘れてしまったのは自分の怠慢だという不安な気持ちが心の奥底にありました。
今になって、自分が間違っていたことに気づきました。ハッカーが計算理論を理解する必要があるのは、画家が絵の具の化学を理解する必要があるのと同じくらいです。時間と空間の複雑さを計算する方法とチューリング完全性について知っておく必要があります。また、パーサーや正規表現ライブラリを書かなければならない場合に備えて、少なくとも状態マシンの概念を覚えておく必要があるかもしれません。実際、画家は絵の具の化学についてそれよりもずっと多くのことを覚えておく必要があります。
アイデアの最良の源は、名前に「コンピュータ」という言葉が含まれる他の分野ではなく、メーカーが活動する他の分野であることがわかりました。絵画は、計算理論よりもはるかに豊富なアイデアの源です。
たとえば、大学では、コンピュータに近づく前に、まず紙の上でプログラムを完全に理解すべきだと教えられました。しかし、私はそのようにプログラミングをしませんでした。紙ではなく、コンピュータの前に座ってプログラミングする方が好きだと気づきました。さらに悪いことに、私は根気よく完全なプログラムを書き出して正しいと確信するのではなく、どうしようもなく壊れたコードを吐き出して、徐々に形を整える傾向がありました。デバッグは、タイプミスや見落としを見つけるための最終段階のようなものだと教えられました。私のやり方では、プログラミングはデバッグで構成されているように思えました。
長い間、私はこれについて申し訳なく思っていました。小学校で教わった通りに鉛筆を持てなかったことを申し訳なく思ったのと同じです。他の製作者、画家、建築家に目を向けさえすれば、自分がやっていることには「スケッチ」という名前があることに気付いたでしょう。私が知る限り、大学でプログラミングを教わった方法はまったく間違っていました。作家や画家、建築家と同じように、プログラムを書きながら理解するべきです。
これを理解することは、ソフトウェア設計に現実的な意味を持ちます。つまり、プログラミング言語は、何よりも柔軟性を持つべきです。プログラミング言語は、プログラムを考えるためのものであり、すでに考えたプログラムを表現するものではありません。ペンではなく鉛筆であるべきです。静的型付けは、私が大学で教わった方法で実際にプログラムを書くのであれば、素晴らしいアイデアでしょう。しかし、私が知っているハッカーは誰も、そのようにプログラムを書きません。私たちに必要なのは、走り書きしたり、汚したり、塗り付けたりできる言語であり、膝の上に型の入ったティーカップを乗せて座り、厳格なコンパイラーのおばさんと丁寧な会話をしなければならないような言語ではありません。
静的型付けの話題が出たところで、作成者と自分を同一視することで、科学を悩ませている別の問題、つまり数学への嫉妬から逃れることができます。科学に携わる人は皆、数学者は自分よりも賢いと密かに信じています。数学者もそう思っていると思います。いずれにせよ、その結果、科学者は自分の研究をできるだけ数学的に見せようとする傾向があります。物理学のような分野では、これはおそらくそれほど害にはなりませんが、自然科学から離れるほど、問題が大きくなります。
数式のページは、とても印象的です。(ヒント: さらに印象的にするには、ギリシャ変数を使用します。) そのため、たとえば重要な問題ではなく、正式に扱うことができる問題に取り組みたいという強い誘惑があります。
もしハッカーが作家や画家のような他の制作者と同一視していたら、こんなことをする誘惑にかられることはないでしょう。作家や画家は数学への羨望に悩まされることはありません。彼らはまったく無関係なことをしているように感じています。ハッカーもそうだと思います。
大学や研究所がハッカーのやりたい仕事を妨げるのであれば、彼らの居場所は企業にあるのかもしれません。残念ながら、ほとんどの企業もハッカーのやりたいことをやらせてくれません。大学や研究所はハッカーに科学者になることを強制し、企業はハッカーにエンジニアになることを強制します。
私自身、つい最近になってこのことに気付きました。Yahoo が Viaweb を買収したとき、彼らは私に何をしたいのかと尋ねました。私はビジネス面はあまり好きではなかったため、ただハッキングがしたいだけだと答えました。Yahoo に入社して、彼らにとってハッキングとはソフトウェアを設計することではなく、実装することだと知りました。プログラマーは、製品マネージャーのビジョン (それが言葉であるならば) をコードに変換する技術者とみなされていました。
これは大企業ではデフォルトの計画のようです。結果の標準偏差が下がるため、大企業はこれを採用します。実際にソフトウェアを設計できるハッカーはごくわずかで、企業を経営する人々がこうしたハッカーを見分けるのは困難です。そのため、ソフトウェアの将来を 1 人の優秀なハッカーに委ねるのではなく、ほとんどの企業は委員会で設計し、ハッカーは設計を実装するだけにします。
いつかお金を稼ぎたいなら、このことを覚えておいてください。これがスタートアップが勝つ理由の 1 つです。大企業は、災害を避けたいので、設計結果の標準偏差を下げたいと考えています。しかし、振動を抑えると、低い点だけでなく高い点も失ってしまいます。これは大企業にとっては問題ではありません。なぜなら、大企業は素晴らしい製品を作ることで勝つわけではないからです。大企業は、他の大企業よりも劣っている点が少ないことで勝ちます。
したがって、製品マネージャーがソフトウェアを設計するほど大きな会社と設計戦争をする方法を思いついたら、彼らはあなたに追いつくことは決してできないでしょう。しかし、このような機会を見つけるのは簡単ではありません。城の中にいる敵と直接戦闘をするのが難しいのと同じように、大企業と設計戦争をするのは困難です。たとえば、Microsoft Word よりも優れたワードプロセッサを書くのは非常に簡単ですが、オペレーティングシステムの独占の城の中にいる Microsoft は、あなたがそれを書いたとしてもおそらく気付かないかもしれません。
デザイン戦争を戦うべき場所は、誰もまだ要塞を築いていない新しい市場です。そこでは、大胆なデザインアプローチを採用し、同じ人が製品のデザインと実装の両方を行うことで、大きな勝利を収めることができます。Microsoft 自身も当初これを行っていました。Apple もそうでした。そして Hewlett-Packard もそうでした。成功したスタートアップのほとんどがそうしているのではないかと思います。
素晴らしいソフトウェアを作る方法の 1 つは、自分のスタートアップを始めることです。ただし、これには 2 つの問題があります。1 つは、スタートアップではソフトウェアの作成以外にもやらなければならないことがたくさんあることです。Viaweb では、ハッキングに 4 分の 1 の時間しか使えなければラッキーだと思っていました。そして、残りの 4 分の 3 の時間は、退屈なものから恐ろしいものまで、さまざまなことをしなければなりませんでした。私にはこれに関するベンチマークがあります。かつて、虫歯を埋めるために役員会議を抜け出さなければならなかったことがあるからです。歯科医の椅子に深く座り、ドリルを待っている間、休暇中のような気分だったことを覚えています。
スタートアップのもう 1 つの問題は、お金を生む種類のソフトウェアと、書くのが面白い種類のソフトウェアの間に重なり合う部分があまりないことです。プログラミング言語は書くのが面白いもので、実際、Microsoft の最初の製品はプログラミング言語でした。しかし、今ではプログラミング言語にお金を払う人はいません。お金を稼ぎたい場合、無料では誰も解決できないほど厄介な問題に取り組まざるを得ない傾向があります。
すべてのメーカーがこの問題に直面しています。価格は需要と供給によって決まりますが、作業が楽しいものよりも、個々の顧客の日常的な問題を解決するものの方が需要があります。オフブロードウェイの演劇に出演しても、トレードショーのブースでゴリラの着ぐるみを着るよりも儲かりません。小説を書いても、ゴミ処理機の広告文を書くよりも儲かりません。プログラミング言語をハッキングしても、ある会社のレガシーデータベースを Web サーバーに接続する方法を考えるよりも儲かりません。
ソフトウェアの場合、この問題の答えは、ほぼすべてのメーカーが知っている概念、つまり「昼間の仕事」だと思います。この言葉は、夜に演奏するミュージシャンから始まりました。より一般的には、お金のために行う仕事と、愛のために行う仕事があることを意味します。
メーカーのほとんどは、キャリアの早い段階で昼間の仕事を持っています。画家や作家はよくそのようにしています。運が良ければ、本業と密接に関係した昼間の仕事に就くことができます。ミュージシャンはレコード店で働いていることが多いようです。プログラミング言語やオペレーティングシステムに取り組んでいるハッカーも同様に、それらを使用して昼間の仕事に就くことができるかもしれません。[1]
ハッカーにとっての答えは、昼間は仕事を持ち、その傍らで美しいソフトウェアの開発に取り組むことだと私が言うとき、私はこれを新しいアイデアとして提案しているわけではありません。これこそがオープンソース ハッキングの本質なのです。私が言いたいのは、オープンソースはおそらく正しいモデルだということです。なぜなら、他のすべてのメーカーによって独立して確認されているからです。
オープンソース プロジェクトにハッカーが関わることに消極的な雇用主がいるというのは、私にとっては意外なことです。Viaweb では、オープンソース プロジェクトに関わらない人を雇用することに消極的でした。プログラマーを面接するとき、私たちが最も気にしたのは、彼らが余暇にどのようなソフトウェアを書いているかでした。好きでなければ、本当にうまくできるものはありません。ハッキングが好きなら、必然的に自分のプロジェクトに取り組むことになります。[2]
ハッカーは科学者ではなくメーカーなので、比喩を探すのに適切な場所は科学ではなく、他の種類のメーカーの中にあります。絵画はハッキングについて他に何を教えてくれるでしょうか?
絵画の例から学べること、あるいは少なくとも確認できることは、ハッキングの習得方法です。絵を描くことは、主に実際にやってみることで習得します。ハッキングについても同じです。ほとんどのハッカーは、大学のプログラミングの授業でハッキングを学びません。13歳で自分でプログラムを書くことでハッキングを学びます。大学の授業でも、ハッキングは主にハッキングすることで学びます。[3]
画家は作品の痕跡を残すので、彼らが実践を通して学んでいくのを見ることができます。画家の作品を年代順に見ていくと、それぞれの絵が以前の作品で学んだことに基づいていることがわかります。絵の中に非常にうまくいったものがあった場合、通常、それのバージョン 1 は、以前の絵の中に小さな形で見つかります。
ほとんどのメーカーはこのように作業していると思います。作家や建築家も同様のようです。ハッカーは、1 つのプロジェクトに何年も取り組み続け、後からのアイデアをすべて改訂版として取り入れるのではなく、画家のように行動し、定期的にゼロからやり直すのが良いかもしれません。
ハッカーがハッキングを実際にやってみることでハッキングを学ぶという事実は、ハッキングが科学といかに異なるかを示すもう 1 つの証拠です。科学者は実際にやってみることで科学を学ぶのではなく、実験や問題集をこなすことで科学を学びます。科学者は、他の誰かがすでに行った作業を再現しようとしているという意味で、完璧な作業から始めます。最終的に、独自の作業ができるところまで到達します。一方、ハッカーは最初から独自の作業を行っていますが、それは非常に下手です。つまり、ハッカーは独自の作業から始めて上手くなり、科学者は上手から始めて独自の作業になります。
制作者が学ぶもう 1 つの方法は、例から学ぶことです。画家にとって、美術館は技法の参考図書館です。何百年もの間、巨匠の作品を模写することは画家の伝統的な教育の一部でした。模写をすると、絵画の制作方法を詳しく見るよう強いられるからです。
作家も同じことをします。ベンジャミン・フランクリンは、アディソンとスティールのエッセイの要点を要約し、それを再現することで文章の書き方を学びました。レイモンド・チャンドラーも探偵小説で同じことをしました。
同様に、ハッカーも、優れたプログラムを見てプログラミングを学ぶことができます。プログラムの動作だけでなく、ソース コードも見ることができます。オープンソース運動のあまり知られていない利点の 1 つは、プログラミングの学習が容易になったことです。私がプログラミングを学んだときは、主に本の例に頼らざるを得ませんでした。当時利用できるコードの大きな塊は Unix でしたが、これもオープンソースではありませんでした。ソースを読んだ人のほとんどは、1977 年に書かれたにもかかわらず、1996 年まで出版が許可されなかった John Lions の本の違法コピーでソースを読みました。
絵画から得られるもう 1 つの例は、絵画が徐々に洗練されて作られる方法です。絵画は通常、スケッチから始まります。徐々に細部が埋められます。しかし、これは単に埋めるだけのプロセスではありません。時には、当初の計画が間違っていたことが判明することもあります。無数の絵画を X 線で見ると、手足が動かされていたり、顔の特徴が再調整されていたりすることがわかります。
これは絵画から学べる事例です。ハッキングも同じように機能するべきだと思います。プログラムの仕様が完璧であることを期待するのは非現実的です。これを前もって認め、仕様が即座に変更できるようにプログラムを書く方がよいでしょう。
（大企業の構造上、これを実行するのは困難ですが、ここがスタートアップが有利になるもう一つの場所です。）
おそらく、今では誰もが早すぎる最適化の危険性を知っているでしょう。早すぎる設計、つまりプログラムが何をすべきかを早すぎる段階で決めてしまうことについても、同様に心配する必要があると思います。
適切なツールは、この危険を回避するのに役立ちます。優れたプログラミング言語は、油絵の具のように、考えを変えるのが容易でなければなりません。動的型付けは、特定のデータ表現を事前に決める必要がないため、この点で有利です。しかし、柔軟性の鍵は、言語を非常に抽象的にすることだと思います。変更が最も簡単なプログラムは、非常に短いプログラムです。
これは矛盾しているように聞こえますが、偉大な絵画は、必要以上に優れている必要があります。たとえば、レオナルドがナショナル ギャラリーにあるジネヴラ デ ベンチの肖像画を描いたとき、彼は彼女の頭の後ろにジュニパーの茂みを置きました。彼はその中の葉を 1 枚 1 枚丁寧に描きました。多くの画家は、これは彼女の頭を囲むための背景に置くだけのものだと考えたかもしれません。誰もそれをじっくり見ることはないでしょう。
レオナルドは違います。彼が絵画の一部にどれだけ熱心に取り組んだかは、誰がそれをどれだけじっくり見るかということにはまったく関係ありませんでした。彼はマイケル・ジョーダンのようでした。執念深いのです。
執拗さが勝利するのは、全体として、目に見えない細部が目に見えるようになるからです。ジネヴラ・デ・ベンチの肖像画の前を通りかかると、ラベルを見て「レオナルド・ダ・ヴィンチ」と書かれていることに気づく前に、すぐに注目されることがよくあります。目に見えない細部がすべて組み合わさって、まるで千のほとんど聞き取れない声が調和して歌っているかのような、ただただ素晴らしいものが生まれます。
同様に、優れたソフトウェアには、美しさに対する熱狂的なこだわりが必要です。優れたソフトウェアの内部を覗いてみると、誰も見るはずのない部分も美しいことがわかります。私は自分が優れたソフトウェアを書いていると言っているわけではありませんが、コードに関しては、日常生活に同じように取り組んだら処方薬を処方されるような振る舞いをします。インデントが適切でないコードや醜い変数名を使用しているコードを見ると、気が狂いそうになります。
もしハッカーが単なる実装者で、仕様をコードに変換するだけであれば、溝を掘る人のように端から端まで作業を進めるだけで済みます。しかし、ハッカーがクリエイターである場合は、インスピレーションを考慮に入れなければなりません。
ハッキングでは、絵画と同じように、仕事は周期的に発生します。新しいプロジェクトに興奮して、1 日 16 時間作業したくなるときもあれば、何も面白くないときもあります。
良い仕事をするためには、これらのサイクルを考慮に入れる必要があります。なぜなら、サイクルはあなたがそれらにどう反応するかによって影響を受けるからです。坂道でマニュアル トランスミッションの車を運転しているとき、エンストを避けるために時々クラッチを戻さなければなりません。同様に、クラッチを戻すことで、野心がエンストするのを防ぐことができます。ペイントとハッキングの両方において、恐ろしく野心的なタスクもあれば、心地よいほど日常的なタスクもあります。そうしないとエンストしてしまう瞬間のために、簡単なタスクをいくつか取っておくのは良い考えです。
ハッキングでは、これは文字通りバグを溜め込むことを意味します。私はデバッグが好きです。デバッグは、ハッキングが人々が考えるほど簡単な唯一の方法です。完全に制約された問題があり、それを解決するだけでよいのです。プログラムは x を実行するはずですが、代わりに y を実行します。どこで間違っているのでしょうか。最終的には勝つことがわかります。壁を塗るのと同じくらいリラックスできます。
絵画の例は、自分の仕事の管理方法だけでなく、共同作業の方法も教えてくれます。過去の偉大な芸術の多くは、複数の人の手によるものですが、美術館の壁にその横に名前が 1 つしか書かれていないこともあります。レオナルドはヴェロッキオの工房で弟子として働き、キリストの洗礼の天使の 1 人を描きました。このようなことは例外ではなく、規則でした。ミケランジェロはシスティーナ礼拝堂の天井の人物像をすべて自分で描くことにこだわったことで特に献身的だったと考えられています。
私の知る限り、画家たちが協力して絵を描くとき、同じ部分を描くことは決してありませんでした。主役は巨匠が描き、その他の人物と背景は助手が描くのが一般的でした。しかし、一人の画家が別の画家の作品の上に絵を描くということは決してありませんでした。
これはソフトウェアのコラボレーションにも適切なモデルだと思います。あまり無理をしないでください。コードが 3 人か 4 人の異なる人々によってハッキングされ、誰もそれを実際に所有していない場合、それは談話室のような状態になります。荒涼として放棄された感じになり、不要なものが蓄積されがちです。コラボレーションの適切な方法は、プロジェクトを厳密に定義されたモジュールに分割し、各モジュールに明確な所有者を設定し、それらの間のインターフェイスをプログラミング言語と同じくらい注意深く設計し、可能であれば明確にすることだと思います。
絵画と同様、ほとんどのソフトウェアは人間の観客を対象としています。ですから、画家と同様、ハッカーも本当に素晴らしい作品を作るには共感力が必要です。ユーザーの視点から物事を見ることができなければなりません。
子どもの頃、私はいつも他人の視点から物事を見るように言われていました。これは実際には、自分のしたいことではなく、他人のしたいことをするということを意味していました。もちろん、これによって共感力は悪評を買ってしまい、私は共感力を養うことを心がけませんでした。
ああ、私は間違っていました。他人の視点から物事を見ることが、成功の秘訣であることがわかりました。それは必ずしも自己犠牲を意味するわけではありません。まったく違います。他人が物事をどう見ているかを理解することは、その人の利益のために行動することを意味するわけではありません。状況によっては、たとえば戦争では、まったく逆のことをしたい場合があります。[4]
ほとんどの製作者は、人間の観客のためにものを作ります。観客を魅了するには、観客が何を求めているかを理解する必要があります。たとえば、最も優れた絵画のほとんどは人物を描いたものです。なぜなら、人々が興味を持つのは人間だからです。
共感力は、おそらく優れたハッカーと偉大なハッカーの最も重要な違いです。一部のハッカーは非常に頭が良いのですが、共感力に関してはほとんど独善的です。そのような人はユーザーの視点から物事を見ることができないため、優れたソフトウェアを設計するのは難しいです[5]。
共感力がどのくらい優れているかを知る方法の 1 つは、技術的な背景を持たない人に技術的な質問を説明するのを観察することです。私たちは皆、他の点では頭が良いのに、この点が滑稽なほど下手な人を知っているでしょう。ディナー パーティーでプログラミング言語とは何かと尋ねられたら、彼らは「ああ、高水準言語とは、コンパイラがオブジェクト コードを生成するために入力として使用する言語です」などと答えるでしょう。高水準言語? コンパイラ? オブジェクト コード? プログラミング言語が何であるかを知らない人は、当然、これらのことも知りません。
ソフトウェアがしなければならないことの一つは、それ自体を説明することです。ですから、良いソフトウェアを書くには、ユーザーがどれだけ理解していないかを理解する必要があります。ユーザーは準備もせずにソフトウェアに近づき、マニュアルを読まないので、ソフトウェアはユーザーが予想した通りに動作する方がよいでしょう。この点で私が今まで見た中で最高のシステムは、1985 年の初代 Macintosh です。ソフトウェアがほとんど行わないこと、つまり、ただ動作するという動作をしました。[6]
ソース コードもそれ自体で説明する必要があります。プログラミングに関する引用を 1 つだけ覚えてもらうとしたら、それは*『Structure and Interpretation of Computer Programs』の冒頭にある引用です。*
プログラムは人間が読むために書かれるべきであり、機械が実行するために書かれるべきではありません。
ユーザーだけでなく読者に対しても共感を持つ必要があります。読者の一人になるのですから、それはあなたの利益になります。多くのハッカーは、プログラムを書いてから 6 か月後にそのプログラムに戻ってみると、それがどのように動作するのか全く分からないことに気付きます。私は、そのような経験の後で Perl を断念した人を何人か知っています。[7]
共感力の欠如は知性と関連付けられており、一部の地域ではそれが流行しているほどです。しかし、相関関係はないと思います。共感力を学ばなくても数学や自然科学で優秀な成績を収めることができますし、これらの分野の人は頭が良い傾向があるため、この 2 つの資質が関連付けられるようになりました。しかし、共感力が乏しい愚かな人も大勢います。トーク ショーで電話で質問する人の話を聞いてみてください。彼らは何を質問するにしても、非常に遠回しな言い方をするため、司会者が質問を言い換えなければならないことがよくあります。
では、ハッキングが絵を描いたり文章を書いたりするのと同じように機能するのであれば、それは同じくらいクールなことなのでしょうか? 結局のところ、人生は一度きりです。その時間を何か素晴らしいことに費やすのもいいでしょう。
残念ながら、この質問に答えるのは困難です。名声には常に大きなタイムラグがあります。それは遠くの星からの光のようなもの。絵画が現在名声を得ているのは、500年前の人々が成し遂げた素晴らしい仕事のおかげです。当時は、これらの絵画が今日ほど重要だとは誰も思っていませんでした。当時の人々にとって、ウルビーノ公爵フェデリコ・ダ・モンテフェルトロが、ピエロ・デッラ・フランチェスカの絵画に描かれた奇妙な鼻の男として知られるようになることは、非常に奇妙に思われたことでしょう。
だから、ハッキングは今や絵画ほどクールではないと認める一方で、絵画そのものが全盛期には今ほどクールではなかったことを忘れてはならない。
自信を持って言えるのは、今はハッキングの黄金時代だということです。ほとんどの分野では、偉大な仕事は早い段階で行われます。1430年から1500年の間に作られた絵画は、今でも比類のないものです。シェイクスピアは、プロの演劇が誕生したちょうどその頃に登場しました。
そして、このメディアを非常に大きなレベルに押し上げたため、それ以降のすべての劇作家は彼の影の中で生きざるを得なくなった。アルブレヒト・デューラーは版画で、ジェーン・オースティンは小説で同じことをした。
何度も同じパターンが見られます。新しいメディアが登場し、人々はそれに興奮し、最初の数世代でその可能性のほとんどを探求します。ハッキングは今この段階にあるようです。
レオナルドの時代には、絵画は彼の作品が貢献したほどクールなものではありませんでした。ハッキングがどれほどクールになるかは、この新しい媒体で何ができるかにかかっています。
注記
[1] 写真が絵画に与えた最大のダメージは、最高の日雇い仕事を殺してしまったことかもしれない。歴史上の偉大な画家のほとんどは肖像画を描くことで生計を立てていた。
[2] マイクロソフトは、従業員が余暇であってもオープンソース プロジェクトに貢献することを奨励していないと聞きました。しかし、今では優秀なハッカーの多くがオープンソース プロジェクトに取り組んでいるため、このポリシーの主な影響は、一流のプログラマーを雇用できなくなることかもしれません。
[3] 大学でプログラミングについて学ぶことは、本や服装、デートについて学ぶこととよく似ています。つまり、高校時代にどんな悪趣味を持っていたかということです。
[4] 共感の応用例を挙げましょう。Viaweb では、2 つの選択肢のどちらかを選べない場合、競合他社が最も嫌うのは何かと自問します。あるとき、競合他社がソフトウェアに基本的に役に立たない機能を追加しましたが、それは競合他社が持っていて当社にはない数少ない機能の 1 つだったため、業界紙で大きく取り上げられました。その機能が役に立たないことを説明することもできましたが、自分たちで実装しただけでは競合他社をもっと苛立たせることになると判断し、その日の午後に独自のバージョンを作り上げました。
[5] テキストエディタとコンパイラは例外です。ハッカー自身が典型的なユーザーであるため、これらを設計するのに共感は必要ありません。
[6] まあ、ほぼそうです。RAMの空き容量を多少オーバーしたため、ディスクの交換に非常に不便が生じましたが、追加のディスクドライブを購入することで数か月以内に修正できました。
[7] プログラムを読みやすくする方法は、コメントを詰め込むことではありません。私はアベルソンとサスマンの引用をさらに一歩進めたいと思います。プログラミング言語はアルゴリズムを表現するために設計されるべきであり、コンピューターにその実行方法を伝えることは付随的にのみ行うべきです。優れたプログラミング言語は、英語よりもソフトウェアを説明するのに優れているべきです。道路で予想外に急カーブがある部分にのみ矢印があるのと同じように、読者に警告する必要がある何らかの不具合がある場合にのみコメントが必要です。
この原稿を読んでくれた Trevor Blackwell、Robert Morris、Dan Giffin、Lisa Randall、そして講演を依頼してくれた Henry Leitner と Larry Finkelstein に感謝します。