マルチタスク型製品の場合

自動車のカーオーディオを使うユーザーは、車を運転し走らせるというタスクと、音楽を聴くという2つのタスクを同時に行います。リビングルームの壁面にあるインターフォンのユーザーは、テレビ番組を視聴するというタスクをしている最中に来客を知るという2つ目のタスクをします。
入院患者の血管に薬液を投与するときに看護師が使うポンプ、投与には1時間も1時間半もかかります。その間、看護師は他の患者に薬液を投与したり、世話をしたり、別のタスクをします。
このようなマルチタスク型製品の場合、ユーザビリティテストの目標（知りたいこと）設定については、どのように考えたらいいでしょうか。

あなたはカーオーディオ製品のメーカーで開発中の試作機のユーザビリティテストを担当しているとします。
ドライバーが一般市街地を法定速度で自動車を運転中に、視線は前方を見たまま、左手の指を使ってラジオ番組を自在に切り替える新しい試作機が完成しました。カーオーディオの新製品です。AMやFM、ユーザーが好きなラジオ番組を自由自在に聴くことができるか、運転しながら視線は前方を見たまま、音量調節もしながら好きな番組を楽しめるかどうか、ユーザビリティテストで確認することになりました。使うのはドライビングシミュレーターです。

このケース、ユーザビリティテストで私達が知りたいこと、確認したいことは何でしょうか？ テストが終わった段階で私達は何がわかればいいでしょうか？　少し考えてみましょう。あなたが思いついたことはどんなことですか？

目標1
視線は前方を見たままで、好きなラジオ番組を選び、音量調節して聴くことができるか、知りたい。

ですね。確かにそれは知りたいことです。開発プロジェクトリーダーの要求はそれだけです。
こんなケース、あなたはどうしますか？ プロジェクトリーダーの要求はそれだけなんだからそれが確実にわかるように計画する、それだけでしょうか？
あなたが実際に車を運転していたとしたらどうでしょうか？
視線は前方を見たまま操作できると言っても、長い時間片手運転を続けるのは不安だと言う人もいます。あなたは麻雀をしたことはありますか？もうパイといいますが、中央に積まれたハイを他の人に見えないように一つずつ取るときに親指の平でなぞって模様を触覚で読み取ります。模様無しや、いーぴん(日の丸のような形)などはすぐにわかりますが、触っただけではわからないものも沢山あります。右手だけでハンドルを持ち、前方を見て運転している最中に、左手の指でスイッチを触り、あれ！これ文化放送かな？TBSかな？日本放送かも？ と迷ったらどうなるんだろう。結局、視線を前方から左手に移したりするかもしれない。大丈夫だろうか？ いろいろ疑問がありますよね。
そういう疑問の答が知りたいですよね。

つまり、次のことも知りたい。
目標2
走行中、視線を前方から左手に移した回数。
どの被験者もこの回数がゼロであれば、確かに前方を見たまま触角だけで操作できたと言えるでしょう。しかし、この試作機は新製品ですからユーザーははじめて見て、はじめて使います。使い方を理解し触覚だけでわかるようにある程度の練習も必要です。一定の練習をした後、タスクを10回繰り返し、毎回のタスクで「視線が左手に移動した回数」のデータが採れればいいでしょうね。もちろん理想はゼロです。

目標3
走行中、視線が左手に留まった時間
たまに視線が左手に移動することは全くないでしょうか。10回に1度、2度くらいあるかもしれません。ある程度視線移動はあるのが自然かもしれません。仮に、視線移動があった場合、視線が左手に留まる時間、言い換えると視線が前方を向いていない時間がどのくらいになるかは、とても重要です。1秒も2秒も視線が左手に留まるようでは、脇見運転していることになりますから、危険な運転になります。ですから、走行中の視線が左手に留まる時間は0.1秒の精度で測定する必要があります。

