プロトタイプでのユーザーテストの進め方

プロトタイプのユーザーテストは、想定する利用者に実際に操作してもらい、どこでつまずくかを観察する作業です。デジタル庁のガイドブックは、主要な課題を見つけるには少なくとも5人以上を目標にし、1人あたり1時間〜1時間半、操作課題は2〜3個程度と考えるよう示しています。多くの人数を集めるより、目的を絞って小さく繰り返すほうが役に立ちます。

この記事では、MVP開発の途中でプロトタイプを使ったテストを行う場面を想定し、準備から結果の整理までの手順をまとめます。PoC・プロトタイプ・MVPの違いそのものはPoC・プロトタイプ・MVPの違いと進め方で扱っています。

ユーザーテストで確かめること

デジタル庁の「ユーザビリティ導入ガイドブック」は、ユーザビリティを「特定のユーザーが特定の目的を達成するために、システムや製品をどれだけ効果的、効率的に、そして満足して使用できるか」と説明しています（JIS Z 8521:2020の定義に基づく）。つまり、評価の単位は「画面がきれいか」ではなく、「決まった利用者が、決まった目的を達成できるか」です。

同じガイドブックは、ユーザビリティテストで見る点として次の4つを挙げています。

認知：操作に必要な機能を利用者が見つけられるか
判断：利用者が正しく理解し、判断できるか
行動：利用者が正しい操作を行えるか
フィードバック：操作の結果として起きたことを、利用者が正しく受け取れるか

新規事業の場合、これに加えて「そもそもこの機能を使おうと思うか」という需要の問いが混ざりがちです。ユーザーテストは「使えるか」を確かめる方法であり、「欲しいか」を確かめるには向いていません。欲しいかどうかは、事前の顧客ヒアリングや、申込み・支払いといった行動で確かめます。ヒアリングの進め方は顧客ヒアリングの質問項目と聞き方を参照してください。

ヒアリングとユーザーテストの違い

	顧客ヒアリング	ユーザーテスト
主に分かること	課題の有無、現在の対処法、優先度	操作のつまずき、誤解、分かりにくい言葉
相手にしてもらうこと	過去の経験を話す	課題に沿って実際に操作する
聞き手の役割	質問して掘り下げる	口を出さずに観察する
使う素材	なくてもよい	紙・画面のプロトタイプ、試作品

両者を1回の面談で行うこともできますが、その場合も前半をヒアリング、後半を操作テストと分け、目的が混ざらないようにします。

準備

1. 確かめたいことを1文で書く

「新規登録から最初のデータ入力までを、説明なしで完了できるか」のように、利用者の目的と範囲を1文で書きます。1回のテストで確かめられる操作課題は2〜3個程度なので、MVPで最も重要な流れ（申込み、初回設定、中心となる機能の1回目の利用など）に絞ります。

2. 対象者を決める

テストの結果は、誰に試してもらったかで大きく変わります。社内の同僚や開発メンバーは、製品の前提知識を持っているため、つまずくべき所でつまずきません。想定顧客に近い人を、条件（業種、職種、今使っている道具、ITへの慣れなど）を決めて集めます。

デジタル庁のガイドブックは、発見できる課題の数に関する数理モデルを紹介し、先行研究では1人の被験者が見つける課題の割合の平均が31％とされ、5人でおよそ85％の課題が見つかる計算になると説明しています。ただし同時に、この計算は課題の深刻さを考慮していないこと、利用者の層が複数あるならそれぞれで試す必要があることも注意しています。たとえば「経理担当者」と「決裁者」が別の画面を使うサービスなら、層ごとに数人ずつ試すのが妥当です。

3. シナリオと課題文を作る

課題は「〇〇ボタンを押してください」のように操作を指示するのではなく、「来月の出張費を申請してください」のように、利用者の目的として書きます。画面上の言葉をそのまま課題文に使うと、答えを教えることになるので避けます。

4. プロトタイプの精度を決める

