複数のユーザを同時にテストする（MUST）
一度に5～10人のユーザをテストすれば、大規模なユーザビリティテストも可能。しかも、納期にも間に合う。
大勢のユーザをテストしなければならないときもある。従来の手法で、精根尽き果てるまでひたすらユーザテストを繰り返していくというのが一つ目の選択肢だ。ただし、プロジェクトの締め切りに間に合わず困った事態に陥ることが多い。
もう一つ、複数のユーザを同時にテストするという選択肢、MUST（Multiple-User Simultaneous Testing）がある。その名が示すとおり、複数のユーザを同時にテストして期間を短縮するのだ。MUSTを使うときは、たいてい一度に5～10人のユーザをテストする（後述するが、もっと大人数を一度にテストするためのラボを作ることも可能）。一度にテストできるユーザの数に、理論的には上限はない。
MUSTを使うべきときは？
ユーザビリティ調査は通常、シンプルで小規模なものであるべきだ。しかし、MUSTを使った方が良い場合もある。
- 定量調査やベンチマーキング調査の場合、統計的な有意性を確保するためには、条件ごとに最低20名のユーザをテストする必要がある。
- 長期間に及ぶタスクの場合、確実な行動観察をするには、数日、または数週間にわたって各ユーザをテストしなければならない。例を挙げよう。
- 開発者用のツール。本職のプログラマーが使うことになるシステムの場合、20行のHello Worldプログラムを設計し、デバッグしてもらうだけではテストにならない。現実にあり得る規模の問題に遭遇し、対処する様を見せてもらわなければならないのだ。CADのような高性能アプリケーションの場合にも、同じことが言える。
- eラーニング。レッスン39をテストするには、レッスン1からレッスン38を終えてもらわなければならない。十分に作り込まれたeラーニングのコースなら、テストするのに1週間かそこらはかかるだろう。
- ユーザビリティに関するフォーカスグループインタビューの場合、従来の手法では避け得ないフォーカスグループインタビューの問題を解消するために、ユーザにはまず進行役とマンツーマンのセッションを受けてもらい、ユーザ・インターフェイスを直に体験してもらう必要がある。そのうえで集まってもらい、その体験を振り返ったり、日頃感じているニーズと付き合わせて意見を聞かせてもらったりするのだ。この手法には、MUSTがどうしても必要になる。フォーカスグループインタビューの直前に、参加者全員がインターフェイスを体験できるようにしたいからだ。
- ゲームのデザイン。この例については後述する。
複数のユーザを同時にテストする方法
一度に複数のユーザをテストするとなれば、テストの進行役も複数必要になる。長期間に及ぶテストの場合は例外で、少数の進行役が巡回したり、重要なところのビデオを見直したりすることで対応できる。
多くのユーザビリティ専門家を抱えているところなら、MUSTでも進行役に困ることはない。費用は嵩むが、効率も上がる。専門家なら調査はお手の物なので、一切を任せてしまえば良い。
しかし、各ユーザにユーザビリティ専門家を専属させられるほど潤沢にスタッフを抱えている企業は多くない。だが幸い、ユーザテストの進行はユーザビリティ専門家でなくてもできる。ベテランがテストプランを立て、タスクを書きさえすれば。
最近MUSTを使ったときには、Don Normanが以前教鞭を執っていたカリフォルニア大学サンディエゴ校（UCSD）で認知科学を勉強している学生に手伝ってもらった。彼らは、進行役として素晴らしい仕事をしてくれた。プロジェクトチームの開発者やマーケティング担当者に進行役をやらせたこともある。顧客の前に顔を出し、直接顧客に接することができるようにするには、MUSTの進行役をやらせるのが一番だ。
進行役のトレーニング
進行役初心者には、ユーザビリティのワークショップを受けてもらうのが理想だが、そうも言っていられないのが現実だ。ユーザの前に出す前に、ほんの2～3時間でもトレーニングをしておこう。
- まず、ユーザテストとは何か、どうあるべきものなのかを話して聞かせよう。これまでも繰り返し言ってきたが、“自分はなるべく喋らず、ユーザに話させること”といった基本的な心構えを伝えること。
- 次に、予備のセッションを経験豊富なユーザビリティ専門家が進行するところを見てもらおう。狙いは、次の2つである。
- 進行役初心者にセッションの進行方法を見せること。
- テストプランやテストタスクを、紙面上の議論や検討にとどまることなく、具体的に検証すること。
- 次は、ロールプレイングテストをやってみることである。ユーザビリティ専門家がユーザ役を演じ、進行役が遭遇する可能性のある難しい状況をシミュレートするのだ。あまり喋ってくれないユーザや、「この機能は使っても良いですか？」などと絶えず質問してくるユーザを装おってあげよう。（後者のようなユーザには、「家で（あるいはオフィスで）普段やっているようにご自由にやってください。」と返すのが基本である。）
ユーザを集める
MUSTだからといって、ユーザを集めるのに特別な準備はほとんど必要ない。テストユーザを集めるときの手続きを踏み、会場でお迎えして同意書にサインをもらい、必要な説明をすれば良い。
ただし次の2点は、通常のユーザテストの場合と異なる。
- ユーザには、パーティションか何かで区切った小さな作業スペースでテストを受けてもらうことになるため、思考発話は使えない。操作をしながら思ったことを口に出してもらう必要はないので、その説明は割愛しよう。
- 他のユーザの存在が気になって集中できないという状況をできる限りなくすために、他の人は別のタスクをやっているのだと伝えよう。そうすれば、他の人の画面をつい覗いてしまうような行動は減り、他の人が先にテストを終えて退室するのを見ても、気にせずテストを続けてもらいやすくなる。
自動テストを使わない理由
登録ユーザにウェブサイトを使わせてデータを取り、その結果を精緻なチャートにして納品してくれる企業がある。そういったところに外注できなくもないのに、わざわざ苦労してMUSTをやる意味はどこにあるのだろうか？ ウェブサイトやインタラクティブな製品にとって、ユーザビリティはその成否を握る鍵である。外注先の登録ユーザは、その任に堪えるものではない。
ユーザテストの一番の原則は、代表的な顧客を集めてテストすることである。登録ユーザがこの要件を満たしてくれることはまずない。巣にいるだけで働くことのない雄バチのように労せず日銭を稼ごうとする人が大勢登録して、オンラインテストに参加している。そんな低レベルの消費者を相手にしているのならこの方法で良いかもしれないが、建設技師や病院薬剤師などに商品を販売するB2Bサイトのテストには適さない。B2Cのeコマースサイトにも不適当だろう。
同僚がとあるサイトにお遊びで登録してみたことがあった。質問に精一杯誠実に回答して登録したにもかかわらず（誠実な回答をして登録している人は実際にはそう多くないことだろう）、どう考えても対象ユーザに当てはまらないのに調査の依頼が来た。これらの“調査”は、誤解につながりかねない結果をもたらす一種の迷信的ユーザビリティ調査である。
登録ユーザの中に代表的な顧客が含まれていたとしても、自動テストは本来のユーザビリティ調査にまだ追いつかない。ユーザの隣に腰を下ろすことができないからだ。データチャートには決して載ることのない細部に至るまで観察し、ユーザ個々人の行動を深く理解するために、直接観察ほど重要なものはない。
回答にもとづいてユーザをセグメントに分けることになるが、その出来が悪くて困ることも多い。たとえば、ペルソナを作って各セグメントをその名前で呼んでいるとしよう。「これが本当にSusan？ かなりPatrickに近いと思うけど…」 なんて台詞が口をついて出れば、このユーザをPatrickに分類し直すことになる。ときには、対象ユーザにまったく当てはまらなくて捨てるしかないデータもある。そのユーザの意見については、対象を分かつ境目の意見として使えるかもしれないが、核となるデータには入れられない。ユーザの横にいれば、状況をその場で判断して適宜対応できる。しかし、チャートを受け取るだけでは、ユーザの中に対象として際どい人や完全に対象外の人がいたのかどうかも分からないままになる。
プロジェクトチームのメンバーにユーザテストの進行役を担い、顧客に直に接してもらえば、彼らのモチベーションは格段に上がるだろう。500人分の匿名データに感情に訴えるものは欠片もないが、生きた人間の隣に座り、自分がデザインしたものを使えずに苦労する様子を目の当たりにすることで感じることは大きいはずだ。
洗練されたMUST用ラボ：Microsoft Games Studios
MUSTを実施する方法は色々とあるが、私の知る限りでもっとも立派なMUST用のラボは、MicrosoftのGames Studiosである。いくつかあるプレイテストラボのうちの一つがこれだ。
Microsoft Games Studiosのプレイテストラボ。
同じ部屋で複数のユーザに音の出るゲームをやってもらうにはヘッドセットを用意しよう
プレイテストラボ3室の平面図
Microsoft Games Studiosのユーザリサーチ担当マネージャであるDennis Wixonによれば、年間およそ8,000人のゲーマーにこのラボへ来てもらうそうだ。もの凄い数のユーザテストを行っているのである。平均的な企業が実施する調査量をはるかに凌ぐ数である。Microsoftが、ゲーム専用の立派なテストラボを必要とするのも当然だ。
（Microsoftのソフトウェアやウェブサイトは別のユーザビリティラボでテストされている。そちらのラボにはXbox 360を置いていない。Excelで円グラフを作ろうとするユーザの気が散っては困るからね。）
Microsoftが、ゲームのユーザビリティテストを数多く実施するのは何故か？ 巨額 の資金を投じるのは、Halo 3 のようなゲームソフトがXbox 360の売り上げの“決め手”になると考えられているからだ。Halo 3 が素晴らしければ、ゲーマーはXbox 360を買ってくれる。Halo 3 が不出来なら、古いXboxで我慢したり、PlayStationを買ったりしてしまうかもしれない。
Wixonのグループがどれ程の予算を持っているのかは知らないが、Halo 3 が発売第一週で売り上げた3億ドルのごく一部に過ぎないことは確かだ。Xboxの売り上げのうち、Halo 3 の成功に依る部分はさらに小さな割合になるだろう。ユーザビリティのグループが手がけているゲームはHaloシリーズばかりではない。しかし、Halo 3 だけでも、600名のゲーマーにプレーしてもらった3,000時間を超えるデータの分析をしたのだそうだ。徹底的にユーザ調査を実施したことで、Halo 3 はこれまで以上に面白いものとなり、Halo 2 を凌ぐ驚異的な売り上げの要となる新しいファンの獲得をも実現した。
コンピュータゲームの場合に多くのユーザをテストしなければならない2つ目の理由は、他の分野よりもゲームのユーザ・インターフェイス・デザインが難しいことにある。ゲームは常に、新たな世界を創り出そうとする。一方ウェブサイトは、一定のルールに従おうとする。ウェブサイトのテストで見られるユーザの行動は、既にガイドラインに記されているものばかりで容易に説明が付くのだ。どんな行動も、たとえば、「あぁ、これはガイドライン#728に該当するね」 と結論づけられる。他のサイトで同じように行動するユーザを過去に何度も目撃しているからだ。ガイドラインに記されている行動を確認するだけなら、それほど多くのユーザをテストしなくても良い。同じ行動が何度か観察されれば、道を誤っていないと自信を持って言えるからだ。過去の調査結果を足場にできるので、データの分析も簡略化できる。
機能性重視のインターフェイスよりも、巧みにバランスのとれたユーザ・エクスペリエンスを求めるのがゲームである。狙撃システムをデザインしているとしよう。軍隊向けのシステムなら、できるだけ素早く、そして正確に的を絞ることのできるインターフェイスを作らなければならない。敵が自分に照準を合わせる前に撃てるシステムを作るのだ。しかし、Halo 3 用に同様のシステムをデザインするとしたら、答えはそう簡単ではない。あまりにも素早く、簡単に照準を合わせられるようでは、ゲームは面白くならないからだ。汗ひとつかかずに敵を全員撃ちとりたいという気持ちは確かだが、ゲームが目指す のは、生死を分けるぎりぎりのところで勝利する快感を提供することだ。（危険に身を晒す本物の兵士なら絶対に避けたいと思うものだが。）
問題点を取り除くためにユーザ・インターフェイスをテストするのは簡単だ。適度な難しさを残せているかどうかを判断することこそが難しい。MicrosoftのGames Studiosが、プレイテストラボを使ってかくも多くのユーザをテストしているのは、このような事情があるからなのだ。
シンプルなMUST用ラボ
豪華なラボを持っていなくてもMUSTはできる。次の写真は、我々が最近MUSTを行ったときに使ったラボの様子で、このときは一度に5人のユーザをテストした。
会議室をアレンジして即席でブースを作りMUSTを実施。
（テストは5人同時に行ったが、写真は3人分のスペースを写したもの）
机に貼り付けた厚紙の仕切りで各自の作業スペースを即席した。きちんと仕切られた空間を用意できるに越したことはないが、こんな間に合わせでもまったく問題はなかった。このときは、進行役がユーザの画面遷移を横から覗き込まずに観察できるようスレーブモニターを一台ずつ用意したが、ユーザ用のモニターだけで十分な場合も多いだろう。
他にも、次のような環境でMUSTを行ったことがある。
- 個室オフィスを利用。（イントラネットの調査では、ユーザの実際のオフィスを使わせてもらった。） 個室オフィスは隣り合っているとも限らない（ビルも違うかもしれない）ので、一人のユーザに対して進行役も一人割り当てることになる。
- 複数のテストラボが並ぶ大規模なユーザビリティラボを利用。このときは、各テストラボにユーザを一名ずつ配置してタスクをやってもらった。大掛かりなタスクを数日かけてやってもらうような調査で、数人の進行役が巡回して歩けるようにするにはこれが一番である。進行役は、観察室を経由すればユーザに気づかれることなくラボを行き来できるので、ユーザの集中を乱すことなく、一日に大勢を観察できる。ユーザと言葉を交わすことなく中座できるので、重視していないタスクのときには、そうとは言わずに、かつユーザの行動に影響を及ぼすこともなく席を外せる。
- オフィスをネットワークラボに変えて利用。上記2つを合体させたようなもので、ユーザの個室オフィスを無線でつなぎ、一つの観察室で全ユーザを観察できるようにするのである。観察室に準備したスレーブモニターにLANを使って画面の動きを配信し、ウェブカメラを使ってユーザの表情を見られるようにする。
ユーザビリティ調査の大半は定性調査であるべきだし、5人のユーザをテストできれば十分なはずだ。しかし、数が求められる場合もある。そんなときはMUSTを使ってみると良いだろう。そうすれば、納期までに調査を終えられるはずだ。
2007 年 10 月 15 日