ここまで考えて、あなたの中に何か疑問は残っていませんか？
道路状況に大きく左右されるではないかと言うことです。
前方を走っている車が1台もなく、後方に続いている車もいない、そういうときなら、視線が左手に移動しても、視線を戻すのに1秒以上かかったとしても困ることはありません。しかし、時速60キロで走行中、すぐ前を車が走り、その車のスピードが速くなったり遅くなったりするときには、追突や後からの衝突の危険が高まり、視線は前方に釘付けになりがちです。こういった道路状況と走行スピードなどは適切な条件を設定することになります。

目標4
事故発生回数
ドライビングシミュレーターの仕様にもよりますが、前の車に追突せず、後ろの車から衝突されない、車線変更時に衝突しない、その他の交通事故を起こさないかどうか。これが一番大切なことですね。
ですから、事故発生がゼロだったのかどうか知る必要があります。
前方を見たまま、左手の触覚だけでカーオーディオの操作ができても、交通事故を起こしては元も子もありません。

以上のように、マルチタスク型の製品では、ユーザビリティテストにおける目標（知りたいこと）は、ふたつのタスクにそって設定する必要があります。自動車以外の分野の製品を扱っている場合は上記を参考にしてユーザビリティテストの目標を設定しましょう。

開発中の試作品のユーザビリティテストで、問題見逃しにつながるケースはどんな場合でしょうか？実際のテストのやり方、進行の仕方によっては様々な理由で問題見逃しが起こりますが、いくらテスト進行を完璧にやったとしてもテストデザインが不備であれば問題見逃しが起きてしまう可能性があります。それはどんなことでしょうか？
ひとつは、テストの目標(知りたいこと)設定の失敗です。本来、ユーザビリティテストをするときは、そのテストを実施することによって何を知りたいのか、いかなる知見を得たいのか明確にし、文書化し、関係者で共有します。
スマートフォンのアプリの試作品の場合で考えてみましょう。例えば、ユーザビリティテストを前に次の 2つの目標を決めました。
1 メールの署名欄の修正ができるか知りたい。
2 過去に受信したメール本文の一部をコピーして新しいメールを作成することができるか知りたい。
この2つにもとづいてタスクを決めユーザビリティテストをしましたが、リリース後、実際にユーザーから問い合わせが多発、予想外の問題が発生しました。新しいメールアドレスの登録が難しく、多くの人達がてこずることが判明、問題を見逃していたことに気づきました。この例は目標設定の失敗です。
このような目標設定の失敗を防ぐにはどうしたらいいでしょうか。ユーザビリティテストは限られた時間で行いますから実施できるタスクの数は限られます。ユーザビリティテストで何を確認し、何の知見を得たいのか、目標設定段階での失敗をなくすには、どうしたらいいでしょうか？必要不可欠な確認目標(このタイミングでどうしても確認すべきこと)の設定漏れをなくすには、必ずしも確認の必要がない項目を過剰に盛り込まないためには、どうしたらいいでしょうか？

目標の設定漏れをなくす
考え方としては以下の通りです。まず、製品の全タスクをリストアップします。次に、すでにユーザビリティの品質確認が終わっているタスクを消しこみます。その次に、未確認タスクの
優先度を決めます。その次に、優先度の高いものからテストで実施するタスク候補を決めます。その次に、チームリーダーにタスク候補を示してこれから行うユーザビリティテストの目標を確認します。
これらは大まかな考え方に過ぎません。実際の業務で対応するテストは様々に条件の異なるものばかりですが、上記の考え方を踏まえて現実的に対応してください。

全タスクをリストアップ
この作業は試作品の品質確認担当だけが行うものではありません。と言うより試作品ができる頃には、既にリストアップされている場合がほとんどでしよう。仕様書、外部仕様書、ユーザインタフェース仕様書、ユーザビリティ仕様書、こういった名前の文書の中に記載されていると思います。もし記載されていないなら開発プロジェクトのリーダーか あなたに試作品のユーザビリティ品質の確認業務を与えてくれた方から情報をもらうことができます。
それでも、全タスクのリストがない場合は、あなたが作るしかありません。既にリストがあった場合でも、明らかに不充分なタスクリストかもしれません。そういうときは、次の枠組みを踏まえてタスクリストを点検し、補強してください。