確かめたいことが画面の流れや言葉の分かりやすさなら、紙に描いた画面や、画面遷移だけ作ったプロトタイプで十分です。入力の手間や処理の待ち時間が論点なら、ある程度動くものが必要になります。作り込みすぎると、結果を見て直すことに抵抗が生まれるので、テストで分かったことを反映できる段階で行います。ノーコードツールで画面を試作する方法もあります。

5. 記録と同意の準備

画面録画や音声録音を行う場合は、事前に目的と保存・利用の範囲を説明し、了承を得ます。録画には顔や声、入力内容などの個人情報が含まれることがあるため、保存場所と閲覧できる人を決めておきます。個人情報の扱いは新規事業での個人情報の取り扱いで整理しています。

当日の進め方

役割を分ける

進行役と記録役を分けると、進行役は相手に集中できます。記録役は、つまずいた画面、かかった時間、発言をそのまま書き留めます。

冒頭の説明

「試しているのは製品で、あなたではありません。うまくいかない所が見つかることが今日の成果です」と伝えます。こう伝えないと、相手は失敗を隠そうとしたり、気を遣って褒めたりします。

考えていることを話してもらう

操作しながら「今何を探しているか」「この言葉をどう理解したか」を声に出してもらうと、つまずきの理由が分かります（思考発話と呼ばれる方法です）。

助けない

相手が迷っても、すぐに答えを教えないことが最も大切です。「どこを押せばいいですか」と聞かれたら、「どこだと思いますか」と返します。一定時間進めない場合だけ、次の課題へ移ります。助けた場合は、助けた事実を記録に残します。

最後に感想を聞く

課題が終わった後で、全体の印象や、分かりにくかった点を聞きます。ただし、感想は観察した行動より優先しません。「使いやすかった」と言いながら何度も迷った場合は、迷った事実のほうを重く見ます。

結果の整理

テストが終わったら、発見した問題を1件ずつ書き出し、次の観点で並べます。

何人がその問題に当たったか
課題の達成を妨げたか（完了できなかった、誤った結果になった）、時間がかかっただけか
原因の仮説（言葉、配置、手順の順番、前提知識の不足など）
修正案と、修正にかかる手間

課題の達成を妨げた問題から直し、直したら次の回で同じ課題を試します。数人に試して直し、また数人に試すという小さな繰り返しのほうが、一度に大人数を集めるより早く改善が進みます。

ほかの評価手法との組み合わせ

1回のテストで全ての画面を確かめることはできません。デジタル庁のガイドブックは、専門家が評価するヒューリスティック評価やエキスパートレビュー、初めて使う人の視点で手順を一つずつ確認する認知的ウォークスルーを紹介し、ユーザーテストと組み合わせる方法を示しています。また、アンケートやアクセス解析、A/Bテストのような量的な方法は、ある程度の利用者数がある段階で「どの層に、どのくらい起きているか」を確かめるのに向くとしています。MVPの公開前は質的なテスト、公開後は量的なデータで追う、という使い分けが基本です。

大企業と起業家で異なる点

大企業の新規事業担当者の場合

社内の既存顧客に協力を頼める一方、営業部門を通すと「新製品のお披露目」の場になりやすい点に注意します。テストの目的が改善点の発見であることを営業担当者と共有し、同席する場合も口を挟まないよう事前に頼んでおきます。社内規程で、社外の人に試作品を見せる際の秘密保持の手続が決まっていることもあるので、早めに確認します。

起業家・スタートアップの場合

対象者集めが最も大きな負担になります。これまでヒアリングに協力してくれた人に、続けてテストへの協力を頼むのが現実的です。オンラインで画面共有をしながら行えば、場所の制約も小さくなります。人数が少なくても、同じ課題で毎週数人ずつ試すことを続けると、改善の方向が見えてきます。

まとめ

ユーザーテストは「使えるか」を確かめる方法で、「欲しいか」の確認とは分ける
確かめたいことを1文で書き、操作課題は2〜3個に絞る
想定顧客に近い人を5人程度から始め、利用者の層が違えば層ごとに試す
当日は助けずに観察し、発言より行動を重く見る
課題の達成を妨げた問題から直し、小さく繰り返す

参考資料

ユーザビリティ導入ガイドブック DS-671.1（デジタル庁）