コンセプトテストとは|設計手順・質問項目・判定基準を解説

この記事は、ネクストイノベーションベース編集部の鳥居 誉定が書きました。

顧客へ新サービス案を見せたら、「面白い」「使ってみたい」と好評でした。ところが次の会議では、案を残すのか、対象者を変えるのか、試作へ進むのか、誰も決められません。反応を集めるだけでは、コンセプトテストは終わりません。

必要なのは、結果を受けて何を決めるかを先に固定することです。そのうえで、提示する情報、回答者の条件、質問順、判定の分岐をそろえます。解決案を見せる前の課題探索や、完成に近い試作品の操作確認まで、1回の調査へ背負わせないことも大切です。

この記事では、コンセプトテストの設計から、質問項目、定性・定量の使い分け、結果を4つの判断へ分ける方法までを解説します。

コンセプトテストとは|企画への感想を次の判断へ変える

コンセプトテストとは、商品・サービス案を同じ条件で対象者へ示し、理解、価値認識、選択理由、採用を止める条件を確かめる検証です。平均点を出すことより、どの仮説を残し、何を直し、次に何を確かめるかを決めることが目的になります。

コンセプトテストで確かめる範囲

確かめる範囲は、次の6点です。

  • 誰の、どの課題を扱う案として理解されたか
  • 課題が回答者の経験と結びついたか
  • 現在の手段から移る理由が生まれたか
  • 価値を信じるために何が足りないか
  • 利用や社内検討を止める条件は何か
  • 詳細確認、共有、試用準備へ進む条件は何か

点数が高くても、対象者が案を誤解していれば続行の根拠にはなりません。反対に、点数が低くても、説明文の1か所だけが誤解を生んだなら、直す場所は特定できます。

一案を深掘りするか、複数案を比べるか

一案を見せるときは、理解されない箇所や採用を止める条件を探ります。複数案を見せるなら、残す案と、選択を動かした要素を特定してください。

ただし、片方はデザイン済み、もう片方は文章だけでは比較になりません。対象者、情報量、見た目の完成度、説明時間が同時に違えば、何が効いたのか判定できないからです。

コンセプトテストとニーズ調査・受容性調査の違い

解決案を見せる前か後か、そして調査後に何を決めるかで分けると迷いません。5つの調査・検証を整理します。

  • ニーズ調査:案を示す前の経験や現在の対処を捉え、扱う課題を決めます。
  • コンセプトテスト:一案または複数案を示し、理解や選択理由を捉え、残す企画を決めます。
  • 受容性調査:提示案を採用候補に残す条件と、止める条件を詳しく見ます。
  • ユーザビリティテスト:操作できる試作品を使ってもらい、どこで作業が止まるかを確認します。
  • テストマーケティング:販売や申込に近い環境で、顧客反応と提供運用を確かめます。

価格をコンセプトへ含めれば、「この条件では検討しにくい」という障壁は見えます。一方、受け入れられる価格帯を知りたいなら、案への評価と価格への評価は別々に記録します。

コンセプトテストの実施前に決める3点|判断・仮説・対象者

質問票の前に、調査後の意思決定、検証する仮説、回答者の条件を決めます。この3点があれば、集めた回答を「参考になった」で閉じず、続行・修正・追加確認・見送りへ接続できます。

調査後に決めることを一つに絞る

「顧客の反応を知る」では終了条件がありません。決めるのは、次の試作へ進める案、対象者を残すか変えるか、中心となる価値表現を直すかのいずれかです。今回の結果で決めることを、1文にしてください。

仮説と反対の証拠を一組にする

仮説には「誰が」「どの場面で」「案のどこに反応し」「どんな行動へ進むか」を入れます。支持する反応だけでなく、何が出たら対象・課題・価値・提供条件を書き換えるのかも先に置きます。

たとえば「事業部責任者が、月次報告の入力状況を一覧で確認できる案を情報システム担当者へ共有する」と書けば、次に見る行動が明確です。「便利だと思う」では、まだ弱いままです。

対象者は属性だけでなく経験と役割で選ぶ