使用頻度の高いタスク
使用頻度の高いタスクに漏れはありませんか？どのユーザーでも頻繁に行うタスクが、わかりにくく、つまずいては大問題です。スマートフォンで言えば、電源オンオフ、電源は切らないが画面表示だけオフにする操作、それを戻す操作、対象物を選択する操作、画面上をなぞって画面を動かす操作、キーワードを入力しネット上で検索する操作、メール受信発信の操作、このような多くのユーザーが頻繁に行うタスクは、しっかりリストアップして漏れのないようにしましょう。

基礎タスク
使用頻度の高いタスクのリストができたら、次は基礎タスクの漏れを検討します。
例えば、メールアドレスの登録など、使用頻度は高くはないが、頻度の高いタスク(メール発信)の基礎となるタスクです。私は、今使っているスマートフォンでメールアドレス登録をしたことがありません。半年以上使っていてもやり方がわからないのです。マニュアルで調べればわかるでしょうが、このくらいのことは自然にわかりたいものです。
メールアドレスの登録がわからないと、出すのは返信ばかり、自分からメールを出すのは億劫になりますし、出すときは宛先欄にいちいち手入力しなければなりません。

重大タスク
重大タスクの漏れがないかを検討します。問題が起こったときに、重大な影響が生じる可能性のあるタスク、つまり生命の安全、健康への影響、財産、金銭の損失、信用の消失、データ消失などにつながる可能性のあるタスク、こう言う重大タスクは目標として設定し確認する必要があります。スマートフォンで言うと、ネットショッピング、本人が買ったつもりがないのに買ったことになった り、買ったはずなのに、実際には買われていない。
また、人が行う操作は必ずしも、本人がしっかり意識した操作ばかりではありません。本人が気づかないうちに、あるいは勘違いしてやっている操作もあります。毎年、大勢のドライバーがアクセルとブレーキを間違えて事故を起こしています。事故は日本国内で2008年に6600件、9600人の死傷者があったと言われています。
あなたが担当する製品の場合、どんな重大タスクがありますか？

懸念タスク
懸念タスクの漏れを検討します。懸念タスクとは、その製品のユーザインタフェースを設計した開発者、ユーザインタフェースデザイナーが不安に感じているタスクのことです。ユーザインタフェース設計はひとつの正解があるわけではありません。ある経験をしたAさんのようなユーザーにはわかりやすいが、その経験をせず、別の経験をしたBさんのようなユーザーにはかなりわかりにくい、結局、多くの人々にとってわかりやすく、わかりにくい人達ができる限り少なく、わかりにくさ加減も少しのわかりにくさになっている。そういうバランスだと思います。ですから設計者が、ユーザーにうまく伝わるか心配だと感じているタスク、懸念タスクはユーザビリティテストで確認しておくべきです。しかし懸念内容は文書化されていないことが多いでしょうから、評価担当者が一通り点検した段階で、「あれ？」と感じた箇所も含めて、ユーザインタフェースの設計者と相談し、懸念タスクがないか確認することをお勧めします。

セールスポイントのタスク
セールスポイントのタスクが漏れていないかの検討です。
製品を買ってくれたユーザー、その中にはメーカーが宣伝するセールスポイントに惹かれて買ってくれる人も少なくないはずです。セールスポイントのタスクが難しいようではユーザーに買って良かったと感じてもらうことはできません。

最悪のシナリオ
最悪の状況で、起こり得る問題が充分検討されているかの検討です。
これについては別途、触れます。

