プログラマのためのユーザインタフェースデザイン 第9章: 製品デザインプロセス

From The Joel on Software Translation Project

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

私たちは良いデザインの原則について話してきたが、原則は既存のデザインの評価と改善のための手段を与えるだけだ。しかし･･･そもそもデザインがどうあるべきかどうやって見出せばいいのだろうか？多くの人は、大きな、考えつく限りの機能のアウトラインを書く。それから各機能をデザインし、メニューアイテム(あるいはWebページ)にくっつける。それが終わったとき、プログラム(あるいはWebサイト)は望んでいたすべての機能を持っているが、正しく遷移しない。人々はそれが何をするのか分からず、彼らの望むことをどうやって実現できるのか知らない。

Microsoftのこれに対する解法は、アクティビティベース プランニングと呼ばれるものだ。(私に言える限りでは、このコンセプトはExcelチームのマイク・コンテが発明したものだ。彼はそれに飽きてカーレースドライバに転職した。) 鍵となる洞察は、ユーザがしているアクティビティを見出すことで、そのアクティビティの達成を容易にすることに努力を集中するのだ。これは例で説明するのが一番いい。

あなたはユーザがグリーティングカードを作成できるWebサイトを作ることにしたとする。あなたはいくぶんナイーブなアプローチを取って、以下のような機能リストを作るかもしれない：

カードに文章を追加する カードに画像を追加する ライブラリからデザイン済みの(出来合いの)カードを取り出す カードを送る： emailで送る 印刷して送る

この問題について考えるもっと良い方法がないため、これは1984年頃の典型的なMacintoshのユーザインタフェースに導かれるかもしれない：プログラムは白紙のカードで始まり、メニューを使って文章と画像を追加し、ライブラリからカードをロードし、カードを送る。次にユーザがしなければならないことは、座ってメニューを一通り眺め、使えるコマンドを全部理解しようとし、そして、これらの基本的なコマンドをどう組み合わせたらカードが作れるか考えることである。

一方、アクティビティベース プランニングでは、最初にユーザがするだろうアクティビティのリストを作る。そこであなたは潜在的なユーザたちと話し、｢トップ3｣のリストを作る：

1. 誕生カード
2. パーティの招待状
3. 記念日に送るカード

プログラマのようにプログラムについて考える(カードを作るためにはどんな機能が必要か)のではなく、具体的にユーザがするアクティビティは何かという言葉で、ユーザのように考えてみる：

1. バースデーカードを送る
2. パーティを計画し、人々を招待する
3. 記念日のカードを送る

突然、あらゆる種類のアイディアがあなたの頭に飛び込んでくるだろう。空白のカードから開始するのでなく、次のようなメニューであなたは始めるかもしれない：

何をしたいですか？ バースデーカードを送る 記念日のカードを送る パーティーの招待状を送る 空白のカードから始める

ユーザはあなたのプログラムの方がずっと楽にやり始められることに気づくだろう。アクティビティを完了するためにプログラムがユーザを各ステップを通してリードしてくれるので、メニューを見て回る必要もない。(あなたがアクティビティを正しく選択しなかったなら、ユーザを遠ざけたり混乱させたりするというリスクは存在する。たとえばユーザがハヌカー祭のカードを送ろうとしたけれど選択肢にないといったような。だからアクティビティの選択は、あなたがターゲットとするマーケットの大多数をカバーするよう、注意深く行うこと。)

3つのアクティビティのリストを見ているだけで、あなたが追加したいと思うすばらしい機能が見えてくる。たとえば、バースデーカードか記念日カードを送ろうとしているのなら、翌年も同じ人にカードを送るのを思い出させてほしいと思うかもしれない･･･そしてあなたは｢翌年も送る｣チェックボックスをつけるかもしれない。パーティの招待状には参加の可否を確認する方法が必要なので、電子的に出欠情報を集める機能をつけるかもしれない。これらの機能のアイディアはアプリケーションの機能ではなく、ユーザの行うアクティビティを見ていて出てきたものである。

