すばらしいデザイン: デザインとは何か? (初稿)
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2006年1月26日 木曜
では、始めよう。カバーしなきゃいけないことはたくさんある。
前回は、このアーティクルシリーズの暫定のタイトル「すばらしいデザイン」を導入した。私が「すばらしい」という言葉と「デザイン」という言葉を使うときには、ごく特定のことを念頭に置いている。だからこれらの言葉を定義するのにちょっと時間を使ってもいいだろう。
最初に、「デザイン」とは何か。
ニューヨークにある、あの見事な褐色砂岩の建物をご存知だろうか? 精巧な彫刻やガーゴイルや美しい鉄のフェンスのある建物だ。古い設計図を探し出せば、昔の建築家がしばしば単に「美しい雷紋模様」としか書いてないのがわかるだろう。熟練の大工が美しい何かを作ってくれるのを当てにして、そのイタリアからやって来た老職人に任せておくのだ。
そういうのはデザインではなく、デコレーション(装飾)だ。我々ソフトウェア業界の人間が「鶏に口紅する」と言っているものだ。デザインには何か芸術的なスキルが必要だろうと考えているなら、その考えは捨てることだ。直ちに、素早く、今すぐにだ。芸術はデザインを強めもするが、デザイン自体は厳格に工学上の問題なのだ(しかし期待を捨てないで---今後のアーティクルで、美についてもう少し書くつもりだ)。
デザインというのは、私の用法では、トレードオフの選択をすることだ。
街角のゴミ箱を一緒にデザインしてみよう。
デザイン上の制約をいくつか挙げておく。
ゴミ箱はとても軽い必要がある。ゴミ集めが、もとい、衛生エンジニアがやってきて、ゴミ収集車にゴミを空けるために持ち上げられる必要があるからだ。
それに、ゴミ箱は重たくないといけない。そうでないと、風で飛ばされたり、ひっくり返されたりするからだ。(本当にあった話: 私の車の前にゴミ箱が飛ばされてきて事故を起こしたことがある。誰も怪我しなかったし、ゴミ箱だって無事だったのだけど。)
ゴミ箱はすごく大きい必要がある。人通りの多いところでは、一日の間にみんながたくさんのゴミを放り込む。十分な大きさがなかったとしたら、あふれてゴミが散らかってしまうだろう。そうなると、ジュースの缶を6本に束ねていたプラスチックの輪っかが海に流れて行って、絡まったかわいい小さな小鳥が窒息してしまうだろう。小鳥を死なせたくはないよね?
それにゴミ箱はかなり小さくないといけない。そうでないと、歩道で場所を取りすぎて、歩行者が脇を通るときに押し合うことになり、iPodでリッキー・ジャーベイスのポッドキャストを聞いている退廃的なヤッピーが、ジョークがあんまりおかしくて上の空で歩いていていたためにベトナム戦争の復員軍人にぶつかって、歴史的均衡について口論になってしもうかもしれない。
だからゴミ箱は軽くて、重たくて、大きくて、小さい必要がある。さらに、風でゴミが飛ばないようにふたが閉まるようになってなきゃいけない。それにゴミが簡単に空けられるように上が開いている必要がある。
あと、ゴミ箱はすっごく安価である必要がある。
傾向がつかめたかな? デザインをするときには、しばしば相矛盾する制約がたくさんあるのだ。
実際、これはデザインの鍵となる部分だ。そういった矛盾するゴールのすべてを満たすこと。
通常矛盾することのない唯一のゴールは、デザインされている製品をとても安価なものにするという要求だ。
すべてのデザイン上の決断にはトレードオフがかかわっている。ツールバー上に必要なアイコンをすべて並べるスペースを見つけるという問題であれ、フォントの大きさと内容の密度の最適なバランスをとって情報を詰め込むということであれ、携帯電話の限られたボタンのスペースの一番上手い使い方を決めるという問題であれ、それは変わらない。
新しく付け加える機能もトレードオフだ。その機能を本当に使うかもしれない人々と、そんなたくさんのオプションがあるのにはただ圧倒されてしまう人々との間の。1950年代の電話が現代的なオフィスフォンよりずっと使いやすいのは、あんまり機能がなかったからだ。ボイスメールも電話会議も3者通話機能もJavaゲームもないのだとしたら、必要になるのは番号をダイアルする方法と、警察グッズを売ろうとしている男の電話を切る方法くらいのものだ。
つまり言いたいのはこういうことだ。新機能はみんないいものだし、「使わないなら気にかけなきゃいい」のだから、誰を害することにもならないとあなたは思っているかもしれないが、気にかけない人たちも依然としてその機能を目にし、必要なときには理解することを強いられるのだ。
「どうしたらミュートボタンがサウンドシステムを損なうなんてことがあるの?」 ミュートボタンについて学ぶのに時間を使いたくないなら、単に無視することだってできるものね?
でもそれは正しくない。ある時点で、誰かが間違ってそのボタンを押し、スピーカーから音が出なくなる。その人が「ミュート」について知らなかったなら、ボリュームをめいっぱい上げたり、いろいろいじり回し、ようやくミュートの解除ができたとき、スピーカーは耳をつんざく音を出して、サウンドシステムがついていた部屋の壁に恒久的な凹みを作ることになる(そして対応する盛り上がりが上の階の床にできる)。
ミュートボタンは操作盤上のスペースを取るため、他のボタンを幾分か小さくする必要があり、ボタンが読みにくくなる。ボタンが増えるほどインタフェース全体がぞっとするものになる。私が決して目覚ましとして使おうと思わないホテルのラジオつき時計みたいになるのだ。あれにはオプションが山ほどあって、重要なミーティングに備えてアラームをセットしているのか、モンゴルからの最新ニュースをダウンロードするように予約しているのかわかりゃしない。
「要はシンプルにしろってことでしょ?」と思っているかもしれないけど、そうじゃない。そんな簡単な話ならどんなに楽かと思うよ。
電話会議機能がなければ、オフィスフォンは売れないのだ。
グラフィックスアプリケーションはユーザに16777216色の選択肢を与える必要があり、そうしないとイェール大学に売りつけることはできない。彼らはあらゆるドキュメントにイェールブルー(Pantone 289)を使うのだ。
わかったかな? 2つの要求があるのだ。たくさんの機能と、少しの機能。そう、そこが禅みたいなデザインのミステリが現れるところだ。デザインするときには、たくさんの難しい制約を満たす必要がある。その1つを間違うだけで、奈落に落ち込むことになる。これを正しくやるのはばかみたいに難しいのだ。あなたは私がMotorola RAZRの電源ボタンの問題の解決方法を知っていると思う? とんでもない! Motorolaのデザインチームは、この問題に何週間もかけたはずだ。RAZRのキーボードがONボタンを押すと即座に光るようにするために、あるエンジニアか、あるいはエンジニアのチームが、まったく膨大な時間をかけ、遅くまで働き、休日まで仕事していたはずだ。昼間はユーザがそれに気付くことがないにしても。イントロダクションで私が不平を言った問題に彼らは気付いていたが、それについて何もできなかったのだ。現代的な携帯電話の電源を入れるときには、画面に何か出す前にコンピュータをブートする必要があり、しかもそれはあまり速いコンピュータではないのだ。
デザインとは、コストをかけるよりも早く価値を付け加えること
Motorola RAZRは毎月400万セットという割合で売れている。毎秒1.5個だ。Motorolaがデザインの改善のためにあと100万ドルか200万ドルかけたとしても、それを1日で回収できる。
デザインのコストは製品に対して1度だけ支払えばいい。それは固定費の一部であって、変動費ではないのだ。そしてデザインは売られる製品の1つ1つに価値を付け加える。これは2001年に引退したクライスラーの有名な自動車デザイナであるトーマス・C・ゲイルが、「良いデザインはコストを増やすよりも早く価値を付け加える」と言ったときに意味していたことだ。
脚注: JIM MCCRAW "AUTOS ON FRIDAY/Design; He Put a New Face on Chrysler" (The New York Times, February 9, 2001, Late Edition - Final, Section F, Page 1, Column 1)
これこそがデザインをとても重要なものにしていることなのだ。このシリーズを終える頃には、製品の成功のためには良いデザインほど重要なものはないということを、あなたは納得しているだろうと思う。それがソフトウェア製品であろうと、Webサイトであろうと、携帯電話であろうと、ゴミ箱であろうとそうだ。では「すばらしいデザイン」についてはどうか? 次回はそのことついて書くつもりだ。お楽しみに。
メタアーティクル
2番目のドラフトを出し始める前に、一通り全部のアーティクルについて最初のドラフトをひねり出してしまった方がいいだろうということに気付いた。だからそういうプランで行くことにする。
何日かしたら、今後のアーティクルの一覧を出すつもりだ。この一覧は進んでいくにつれてかなり変わると思う。アーティクルの一部は私が前に書いたアーティクルの焼き直しになるだろう。他のものは100%新作だ。
最後になるが、私は途中で読者からのフィードバックを聞きたいと思っている。私はたくさんのすばらしい提案やアイデアを受け取っている。フィードバックを送るのに一番いい場所はディスカッショングループだ。Design of Softwareグループでもいいし、もう少し騒がしいメインのJoel on Softwareグループでもいい。
タイポや文法ミスやスペルの間違いや、あなたの好みからすると口語的すぎるといった問題についてはメールしないでほしい。それというのも、時間が経つとあなたの送る訂正は、他の100人の人がすでに知らせてくれているものだということになってしまうからだ。2番目のドラフトが出る頃には、そういった問題はほとんどすべて修正されていると思う。