私の長年の経験では、タスクのゴールの付近は問題の宝庫です。以前に、ネットショッピングのタスクをしたとき、被験者3人とも、本人たちは目的の商品を買えたと思ったのに1人分の商品は届いたがあとの2人の商品は届かなかったことがあります。注文できたときの確認画面と注文に失敗したときの確認画面がはっきりとした差がなく、被験者は失敗したときの画面を見て購入成功と勘違いしたのです。このケースは実際にはまだゴールに到達していないのに被験者がゴールだと勘違いした例です。
その反対のケースもよく発生します。ネットショッピングで言えば、正常に購入成功したのに、よろしければユーザー登録してくださいなど、一見まだタスクが続いているかのような誘いに惑わされ、経験の浅い被験者が「あれ？まだ終わってなかったのかな？」と迷い続けたりします。

皆さんはタスクのゴールをどのように設定していますか？タスクを達成したのか達成してはいないのか、判断基準を文章で記述していますか？タスク達成の判断をしますからゴールは必ず設定します。タスク達成を判断せず、問題発見だけを目的とするテストであっても、ゴールを設定しないと、そのとき、そのときの判断でタスクを終わらせてしまいがちです。そうすると問題を見逃す可能性が出てきます。ユーザビリティテストのたびに、これでいいのか迷いながら実施している方、経験の少ない方であればあるほどルールや設定を明確にしてユーザビリティテスト結果の品質が低下しないようにしましょう。

被験者にとってのゴール
被験者の立場で言えば、ゴールは自分自身で「タスクが終わった。」と、内発的に実感できたときです。それは全く主観的で、同じ画面を見ても、終わったと感じる被験者もいれば、終わったとは思わない被験者もいます。ネットショッピングなら「目的の商品の注文が終わった。数日中に手元に届くから待てばよい。」と実感するのが被験者にとってのゴールです。
被験者がゴールを実感したかどうかは被験者の心の様子ですから観察するだけではわかりません。だから、タスクの終わりは、被験者自ら自発的に「終わりました」と声に出して言ってもらう必要があるわけです。皆さんがユーザビリティテストをするとき、タスクの終わり方はどんな風でしょうか。よくあるのは被験者が無言で何もしない状態が続くケースです。こういうケースの対応、皆さんはどうしていますか？これについては別のところで触れます。
　
システム上のゴール
被験者にとってのゴールは被験者自らが感じる主観的な判断でしたが、テストする側にとってのシステム上のゴールはできる限り客観的な判断を求められます。そのときの被験者の行動と評価対象である製品側の反応、この一対の客観的事実によって誰が判断してもタスクが達成したと思える状態をゴールとします。

認知的なタスクの場合
メールアプリ、新規メールアドレス登録のタスクで考えてみましょう。ゴールの候補としては次の場合が考えられます。
A 相手先の名前とメールアドレスを正しく入力出来た段階
B 相手先の登録が完了しました とメッセージが表示された段階
C アドレス帳を開いて登録された相手先を確認できた段階
この場合は、A を選んでよくないことはありませんが、B またはC をゴールとして設定します。どちらも誰が観察しても客観的事実として迷うことなく判断出来ます。但し、C を選んだ場合は、登録が正しく出来たかどうかの確認までするようにタスク指示する必要があります。

物理的タスクの場合
部屋の窓を開ける、と言うような物理的タスクではどうでしょう。少しでも開けば、開きましたと感じる人もいます。窓が半分ぐらい開くと開きましたと感じる人もいます。窓が全部開き切ってはじめて 開きましたと言う人もいます。このケース、ゴールをどのように設定すればいいでしょうか？ 一般的にこのようなケースでは、窓を全開した状態をゴールに設定します。理由は単純です。仮に窓の開けはじめや、中央付近にやりにくさが隠れていた場合でも発見することができるからです。中央付近まで開いた状態をゴールに設定していたら、最後の全開にする段階にやりにくさがあった場合、問題を見逃すことになりかねません。