業種や役職に加え、課題が最後に起きた場面、現在の対処、解決策を探した経験、導入判断への関与を条件にします。会いやすい人を優先して対象を広げると、誰の反応なのか説明できません。

BtoBでは、利用者、起案者、決裁者、情報システム・法務・購買など導入審査に関わる人を分けます。利用者1人の意向を、会社全体の導入意向へ置き換えないためです。

コンセプトシートの作り方|8項目の情報量をそろえる

コンセプトシートは、説明者の補足がなくても案の骨格を読める提示物です。複数案を比べる場合は、次の8項目を同じ詳しさでそろえます。

  • 対象者:誰が使う、または導入を検討する案か
  • 利用場面:どの出来事の前後で必要になるか
  • 現在の問題:何が滞り、どんな対処が発生しているか
  • 提案内容:何を、どのような形で提供するか
  • 利用後の変化:対象者の行動や判断がどう変わるか
  • 代替手段との差:現在の方法を続ける場合と何が違うか
  • 信じる根拠:仕組み、制約、前提として何を示せるか
  • 利用・導入条件:価格、準備、関係者、運用変更は何か

一案につき中心となる約束を一つ置く

機能一覧、将来構想、社会的意義を1枚へ詰めると、回答者が何を評価したのか追えません。中心となる対象者、課題、価値を一組にします。補助機能は、中心の価値を理解するために要るものだけ残してください。

複数案は完成度と説明条件を合わせる

同じ人に複数案を見せるなら、共通の見出し、情報項目、文字量、図の種類、閲覧時間、補足台本を決めます。提示順も回答者ごとに入れ替え、単独評価と比較後の選択を分けて記録します。

一人に一案だけ示す方法なら、他案との比較や提示順の影響は避けられます。ただし回答者の条件がずれると、案による差なのか回答者による差なのかを切り分けにくくなります。何を決めたいかから方式を選びましょう。

BtoBは会社向けの条件を別紙へ逃がさない

利用者向けの価値だけを見せ、導入時の準備、既存業務との接続、情報管理、契約、支払い条件を伏せると、個人の好意しか測れません。今回の判断を左右する条件は、各案へ同じ詳しさで入れます。

利用者には利用場面、起案者には社内説明、決裁者には判断条件、導入審査者には情報管理や契約を聞きます。1つのシートでも、役割ごとに答えられる問いは違います。

コンセプトテストの質問項目|提示前から次の行動まで7段階で聞く

質問は、提示前の現状、提示直後の理解、課題との適合、価値と比較理由、信頼に必要な情報、次の行動、採用を止める条件の順に置きます。「良いと思いますか」だけでは、直す場所が分かりません。

提示前|現在の行動を確認する

  • 「想定する課題が最後に起きた場面を、起きた順に教えてください」
  • 「そのとき、誰がどのように対処しましたか」
  • 「現在の方法を変えなかった理由は何ですか」

提示直後|説明を自分の言葉で再現してもらう

  • 「この案は、誰のどんな問題を扱うものだと受け取りましたか」
  • 「使う場面と、利用後に変わることをどう理解しましたか」
  • 「意味が分からなかった言葉はありますか」

課題適合と価値|現在の方法との差を聞く

  • 「現在のやり方と比べ、変わると思った点はどこですか」
  • 「自分の業務や利用場面に当てはまらない点はどこですか」
  • 「この案を使わないとしたら、理由は何ですか」

複数案|選択と理由を分けて取る

  • 「次に詳しく検討するとしたら、どの案を残しますか」
  • 「選んだ案の決め手は何でしたか」
  • 「どの案も選ばない場合、何が足りませんでしたか」

信頼・行動・導入条件|検討が止まる場所を聞く

  • 「検討するために、どの情報や根拠が必要ですか」
  • 「検討を一段進めるなら、次に誰と何を確認しますか」
  • 「会社で扱う場合、誰の承認やどの部門の確認が必要ですか」

「使いたい」という意向だけを、需要や受注の証拠にしないでください。選択理由、全案を拒否した理由、次の行動に必要な条件まで残します。

コンセプトテストの進め方|7工程で定性と定量をつなぐ

