デザインと研究

2003年1月

(この記事は、2002年秋のNEPLS会議でのキーノートスピーチに基づいています。)

この国を訪れる人は、アメリカ人が会話を始める際によく「あなたは何をしているのですか?」と尋ねることに驚くことが多いです。私はこの質問が好きではありません。それに対する明確な答えを持っていることはほとんどありません。しかし、ついにその問題を解決したと思います。誰かが「あなたは何をしているのですか?」と尋ねてきたら、その人の目を真っ直ぐ見つめて「新しいLispのメタ言語を設計しています」と答えます。これが気に入らない人にはおすすめの答えです。すぐに会話は別の話題に移っていきます。

私は自分がプログラミング言語の研究をしていると考えていません。建物やチェア、新しいフォントを設計するのと同じように、言語を設計しているだけです。新しいものを発見しようとしているわけではありません。プログラミングしやすい言語を作りたいだけです。この前提によって、私の生活はずっと楽になります。

デザインと研究の違いは、新しさと良さの問題だと思います。デザインは新しい必要はありませんが、良いものでなければなりません。研究は良いものである必要はありませんが、新しいものでなければなりません。私は、最高のデザインは新しいアイデアを使って先達を凌駕し、最高の研究は新しいだけでなく実際に解決する価値のある問題を解決するという点で、これら2つのアプローチが頂点で収束すると考えています。結局のところ、私たちは同じ目的地を目指しているのですが、ただ異なる方向から近づいているだけです。

今日お話しするのは、その目的地を背中から見たときのことです。プログラミング言語を研究テーマではなくデザインの問題として扱うとき、あなたはどのように行動を変えるのでしょうか。

最も大きな違いは、ユーザーに焦点を当てることです。デザインは、誰のためのものなのか、そしてそのユーザーに何が必要かを尋ねることから始まります。優れた建築家は、ユーザーに押し付けるデザインを先に作るのではなく、対象となるユーザーを研究し、彼らのニーズを把握することから始めます。

「欲しいもの」ではなく「必要なもの」と言ったのは、デザイナーとしての仕事が単なる注文請負人のようなものではないということを示すためです。分野によって異なりますが、最高の仕事は、単にクライアントの指示通りに作るだけの人によってなされるのではないと思います。

ただし、ユーザーの要求に応えることが重要なのは確かです。良いデザインの尺度は、ユーザーにとってどれだけうまく機能するかです。退屈な小説を書いたり、座りにくい椅子を作ったりしたら、それは単に悪いデザインです。最先端の理論に基づいて設計されていても、それは弁解にはなりません。

しかし、ユーザーのニーズに合わせて作るということは、ユーザーの指示通りに作るということではありません。ユーザーは選択肢の全てを知らず、自分が本当に欲しいものを間違えていることも多いのです。

このジレンマの答えは、ユーザーのために設計しなければならないが、ユーザーが言うことを単に実行するのではなく、ユーザーが本当に必要としているものを設計しなければならないということだと思います。医師の仕事と同じように、症状だけに対処するのではなく、実際に何が問題なのかを見極め、それに対処しなければならないのです。

このユーザー中心のアプローチは、優れたデザインの実践のほとんどを導き出すことができる公理のようなものであり、ほとんどすべてのデザイン上の問題がこの周りに集中しています。

良いデザインはユーザーのニーズに応えなければならないのであれば、そのユーザーとは誰なのでしょうか。ユーザー中心のデザインと言っても、必ずしも最低レベルのユーザーを対象にするわけではありません。例えば、ツールをデザインする場合、初心者からエキスパートまでさまざまなユーザーを想定できます。そして、ある群のユーザーにとって良いデザインが、別の群のユーザーにとっては悪いデザインかもしれません。つまり、良いデザインや悪いデザインを論じるには、必ず対象となるユーザーを特定する必要があるのです。