作成型タスクの場合
タスクの結果として何か形あるモノができる、そういうタスクの場合です。例えば、デジタルカメラで写真撮影のタスク、室内に高さ20㎝ぐらいの2体の人形が置いてある。右側の人形は被験者から1メートルの位置にあり、左側の人形は被験者から1.5メートルの位置にある。右側の人形にピントが合い、左側の人形はぼやけた写真を撮る。このような作成型タスクのゴールはどのように設定すればいいでしょうか。皆さんならどう設定しますか？
例えば、このように設定します。2体の人形はそれぞれ全身が撮れていること。右側の人形にピントが合い、左側の人形にはピントが合っていないこと。手振れがないこと。極端な明る過ぎ、暗過ぎがないこと。このくらいが決まっていれば誰でも判断出来ます。また、条件を満たした写真を事前にプリントして作っておき、ゴールとして被験者に示すことも有効です。
しかし、カメラは被験者が持っていますから進行係からは画面はか見えません。皆さんならどうやって確認しますか？ 考えてください。
A 本人に言葉で質問しゴールの条件に合っているかどうか答えてもらう。
B テスト終了後、次の被験者のテストが始まる前にカメラを見て進行係が確認する。
C テストが終わってから写真画像をパソコンに取り込み、表示させて確認する。
D その他

タスクの達成とは
ところで、タスクの達成とはどういうことでしょうか？皆さんがユーザビリティテストをやっていて、今、終わったばかりのタスクが達成したか、達成しなかったか？ は、どのように判断していますか？
次のA B C の場合、皆さんならどう対応し判断しますか？
A システム上のゴールに達したが、被験者は何やら続けたい様子である。
B システム上のゴールに達したが、被験者は何も操作はせず、画面を見ている。
C システム上のゴールに達し、被験者は終わったと言う。
D システム上のゴールに達していないが、被験者が終わったと言う。

被験者にとってのゴールとシステム上のゴールが、同時に生じたときがタスクの達成です。
タスクの達成、つまり被験者はタスクが出来たのか、出来なかったのかの判断は、操作の結果としてシステム上のゴールに達したとの事実だけでは十分ではありません。同時に、被験者自らが「終わった」と実感する必要があります。あなたは、被験者が「終わった」と実感したことをどのように確認していますか？

よろしければ、当社のホームページをご覧ください。

ターゲットユーザーにテストの被験者になってもらえず、被験者を探すのが困難なことはよくあることです。医療機器のテストにはドクターが必要ですが、命に関わり多忙な毎日を過ごすドクターに被験者になってもらうのは不可能に近いといえます。しかし、被験者がいなければユーザビリティテストはできません。どうしたらいいでしょうか。

代打の出番
野球と同じ代打の出番です。ドクターに代わって医療の知識のある人達、すなわち検査技士、看護師、医学部の学生さんにお願いします。薬剤師であれば薬学部の学生さん、以前に薬剤師として最近まで仕事していた主婦にお願いします。コンビニのレジを使う店員であれば最近までバイトでやっていた学生や主婦にお願いします。このような人達はターゲットユーザーと同じような基礎知識をある程度は共有しています。彼等にタスクに必要な最小限の知識を与え、ユーザビリティテストに臨んでもらいます。必要な最小限の知識とは例えばこんなことです。入院患者の世話をする看護師さんの代わりに若い女性に被験者をお願いするとき、 医療ミスとその結果の重大性、具体的な影響について知識を与えます。そうすることで自分の行動や判断ミスが引き起こす重大な結果を予知できるようになり、ある程度は迅速でかつ慎重な態度が生まれます。但し、彼等はあくまでも代打ですから当然、マーケティング面の質問は意味がありません。

会場を変える
地域によってはターゲットユーザーがユーザビリティテストに参加してくれるところもあります。もし、あなたの会社が大都市圏から外れた場所にあるなら、テスト会場を変えることで適切な被験者を確保できる可能性があります。首都圏にはいろいろな種類の人々が住み活動しています。