定性と定量は、理由を探すのか、定義済みの反応がどこに分布するかを見るのかで選びます。実施は次の7工程です。

  1. 調査後の意思決定を記録する
  2. 仮説、反対の証拠、結果別の行動を書く
  3. 対象者の条件と役割を固定する
  4. 提示物、版、説明台本を固定する
  5. 提示前後の反応を同じ順序で取る
  6. 評価、理由、観察した事実を分けて記録する
  7. 事前の分岐で判定し、修正版は別の版で確かめる

案が誤解される理由や、選ばない理由を探すなら、インタビューや自由回答が向きます。対象者条件、比較案、評価項目が固まり、反応の分布や条件別の違いを見たい段階ではアンケートを使います。

定性調査が向く場面

回答の数より、仮説のどの言葉が崩れたかを記録します。少数の回答を割合へ変換し、市場全体の傾向として扱わないでください。

たとえば、3人が同じ言葉を誤解したなら、説明文を直す手掛かりにはなります。しかし、顧客全体の何割が誤解するかは別の問いです。

定量調査が向く場面

同じ条件で反応の分布や役割別の差を確かめたいときに使います。全項目の平均点だけで順位を決めず、理解、課題適合、比較理由、障壁など、仮説ごとに結果を読みます。

必要人数に全案件共通の固定値はありません。意思決定の大きさ、対象者の分かれ方、許容する誤差から設計します。

コンセプトテストの判定基準|4つの分岐を事前に置く

判定は総合平均の1点へまとめず、仮説ごとに「続行」「修正して再テスト」「追加確認」「見送り」へ分けます。理解できたが価値を感じない案と、価値はあるのに説明を誤解された案では、次の行動が違うからです。

四つの分岐を事前に書く

  • 続行:対象、課題、価値の仮説が観察結果と矛盾せず、次に確かめる論点が明確です。
  • 修正して再テスト:課題との接続は残るものの、表現、提案内容、信頼材料、提供条件のどこかで止まりました。
  • 追加確認:対象者、提示条件、役割別の回答など、判定に必要な証拠が不足しています。
  • 見送り:課題が対象者の行動と結びつかない、現在の手段から移る理由がない、解消できない導入条件があります。

4つとも、結果を見てから意味を変えてはいけません。誰が、いつ、どの記録を使って判定するのかも先に決めます。

平均の裏にある役割差を残す

BtoBでは、利用者が価値を認めても、起案者は社内説明の材料が足りず、導入審査者は情報管理の条件を満たせない場合があります。回答を平均せず、役割ごとに事実、解釈、判断への影響を分けます。

架空例|月次報告サービス案を判定までつなぐ

月次報告を集めるサービスを考えます。案Aは「未入力の部署と項目を一覧で確認できる」、案Bは「入力済み情報から報告書の下書きを作る」という内容です。対象者、利用場面、導入条件、見た目、説明時間はそろえます。

提示後、案Aは「入力の遅れを把握するもの」と理解された一方、案Bは「人の確認なしで報告書を確定するもの」と誤解されたとします。利用者は案Aを残しましたが、起案者は変更履歴、導入審査者は閲覧権限の説明がなければ判断できませんでした。

この場合、案Aの中心価値は「続行」、案Bの説明は「修正して再テスト」、変更履歴と閲覧権限は「追加確認」です。人の確認を外して確定する案は、今回の前提に合わないため「見送り」とします。

残すのは案の勝敗だけではありません。理解のずれ、役割別の不足情報、次の検証物、担当者、再判定日まで一続きに記録します。

まとめ|コンセプトテストは次の判断まで設計する

コンセプトテストの成果は、好意的なコメントの多さではありません。どの案を残し、何を直し、誰を対象に、次のどの検証へ進むかを決められる状態です。

実施前に、調査後の判断、仮説と反対の証拠、対象者の経験と役割を固定してください。提示時は案ごとの情報量をそろえ、現状、理解、価値、比較理由、信頼、次の行動、止まる条件を分けて聞きます。結果は平均点へ畳まず、4つの分岐へ戻します。

このテストで分かるのは、案のどの前提が反応に耐え、どこで止まったかです。市場全体の需要、実際の購入、継続利用、採算は、それぞれに合う次の検証で確かめてください。

無料相談を申し込む