デザイナー自身がそのユーザーに含まれている場合に、最高のデザインが生み出される可能性が高いでしょう。デザイナー自身が含まれていないユーザーを対象にする場合、自分より劣っていると見なされがちで、それが必ずしも良いデザインにつながるわけではありません。

これは問題だと思います。ユーザーを、たとえ善意であっても、軽んじることは、デザイナーを必ず堕落させてしまうからです。おそらく、アメリカの公営住宅の大半は、自分で住むつもりのない建築家によってデザインされたのではないでしょうか。プログラミング言語でも同じことが言えます。 C、Lisp、Smalltalkは、デザイナー自身が使うために作られましたが、Cobol、Ada、Javaは他人のために作られました。

「バカ」のためにデザインしていると思っていれば、たとえバカのためであっても、良いデザインはできないでしょう。

最も洗練されたユーザーを対象にしていても、結局のところ人間のためのデザインなのです。研究の世界では事情が違います。数学では、人間にとって理解しやすいかどうかではなく、証明を短くするかどうかによって抽象化を選択します。科学全般についても同じことが言えるでしょう。科学的なアイデアは人間工学的である必要はありません。

一方、芸術の世界では事情が全く異なります。デザインは人間中心なのです。人間の体は奇妙なものですが、椅子をデザインする際は、それを前提としなければなりません。すべての芸術は、人間の興味や制限に合わせざるを得ません。絵画の例を挙げると、他の条件が同じなら、人物のいる絵の方が、人物のない絵よりも興味深いでしょう。ルネサンス期の偉大な絵画がみな人物で満ちているのは、単なる歴史的偶然ではありません。人物がいなければ、絵画という媒体は今日ほどの威信を持っていなかったかもしれません。

好むと好まざるとにかかわらず、プログラミング言語も人間のためのものです。そして、人間の脳も人間の体と同じように、ごつごつしていて変わりやすいのではないかと思います。ある考えは人間にとって理解しやすく、ある考えは難しいのです。例えば、細部を扱う能力には限界があるようです。この事実がプログラミング言語の必要性を生み出しているのだと思います。細部を自在に扱えれば、機械語でプログラミングすればよいのですから。

言語は完成したプログラムの形式ではなく、プログラムを開発するためのものであることを忘れないでください。芸術分野の人なら、二つの状況では異なるメディアを使いたいと言うでしょう。例えば、大理石は完成したアイデアには適していますが、新しいアイデアを開発するには柔軟性がありません。

プログラムは、過去に誤りの枝分かれが多数あった木の剪定された版のようなものです。したがって、言語の評価基準は、完成したプログラムがきれいに見えるかどうかだけではなく、完成したプログラムに至る過程がきれいであるかどうかです。洗練された完成プログラムを生み出す設計選択肢が、必ずしも洗練された設計プロセスをもたらすとは限りません。

私たちは、しばしば言語の評価基準を完成したプログラムの外見だけに置いています。二つの言語で同じプログラムを書いて、一方が短いと説得力があるように見えます。しかし、芸術の視点から問題に取り組めば、このような評価基準に頼る必要はありません。プログラミング言語を大理石のようなものにしたくはありません。

例えば、ソフトウェア開発において、対話型トップレベルインターフェースを持つことは大きな利点です。これは、言語設計に大きな影響を及ぼします。変数を使う前に宣言しなければならない言語では、うまく機能しません。トップレベルで式を入力しているときは、xに値を代入してからxを操作したいのです。xの型を先に宣言したくありません。

良いデザインを得るには、ユーザーに近づき、ユーザーに寄り添い続ける必要があります。特に初期の段階では、実際のユーザーを基準に自分のアイデアを調整する必要があります。ジェーン・オースティンの小説が優れているのは、家族に朗読していたからです。そのため、風景の自己満足的な描写や、押し付けがましい哲学的な考察に陥っていません。

