Joel on Software このページは"ジョエル・オン・ソフトウェア

プログラマのためのユーザインタフェースデザイン
第1章
第2章
第3章
第4章
第5章
第6章
第7章
第8章
第9章

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

ユーザが新しいプログラムを使おうとするとき、彼らはまっさらな状態にあるわけじゃない。彼らはそのプログラムがどのように動くかについて、なんらかの期待を持っている ものだ。似たようなソフトウェアを以前にも使ったことがあるなら、それと同じような動きをすると期待するだろう。彼らが何であれソフトウェアを使ったことがあるのなら、彼らはあなたのソフトウェア も、ある共通の慣習に従っているものと考えるだろう。彼らはUIがどう機能するかについて知的な推測をしているかもしれない。これはユーザモデルと呼ばれ、プログラムが何をしてくれるかについてのユーザの心理的な理解のことである 。

プログラムもまた｢メンタルモデル｣を持っており、これはビット列に符号化され、CPUによって忠実に実行される。これはプログラムモデルと呼ばれ、律法である。第1章で学んだように、プログラムモデルがユーザモデルと一致しているなら、ユーザインタフェースは成功だと言える。

ひとつの例を見てみよう。Microsoft Word(およびほとんどのワープロソフト)では、画像をドキュメントに挿入したとき、その画像はドキュメントファイル自体に埋め込まれる。あなたは画像を作り、それをドキュメントにドラッグし、それからもとの画像ファイルを削除しても、ドキュメントの中の画像はそのまま残る。

さて、HTMLではこうはならない。HTMLドキュメントでは画像は別なファイルに保存しなければならない。もしワープロを使い慣れているがHTMLについては何も知らないユーザを連れてきて、そしてFrontPageのようなすてきなWYSIWYG HTMLエディタを使わせたとしたら、彼らはほとんど間違いなく、画像ファイルがHTMLファイルの中に保存されると思うだろう。これをユーザモデルの惰性とでも呼ぶことにしよう。

そしてユーザモデル(画像は埋め込まれる)とプログラムモデル(画像は別なファイル)との間には不幸な食い違いがあり、UIは問題を生じることになる。

もしあなたがFrontPageのようなプログラムを設計しているのなら、あなたは最初のUI上の問題に直面したことになる。あなたはHTMLの仕様を変えることはできない。プログラムモデルをユーザモデルに合わせるための何かが必要だ。

選択肢は二つある。あなたはユーザモデルを変えようと試みることはできる。しかしこれは非常に難しいということがわかるだろう。あなたはマニュアルの中で説明することもできるだろうが、ユーザがマニュアルを読まないことは誰でも知っているし、マニュアルを読まないと使えないというのは好ましくない。画像ファイルは埋め込まれませんと説明する小さなダイアログボックスを出す手もあるが、これには二つの問題がある。使い慣れているユーザには煩わしいこと、そしてユーザはダイアログの内容なんて読まないということだ(これについては第6章で詳しく扱う)。

だから山がマホメットのところに来ようとしないなら･･･ほとんどすべての場合に一番良い選択は、ユーザモデルではなくプログラムモデルの方を変える、ということだ。彼らが画像を挿入するとき、ドキュメントファイルのあるディレクトリにサブディレクトリを作って画像のコピーを置くことで、｢画像はコピーされる(そしてオリジナルの画像は安全に削除できる)｣というユーザの発想に、プログラムを合わせることができる。

ユーザモデルが何かをどうやって知るか？

この問題は比較的簡単なことがわかるだろう。彼らにただ聞けばいいのだ！同僚や友人や家族の中から5人ランダムに選び、あなたのプログラムが何をするのか普通の言葉で説明する(｢これはWebページを作るためのプログラムだ。｣)。それから状況を説明する 。｢あなたはあるWebページと、Picture.JPGという画像ファイルで作業していて、その画像をWebページに挿入する。｣ それからいくつかの質問をして、彼らのユーザモデルを推測する。｢画像ファイルはどこに行くと思う？Picture.JPGを削除してもWebページに画像は表示されると思う？｣ 

私のある友達がフォト･アルバム･アプリケーションを作っていた。写真を入れると、そのアプリケーションは一連のサムネイル(それぞれの画像の小さなコピー)を表示する。ところで、このサムネイルを生成するのにはちょっと時間がかかる。特にたくさんの画像を入れた場合にはそうだ。そこで彼は、サムネイルの生成が一度だけですむように、ハードディスクのどこかに保存されるようにしたいと思った。それにはいくつもの方法がある。Thumbnailsという名前の一個の大きなファイルにすべてのサムネイルを保存することもできる。Thumbnailsという名前のサブディレクトリにバラバラのサムネイルを保存することもできる。それをオペレーティングシステムの隠しファイルに設定して、ユーザにはわからないようにするかもしれない。私の友達は彼がもっともバランスがとれていると思った方法を選択した。それぞれの画像picture.JPGに対して、そのサムネイルをpicture_t.JPGという名前で同じディレクトリに保存する、というものだ。30枚の画像からなるアルバムを作ると、ディレクトリにはサムネイルも含め60枚の画像ができることになる。

