デザインとリ検索 ---Design and Research---
Paul Graham, January 2003.
Copyright 2003 by Paul Graham.
これは、Paul Graham：Design and Research を、原著者の許可を得て翻訳・◇するものです。<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2003 by Paul Graham
原文: http://www.paulgraham.com/desres.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の邦訳版が出版されました。
出版社の案内ページ Amazon.co.jp サポートページ
2003/01/04 翻訳◇
(この記事は2002年秋のNEPLSのミーティング[訳註1]の基調講演を基に作成された)
外国人はよく驚くのだが、アメリカ人は会話の初めに「どんなお仕事をなさっていますか」と尋ねることがとても多い。私はこの質問は好きじゃない。うまい答えを思い付いたためしがないんだ。でも最近、ついにこの問題は解決をみた。誰かが私が何の仕事をしているか尋ねたら、その人の目をまっすぐ見て「Lispの新しい方言を設計しています」と言うことにしたんだ。この答えは仕事を聞かれるのが好きじゃない人にはお勧めだよ。会話はあっという間に別の話題に移るだろうからね。
私は、自分がプログラミング言語の研究をしているとは思っていない。人が、建物や椅子や新しいフォントをデザインするのと同じように、言語をデザインしているだけだ。何か新しいことを発見しようとしているわけじゃない。ただ、プログラムするのに良い言語を作りたいと思っている。こう考えることで、問題はずいぶん扱いやすくなっているようだ。
デザインとリサーチの違いは、新しさ対良さの問題だと言えると思う。デザインは必ずしも新しくある必要はないが、良くなくてはならない。リサーチは必ずしも良くある必要はないが、新しくなくてはならない。この二つの道は頂上で一緒になると私は思う。最高のデザインは新しいアイディアでもってそれまでのものを凌駕するだろうし、最高のリサーチは新しいだけでなく、解くに値する問題を解くのだ。従って我々は究極的には同じ方向を目指しているが、別々の方向から近付いていると言えるだろう。
今日私が話したいのは、あなたがたの目標を反対側から眺めたらどんなふうに見えるかってことだ。プログラミング言語を研究対象としてでなく、デザインの問題と考えたら、あなたはどんなふうにそれに取り組むだろう。
一番わかりやすい違いは、よりユーザーに注意を向けることだろう。これは誰のためで、どんな必要を満たすモノか、と問うところからデザインは始まる。例えば良い建築家は、まずデザインを作ってから住む人にそれを押しつけるのではなく、住む対象となる人を研究して彼らが必要としているものを見付けることから始めるだろう。
私が、彼らが「欲しているもの」ではなく「必要としているもの」と言ったことに注意して欲しい。デザイナーの仕事は、お客の言う通りなんでもすぐ作ってみせる料理人みたいなものじゃない。芸術の分野によって違いはあるだろうが、どんな分野にせよ、最高の仕事というものはお客が頼んだことをただそのままやるような人にできるものじゃないと思う。
もちろん、お客は常に正しい。良いデザインはユーザーに対してもたらす効用によって測られる、という意味においてはね。皆を飽きさせる小説を書いたり、座り心地が最悪な椅子を作ったりしたら、それは単にダメな仕事だ。たとえその小説だか椅子だかが最新の理論に基づいて作られていたとしたって何の足しにもなりゃしない。
それでも、ユーザーにうまく使ってもらえるものを作るというのは、ユーザーの言う通りに作るということとは違う。ユーザーは全ての選択肢を知っているわけじゃないし、本当に欲しいものが何かということについてはよく間違う。
このパラドックスへの答えが、あなたはユーザーのためにデザインしなくちゃならないけれど、単にユーザーが欲しいというものではなく、ユーザーが必要としているものをデザインしなくちゃならない、ということなんだ。これは医者の役割によく似ている。患者の症状だけを看ていてはだめだ。患者が症状を話している時に、何が原因となっているかを見極めて、それを手当てしないと。
こんなふうにユーザーに注意を向けることが、良いデザインをつくり出す多くの方法の原則であり、多くのデザイン上の問題が解決しようと目指しているところでもある。
良いデザインがユーザーの必要としているものを作るんだとして、ではユーザーとは誰だろう。私はデザインはユーザーのためのものだと言ったが、ユーザーの最小公倍数みたいなものを目指すのが良いデザインだというつもりはない。どんなふうにでもいいから、あるユーザーの集合を決めるんだ。例えば道具をデザインしているなら、初心者向けにデザインしてもいいし、熟練者向けでもいい。ただ、あるグループ向けの良いデザインは、別のグループ向けとしては良くないかも知れない。大事なことは特定のグループのユーザーを対象とすることだ。対象とするユーザーを特定しないことには、デザインの良否さえ議論できないんじゃないかと思う。
良いデザインが出て来やすいのは、対象とするユーザーがあなた自身を含んでいる時だ。あなた自身を含まないグループに対して何かをデザインしていると、対象ユーザー層は自分より上ではなく、下だと思ってしまいがちになる。
それは問題だ。ユーザーを見下ろすことは、たとえ慈悲心があったとしても、いずれはデザイナーをだめにする。アメリカの住宅のうち、自分でそこに住もうと思っている設計者が作ったものはほとんど無いんじゃないか。同じことはプログラミング言語にも見て取れる。 C、Lisp、Smalltalkはデザイナーが自分で使うために作られた。 Cobol、Ada、Javaは他人が使うために作られた。
あなたがまぬけのために何かをデザインしているんだとしたら、まぬけにとっても役に立たないものをデザインすることになるのが落ちだろう。
しかし、最も優れたユーザー層のためにデザインしている場合でも、相手にしているのは依然として人間なんだ。そこがリサーチと違うところだ。数学では、人間にわかりやすくするためにある抽象化方法を選ぶなんてことはしない。証明を短くするのに良い抽象化方法を選ぶだけだ。どの科学でも概ねそういうものだと私は思う。科学的な思考は使う人にやさしいことを指向してはいない。
芸術の分野では事情は全く異なる。デザインは人々のためのものだ。人間の身体というのは奇妙で扱いにくいものだが、椅子をデザインしているならそれを避けて通るわけにはいかない。全ての芸術は人間の興味と限界に迎合しなくちゃならない。例えば絵画では、他の全ての要素が等しければ、人間が描かれているものの方が面白いものになる。ルネッサンスの偉大な絵画が人でいっぱいなのは歴史の偶然ではない。そうでなかったら、媒体としての絵画が今のような地位を得ることは無かっただろう。
好むと好まざるとにかかわらず、プログラミング言語も人々のためのものだ。そして人間の頭脳は身体と同じく、でこぼこでへんてこりんなものだと思う。人々にとって理解しやすい考えもあれば、そうでない考えもある。例えば、我々人間が細部を扱う能力は極めて限られているようだ。だからこそ、プログラミング言語というものが有用になったと言える。我々が細部を扱うことに障害が無ければ、機械語でプログラムしていたって良かったはずだ。
また、プログラミング言語はまず、完成されたプログラムの形ではなく、プログラムがまさに開発されている最中の形をとるということを忘れないで欲しい。芸術の分野で仕事をしている人なら誰でも、その二つの過程には異なる媒体が必要になるだろうと言うだろう。例えば、大理石は最終的な考えを保持するには素晴らしく長持ちする媒体だが、新しい考えを発展させている時にはおそろしく融通の利かない媒体でもある。
プログラムというものは、証明のように、もともと様々な間違いの枝がそこいらじゅうに生えていた木の枝をきれいに刈り込んだものだ。だから言語の良さを測るには、完成したプログラムがどれだけ綺麗かを見るだけじゃだめで、プログラムが完成へと至った道筋がどれだけ綺麗だったかをみなければいけない。プログラムの最終形をエレガントにするためのデザイン上の選択は、プログラムそのもののデザインの道筋を綺麗にするものではないかもしれない。私は入れ子になったバッククオートで固められたマクロ定義を生成するマクロをいくつか書いたことがあり、それは今では小さな宝石のように見えるが、それを書くにあたっては何時間もの醜い試行錯誤を繰り返したし、正直に言って、それが完全に正しいかどうか今でも自信がない。
われわれはつい、完成したプログラムがどれだけ良く見えるかで言語の良さを測ってしまいがちだ。二つの言語で書かれた同じプログラムを眺めて、片方がもう片方よりうんと短かかったりすると、その議論にはひどく説得力がある。だが芸術の方向からこの問題に取り組んでみれば、そういう測り方をしてしまうことは少ないだろう。プログラミング言語を、大理石のような、完成形は美しいけれどそれを使った製作が苦痛であるような媒体にはしたくはないだろう。
例をあげよう。ソフトウェアを開発する時、インタラクティブなトップレベルをつけておくのは非常に有効だ。 Lispではread-eval-printループと呼ばれているものだ。だがインタラクティブトップレベルをつけた途端、それは言語のデザインに確かな影響を与える。例えば変数を前もって宣言しなければならないような言語はうまくないというようなことだ。トップレベルに式を打ち込んでいる時は、まずxに何かの値をセットしてそれからxをこう使おうという具合に考えているはずだ。そんな時に最初にxの型をいちいち宣言したくはない。前提条件に反論の余地はあるだろうが、もし便利な言語はトップレベルを持たなければならず、そして型宣言を強制することはトップレベルと親和性が悪いということであれば、型宣言を強制する言語は便利な言語には成り得ないということになる。
現実には、良いデザインを得るにはユーザーに近付き、そして常にユーザーの側に居なくてはならない。実際のユーザーに合わせて常に考えを調整しなければならない。特に最初の段階がそうだ。ジェーン・オーステンの小説が良いわけは、彼女はまず作品を家族に読んで聞かせたからだ。だから彼女は自己満足的な芸術ぶった風景の描写や、もったいぶった哲学的考察に堕ちることが決して無かった。 (もちろん彼女の小説に哲学はある。だがそれはお札のようにストーリーの上にぺたぺた貼られているのではなく、ストーリーの中に編み込まれているのだ)。そこらにある「文学」小説を開いて、自分の書いたもののふりをして友人に読み聞かせるところを想像してみたまえ。きっとそれがどれだけ読み手の負担になることか感じられるだろう。
ソフトウェアの世界では、これは「悪いほうが良い」原則[訳註2]として知られている。実は「悪いほうが良い」原則にはいくつかのアイディアが混ざり合っていて、そのせいで人々はいまだに悪いのは本当に良いのかどうか議論を続けているんだが、そのアイディアの中でも一番主たるものは、何か新しいものを作る時はできるだけ速くプロトタイプをユーザの前に出すべきだということだ。
反対の方法は「マリア様万歳」作戦とでも呼べる。プロトタイプをさっさと出して少しづつ改善する代わりに、長い時間をかけて完全な最終形の製品を作り上げようとすることだ。私の知る限り、これは惨劇への切符だ。インターネットバブルの頃には、数え切れないほどのベンチャー企業がこの方法を取って自滅していった。私はこの方法が成功した例を聞いたことがない。
ソフトウェアの世界の外にいる人々が見落としがちなのは、この「悪いほうが良い」原則は芸術の分野に普遍的に見られるということだ。絵画では、この方法はルネッサンスの時代に発見された。今ではほとんどの絵画の教師が、正確な線画を得るにはものの輪郭を順にゆっくりなぞっていってはいけないと教えるだろう。誤差が積み重なって、最終的に線が合わなくなる。そうではなく、いくつかの線をだいたいの位置にざっと置いてみて、そのスケッチを次第に詳細化してゆくのだ。
多くの分野では、プロトタイプは伝統的に異なる材料で作られてきた。活字は紙の上で筆書きでデザインされた後に金属に刻まれた。彫像は蝋でモデリングされた後にブロンズに鋳造された。タペストリーに織り込まれる模様はまず紙にインクウォッシュで描かれた。石造りの建物はまず木で模型が造られた。
油彩画が、15世紀に広まった時に熱狂的に受け入れられたのは、プロトタイプからそのまま最終的な作品を作ることができたからだった。もちろん下書きを書くことはできるが、そこで止める理由はない。完成するまでどんどん詳細化してゆくことができるし、大きな変更を加えることだってできる。
ソフトウェアでも同じことができる。プロトタイプはただの模型に留まる必要はない。それを詳細化して、最終的な製品にまで持っていけるんだ。これは可能ならいつでもそうすべきだと思う。この方法は作ってゆく過程で新しいアイディアを入れて行けるし、何より大事なのは、志気を保てることだ。
志気はデザインの要だ。何でこのことがもっと話題にのぼらないのか私は不思議に思う。私の最初の絵画の教師はこう教えてくれた。もし何かを描いていて飽きてきたら、画も退屈なものになるだろうと。例えば建物を描いているとしよう。そして煉瓦をひとつひとつ描き込もうと思ったとしよう。もちろんやってやれなくはないだろう。しかし、半分まで行って飽きが来て、残りの煉瓦を一つ一つをよく観察するかわりに機械的に埋めて行ったとしたら、出来上がりは煉瓦をただ感じさせるだけの仕上げよりもずっと悪いものになるだろう。
プロトタイプから次第に詳細化してゆく方法が志気に良いのは、常に没頭していられるからだ。ソフトウェアにおける私のルールはこうだ：常に動くコードを持っていろ。一時間後には試せるものを書いていれば、目の前にある見返りによっていつも元気づけられていられる。芸術でも同じだ。特に油彩画では。多くの画家はぼんやりしたスケッチからはじめて徐々に細部を描き込んで行く。この方法を取れば、原理的に画が未完成に見えるまま一日が終るということが無い。実際、画家の間でよく言われるせりふがある。「画には終りがない。ただ描くのを止めるだけだ」。ソフトウェアの仕事をしたことのある人なら、この考えはよくわかるだろう。
志気の問題は、低いレベルのユーザーのために何かをデザインするのが難しいことのもう一つの理由でもある。自分で気に入らない何かに対して興味を持ち続けるのはとても難しい。良いものを作りたいなら、いつも「うーむ、こいつは素晴らしいぞ」と思い続けていなくちゃ。「なんてひどいがらくただ。馬鹿どもは気に入るだろうがな」なんて考えるんじゃなく。
デザインは、人間のために何かを作るということだ。でもただユーザーだけが人間なんじゃない。デザイナーもまた、人間なのだ。
ところで私は常に、「デザイナー」という言葉を単数で使って来たことに注意して欲しい。デザインが良いものになるためには、通常は一人の人間の制御下に無くてはならない。しかし、リサーチのプロジェクトでは何人かの人々が協力し合うことは可能に思える。これは、リサーチとデザインの違いのうちの最も興味深い点だと私には思える。
芸術の分野でも協力し合った有名な事例が無いわけではないが、その多くは核融合みたいなものじゃなく、分子結合のようなものだと思う。オペラでは一人がリブレットを書いてもの一人が作曲するのは普通のことだ。絵画でも、画の別々の部分がそれぞれの専門家によって描かれることはあり得る。ルネッサンスの時代、北ヨーロッパからの旅人はしばしばイタリアの絵画の背景を描くために雇われた。だがこれらは本当の協調作業ではない。どちらかというと、フロストが言う「良い柵は良い隣人をつくる」の具体例みたいなものだ。それ自体が良いデザインであるものをくっつけることはできるが、それぞれのプロジェクトの中では、一人の人間がコントロールすることが必要だ。
別に、良いデザインをするには一人の人間が全てを考えなくちゃならないと言っているわけじゃない。あなたが信頼できる人の批判より貴重なものはない。だが、会話が終ったら、決断は一人の人間に任されなければならない。
何故リサーチは協調して出来るのにデザインは出来ないのだろう。これは面白い問いだ。私には答えはわからない。もしかすると、デザインとリサーチがいずれ出会うとすれば、最高のリサーチは良いデザインでもあるはずで、だとすればそれは協調しては出来ないものかもしれない。最も有名な科学者達の多くは一人で仕事をしていたように思える。だがここにパターンがあると言えるほど私はよく知っているわけじゃない。有名な科学者の多くは協同研究がそれほど一般的では無かった時代にいたと言うだけかもしれない。
科学者の間にどんなストーリーがあろうと、芸術の分野での真の協調作業はほとんど見出せないと言えるだろう。委員会によるデザインは悪いデザインと同義語だ。なぜそうなのだろう。この限界を破る方法はあるのだろうか。
私はその方法は無いという考えの方に惹かれる。良いデザインには独裁者が必要なんだ。ひとつの理由は、良いデザインは完全に一つにまとまったものでなければならないということだろう。デザインは単に人間のためのものであるというだけでなく、個々の人間のためのものだ。デザインが一人の人間の頭に収まる考えを表わしているのなら、それはユーザーの頭にもきっと収まるだろう。
Related:
* ものつくりのセンス ---Taste for Makers
訳者コメント：今回はそのまんまの邦題です。「設計と研究」では「デザイン」という語の持つ感じがあまり出ないように思えたので。内容的には今までのGraham氏の記事を噛み砕いた感じで目新しいことはあまり無いのですが、これまでの流れの上にあるので一応訳してみました。
訳註1：
NEPLS: New England Programming Languages and Systems Symposium Series. http://www.nepls.org/.
訳註2：
「悪いほうが良い」原則：Richard Gabriel, The Rise of "Worse is Better"