遠隔テスト
評価対象がパソコン上で動くソフトウェアであれば遠隔テストという方法があります。実際のテストは被験者を集めやすい首都圏で行い、自社のオフィスにいながら観察できます。
テスト現場での観察と全く同じというわけにはいきませんが、首都圏でユーザビリティテストをする様子を、遠く離れた場所にいながら、ほぼリアルタイムで観察し、結果を確認することができます。あなたは貴重な時間とお金を使って出張する必要もなく、時間調整できた隙間の時間を使って被験者一人でも二人でも都合のつけられた分だけ、ユーザビリティテストの様子を観察できます。
　市販のネットミーティングソフトウェアを利用することができます。当社の船橋のテスト室で行うユーザビリティテストを離れたオフィスで観察する場合を想定してみましょう。テスト開始に先立って、船橋の私から観察者のパソコンにネットミーティングへの招待メールを送り、パスワードを知らせます。知らせを受け取った観察者はネットミーティングに参加、被験者が操作する画面を見ることができます。被験者と進行係の音声はヘッドホンで聞くことができます。数人で観察したい場合はプロジェクターやスピーカーにつなぐなどで対応します。

遠くの被験者を呼ぶ
自社の近くには被験者がいないが別の地域には、被験者がいる。こんなケースもあります。
例えば、東海地方ではなかなか目的の被験者を集めるのは難しいが、首都圏なら集めることができます。交通の不便な山間地域にある研究所でユーザビリティテストをしたいが被験者を集められない。求める被験者は首都圏にはいます。こういう場合はテスト会場を首都圏に変えるという案も考えられますが、逆に、首都圏にいる被験者を距離の離れた自社まで来てもらうことを考えます。被験者は観光気分半分で、特急電車や新幹線やマイカーで出掛けてくれます。被験者の旅費はかかりますが、社員が何人も出張する必要はありません。また、大勢の関係者がユーザビリティテストを観察することもできます。

車で送迎
視力に障害のある人や高齢で長い距離の歩行が困難な人、このような人達はその人の自宅まで車でお迎えに行き終ったら自宅まで送ります。

車椅子ユーザー
車椅子を使って、普通に社会生活を送っている人達も沢山います。ガソリンスタンドなどの公共施設を利用するのは健常者ばかりではありません。銀行のATMや電気自動車の充電スタンドは車椅子のユーザーにも使いやすいものでなければなりません。私はそういうための車椅子利用の被験者をお世話したことがあります。こういう被験者を探すのは、十分な期間が必要ですから早目に取りかかるようにします。

専門サービス会社を利用
被験者を探してくれる専門の会社を利用することをお勧めします。当社も同様なサービスを提供しています。以下は当社が探した被験者の例です。
・4～6歳の幼児
・身長90㎝から140㎝の子供、5㎝区切りごとに数人ずつ
・高齢のパソコンユーザー
・80代の人
・特定のメーカーの複合プリンターを使っている人
・特定のセキュリティソフトを使っている人
・特定のグループウェアを使っている人
・看護師さん
・宝石に興味があり、宝石を持っている人
・システム管理者
・上腕の周囲が40㎝以上の人
・健康に関心のある英語圏の国籍をもつ50代の人
・SOHOで働く人
・車椅子を使って活動している人
・海外旅行をよくする人
・などなど

よろしければ、当社のホームページをご覧ください。

見つかった問題の数は少ないが、それぞれの問題を複数の被験者が起こしたケース1の方が好ましいでしょうか？それとも、問題を多く見つけられたケース2の方が好ましいでしょうか。

皆さんの答えはいかがでしたか？　
好ましいのは、問題を多く見つけられたケース2の方です。試作品に内包している問題を発見するために行うユーザビリティテストですからひとつでも多くの問題を見つけられることが大切です。
ケース1は、問題D、E、Fの3つを見逃していることになります。見逃した3つの問題のどれかが市場に出た後に大きな問題となり、メーカーの信用を失墜させることもありえるわけです。

ところで、ひとりの被験者だけで見つかった問題は本当は問題ではなく、大多数のユーザーにはあてはまらないかもしれないという考えについて、あなたはどう思いますか？

ユーザビリティテストで見つかる問題を、何人の被験者がつまずいたのかでみると、ほとんどの被験者がつまずく問題、2～3人がつまずく問題、1人だけがつまずく問題に分けられます。

