プログラマのためのユーザインタフェースデザイン第5章: 一貫性とそのほかのゴブリンについて

From The Joel on Software Translation Project

Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/4/22

Microsoft Officeスイートの主要なプログラムのうち、WordとExcelはMicrosoftがスクラッチから開発したものだが、そのほかのプログラムは外部の企業から買い取ったものだ。FrontPageはVermeerから、VisioはVisio Incから買い取られたが、この二つのプログラムに共通することはいったい何だろう？それははじめからMicrosoft Officeアプリケーションのルックアンドフィールで設計されたということだ。

OfficeのUIをエミュレートするという選択は、単にMicrosoftにへつらったり、会社を買ってもらえるようにするというためだけではなかった。FrontPageを開発したチャールズ・ファーガソンは嫌悪感を隠そうとしていない。彼はレドモンドのやつらをどうにかしてくれるように、繰り返し司法省に頼んでいた(彼が会社をMicrosoftに売るまでは。その後の彼の立場はより複雑なものになった)。事実VermeerとVisioは、そのほうが都合が良かったためにOffice UIをまねたようだ。その方がデザインをはじめからやり直すより、早くて簡単だったのだ。

Microsoftのプログラムマネージャのマイク・マシューがVermeerのWebサイトからFrontPageをダウンロードして試しに使ってみると、それはちょうどWordと同じような動きをした。プログラムはそう動くものだと彼が期待したようにFrontPageは動いたので、とても使いやすかった。そしてこの使いやすさのために、彼はこのプログラムに対し、はじめから好ましい印象を持った。

Microsoftははじめから良い印象を持ったため、1億5千万ドルかそこらの金を出した。あなたの目標はもう少し控えめなものだろう。あなたは顧客が好ましい印象を持ち、39ドルくらいで買ってくれることを望んでいる。しかし考え方は同じだ。一貫性は使いやすさをもたらし、それが好ましい感じをもたらし、結果としてあなたはより多くの収入が得られる

様々な種類のプログラムを人々が習得し使用する上で、一貫性がどれほど助けになるかは計り知れない。GUI以前には、すべてのプログラムがユーザインタフェースのもっとも基本的な部分から作り直されていた。｢exit｣のようなすべてのプログラムが持つ必要のある単純な操作ですら、まったく一貫性がなかった。その時代の人々は、プログラムを実行し終了させることができるように、一般的なプログラムのexitコマンドを必ず覚えたものだ。Emacs信者でもviを使っていてにっちもさっちもいかなくなったときのために、":q!"コマンドだけは覚えていた。viユーザは"C-x C-c"を覚えた(Emacsはコントロールキャラクタを表現する独自の方法さえ持っている)。DOSの世界では、Alt+Ctrl+F3が何をするのか思い出させてくれるキーボードにかぶせる変なテンプレートがないと、WordPerfectを使うことすらできなかった。私はプログラムから抜け出すためのF7コマンドだけ覚えていた。

そればかりでなく、(上書きか挿入かというような)デフォルトのタイピングの振る舞いなどにおける、ちょっとした非一貫性があなたを悩ませるだろう。私はWindowsアプリケーションで｢やり直し｣を意味するCtrl+Zに慣れていたので、Emacsを使うとき、しょっちゅう誤ってウィンドウを最小化(Ctrl+Z)してしまう。(おかしいのはEmacsがCtrl+Zを最小化と解釈するのはUNIXのC shell(csh)のあのひどいユーザインタフェースとの｢一貫性｣を保つためだと言うことだ。) これは積み重なると不幸せな感覚をもたらすところの、あの小さなフラストレーションのひとつだ。

さらに小さな非一貫性の例を挙げると、PicoとEmacsはどちらもCtrl+Kを行の削除に使うが、微妙に振る舞いが異なり、Picoを使っているといつも、私の文書はひどいことになってしまう。あなたもそういった例をたくさん知っているに違いない。

Microsoft Windows以前、Macintoshの初期の時代において、Appleの伝道者たちは、平均的なMacユーザが作業するとき、平均的なDosユーザよりもたくさんのプログラムを使うと宣伝していた。正確な数字は覚えていないが、平均的なDosユーザは1個か2個で、Macユーザは12個だったと思う。Macではプログラムは概ね同じように振る舞うため、新しいプログラムを習得するのがとても楽だから、というのがその理由だった。

