プロトタイプができた！ さあユーザーインタビューをしよう
はじめに
友人に、「サービスアイディアの簡単なプロトタイプ作ったけど、ユーザーインタビュー※はどうすればいい？」という相談を受けました。
新規事業開発で参考になる書籍の紹介をしてから１週間、もうできたの！？ というのが素直な感想でしたが、こういうスピード感の世界に自分はいるんだなぁとも思いました。
新規事業開発においてインタビューというのはいろいろなフェーズで行われますが、友人のケースで言えば、顧客課題がある程度わかってきたあと、ソリューションをぶつけて仮説検証のタイミングのインタビューを想定しているようでした。
友人に説明するためにいくつかポイントを整理したら思いの外文章が膨らみましたので、記事にまとめて考え方を紹介しようと思います。
ユーザーインタビューのHowは優れた書籍や記事が沢山ありますので、この記事ではユーザーインタビューのHowの紹介ではなく、プロトタイプの考え方、仮説検証のためのユーザーインタビューというWhy、Whatの観点にフォーカスして解説したいと思います。
この記事が誰かの役に立てば幸いです。
※正確な名称で言えば、コンセプトテストだったり、ユーザビリティテストだったりすると思いますが、ここでは単純化のために想定顧客に直接フィードバックをもらう行為を乱暴に「ユーザーインタビュー」とまとめてしまおうと思います。
ユーザーインタビューの目的
いきなり、ユーザーインタビューの各論に入る前に、そもそもなぜユーザーインタビューをするのかについて整理したいと思います。
ユーザーインタビューというのは簡単に言えば、新たな気づき（インサイト）を得たり、もともと持っていた自分たちの仮説を検証することを目的として、顧客・潜在顧客の方々に対して、インタビューを行う行為です。
この目的を達成し、インタビュー後のアクションに繋がるようにユーザーインタビューはしっかりと設計する必要があります。
例えば今回の友人の相談のケースであれば、作成したプロトタイプについて、顧客の課題を解決できそうか、ソリューションの方向性は合っているかなど、いくつかの検証したい観点があります。
インタビューの時間は限られていますし、あれもこれも聞いてしまうと相手も混乱してしまいます。
フォーカスを絞り、核心に迫ったインタビューをするために、インタビュー目的の深い言語化が大切です。
参考：ユーザーインタビューの準備ステップ
ユーザーインタビューには様々な種類がありますが、共通して言えることは時間がかかるということです。
例えば、1対1のユーザーインタビューの場合、準備は概ね以下のように進めて行きます。（各ステップで具体的に何をやるかはユーザーインタビューについての書籍※1に丁寧に書いてありますので参照ください）
インタビュー目的の設定
インタビューで仮説検証することの整理/インタビュースクリプトの準備
インタビュー対象者の設定
候補者のスクリーニング/リクルーティング※2
日程調整
インタビュー実施
インタビュー結果の整理/示唆だし
仮説検証結果に基づくアクション
ユーザーインタビューの件数にもよりますが、経験的には短くても10営業日以上はかかる印象です。
ここで言いたいことは、ユーザーインタビューは結構手間のかかるものであり、効果的にやるためにはしっかり計画してやる必要があるものだということです。
※１：ユーザーインタビューの参考書籍：
※２：インタビューの目的に叶う候補者は普通なかなか見つけることは難しいです。リクルーティングの時間を短縮するために多少お金をかけてビザスクやクロス・マーケティング等、専門の調査会社に協力してもらうことをおすすめします。
新規事業/プロダクト開発において答えるべき3つの問い
以前別の記事でも紹介しましたが、新規事業/プロダクト開発というのは以下の3つのクリティカルな問に答えていく活動だと私は考えています。
顧客がお金を払ってでも解決したい大きな課題は存在するか？
その課題を解決する適切なソリューションを選定できているか？
そのソリューションの提供によって十分な収益が見込めるか？
この問いには答えるべき順番があり、課題の仮説検証が済んでいないうちにソリューションを考えたり、収益性やビジネスモデルの検証に移ることは足場が固定される前の橋を渡るようなもので、渡れないこともないですが報われない努力に終わることも少なくありません※3。
今回のケースでは１．顧客課題はある程度仮説検証を経てクリアになっているという前提で、プロトタイプを使った２．ソリューション仮説の検証を目的としたユーザーインタビューを検討していきました。
補足：生成AIの時代における仮説検証※3
上記はあくまで現在のスピード感では、という前提で書きました。
最近、生成AIを使って、プロトタイプもとても簡単に作れるようになってきており（つまり、コストが激減しており）、課題の検証とソリューションの検証がもはや一体化して行われるようなケースも出てきました。
我々は変化のただなかにいるのです。
※3：以前書いた記事
プロトタイプのインタビューで抑えるべきポイント
プロトタイプのユーザーインタビューでは先に述べたように、自分たちの考えているソリューションの方向性が合っているかどうかを検証していく必要があります。
ちなみに個人的にはソリューションというのは提供価値（Value Proposition）と読み替えてもいいと考えています。
顧客課題を理解したうえでどのような価値を提供するか、という視点で考えることで、特定のソリューションへのこだわりに囚われず、顧客課題の解決のための価値にフォーカスすることができるからです。
プロトタイプのユーザーインタビューではソリューションの方向性だけではなく、その前提となる大きな顧客課題が存在しているかどうかについても洞察が得られます。
なぜなら、ソリューションを通じて提供する価値が顧客のためになっているのであれば、その前提として想定した顧客課題が解決されている必要があるからです。
仮にソリューションがマッチしてなかったとしたら、ソリューションの再検討をしてより良い策を考えればいいですが、顧客課題が実は無かった/解決したいほど大きくはなかった場合、前提がひっくり返ることになりますので大きな手戻りが発生することがあります。
もちろん誤った仮説を検証しないまま次のステップ（ビジネスモデル構築etc.）にいくほうが最終的により大きな手戻りになりますので、ここは恐れず、なあなあにせずにしっかりやっていく必要があります。
ここまでの説明でなんとなく感じたかもしれませんが、ユーザーインタビューをするということは開発を前に進めるために、足場に楔を打っていく・足場を作っていく作業に似ています。
しっかりした足場を作っていくために、プロトタイプのインタビューで最低限抑えるべきと私が考えたこと、および注意点を以下３つにまとめました。
1️⃣インタビューに答えてくれている人の背景確認
「あなたの普段のお仕事を教えて下さい」
「＊＊＊（ソリューションで解決したいこと）に関する業務に関する経験/課題を教えてください」
特にBtoBの対企業向けの検証では、インタビューで誰が回答しているのかは注意が必要です。
企業内では複数の部署が関わって仕事をしており、窓口の人が適切なインタビュー対象でないことが多いからです。
聞く相手が間違えていた場合、仮説検証が遅れるだけではなく、最悪の場合誤った示唆に基づいてアクションを取ってより多くのお金と時間をロスすることになりかねません。
また、相手がインタビューで検証したい課題を持っている人であるかは一番最初に深く確認します。
できることなら事前に適する経歴・部署の人を連れてきてもらう、ビザスクなどのサービスでそういう人を探してもらうなど、より目的に合う候補者を確保する努力をしましょう。
この背景確認では、どういった背景の人がこの発言・フィードバックをしてくれたのか、がとても重要です。
後段のインタビューで得られた発言がどんな経験に基づいたものなのかを理解し、深堀りしていくきっかけになる情報ですので時間をかけてしっかり聞くと良いでしょう。
2️⃣プロトタイプのテスト/フィードバック
「使って見た率直な感想を教えて下さい」
「先ほど教えてもらった業務・課題はこのサービスでどれくらい解決できそうですか？」
聞き方はとてもたくさんあると思いますが、仮説検証したいことをベースに半構造化インタビューの質問を組み立てて聞いていきます。
今回のようなプロトタイプのテストの場合、簡単な操作説明をして、実際の業務での利用を想像してもらいながら使ってもらう流れになるかと思います。
こういったインタビューでは協力的な人ほど、想像や一般論（UIはこうした方が良い、こういう機能があったほうがいいと思うなど）でフィードバックをしがちですが、「なぜそう思いますか？ 具体的にそれができるとどう嬉しいですか？」というように深堀りしてその人がそう考える根拠となるファクトを集めていきましょう。
また、相手の言ったことは基本的に理解しやすい意見だったとしても、発言の背景（Why）を確認します。
なぜ、と聞きすぎると嫌がられるので、「どんなところがそう思いましたか？」「例えば、どんな使い方を想定しましたか？」など相手が具体で答えやすいように聞き方は工夫しましょう。※4
※4：なぜを使わない聞き方の参考（プロンプト付き）
文字を大きくしたほうがいいとか色使いを変えたほうがいいなど、提供価値に紐づかない枝葉のフィードバックはこの時点で対応は不要です。
※もちろん、そういう細かなところにユーザーの意識がいって気を散らせてしまわないように、ある程度しっかりしたUIのプロトタイプを見せる工夫はすべきです。
あったら便利は、なくても平気です。
ユーザーの声に惑わされないように、自分たちが仮説検証したいことを忘れずにユーザーインタビューに臨んでいきましょう。
3️⃣提供価値がユーザーの期待を満たしているか？
「このサービスを使うと、＊＊＊という業務課題が解決すると思いますが、お金を払って使いたいと思いますか？」
ここも聞き方は色々あると思いますが、例えば試作品のUIや一つ一つの機能について聞いても細かな話しか出てこないので、サービス全体として解決できることにお金を払いたいか聞いてみるなど、工夫して聞いてみましょう。
経験的には、「金額によりますね〜」と大体は答えてきますが、その会社にとってその業務課題があることでどれくらいの損失・コストがかかっているかを想定し、それらを〇〇％削減できる・そのコスト以下で導入できることに対して感度を確認するなど、こちらが考えているロジックも話してもいいと思います。
もしそれを聞いて、「いやいやこのサービスだったらそんなに削減できないですよ」、みたいなフィードバックがあれば提供価値を広く考え過ぎていた可能性があるので、なぜそう考えたのかしっかり確認することで、自分たちの考えていた仮説を見直す糸口を見つけることができます。
ちなみに個人的な経験で言えば、ユーザー企業の中にある複雑な業務・社内プロセスに想定とずれる原因があることが多いように思います。
ある一つの技術が顧客のすべての課題を解決することはありません。
だからこそ、技術単位でソリューションを考えるのではなく、提供価値として考えることが顧客の課題に正しく向き合う上で大切なのだと私は考えています。
ユーザーがお金を払いたいと思う提供価値を見つけるために、ユーザーインタビューを諦めずに繰り返していきましょう。
おわりに：ユーザーインタビューはN数じゃない
偉大な起業家であるピーター・ティール氏が著書Zero to Oneで書いていたことの中で以下の記述が目に止まりました。
なにか新しいものを発明しても、それを効果的に販売する方法を創りだけなければ、いいビジネスにはならない。どれがどんなにいいプロダクトだとしても。
（中略）個人セールスと従来の広告宣伝の間にはデッドゾーンがある。（中略）コンビニの受発注システムの場合、広告宣伝は範囲が広すぎて効率が悪すぎる、対人セールスが必要だとしても製品単価を考えると見込み顧客すべてに営業マンを訪問させる余裕はない。大企業にとっては当たり前のツールを中小企業が使わないのは、そうした理由からだ。中小企業のオーナーが遅れているわけでも、ツールが存在しないわけでもない。販売は隠れたボトルネックなのだ。
我々はプロダクトを考えるとき、なんとなく、良いソリューションのアイディアにこだわったり、顧客ニーズを定量的に知りたいがためにアンケートを取ったりします。
しかし、我々が本当にやりたいことというは顧客の課題を解決できるビジネス/プロダクトを作ることです。
そのためには、顧客課題の本質に迫っていく必要があります。
いくら数百人にアンケートを薄く広く取ったとしても、まだ誰もビジネスにしていない深い顧客課題を見つけることは滅多にできません。
だから、新規事業の最初であればあるほどアンケートを使ったN数を稼ぐ定量調査より、ユーザーインタビューによる定性調査が重要です。
日本の伝統的な大企業では社内承認を得るためにN数を聞かれることもあるでしょうけれど、たとえN＝１でもその業界・業種の課題をしっかり捉えられていれば、詳細なペルソナ・ターゲッティングができ、それをベースに「この業界業種でこういった業務をやっている企業・部署は必ずこの課題を持っていて、それに対する有力な代替手段はないから、市場としてはこれくらいを見込める」というロジックを作ることができます。
N数を稼ぐのではなく、本質に迫る深いユーザーインタビューを通じて、自社しか知らない深い顧客課題を見つけ、独自の提供価値を生み出していきましょう。
以上
この記事が気に入ったらサポートをしてみませんか？