この例は簡単だが、重要なアプリケーションでアクティビティベースプランニングから得られるものはもっと大きなものとなる。プログラムをスクラッチからデザインする場合でも、ユーザがどんなアクティビティを行うだろうかについてのビジョンを、あなたはすでに持っている。このビジョンを見つけるのは難しいことではない。同僚とちょっとブレーンストーミングをし、可能性のあるアクティビティについてのリストを書き出し、その中のどれにフォーカスするかを決めるということにさほどの努力は必要とならない。これらのアクティビティを必ず紙に書き出すようにしておくと、デザインの過程全体を通してとても助けになるだろう。

アクティビティベース プランニングは、人々がすでに使っている製品の改訂版の作業をしているとき、より重要になる。その場合には、サンプルに選んだ顧客があなたの製品を何に使っているのか観察する、ということになるだろう。

Excel1.0から4.0までの間、Microsoftのほとんどの人がExcelのもっとも一般的なユーザアクティビティは、インフレ率を変えると収益性にどう影響するか見てみる、というようなファイナンスに関するもし-ならばシナリオ分析をすることだと考えていた。

私たちがExcel 5.0をデザインしていたとき、これはアクティビティベース プランニングを本格的に適用した最初のメジャーリリースだったが、5人ほどの顧客が製品を使っているところを見ただけで、たいていの人はExcelをただ表の管理のためだけに使っているということが分かった。彼らは数式を入れたり何か計算をしたりといったことを全然してなかったのだ！私たちはこんなことをそれ以前にはまったく考えていなかった。Excelにおいては表の管理がほかのどんなアクティビティよりもずっとポピュラーだということが明らかになった。そしてこのことから、私たちは表の管理を簡単にするためのおびただしい数の機能を作った：より簡単に行えるソート、データ入力の自動化、表のスライスを見ることができるオートフィルタ機能、そして複数のユーザが同時に同じ表を使って作業ができるようにExcelが自動的に調整するマルチユーザ機能など。

Excel 5がデザインされていた間に、LotusはImprovという、｢ニューパラダイム｣表計算ソフトを出荷した。プレスリリースによれば、Improvはまったく新世代の表計算ソフトで、それ以前にあったすべてのものを吹き飛ばすだろう、ということだった。さまざまな奇妙な理由により、Improvは最初、売上げには貢献しないだろうNeXTコンピュータ向けのものが売り出されたが、多くの賢明な人々が、NeXTにとってImprovはApple IIにとってのVisiCalcになるだろうと信じた：そのプログラムを走らせるだけのために、人々が新しいハードウェアを買いに行くキラーアプリケーションになるだろうと。

もちろんImprovはいまや歴史にわずかに名をとどめるにすぎない。Webで探してみれば、見つかるリンクは、組織化過剰な在庫管理者が何かの理由で作った在庫の総目録のWebサイトくらいなものだ。

なぜか？それはImprovでは表を作るのがほとんど不可能だったからだ。Improvのデザイナは、人々は表計算ソフトを複雑な多次元ファイナンスモデルを作るのに使うと考えた。彼らがユーザに尋ねていたなら、多次元ファイナンスモデルより表作成のほうがずっと一般的であることが分かっただろうに。そしてImprovでは表を作るのが不可能と言わないまでも非常に面倒だったのだ。

アクティビティベース プランニングは、ユーザが何をしたいだろうかと想像する必要のあるアプリケーションのファーストリリースにおいて有用なものだが、アップグレード時には、開発者は顧客が何をしているのかわかるので、さらに有用となる。

Webの世界における別な例として、deja.comの進化がある。それはdejanewsと呼ばれるUsenetの巨大な検索インデックスとして始まった。もともとのインタフェースは、エディットボックスに｢Usenetでこれこれについて検索｣と入力するだけのものだった。1999年に、少しばかりのアクティビティベースプランニングにより、一般的なユーザアクティビティの一つは製品やサービスについて、｢どの車を買ったらいいか｣といったたぐいのことを調べることだとわかった。Dejaは完全に再編成されて、今日ではどちらかといえば製品についての意見を調べるサービスとなっており、Usenet検索機能はほとんど完全に隠れている。これはMatroxのビデオカードが Redhat Linux 5.1で使えるかどうか調べるような少数のユーザを煩わせたが、単に一番いいデジカメを買いたいと思っているような大多数のユーザには喜ばれた。