ほとんどの被験者がつまずく問題
ほとんどの被験者がつまずく問題は本来はあってはならない問題です。ユーザインタフェースは、一般的な普通の経験をし、それなりの知識を持つ、普通の人が使うことを想定して設計されているわけですから、ほとんどの被験者がつまずくということはあまりにも、試作品の品質が悪いとんでもない問題と言えます。しかし、意外なことにそのとんでもない問題もまれに見つかります。

2～3人がつまずく問題
2～3人がつまずく問題は、私の経験では高い頻度で現れます。このケース、2～3人は確かにつまずいたのですが、残りの人達は同じつまずきをしていません。
何故、同じ箇所で、人によって操作につまずいたり、つまずかなかったりするのでしょうか？

知識、体験の差
道具を使う上での知識、道具を使う体験は誰でも同じわけではなく、ひとりひとり違います。その知識の中で、常識と言われる知識は同じ文化圏に住む人々であれば誰もが共通にもっています。交通信号の知識、人は右車は左という対面交通の知識、このような知識は日本人なら誰でも知ってる常識です。しかし、製品を世界中の人達に使ってもらうことを考えると、ご承知の通り対面交通の知識は国によって違います。日本人の常識は世界では少数勢力にすぎません。
私は以前、北欧の人達とユーザビリティテストのスケジュールについて打ち合わせをしたことがあります。等の話では、34から35週に準備をして、36週目にテストを実施しましょう、というような話になりました。ちょっと待ってください、私たち日本人は、10月中旬に準備して、10月下旬にテストを実施というように、月を10日間ずつ上旬、中旬、下旬と3つに分けて、スケジュールを考えます。35週とか言われてもイメージしにくいです。と言うと、あなた達の手帳には、1月1日の週を第1週として1年を通して何週目にあたるか、表記されてないのですか？とのこと。その当時、私が使っていた手帳にはそれは表記されていませんでした。しかし、最近の手帳には印刷されているものもあるようです。グローバル化の影響で欧州の常識が私達の常識に変化をもたらしているのかもしれません。
　
道具を使う上での知識といっても、常識のように殆どの人々に普及している知識もありますが、あまり普及しておらず、一部の人だけが知っている知識もあります。
　先日、九州の地方都市に住んでいる70歳の兄が、娘の結婚披露宴に来てくれました。彼は地元で買った紙の切符を持っていて、JR船橋駅の改札を出ようとしましたが、自動改札ばかりで、駅員は見当たりません。持っている紙の切符は自動改札のスリットには入りません。8つほどある自動改札の一番端が駅員のいる改札なのですが駅員は外から見えにくい室内にいるため気づきにくかったようです。改札を出るだけに数分もかかってしまいました。自動改札が沢山並んでいるところでは端に駅員がいて対応してくれると言う知識はありませんでした。彼は日頃、車での移動が多く駅を利用することはめったになかったのです。
　
電車通勤の定期券と言えば今ではSUICAなどのプリペイドカードですが、以前は改札口に立っている駅員に紙の定期券を見せるか、定期券を改札ゲートのスリットに差し入れて通るやり方でした。切り替わった頃は多くの人々が戸惑ったものです。かなり前ですが、私が香港に行ったとき地下鉄の駅で、エスカレータのスピードが予想外に速くてびっくりしました。もうひとつ、改札機に買った切符を差し入れるスリットがなく、ガラス面のような部分に紙の切符をいったん置くだけと言う作法の違いに戸惑いました。

未体験だったことを一度体験すると、私達は新しい知識を手に入れます。そして2回目からはその知識のおかげで戸惑うことなくできるわけです。ただ、2回目の体験があまりにも遅いと、人によっては知識を忘れてしまうかもしれません。道具を使うとき、同じ箇所でできる人とできない人がいるのは、その操作に役立つ知識をすでに持っている人と、その知識をまだ持っていなかったり、思い出せない人がいるためです。このことは、被験者選びに直結する重要なことです。