画像を保存するそれぞれの方法について、その長所短所を何週間でも議論することができるだろう。しかしそれよりももっと科学的な方法がある。たくさんのユーザに、サムネイルがどこに保存されると思うか聞いてみるのだ。もちろん彼らの多くは、知らなかったり、気にかけてなかったり、考えたこともなかったりするだろう。しかしたくさんの人々に聞いたなら、あなたはある種のコンセンサスがあることに気づくだろう。もっともポピュラーな選択が最良のユーザモデルであり、プログラムモデルをそれに合わせるのがあなたの仕事だ。

次に、あなたの理論をテストする必要がある。ユーザインタフェースのモデルないしはプロトタイプを作り、何人かの人に作業を与える。彼らが作業をしているとき、何が起こっていると思うか質問をしてみる。あなたの目標は彼らが何を期待しているのか解明することだ。作業が｢画像を挿入する｣ことであり、そして彼らが画像をプログラムにドラッグしようとしているなら、あなたはドラッグ アンド ドロップをサポートした方が良いということがわかるだろう。もし彼らが挿入メニューを使おうとするなら、挿入メニューに画像の選択肢を入れた方が良いことがわかるだろう。もし彼らがフォントツールバーで"Times New Roman"を"Insert Picture(画像を挿入)"に変更しようとしているなら、GUIを使った経験がなく、コマンドラインインタフェースを期待しているいまどき珍しい人を見つけたことになる。

ユーザインタフェースをテストするためには何人のユーザが必要だろう？あなたの直感は｢多いほど良い｣というものかもしれない。これは科学では意味のあることだが、正しくない。ユーザビリティテストを生業としている人々のほとんどは、5、6人で十分と考えているようだ。それ以上やったところで同じ結果を何度も見ることになるだけで、追加ユーザは時間の無駄にしかならない。

フォーマルなユーザビリティラボは必要なく、実際のところユーザを通りから連れてくる必要もない。単にあなたが次に出会う人を捕まえ、簡単なユーザビリティテストを頼むという｢50セント ユーザビリティ テスト｣をすればよい。口をすべらせてどうやるのか教えてしまわないように気を付けること。｢声に出して考えてください。｣と頼み、yes/noでない質問をし、彼らのメンタルモデルの発見に努めるのだ。

プログラムモデルが自明でないなら、それはたぶんユーザモデルとは違っている

私が6歳の時、父が世界初のポケット電卓HP-35を買ってきて、その中にはコンピュータが入っているのだ、ということを私に理解させようとした。私はそんなはずはないと思った。スタートレックに出てくるコンピュータはみんな部屋ほどの大きさがあって、リール式のテープレコーダがついていた。単に巧妙な相関関係がキーパッドのキーと発光ダイオードの個々の要素との間にあって、たまたま数学的に正しい答えが出ているのだと私は思っていた(なにしろ6歳だったから)。

重要な経験則がある。ユーザモデルというのはあまり複雑なものではない、と言うことだ。プログラムがどう動くのかと人々が推測するとき、複雑なことよりは単純なことを推測する傾向がある。

Macintoshの前に座って、Excelの二つのスプレッドシートとWordドキュメントを開く。新米ユーザのほとんどはウィンドウが独立なものと思っている。それらは独立しているように見える：

ユーザモデルはスプレッドシート1をクリックすると、そのウィンドウが前に出てくるというものだ。実際に起こるのはスプレッドシート2が前に出くることで、これはほとんどすべての人にとっていらだたしい驚きを与える：

Microsoft Excelのプログラムモデルは｢それぞれのアプリケーションには見えないシートがあり、アプリケーションのウィンドウはそのシートに貼り付いている。ひとつのExcelを前面に出すと、ほかのExcelのウィンドウもいっしょに前に出てくる。｣というものだ。

なーるほどね。見えないシートか。ユーザモデルが見えないシートなんていう概念を含んでいる可能性がどれくらいある？たぶんゼロだろう。だから新しいユーザはこの振る舞いに驚くのだ。

Microsoft Windowsの世界におけるもうひとつの例はAlt+Tabキーだ。このキーの組み合せは次のウィンドウに切り替える。ほとんどのユーザはすべてのウィンドウが順繰りに選択されると思っているだろう。ウィンドウA、B、CがあってウィンドウAがアクティブな時、Alt+TabでウィンドウBに切り替わり、もう一度Alt+Tabを押すと、ウィンドウCに切り替わると。実際に起こるのは、2回目のAlt+TabでウィンドウAに戻るということだ。ウィンドウCに切り替える唯一の方法は、Altを押したままの状態でTabを2回押すことだ。これは二つのアプリケーションを切り替えて使うのにはいいやり方だが、｢すべてのウィンドウを順繰りに｣モデルよりも複雑なため、ほとんどのユーザはこれを理解しない。

モデルが単純な場合でも、プログラムモデルをユーザモデルに合わせるのは結構難しいものだ。モデルが複雑になるといっそう困難になる。だから可能な限り単純なモデルを選ぶようにしよう。