プロトタイプのユーザーテスト｜新規事業での確かめ方と質問
新規事業でプロトタイプができあがると、次に待っているのが最初の利用者に触ってもらう場面です。この記事では、プロトタイプのユーザーテストで何を確かめるのか、誰に頼むのか、当日に何を聞くのかを、順を追って整理します。使いやすさの確認にとどまらず、事業の仮説を確かめる場として使うための考え方もあわせてまとめます。
プロトタイプのユーザーテストで確かめたいこと
プロトタイプのユーザーテストとは、作りかけの製品やサービスを想定した利用者に実際に触ってもらい、その様子や反応から課題を見つける方法です。通常のシステム開発では「操作が分かりにくくないか」を確かめるために行われることが多いのですが、新規事業では確かめたい範囲がもう少し広くなります。
使いやすさと、事業として成り立つかは別の問い
画面が分かりやすいことと、その事業が求められていることは、別の話です。操作に迷わず最後まで使えたとしても、「そもそも自分の仕事や生活には必要ない」と感じられてしまえば、事業は続きません。
そこで新規事業のテストでは、次の3つを分けて考えると整理しやすくなります。
- 課題は本当にあるか：想定した利用者が、いまその困りごとを抱えているか。今はどう対処しているか。
- この解決策で受け入れられるか：プロトタイプの形で、課題が解けると感じてもらえるか。
- 使い続ける理由があるか：一度触って終わりではなく、日々の行動に組み込まれそうか。対価を払う価値があると感じられそうか。
1つ目は、プロトタイプを見せる前の会話でも確かめられます。2つ目は、触ってもらって初めて分かる部分が大きくなります。3つ目は、触っている最中の様子と、触り終えたあとの言葉の両方から推し量ることになります。
「テストの結果」ではなく「次の判断の材料」と捉える
もうひとつ大切なのは、ユーザーテストを合否の判定として扱わないことです。新規事業の初期段階では、何人かに触ってもらった結果をもとに、続ける・作り直す・方向を変える・やめる、のどれを選ぶかを決めます。つまりテストの目的は、次の判断に使える材料を集めることです。
この考え方を最初に共有しておくと、「良い反応だけを集めて安心する」「悪い反応が出て全体を否定する」といった偏りを避けやすくなります。小さく作って確かめる投資判断の考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方でも整理しています。
最初の利用者を誰にするか
テストの質は、誰に触ってもらうかでほぼ決まります。ここを曖昧にしたまま進めると、集まった意見をどう扱えばよいか分からなくなります。
想定する利用者に近い人を選ぶ
最初の利用者は、事業が本来向き合う相手に、できるだけ近い人を選びたいところです。「業種」「役職」「困りごとの有無」「いまの対処方法」といった条件を、事前に書き出しておくと選びやすくなります。
避けたいのは、頼みやすさだけで選ぶことです。社内の同僚、親しい知人、プロジェクトに関わっている協力者は、気を遣って好意的な感想を返すことがあります。また、事業の背景を知っているため、初めて見た人なら迷うところでも迷わず進めてしまいます。こうした人たちの意見は、初期の動作確認には役立ちますが、事業の仮説を確かめる材料としては偏りがちです。
人数は少なくてもよいが、偏りには注意する
人数について、使いやすさの問題発見では、少人数でも主要な課題の多くが見つかるという考え方が知られています。ユーザビリティ研究のNielsen Norman Groupが、5人前後のテストでも多くの問題が見つかるという趣旨の見解を示しており、小規模なテストの根拠としてよく引用されます。ただし、これは主に操作上の問題を見つけるための考え方です。事業としての需要を数で証明するものではありません。
新規事業では、人数を増やして統計的に判断するよりも、次のような進め方が現実的です。
- 利用者のタイプが複数ある場合は、タイプごとに数人ずつ確認する
- 1回で終わらせず、直したものを別の人に見てもらう流れにする
- 同じ指摘が複数の人から出るかどうかを見て、個人の好みと見分ける
数を集めることよりも、「どんな人が、どこで、なぜつまずいたか」を具体的に残すことに力を置くほうが、初期の判断には役立ちます。
協力者への声のかけ方
協力を依頼するときは、テストの目的、所要時間、画面や音声を記録する場合はその旨を、あらかじめ伝えておくのが礼儀です。「製品を評価してもらう」のではなく、「作りかけのものを見て、気づいたことを教えてほしい」という位置づけで頼むと、率直な反応が得やすくなります。
また、取引先や既存の顧客に依頼する場合は、今後の関係に影響すると感じさせないよう配慮します。意見が率直であるほど価値があることを、最初に言葉にして伝えておきたいところです。
テストの前に決めておくこと
当日の進め方よりも前に、準備の段階で決めておくことがあります。ここが曖昧だと、触ってもらったあとに「結局、何が分かったのか」が残らなくなります。
確かめたい仮説を言葉にする
まず、今回のテストで確かめたい仮説を、短い文で書き出します。たとえば次のような形です。
- 「営業担当者は、この画面から次にやることを迷わず選べるはずだ」
- 「依頼する側は、登録の手間を負担に感じても、結果の見え方に魅力を感じて最後まで進むはずだ」
- 「現場の担当者は、いまの管理方法よりもこの画面のほうが速いと感じるはずだ」
仮説が文章になっていると、観察する場所が決まり、結果が出たときに「当たった」「外れた」の判断もしやすくなります。要件を整理する段階で抜け漏れやズレを防ぐ考え方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。
判断の基準を先に置く
次に、結果をどう読むかの基準を、触ってもらう前に決めておきます。たとえば「複数の人が同じ場所で止まったら、画面の作りを見直す」「課題そのものに共感されない人が多ければ、対象の利用者を見直す」といった形です。
結果を見てから基準を決めると、都合のよい解釈に寄りやすくなります。厳密な数値目標を置く必要はありませんが、「こうなったら次に進む、こうなったら立ち止まる」という方向だけでも、事前に関係者で揃えておくと、後の議論が落ち着きます。
作り込む範囲と、課題の題材を決める
プロトタイプのどこまでを触ってもらうかも、決めておきたい点です。すべての機能を見せる必要はありません。仮説に直結する一連の流れだけを、動く形で用意します。最初に作る範囲の考え方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準で扱っています。
あわせて、利用者に取り組んでもらう「課題の題材」も用意します。たとえば「新しい依頼を登録して、状況を確認してください」のように、実際の仕事や生活に近い場面を1つか2つ設定します。機能の名前を並べて「ここを押してください」と案内するのではなく、達成してもらいたいことだけを伝え、操作は任せます。
プロトタイプの種類によって、確かめられることが変わる
画面の絵だけのモックと、実際に動くプロトタイプでは、得られる反応が異なります。違いの整理はプロトタイプとMVP・モックの違いを整理｜新規事業の使い分けにまとめています。この記事の観点でいえば、次のように考えると分かりやすくなります。
- 静止した画面や紙のモック：見た目や情報の並びへの反応を確かめやすい
- 動くプロトタイプ：入力して結果が返ってくる体験や、使い続けたときの感覚まで確かめやすい
当日の進め方と、聞くべきこと
準備ができたら、実際に触ってもらいます。1人あたり30〜45分ほどを目安に、落ち着いて話せる環境を用意すると進めやすくなります。
最初の数分は、プロトタイプを見せる前の会話にあてる
いきなり画面を見せず、まずは現在の状況を聞きます。ここは、課題が本当にあるかを確かめる時間です。次のような質問が使えます。
- 今の仕事（または生活）では、この件をどのように進めていますか。
- 最近、その場面で困ったことや面倒だと感じたことはありましたか。
- そのとき、どのように対処しましたか。
- 今のやり方に、続けたいと思う点はありますか。
事実や過去の行動を聞くのがポイントです。「こういうサービスがあったら便利ですか」という質問は、「便利そうですね」という丁寧な返事を引き出しやすく、実際の行動との関係が薄くなりがちです。
触ってもらうときは、説明しすぎない
プロトタイプを見せるときは、使い方の説明を最小限にとどめます。実際に事業が始まれば、一人ひとりに使い方を説明できるとは限りません。説明がなければ使えないのであれば、それ自体が大切な発見です。
当日は、次の点を守ると、観察の質が上がります。
- 用意した課題の題材を1つずつ渡し、操作は任せる
- 迷っているときも、すぐには助けず、まず様子を見る
- 考えていることを声に出しながら操作してもらう（思考発話と呼ばれる方法）
- 「どこを押せばよいか」と聞かれたら、答えを教える前に「どこだと思いますか」と返す
- 画面と声を、同意を得たうえで記録する
観察する側は、利用者の言葉だけでなく、手が止まった場所、戻る操作、ため息や表情の変化にも注意を向けます。口では「分かりやすいです」と言いながら、実際には何度も迷っている場面は少なくありません。言葉と行動が食い違ったときは、行動のほうが実態に近いことが多いと考えられます。
触っている最中・触ったあとに聞くこと
触ってもらっている最中は、あまり質問を挟まず、気になった点をメモしておきます。操作が一区切りついたところで、次のような質問を使うと、反応の背景が見えてきます。
- さっき止まったところでは、何を考えていましたか。
- この画面を見て、次に何が起きると思いましたか。
- 思っていたことと違った点はありましたか。
- 今日の内容は、普段の仕事の中のどこで使うと思いますか。
- 今のやり方と比べて、良い点と気になる点を1つずつ教えてください。
- 明日から使えるとしたら、最初に何をしますか。
- これが使えなくなったとしたら、どの程度困りますか。
最後の2つは、使い続ける理由があるかを探る質問です。「使いたいですか」という直接的な質問よりも、具体的な場面を想像してもらうほうが、本音に近い答えが返ってくる傾向があります。
避けたい聞き方
聞き方によって、答えが誘導されることがあります。特に次のような質問は、避けたほうがよいものです。
- 「分かりやすいですよね？」のように、肯定を前提にした質問
- 「この機能は便利ですよね」のように、評価を先に示す質問
- 「もし作ったら使いますか」のように、将来の行動を仮定で聞く質問
- 「どの機能が欲しいですか」のように、解決策そのものを利用者に考えさせる質問
利用者は、自分の課題や行動についてはよく知っていますが、どんな解決策が最適かを考えるのは専門ではありません。要望を集めすぎず、背景にある困りごとのほうを丁寧に聞き取るほうが、事業の検討には役立ちます。
動くプロトタイプだから分かること
ここまでの内容は、モックやスライドでも一部は実施できます。それでも、動くプロトタイプで確かめる意義は大きいと考えられます。
企画書や画面案では引き出しにくい反応
企画書や画面の絵を見せて「どう思いますか」と聞くと、利用者は頭の中で使い方を補って答えます。補い方は人によって違うため、反応のばらつきが大きくなります。一方、実際に入力し、結果が返ってくる体験をしてもらうと、反応は具体的になります。「この項目は毎回入力するのは大変」「ここで結果が見られるなら使う」といった言葉は、動くものに触れて初めて出てくることが多いものです。
関係者の見方を揃える効果
もうひとつの効果は、社内での合意形成です。新規事業では、決裁者と現場の担当者が同じ目的を見ているのに、判断の材料と進める速度が違うために話が噛み合わないことがあります。ズレているのは目的ではなく進め方であることが多く、原因の整理は新規事業で経営陣と現場がすれ違う原因は進め方のズレで取り上げています。
利用者が実際に触っている映像や、そのときの発言があれば、関係者は同じ事実を見ながら話せます。稟議や決裁の場でも、企画書の文章だけより、実物と利用者の反応のほうが伝わりやすい場面があります。この点は稟議を通すシステム開発｜プロトタイプの使い方で、決裁の観点から扱っています。
実物を触りながら認識のズレを早く見つける
開発する側と依頼する側の間でも、言葉だけで要件を決めると認識違いが起きやすくなります。実物を触りながら「ここはこう」と指摘できれば、「作ったら違っていた」という事態を早い段階で防げます。この考え方はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも詳しく書いています。
結果の読み方と、次の判断のつなげ方
テストが終わったら、記憶が新しいうちに記録を整理します。ここまでの準備が活きるのは、この段階です。
観察結果を3つに分けて整理する
得られた情報は、性質ごとに分けると扱いやすくなります。
- 事業の前提に関わること：課題そのものに共感されない、利用者のタイプが想定と違う、いまのやり方で十分だと言われる、など。
- 使い方の摩擦：操作でつまずいた、言葉の意味が通じなかった、次の行動が分からなかった、など。
- 個別の要望：あの機能がほしい、この色が好みでない、など。
最も重く受け止めるのは1つ目です。ここが揺らぐと、画面をいくら直しても事業の成立には近づきません。2つ目は、複数の人が同じ場所でつまずいたなら、優先して直す価値があります。3つ目は、そのまま採用するのではなく、背景にある困りごとを確かめる材料として扱います。
要望をそのまま機能にしない
利用者から出た要望を、そのまま作る機能の一覧に加えていくと、最初に絞ったはずの範囲がふくらんでいきます。要望の裏にある課題が何かを考え、最小の形で解けるかを検討するのが基本です。「その機能がなくても課題が解けるなら、まだ作らない」と判断できる余地は、残しておきたいところです。
続ける・直す・止めるを決める
整理した結果は、事前に置いた基準と照らし合わせます。
- 前提も使い方も大きな問題がなければ、次の段階へ進む
- 前提は成り立っているが使い方に摩擦があれば、直して再テストする
- 前提そのものが揺らいでいれば、対象の利用者や提供価値を見直す、あるいは立ち止まる
「止める」という判断も、小さく確かめたからこそ選べる結果です。検証が長引いて結論が出ないまま終わる状態は、避けたいところです。この状態に陥る典型的な原因は、PoC失敗で終わる新規事業の共通点と本開発への進み方でも整理しています。
記録は関係者が見返せる形で残す
最後に、記録の残し方です。発言のメモ、画面の録画、整理した分類と判断の理由を、関係者がのちに見返せる形でまとめておきます。担当者が替わっても「なぜその判断になったのか」を追えるようにしておくと、次の検証がスムーズに進みます。
なお、動作の確認や品質の判断は、プロトタイプを作る工程でも人の目が欠かせません。この点はAI開発でも品質には人の確認が必要な理由で触れています。
テストを進めるときに起こりがちなつまずき
最後に、実際に進めるときに起こりやすいつまずきを整理しておきます。事前に知っておくだけでも、避けやすくなります。
- 仮説が決まらないまま始める：何を確かめたいのかが曖昧だと、感想の羅列で終わってしまいます。
- 開発側が操作を教えてしまう：つい助け舟を出したくなりますが、迷うこと自体が貴重な情報です。
- 都合のよい意見だけを拾う：好意的な声が目立つと安心しがちです。否定的な反応や無反応にこそ、事業の前提を見直すヒントがあります。
- 1回の結果で結論を出す：少人数のテストは、方向を探る材料です。直したものを別の人に見てもらい、傾向が変わるかを確かめる流れが現実的です。
- テストの後に何も変えない：結果を踏まえた修正や判断につなげなければ、時間をかけた意味が薄れます。
まとめ
プロトタイプのユーザーテストは、新規事業では使いやすさの確認だけでなく、課題があるか、受け入れられるか、使い続けられるかという事業の仮説を確かめる機会になります。要点を振り返ります。
- 最初の利用者は、頼みやすさではなく、想定する利用者への近さで選ぶ
- 触ってもらう前に、確かめたい仮説と、結果の読み方の基準を決めておく
- 当日は、使い方を説明しすぎず、過去の行動や具体的な場面を聞く
- 結果は「事業の前提」「使い方の摩擦」「個別の要望」に分けて読み、続ける・直す・止めるを判断する
- 動く実物で確かめると、反応が具体的になり、関係者も同じ事実を見ながら話せる
新規事業では、アイデアを企画書で説明し続けるより、動くものを利用者に触ってもらう方が、判断に必要な材料が早く集まります。JustFitは、構想をもとに約1ヶ月で実際に動くプロトタイプを先に開発し、実物を見てから契約を判断できる受託開発サービスです。仕様が固まっていない段階でも相談でき、システムを軸にした事業の形まで一緒に考えられます。詳しくはJustFitのサービス紹介をご覧ください。