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

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

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

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

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

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

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

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

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