アクティビティベース プランニングのもうひとつのすばらしいところは、いらない機能の一覧を作れるということだ。あなたがどんな種類のものであれソフトウェアを作るときには、作るのに使える時間より三倍多くの機能を思いつく、というのが現実だ。どの機能を作るか決める最良の方法は、どの機能がもっとも重要なユーザアクティビティをサポートするか評価してみることだ。

[edit] 想像上のユーザ

この業界の最高のUIデザイナたちは次のことに同意している：あなたは想像上のユーザを作り出して記述することなしにUIをデザインできない、ということだ。あなたはこの本のイントロダクションで、想像上のユーザ、ピートを導入したことを思い出すかもしれない：

ピートは技術系出版社の経理士で、Windowsを仕事で6年使っており、家でも少し使っている。ピートは非常に有能で技術に強い。彼は使うソフトウェアを自分でインストールし、PCマガジンを購読しており、請求書を送る事務員たちのために簡単なWordマクロを書いてやったこともある。彼は家ではケーブルモデムを使っている。Macintoshは使ったことがない。｢あれは高すぎる。｣と彼は言うだろう。｢同じ値段で128Mのメモリを積んだ 700MhzのPCが買える･･･。｣ よし、ピート。君の人物像がつかめた。

これを読むと、あなたはひとりのユーザを想像することができるだろう。私はまったく別なタイプのユーザを作り出しても良かった：

パトリシアは英文学の教授で、評判のよい詩集を何冊か書いている。彼女は1980年以来コンピュータをワープロ作業のために使っているが、彼女が使ったことのあるプログラムはNota Bene(時代物の学術向けワードプロセッサ)とMicrosoft Wordの二つだけだ。彼女はコンピュータの仕組みを学ぶために時間を費やすつもりはなく、そして彼女はドキュメントを、ディレクトリについて何も知らなければそこに保存されるところのディレクトリにいつも保存していた。

ソフトウェアをピートのためにデザインするのとパトリシアのためにデザインするのとでは、全然違うのが明らかだ。パトリシアはまた、自宅でLinuxを走らせ、何時間もIRCチャットし、"Micro$oft"のソフトを使わない16才のマイクとも全然違っている。

こういったユーザを作り出すと、あなたのデザインが適切であるか考えるのがずっと簡単になる。たとえば、多くのプログラマは典型的なユーザの理解力を過大評価している。私がコマンドラインインタフェースの使いにくさについて何か書くといつも、コマンドラインインタフェースは非常に強力で、 'gunzip foo.tar.gz | tar xvf -'みたいなことができるといった内容のemailの集中砲火を浴びる。しかしパトリシアに"gunzip..."とタイプさせることを考えてみるとすぐに、そのようなインタフェースは彼女のニーズをけっして満たさないだろうことが明らかとなる。"実在感のある"人物について考えることは、その人のニーズを満たすために何かの機能を作らなきゃいけない、と感じさせる。(もちろん、あなたが上級システム管理者のためのLinux用バックアップソフトを作っているなら、"フランク"のようなキャラクタ--Windowsにさわることを拒み、それに言及するときはただ括弧付きで｢オペレーティングシステム｣と呼び、自分で手を入れたtcshを使い、一日中4つのxtermを並べたX11を走らせている--を作り出す必要があるだろう。)

要約すると、良いソフトウェアのデザインは6ステップからなる：

1. ユーザを作り出す
2. 重要なアクティビティを見つける
3. ユーザモデル--そのアクティビティを行うためにユーザがどういう期待をするか--を理解する
4. デザインの最初のドラフトを書く
5. あなたの想像上のユーザの能力で十分楽に使えるようになるまで、より簡単になるよう繰り返しデザインしなおす
6. 現実の人間があなたのソフトウェアを使おうとしているところを観察する。人々がつまずいた部分に気をつける。それはたぶん、その部分でプログラムモデルがユーザモデルと合っていないことを示している。

よいUIはソフトウェアが売れるようにするが、それは人々を幸せにもする。なぜならやりたい仕事を達成できたとき人々は幸せになるのだから。それがUIデザインがこうもやりがいのある分野である理由なのだ。ほかのどんなことで何百万もの人々を少しばかり幸せにしてやることができるだろう？

この記事の原文（英語）はUser Interface Design for Programmers Chapter 9: The Process of Designing a Productです。

戻る