一貫性は良いUIデザインのための基本原則だが、しかしこれは｢プログラムモデルをユーザモデルに合わせよ｣という原理の系にすぎない。ユーザモデルは、ほかのプログラムがどう振る舞うかユーザが見てきたことを反映しているためだ。ユーザがテキストのダブルクリックは語の選択を意味すると学んでいたなら、初めて見るプログラムを与えられたとき、彼らは語の選択をする方法がダブルクリックだと推測するだろう。そうなると、プログラムはダブルクリックされたとき語の選択をすべきであって(たとえばその単語を辞書で検索する、というのでなく)、そうでなければユーザビリティの問題をかかえることになる。

一貫性の利点がそれほど明らかであるなら、なぜ私はその伝道のためにあなたや私の時間を費やしているのだろう？残念ながら一貫性に抗する暗黒の力があり、それはデザイナとプログラマのクリエイティブであろうとする自然な傾向である。

私はあなたに｢クリエイティブであるな｣と言う人間の一人にはなりたくないが、ユーザインタフェースを使いやすいものにするためには、あなたはクリエイティビティを何か別な領域に向ける必要がある。UIに関する決定のほとんどに関して、あなたは何かをスクラッチからデザインする前にほかの有名なプログラムが何をやっているか調べ、できるだけそれをまねるようにする必要がある。あなたがドキュメントエディタか何かを作っているなら、共通なメニューアイテムのアクセラレータに至るまでMicrosoft Wordに合わせるべきである。Ctrl+Sで保存するユーザもいれば、Alt+F,Sで保存するユーザや、Alt,F,S(Altを放してからFを押す)を使うユーザもいる。べつな人々はプログラムの左上の領域からフロッピーディスクのアイコンを探してクリックする。この4つとも機能すべきであり、そうしなければあなたのユーザは好きなのと違うやり方を強いられることになる。

Microsoftとわざと違うやり方をしていることをマネジメントが誇っている会社を見たことがある。｢Microsoftがそうしているからそれが正しいと言うわけじゃない。｣と彼らは自慢し、意味もなく人々が使い慣れているのと違うユーザインタフェースを作る。あなたが｢Microsoftがそうしているからそれが正しいと言うわけじゃない。｣というマントラを唱え始める前に、二つのことをどうか考えてほしい：

たとえそれが正しくなかったとしても、MicrosoftがWordやExcel、Windows、Internet Explorerといったポピュラーなプログラムでそうしているのなら、何百万もの人々がそれを正しいと思うか、少なくともかなり標準的なものとなって、人々はあなたのプログラムも同じように動くものと思うようになる。たとえあなたがAlt+Leftは｢戻る｣のショートカットとして良くないと思ったとしても(Netscape 6.0のエンジニアは明らかにそう思っている)、Alt+Leftを前のページに戻るために使おうとするユーザは文字通り何百万もおり、ビル・ゲイツがスマーフの敵、悪しきガーガメルであるところの宗教原理に従うのを拒むなら、あなたは自分のプログラムを自己満足と独りよがりのためにだめにして、ユーザがそのために感謝することはないだろう。
そして、それが正しくないと言うことにそんなに確信をもたないことだ。Microsoftはユーザビリティテスティングにあなたよりも多くの予算を費やしており、テクニカルサポートへの何百万もの電話に基づく詳細な統計を取っている。彼らがそういうやり方をしているのは、そうすることでより多くの人々が使い方を理解できるためである可能性が高い。

使いやすいユーザインタフェースを持った良いプログラムを作るためには、あなたは最初に自分の信条から離れなければならないだろう。 Microsoftはまねるべき唯一の企業ではないかもしれない。あなたがオンラインブックストアを作っているなら、あなたはおそらくそのウェブサイトが少なくとも意味論的にはAmazonと同じであるようにする必要があるだろう。Amazonはあなたのショッピングカートを90日間保持する。あなたは自分が非常に頭が良く、カートを24時間で空にしようと思うかもしれない。あなたがそうしたとき、ショッピングカートに入れた商品が、2週間後に戻って来たときまだそこにあると期待しているAmazonの顧客がいるだろう。それがなくなっていれば、あなたは顧客を失うことになる。

あなたはグラフィックスのプロのためのハイエンド画像編集ソフトを作っているとする。私はあなたのユーザの90%はAdobe Photoshopを知っているだろうことを請け合える。だから機能の重なる部分についてはPhotoshopと同じように振る舞うようにしたほうがよい。もしそうしないなら、人々はあなたのプログラムが使いにくいと言うだろう。たとえあなたがPhotoshopよりも使いやすいと思っていたとしても。なぜなら、それは彼らが期待したように動かないからだ。