ひとりだけつまずく問題
ユーザビリティテストをすると被験者の中でひとりだけがつまずく問題が発生します。これはごく一般的なことで、ひとりだけだからと言う理由で本当に問題だろうか？と疑問視する必要はありません。被験者のつまずきが本当に問題なのか、本当は問題ではないのか？については、つまずいた人数とは関わりなく確認するべきことがらです。これについては別途、言及する予定です。
　ユーザーのことを深く考え、わかりやすさを確認しながら設計されたユーザインタフェースでは複数の被験者で発生する問題はほとんどなく、1人だけで発生する問題が多くを占めます。5～6人の被験者のうち、1人だけ(Aさん)がつまずいた問題を解決しないまま製品が発売されるとどういう結果になるでしょうか？仮に、その製品が30万個売れたとします。単純計算するとそのうちの5万人という大量のユーザーが同じ箇所でつまずく可能性があります。ある人はそのため10分間時間をロスし、ある人は先生ユーザーに教えてもらうまで数時間かかるかもしれません。ある人は使用を止めてしまうかもしれません。そのときのタスクが使用頻度の高いものだったり、安全や健康に関わる重大なタスクだったりすると、たったひとつの問題であっても深刻な結果を招きかねません。たとえ5～6人の被験者であってもそのひとりひとりは、その人と同じような経験をし、同じような知識しか持っていない類似の大勢の人々の代表なわけです。

6人の被験者
製品が内包しているすべての問題を見つけてくれる6人の被験者とは、どんな人達でしょうか？ 6人の被験者、Aさん、Bさん、Cさん、Dさん、Eさん、Fさんはどのようなプうロフィールの6人を組み合わせるべきでしょうか？もちろん、ターゲットユーザーという条件の中でのことです。
第一に、道具を使うスキルの低い人であること。これについてはすでに具体的な選び方を述べました。製品によってはスキルの高くない層から選ぶというケースもあり得るでしょう。

第二に、ひとりひとり道具使いに関わる体験の異なる人であること。これがとても重要です。 例えば、スマートフォンで使うカーナビアプリを開発し、試作版ができあがったのでユーザビリティテストをするケースを考えましょう。この製品のターゲットユーザーはカーナビを装備した中小型自動車に乗り、ナビの機能を使ってドライブしている20～49歳の男性だとします。6人の被験者を選ぶとして、あなたはどんな6人を選びますか？
道具を使う知識は経験によって蓄積されますから、様々な異なる知識を持つ6人にしたいので、様々に異なる経験の人を選びます。どんな経験をどのくらい経験しているか、どんな経験はしていないか、ということになります。まず経験の種類ですが、いろいろ考えられます。
(1)車自体のこと、乗っている車の大きさ、車の新しさなど。
(2)使用しているナビ自体のこと、メーカー、新しさ、操作はタッチ方式かボタン方式か、その他の方式か、
(3)車使用の目的、買い物、送り迎え、通勤、趣味、観光など。
(4)走る道路、高速道路、一般道、市街地、郊外など。
(5)使っているナビの機能、目的地設定、案内走行、施設検索、ラジオ番組を聞く、テレビ番組視聴、楽曲を聞く、ネット検索、電話、メールなど。
経験の種類の次は経験期間や使用頻度です。
(6)経験の期間、
(7)経験の頻度、
これらの経験の内容を質問し、回答を見ながら経験の差の大きな6人を選びます。経験Aの人と、経験Bの人、どちらを優先して選ぶか迷うときは、ターゲットユーザーに多いと思う人、より問題を見つけてくれそうな人を選べばいいでしょう。経験の種類によっては、○○の経験をしていたら評価対象製品の操作につまずく可能性はとても低いと思えるものもあります。そういった問題発見可能性の低い経験パターンを除いて、問題発見可能性が高いと思われる経験パターンの人々から選んでいくことになります。勿論、わかる範囲でのことです。

よろしければ、当社のホームページをご覧ください。