ソフトウェア界では、これは「Worse is Better」と呼ばれています。「Worse is Better」には、いくつかの考え方が混在しているため、良いのか悪いのかをめぐって議論が続いています。その中心的な考え方の一つは、新しいものを作るときは、ユーザーの前に素早くプロトタイプを提示し、徐々に洗練していくべきだというものです。

一方、「Hail Mary」戦略と呼ばれるアプローチもあります。プロトタイプを素早く提示して徐々に洗練していくのではなく、完成した最終製品を一気に作り上げようとするものです。これは、多くの場合、失敗に終わります。

絵画の分野でも、プロトタイプを作って徐々に洗練していく方法が発見されました。正確な絵を描くには、対象物の輪郭線を少しずつ描いていくのではなく、大まかな線を素早く描いて、徐々に洗練していくのが良いとされています。

ソフトウェアでも、プロトタイプを最終製品に洗練していくことができます。新しい洞察を活かせるだけでなく、モチベーションの維持にも役立ちます。デザインにおいてモチベーションは重要です。描いているものに飽きてしまうと、描いた絵も退屈なものになってしまいます。同様に、ソフトウェア開発においても、常に動作するコードを持つことが重要です。

つまり、プロトタイプを徐々に洗練していくアプローチは、モチベーションを維持するのに良いのです。絵画の分野でも、多くの画家は曖昧なスケッチから始めて徐々に洗練していきます。このようにすれば、一日の仕事を未完成のものではなく、何かしらの完成形で終えることができます。ソフトウェア開発でも同様の考え方が通用します。

モラールは、洗練されていないユーザーのために何かを設計するのが難しい別の理由です。自分で好きではないものに興味を持ち続けるのは難しいです。何かを良いものにするには、「これは本当に素晴らしい」と思うのではなく、「これは糞だ、あのバカどもが好きだろう」と思ってはいけません。

デザインとは人間のためのものを作ることです。しかし、人間なのはユーザーだけではありません。デザイナーも人間なのです。

ずっと「デザイナー」について話してきましたが、デザインは一人の人間の管理下にあるのでなければ、良いものにはなりません。しかし、共同研究プロジェクトが可能であるのは興味深いことです。これは研究とデザインの最も興味深い違いの1つのようです。

芸術分野での共同作業の事例はありますが、ほとんどが分子結合のようなものであって、真の融合ではありません。オペラでは、台本を書く人と音楽を書く人が別々の場合が一般的です。ルネサンス期には、北欧からの職人が、イタリアの絵画の背景の風景を描くことがよくありました。しかし、これらは真の共同作業ではありません。ロバート・フロストの「良い柵が良い隣人を作る」という言葉のように、それぞれの個別のプロジェクトの中では、一人の人間が統制権を持っていなければなりません。

良いデザインには、一人の人間がすべてを考える必要はないと言っているのではありません。信頼できる人の助言ほど価値のあるものはありません。しかし、話し合いが終わった後は、何をするかの決定は一人の人間に委ねられなければなりません。

なぜ研究は共同で行えるのに、デザインはそうではないのでしょうか。これは興味深い問題です。私にはその答えはわかりません。もしかすると、デザインと研究が収束すれば、最良の研究は同時に良いデザインでもあり、実際には共同で行うことはできないのかもしれません。最も有名な科学者の多くは一人で働いていたようです。しかし、ここにパターンがあるかどうかは私にはわかりません。単に共同作業が一般的ではなかった時代に活躍した科学者が多かっただけかもしれません。

科学の世界ではどうであれ、真の共同作業は芸術の世界ではほとんど見られません。委員会によるデザインは、悪いデザインの同義語です。なぜそうなのでしょうか。この制限を克服する方法はあるのでしょうか。

私は良いデザインには独裁者が必要だと考えています。その理由の1つは、良いデザインは一体のものでなければならないということです。デザインは人間のためのものですが、個々の人間のためのものです。デザインが1人の人間の頭の中に収まる考えを表しているのであれば、ユーザーの頭の中にもそのアイデアが収まるはずです。

[1]