もうひとつ、Windowsについているコモンコントロールを作り直そうという一般的な傾向がある。Netscape 6について言わせないでほしい。大きな緑のチェックボックスつきの大きなOKボタンを使っているために、そのプログラムがBorland C++コンパイラでコンパイルされたのだとわかることがある。しかしこれもKai's Photo Soapほどまずくはなかった：

素敵だ、確かにとても美しい、しかし斜線つきの0(これは実際には"no"を意味する)は、私には"OK"を思わせるし、Windowsの標準では OKは左側なので、何度も間違ったボタンを押す羽目になった。"OK" "Cancel"以外の変な記号を使うことの唯一の利点は、あなたがいかにクリエイティブであるかを示せると言うことだ。もし人々がKaiのクリエイティビティのためにミスを犯すとするなら、それはアーティストがいるためだけに彼らが支払わなければならない対価ということになる(このダイアログのもう一つの問題は、それが標準的なタイトルバーを持たず、ダイアログをスクリーン上で動かせないと言うことだ。だからもしこのダイアログが、その質問に答えるために見たい何かの上にあるなら、それは不運としか言いようがない)。

おしゃれでかっこいいユーザインタフェースを持つことで得られることは多い。Kaiのような優れたグラフィックデザインは見ていて楽しく、人々を引きつける。秘訣はルールを破らずにそれをやるということだ。ダイアログの見た目をちょっと変えてもいいが、機能は変えないこと。

Junoの最初のバージョンが書かれたとき、それはユーザ名とパスワードを問う標準的なログインダイアログを持っていた。あなたがユーザ名を入れたらTABを押してパスワード欄に移り、パスワードをタイプするのだ。

WindowsよりはUnixの経験が長く、ユーザ名をタイプした後にENTERを押してパスワード欄へジャンプするのに慣れていたJunoのプログラムマネージャの一人は、このダイアログに混乱した。コンピュータのエキスパートでないWindowsユーザをターゲットとしたプログラムを書いているのなら、UNIXプログラマは典型的なユーザの例としてはおおよそ理想的ではない。しかしこのマネージャはENTERキーはWindows標準の"OK"ではなく、次のフィールドへの移動であるべきだと主張した。｢Microsoftがそうしているからそれが正しいと言うわけじゃない。｣と彼は言った。

そのため、プログラマは非常に複雑なダイアログ処理コードを書くのに膨大な時間を費やした。(一貫性をはずれることは、ほとんどの場合、プラットフォームが期待するように行動するよりも多くの作業が必要となる。) このコードはメンテナンスの悪夢をもたらした。それは16-bitから32-bitへ移行するときも簡単には移植できなかった。それは人々が期待したようには動かなかった。そして新しいプログラマがチームに加わったとき、その奇妙なダイアログのサブクラスがなぜ存在するのか分からなかった。

非常に多くのプログラマがWindowsの様々なコモンコントロール--ボタン、スクロールバー、ツールバーからメニューバーに至るまで--を再実装しようとしてきた(Microsoft Officeチームの好きなことは再実装だ)。Netscape 6.0はコモンコントロールのすべてを再実装することまでやっている。これには通常予期せぬ悪影響がある。いい例はエディットボックスだ。もしあなたがエディットボックスを再実装するなら、あなたの非標準エディットボックスを認識しないために機能しなくなる非常に多くの、あなたが名前さえ知らないようなユーティリティがあるのだ(中国語編集アドイン、右から左へ書くテキストをサポートする双方向バージョンのWindows)。Netscape 6.0のプレビューリリース版の評価者たちは、URLボックスが非標準のNetscapeエディットコントロールを使っており、右クリックでコンテキストメニューを出すといったコモンエディットコントロールの機能をサポートしてないことに気がついた。

あなたがアンチMicrosoft原理主義者とかクリエイティブなグラフィックデザイナとかと一貫性について議論しているとき、彼らはエマーソンを誤って引用することが多い。｢一貫性は小心者のゴブリンだ･･･。｣正確な引用は、｢馬鹿げた一貫性は小心者のゴブリンだ。｣というものだ。よいUIデザイナは一貫性を知的に使い、それによって彼らのクリエイティビティをひけらかせないかもしれないが、長い目で見ればユーザをより幸せにする。

第6章もっとほかにやることがある人々のためにデザインする