ユーザビリティテスト
Usability Testゆーざびりてぃ・てすと
ユーザビリティテストとは、実際の利用者にサイトを操作してもらい、目的を達成できるか、どこでつまずくかを観察して確かめる検証方法のこと。感想や意見を聞く場ではなく、黙って行動を見ることで、作り手には見えなくなっている問題を表に出すための手続きです。
作った人には、もう迷う場所が見えない
Webサイトを作った側は、どこに何があるかを完全に知っています。だからトップページを開いた瞬間に、目的のリンクへ迷わず手が伸びる。この状態で何度自社サイトを見ても、使いにくさは決して見つかりません。知識が邪魔をして、初めて訪れた人の視界を再現できないからです。社内で「分かりやすいサイトができた」と合意が取れているのに、問い合わせが増えないという状況は、ほとんどがここに原因があります。問題があるのではなく、問題が見えていない。この差は、話し合いをいくら重ねても埋まりません。
では利用者に聞けばよいかというと、それも十分ではありません。人は自分の行動を正確には説明できないからです。「このサイトは使いやすいですか」と尋ねれば、多くの人は気を遣って「分かりやすいと思います」と答えます。ところが同じ人に「サービスの料金を調べて、問い合わせてみてください」と頼むと、途中で手が止まり、同じページを何度も往復し、最後に上部のメニューへ戻る。言うことと、やることは違う。ユーザビリティテストが意見聴取ではなく行動観察である理由はここにあります。見るべきは評価ではなく、実際にどこで詰まったかという事実です。
もうひとつ、中小企業にとって重要な点があります。この検証は大人数を集めなくても成立するということです。ユーザビリティ研究で広く知られる考え方として、ニールセン・ノーマン・グループは、少人数を対象にした観察でも重大な問題の多くが表面化し、人数を増やしても新しく見つかる問題は次第に減っていく、という立場を示しています。統計的な精度を求める調査とは目的が違うためです。実務上は、5人前後に見てもらえば、致命的なつまずきは繰り返し現れます。3人目で同じ場所に手が止まったなら、それはもう偶然ではありません。人数を集める労力を、直して再度見てもらう回数に振り向けたほうが、結果は早く出ます。
意見を集めるのではなく、迷った瞬間を観察して、次の一歩を邪魔しているものを取り除く。
顧客心理の視点で見ると、つまずいた顧客は不満を言わずに、静かに離れます。しかも多くの場合、「自分が分かっていないだけかもしれない」と考えて、質問すらしません。この状態で起きているのは、商品やサービスへの興味が失われることではなく、興味はあるのに前に進む方法が分からないという足止めです。ユーザビリティテストの価値は、この足止めが起きる場所を特定できるところにあります。実際に観察していると、多くの人が同じ場所で同じ迷い方をします。「これは押せるボタンなのか」「この先で見積もりを求められるのではないか」「入力した内容は誰に届くのか」。こうした不安は言語化されないまま行動を止めます。中小企業の現場では、社内で議論していた論点とはまったく別の場所で人が止まっていた、ということが珍しくありません。直すべき場所を、想像ではなく事実で決められるのがこの手法の意義です。
仕組み化の視点では、5つの段取りで回します。①検証する目的を1つのタスクに翻訳する（「使いやすさを見る」ではなく「料金を調べて問い合わせを送る」） ②対象に近い人を5人前後集める（社内の人は答えを知っているので対象外） ③操作を黙って観察し、手が止まった場所と時間を記録する ④3人以上が同じ場所で止まったものを優先課題として並べる ⑤直したら、同じタスクでもう一度見てもらう。ここで肝心なのは⑤です。一度きりの調査で終わらせると、報告書だけが残って何も変わりません。検証は行事ではなく、繰り返す仕組みとして持つのが正しい形です。加えて、記録の様式（タスク・止まった場所・かかった時間・到達できたか）を最初に決めておくと、担当者が代わっても比較できます。様式がないと、感想文が集まるだけで判断材料になりません。
AI活用の視点では、3つの使い方があります。1つ目はタスク設計の点検で、作ったタスク文を渡し「この指示は答えを教えてしまっていないか」と確認させると、誘導になっている表現を事前に除けます。「メニューのサービス一覧から料金を探してください」では、探す過程そのものが検証できません。2つ目は観察記録の整理で、複数人分のメモをまとめて渡し、共通して止まっている場所を抽出させる。手作業では見落とす重複が見つかります。3つ目は改善案の候補出しで、特定したつまずきに対して複数の直し方を挙げさせ、その中から実装できるものを選ぶ。ARGASのような顧客追跡の仕組みを併用していれば、テストで見つかった離脱地点が実際の訪問者でも起きているかを、後から数字で裏づけられます。ただし、人が迷っている瞬間を見る作業そのものは代替できません。記録の整理と案出しにAIを使い、観察は人が行うのが現実的な分担です。
図解：一度きりの調査ではなく、繰り返す流れとして持つ
下の図は、ユーザビリティテストを回すときの流れです。重要なのは最後に元へ戻っている点で、直した後に同じタスクでもう一度見てもらうところまでが1周です。下段は、観察して記録することと、やってはいけないことを対比しています。
事例で見る：国内・海外
ニールセン・ノーマン・グループ ── 少人数の観察で、大きな問題は表に出る
ユーザビリティ研究の分野で広く知られる存在に、ヤコブ・ニールセンらによるニールセン・ノーマン・グループがあります。同グループが長年発信してきた考え方の中で特に知られているのが、少人数を対象にした観察でも重大な問題の多くが見つかり、人数を増やしても新しく発見される問題は次第に減っていくという主張です。背景には、ユーザビリティテストが統計的な代表性を求める調査ではなく、問題を発見するための手続きだという整理があります。同じ導線を通れば、人は同じ場所で同じようにつまずくため、多くの人を集めても記録が重複していくわけです。この考え方が実務にもたらす意味は明確です。調査の規模を大きくするより、小さく行って直し、また行うほうが改善は早い。予算や人手が限られる中小企業にとって、これは特に重要な示唆です。「きちんとした調査ができる体制が整ってから」と待つ必要はなく、5人に協力してもらうところから始められます。なお、適切な人数は検証対象や利用者層の幅によって変わるため、常に同じ数が正解になるわけではありません。
問い合わせが伸びないBtoB企業 ── 5人に見てもらい、想定外の場所を見つける
たとえば、法人向けにサービスを提供する企業で、サイトは新しくしたのに問い合わせが増えない、という状況を考えます。社内では「デザインをもっと洗練させるべきか」「事例をもっと載せるべきか」という議論が続きます。ここで行うのは、議論を止めて5人に実際に操作してもらうことです。取引先の担当者や、業種の近い知人に依頼し、「自社に導入する前提で、費用の目安を調べて問い合わせを送ってみてください」と伝えて、あとは黙って画面を見ます。こうした場面でよく現れるのが、社内の議論とはまったく別の問題です。サービス名が独自の造語で何のことか分からない、料金の記載がないため「高そうだ」と判断して戻る、問い合わせフォームの入力項目に部署名や従業員数があり、そこで手が止まる。いずれもデザインの洗練とは関係がありません。実務上のコツは3つです。1つは、タスクを1つに絞ること。複数出すと後半は疲れて本来の行動と変わります。2つ目は、観察者は口を出さず、記録だけに徹すること。助けた瞬間、その場所は課題として記録できなくなります。3つ目は、その日のうちに直せるものを1つ直し、次の人で確かめること。報告書にまとめるより、直して確かめるほうが早く進みます。これは特定企業の実績ではなく、検討期間の長いBtoBサイトで起こりやすい代表的なパターンです。
現場での使い方：5ステップ
- 検証したいことを、1つのタスクに翻訳する「使いやすさを見る」では観察できない。「費用を調べて問い合わせを送る」のように、達成できたか判定できる形にする。
- 対象に近い人を5人前後集める社内の人は答えを知っているため対象外。取引先や業種の近い知人でよく、まずは人数より着手を優先する。
- 黙って観察し、決めた様式で記録する助けない、説明しない、感想を求めない。止まった場所・時間・戻った回数・到達可否を同じ形式で残す。
- 3人以上が止まった場所から直す1人だけの指摘は個人差の可能性がある。繰り返し現れたものが、実際に売上を止めている場所。
- 直したら、同じタスクでもう一度見てもらうここまでで1周。一度きりの調査にすると報告書だけが残る。繰り返す仕組みとして持つ。
関連用語
まとめ：議論で決めていた場所を、観察で決められるようになる
ユーザビリティテストは、実際の利用者に操作してもらい、どこでつまずくかを観察する方法です。作った側には迷う場所が見えず、聞いても本人は自分の行動を正確に説明できません。だから、黙って行動を見る必要があります。始め方は簡単で、達成できたか判定できるタスクを1つ決め、対象に近い5人前後に依頼し、助けずに記録する。3人以上が止まった場所を優先して直し、同じタスクでもう一度見てもらう。記録の整理や改善案の候補出しはAIに任せ、観察そのものは人が行う。これを繰り返せる形で持てば、直す場所を想像で決める必要がなくなり、顧客が迷わず次へ進める導線が少しずつ積み上がっていきます。
