知人に「いいね」と言われて満足しない。ユーザーインタビューの始め方

「このアイデア、いいね」。友人や同僚にサービスの構想を話したとき、そう言われて安心した経験がある方は多いのではないでしょうか。しかし、その「いいね」を検証の材料にしてしまうのは危険です。知人はあなたを応援したいという気持ちから、本音とは違う感想を返すことが少なくありません。本当に確かめるべきは、「対象となる人が、その悩みに実際に困っていて、お金や時間を払ってでも解決したいと思っているか」です。それを確かめる最も基本的な手段がユーザーインタビューです。この記事では、初めてユーザーインタビューに取り組む方向けに、何から始めればよいか、誰に何を聞けばよいか、聞いてはいけない質問は何かを、具体例を交えて解説します。

この記事で分かること

• 知人・友人への相談だけでは需要検証にならない理由と、その代わりに何をすべきか
• ユーザーインタビューで「何を聞くべきか」「何を聞いてはいけないか」の具体的な設計方法
• 初めてでも実行できる、依頼先の探し方・進め方・失敗パターンの避け方

結論を先にまとめると、次の3点です。

1. 知人への相談は「応援バイアス」がかかるため、需要検証としては機能しません。利害関係のない第三者、できれば「実際にその悩みを抱えている人」に話を聞く必要があります。
2. 「このサービスをどう思いますか」ではなく、「今、その悩みにどう対処していますか」を聞くべきです。未来の行動を想像で答えてもらう質問は、実際の行動とズレやすいためです。
3. 5〜10人程度に同じ悩みが繰り返し出てくるかを確認できれば、最初の仮説検証としては十分です。大規模な調査は不要で、まずは小さく始めることをおすすめします。

なぜ知人の「いいね」だけでは検証にならないのか

新しいサービスのアイデアを思いついたとき、最初に話す相手は多くの場合、家族や友人、会社の同僚です。これは自然な行動ですが、そこで得られる感想を「需要があった」という根拠にしてしまうと、後の判断を誤らせるリスクがあります。理由は大きく3つあります。

1つ目は、応援バイアスです。知人はあなたの挑戦を応援したい気持ちがあるため、率直な欠点を指摘しづらくなります。「面白いね」「いいと思うよ」という言葉の裏に、「でも自分は使わないかもしれない」という本音が隠れていることは珍しくありません。

2つ目は、対象者のズレです。知人があなたの想定する「悩みを抱えている人」と一致している保証はありません。たとえば、個人事業主向けの請求書作成サービスを考えているのに、話す相手が会社員の友人ばかりであれば、そもそも意見を聞く対象が違います。

3つ目は、想像に基づく回答であることです。「こういうサービスがあったら使いますか」という質問に対する答えは、あくまで想像上の未来の行動です。人は自分の未来の行動を、実際よりも好意的に予測する傾向があるとされています。「使うと思う」という回答と、実際にお金を払って使う行動の間には、大きな距離があります。

この3つのズレを解消するために、意図的に「知人以外」「想定対象者に近い人」「今現在の行動」を聞く設計にする必要があります。これがユーザーインタビューの基本的な考え方です。

「いいね」と「お金を払いたい」の間にある溝

需要検証において特に注意すべきなのが、好意的な感想と購買意欲の間にある溝です。マーケティングの世界では、この溝を埋めるための様々な検証手法が提案されています。ランディングページ（LP）を使って実際の登録行動を見る方法や、実際に「購入する」ボタンを押させて反応を見るフェイクドアテストと呼ばれる手法などが代表的ですが、ユーザーインタビューはそれらに先立つ、より初期段階の「悩みの実在確認」に位置づけられます。

インタビューだけで「絶対に売れる」という確信を得ることは難しいですが、「そもそも悩みが存在しない」「悩みはあるが優先順位が低い」といった、企画倒れになりやすい落とし穴を早期に発見できる点が最大の価値です。

ユーザーインタビューの目的を最初に決める

インタビューを始める前に、「何を確かめたいのか」を1つに絞ることをおすすめします。目的が曖昧なまま質問リストを作ると、聞くことが多くなりすぎて、結局何も検証できないインタビューになってしまいます。

初めての立ち上げで確認すべき目的は、主に次の3種類に整理できます。

この記事の対象読者は「まだサービスを形にしていない、構想段階の個人」を想定しているため、最初のインタビューでは「悩みの実在性」と「現状の対処法」の2つに絞ることをおすすめします。既存の代替手段への不満を深掘りするのは、悩みの実在性が確認できた後の、2回目以降のインタビューで十分です。

誰に話を聞くべきか。対象者の探し方

「誰に聞くか」は、インタビューの成否を左右する最も重要な決定です。理想的な対象者の条件は、次の3つを満たす人です。

• 想定しているサービスの利用者像に近い属性を持っている
• その悩みを、実際に現在進行形で抱えている（過去に抱えていた、ではなく今も抱えている）
• あなたと直接の利害関係がない、または利害関係があっても率直に話せる関係性である

3つ目の条件について補足すると、知人であっても「率直に話せる関係」であれば完全に排除する必要はありません。ただし、その場合は後述する「聞き方」の工夫がより重要になります。

具体的な探し方の候補

初めての立ち上げで、知人以外のつながりがない場合、次のような探し方が現実的です。

1. SNSでの募集。 X（旧Twitter）やFacebookグループなどで、「〇〇という悩みについて15分お話を聞かせてください」と募集する方法です。謝礼（Amazonギフト券500円〜1,000円程度が目安とされることが多いです）を用意すると応募率が上がりやすいとされています。
2. 既存のコミュニティへの参加。 対象者が集まっていそうなオンラインコミュニティ、業界団体、勉強会などに参加し、そこで声をかける方法です。専門職向けのサービスを考えている場合、この方法が特に有効です。
3. 知人からの紹介（芋づる式）。 知人本人に意見を求めるのではなく、「〇〇の悩みを抱えている人を知らないか」と紹介を依頼する方法です。応援バイアスを回避しながら、知人のネットワークを活用できます。
4. ユーザーインタビュー専門のマッチングサービスの利用。 有償で対象者を探せるプラットフォームも存在します。予算に余裕がある場合の選択肢です。

どの方法でも、最初から大人数を集める必要はありません。目安として5〜10人程度に話を聞けば、同じ悩みが繰り返し出てくるかどうかの傾向は見えてきます。それ以上の人数は、傾向が見えた後の追加確認として位置づけるとよいでしょう。

依頼メッセージの例

SNSで募集する場合の文面の一例です。

「〇〇（悩みの分野）について、20〜30分ほどお話を聞かせていただける方を探しています。サービスの構想段階で、実際に困っている方の生の声を伺いたいと考えています。オンラインで実施し、御礼として〇〇円分のギフト券をお渡しします。ご興味があればDMください。」

ポイントは、「サービスを売り込む場ではない」ことを明記することです。「〇〇を買ってもらう」ための場だと誤解されると、率直な意見が出づらくなります。

何を聞くべきか。質問設計の基本

質問設計は、ユーザーインタビューの成否を決める核心部分です。ここでは「聞くべき質問」と「避けるべき質問」を対比しながら解説します。

避けるべき質問パターン

まず、初心者が陥りやすい「避けるべき質問」を整理します。

• 「このサービスがあったら使いますか？」 → 未来の想像上の行動を聞いており、好意的な回答が返りやすい典型的な質問です。
• 「いくらなら払いますか？」 → 具体的な金額を提示されても、実際の購買時の判断とは大きく異なることが多いとされています。価格の検証は別の手法（実際の申込みを募る等）で行うことをおすすめします。
• 「このデザイン、どう思いますか？」 → 見た目の好き嫌いの議論に時間を使ってしまい、そもそもの悩みの検証から逸れてしまいます。
• 「〇〇は面倒だと思いませんか？」 → 誘導的な質問です。相手は「面倒だと思う」という前提に同意しやすくなり、本音とズレた回答を誘発します。

これらの質問は、いずれも「相手に評価・想像・同意を求める」形になっている点が共通しています。ユーザーインタビューの初期段階では、評価ではなく事実（過去に実際に取った行動）を聞くことが重要です。

おすすめの質問パターン

代わりに、次のような「事実を聞く」質問を中心に設計することをおすすめします。

1. 直近でその悩みに困った具体的な場面を聞く。

「直近で〇〇に困ったのは、いつ、どんな場面でしたか？」

1. 現在の対処方法を聞く。

「今はその悩みに対して、どうやって対処していますか？」

1. 既存の対処法への満足度を聞く。

「その対処法で、満足していますか？不満な点はありますか？」

1. 費やしている時間・お金を聞く。

「その対処のために、だいたいどのくらいの時間（お金）をかけていますか？」

1. 過去に別の解決策を探したことがあるか聞く。

「これまでに、他のサービスやツールを試したことはありますか？」

この5つの質問は、いずれも「実際に起きた過去の事実」を尋ねている点が共通しています。過去の行動は、未来の想像よりもはるかに信頼できる情報です。

深掘りのための「なぜ」の使い方

回答が一言で終わってしまう場合、「なぜそう思うのですか？」「もう少し詳しく教えてください」と深掘りする質問を追加することをおすすめします。いわゆる「5回のなぜ」という手法をそのまま採用する必要はありませんが、表面的な回答の奥にある本当の動機を探る姿勢は重要です。

たとえば、「その対処法に満足していない」という回答が出た場合、「具体的にどの部分が一番のストレスですか」「その不満は、どのくらいの頻度で感じますか」と続けることで、悩みの深刻度や優先順位が見えてきます。

こうした質問設計の考え方は、開発会社に発注する際の要件定義ヒアリングにも通じるところがあります。事前に何をどう聞くべきかを整理しておくことが、後々のズレを防ぐという点で共通しているためです。要件定義のヒアリングで失敗しないコツも参考にしてみてください。

インタビューの進め方。実施前・実施中・実施後

実施前の準備

• 質問リストは作るが、台本のように読み上げない。 会話の流れに応じて順番を変えたり、相手の回答に応じて深掘りの質問を追加したりする柔軟さが必要です。
• 録音・メモの許可を事前に取る。 後から聞き返せるように録音しておくと、記憶に頼らず正確な記録が残ります。オンライン会議ツールの録画機能を使う場合も、必ず事前に伝えて同意を得ることをおすすめします。
• 1人あたり20〜30分を目安に設定する。 長すぎると相手の負担になり、応募が集まりにくくなります。

実施中に気をつけること

• 自分のサービス案は、最後まで話さない。 先にサービス案を話してしまうと、相手はその案に対する感想を述べる「評価者」になってしまい、率直な悩みの話が聞きにくくなります。まずは悩みについてじっくり聞き、案を話すのは最後の数分にとどめることをおすすめします。
• 沈黙を怖がらない。 質問した後、相手が考え込んでいる間に次の質問を投げてしまうと、深い回答を遮ってしまいます。数秒の沈黙は待つ姿勢が大切です。
• 相手の言葉をそのまま書き留める。 自分の解釈で言い換えてメモをすると、後から見返したときに「本当にそう言っていたか」が分からなくなります。

実施後の整理

インタビューが終わったら、その日のうちに次の3点を整理することをおすすめします。

1. 出てきた悩みの内容（相手の言葉のまま）
2. その悩みの頻度・深刻度（相手の話し方や具体性から推測できる強さ）
3. 現在の対処法とその満足度

複数人へのインタビューが終わったら、この整理シートを並べて、共通して出てくる悩みがあるかどうかを確認します。ここで初めて、「思い込みで作ろうとしていたサービス」と「実際に多くの人が困っている悩み」が一致しているか、あるいはズレているかが見えてきます。

具体例で見る。良い質問と惜しい質問の違い

抽象的な説明だけでは実感が湧きにくいため、架空の例で「良い質問」と「惜しい質問」を比較してみます。ここでは「個人事業主向けの請求書作成サービス」を検討しているケースを想定します。

惜しい質問の例

「請求書作成って、面倒だと思いませんか？もし自動で作れるサービスがあったら使いたいですか？」

この質問には2つの問題があります。1つは「面倒だと思いませんか」という誘導的な前置きが付いていること、もう1つは「使いたいですか」という想像上の未来の行動を尋ねていることです。相手は、質問の前提に引っ張られて「たしかに面倒ですね、使ってみたいです」と答えやすくなります。しかし、この回答からは「本当に困っているか」「実際にお金を払うか」は何も分かりません。

良い質問の例

「直近で請求書を作ったのはいつですか？その時、どうやって作りましたか？」 「請求書を作る作業に、月にどのくらいの時間を使っていますか？」 「今使っているツールや方法で、困っていることはありますか？」

これらの質問は、いずれも「すでに起きた事実」を尋ねています。回答者は自分の記憶をたどって答えるため、想像や気遣いが入り込む余地が少なくなります。仮に「Excelで自分で作っていて、月に2時間くらいかかっている。特に困っていない」という回答が返ってきた場合、それは「悩みがそれほど深刻ではない」という重要な情報です。逆に「毎回テンプレートを探すところから始めて、ミスも多くて困っている」という回答が返れば、悩みの深刻さが具体的に見えてきます。

このように、同じテーマでも聞き方を変えるだけで、得られる情報の質が大きく変わります。質問リストを作った後は、「これは事実を聞いているか、想像を聞いているか」を1つずつ点検することをおすすめします。

複数人の回答をどう集約するか

5〜10人にインタビューを終えた後、次に悩むのが「この結果をどう読むか」です。ここでは、初めてでも実行しやすい集約の手順を紹介します。

ステップ1: 悩みを書き出して並べる

インタビューごとに整理したメモから、「相手が語った悩み」を1件ずつ短い文で書き出します。この段階では、自分の解釈を加えず、相手の言葉に近い表現のままにしておくことが重要です。

ステップ2: 似た悩みをグルーピングする

書き出した悩みを、似た内容ごとにグループ分けします。付箋やスプレッドシートを使い、「請求書のフォーマット作成が面倒」「送付先の管理が煩雑」「支払い漏れの確認が大変」のように、似たテーマをまとめていきます。

ステップ3: 頻度と深刻度を確認する

グループごとに、何人がその悩みに言及したか（頻度）と、話し方から感じられた困り具合の強さ（深刻度）を確認します。頻度が高く、かつ深刻度も高いグループが、検証すべき最有力の仮説になります。頻度が高くても「そこまで困っていない」という話し方だった場合は、優先順位を下げて構いません。

ステップ4: 対処法とのギャップを確認する

最後に、「その悩みに対して、現状どう対処しているか」を確認します。すでに満足度の高い対処法が定着している場合、新しいサービスへの乗り換えは起きにくい傾向があります。一方で、「対処法はあるが不満が大きい」という状態であれば、乗り換えの動機が生まれやすいと考えられます。

この4ステップを踏むことで、「なんとなく良さそうだった」という印象論から、「〇人中〇人が同じ悩みを、同じくらいの深刻さで語っていた」という、次の判断材料として使える形に整理できます。

失敗パターンと、その避け方

初めてユーザーインタビューに取り組む方が陥りやすい失敗パターンを、5つに整理しました。

失敗パターン1: 質問数が多すぎる

30分の枠に20個以上の質問を詰め込もうとすると、1つひとつが浅い回答で終わってしまいます。核心となる質問は5〜7個程度に絞り、残りは深掘り用の追加質問として持っておく構成をおすすめします。

失敗パターン2: 自分の案への同意を求めてしまう

「〇〇があったら便利だと思うんですけど、どうですか？」という聞き方は、知らないうちに同意を求める質問になっています。相手は否定しにくくなり、結果的に「いいと思います」という応援バイアスと同じ現象が起きます。あくまで「悩みの実在確認」に徹することをおすすめします。

失敗パターン3: 少人数の意見を全体の意見だと思い込む

3人に話を聞いて、3人とも同じ悩みを話したからといって、それが市場全体の傾向とは限りません。特に、知人の紹介で集めた対象者は属性が似通っていることが多く、偏りが出やすい点に注意が必要です。人数を増やす、募集経路を複数用意するといった工夫で、偏りをできる限り減らすことをおすすめします。

失敗パターン4: 否定的な意見を無視する

複数人に聞く中で、1人だけ「そんなに困っていない」という意見が出ると、都合の良い意見だけを採用してしまう心理が働きがちです（これはハルシネーションのような技術的な現象とは異なりますが、人間の思考にも似た「見たいものだけを見る」偏りがあります）。否定的な意見が出た場合は、「なぜその人は困っていないのか」の背景まで確認することをおすすめします。属性やシチュエーションの違いが見えてくることがあります。

失敗パターン5: インタビュー結果を検証せずに開発へ進む

インタビューで良い反応が得られたからといって、そのまま大規模な開発に進むのは早計です。ユーザーインタビューは「悩みの実在確認」の第一段階にすぎません。次のステップとして、実際にお金を払う意思があるかを確認するランディングページ（LP）検証や、実際の申込み行動を見るフェイクドアテストのような手法を組み合わせることをおすすめします。

チェックリスト。インタビュー前に確認したい10項目

実施前に、次のチェックリストで準備状況を確認することをおすすめします。

• [ ] インタビューの目的（何を検証したいか）を1つに絞ったか
• [ ] 対象者は「想定利用者に近く、現在悩みを抱えている人」か
• [ ] 対象者の探し方（SNS募集・紹介・コミュニティ等）を決めたか
• [ ] 謝礼の有無・金額を決めたか
• [ ] 質問リストは5〜7個の核心質問に絞られているか
• [ ] 「〇〇があったら使いますか」のような想像上の質問を避けているか
• [ ] 録音・メモの許可を得る手順を決めたか
• [ ] 自分のサービス案を話すタイミングを、インタビューの最後に設定したか
• [ ] 実施後の整理シートのフォーマットを用意したか
• [ ] 目標人数（まずは5〜10人）を決めたか

Q&A。よくある疑問

Q. オンラインと対面、どちらがよいですか？ A. 初めての場合はオンライン（ビデオ会議）で十分です。対象者の居住地に関わらず募集できる点、録画機能で記録が残せる点がメリットです。表情や場の空気感をより丁寧に読みたい場合は対面も検討する価値がありますが、まずはオンラインで数をこなすことをおすすめします。

Q. 謝礼は必ず必要ですか？ A. 必須ではありませんが、SNSでの募集の場合は謝礼があった方が応募が集まりやすいとされています。知人の紹介やコミュニティ内の協力ベースであれば、謝礼なしでも成立することがあります。金額は少額（数百円〜1,000円程度のギフト券等）でも十分です。

Q. 何人に聞けば十分と言えますか？ A. 明確な正解はありませんが、5〜10人程度に聞いて、同じ悩みが繰り返し出てくるようであれば、最初の仮説検証としては十分と考えられます。逆に、5人聞いても全員がバラバラの悩みを話す場合は、対象者の設定自体を見直す必要があるかもしれません。

Q. インタビュー相手にサービスのことを話してもいいですか？ A. 話しても構いませんが、タイミングが重要です。悩みについて十分に聞き終えた後、インタビューの最後に「実は今、こういうサービスを考えているのですが」と共有する順番をおすすめします。先に話してしまうと、相手の回答がその案への評価に引き寄せられてしまいます。

Q. インタビューだけで「作るべきかどうか」を判断できますか？ A. インタビューは「悩みが実在するか」を確認する最初の一歩であり、それだけで開発の是非を断定するのは早計です。悩みの実在が確認できたら、ランディングページ（LP）を使った検証や、無料ツールでの検索需要の確認など、複数の手法を組み合わせて判断材料を積み上げることをおすすめします。（landing-page検証・検索需要確認の具体的な方法は、それぞれ別記事で詳しく解説しています。）

サブペルソナ別の視点。全体に向けて

この記事の対象は「全体」であり、特定のサブペルソナに絞った内容ではありません。ただし、立場によってインタビューの取り組み方に多少の違いが出ることがあるため、簡単に触れておきます。

会社員として複業でアイデアを検証する立場の方は、平日の日中に時間を取りにくいことが多いため、オンラインでの短時間インタビュー（20分程度）を、平日の朝や夜、休日に設定する工夫が有効です。

専門知識を活かしたサービスを考えている士業・医療職などの立場の方は、対象者を専門分野の周辺コミュニティ（業界団体・勉強会・SNSの専門家コミュニティ等）から探しやすいという利点があります。一方で、専門家としての立場が先に立ち、「アドバイスをする」姿勢になってしまいがちな点には注意が必要です。インタビューの場では、あくまで「聞く側」に徹することをおすすめします。なお、同業者に声をかけること自体に「アイデアを話したら真似されるのでは」という不安を感じる場合は、アイデアを人に話すのが怖い。同業者・既存客にぶつけて検証する方法で、不安と向き合いながら話す相手・話し方を選ぶ具体的な進め方を扱っています。

店舗経営など、すでに事業を持っている立場の方は、既存の顧客や取引先に直接聞ける環境があるという強みがあります。ただし、既存の関係性がある分、応援バイアスが働きやすい点は他のケースと同様に注意が必要です。既存顧客だけでなく、まだ関係のない同業者や、他店の顧客にも意見を求めることで、偏りを補うことをおすすめします。

いずれの立場でも共通して重要なのは、「聞く相手を、自分に近い人だけに限定しない」という姿勢です。

オンラインインタビューを実施する際の実務的な工夫

オンラインでインタビューを行う場合、対面にはない工夫が必要になる場面があります。ここでは、実務上つまずきやすいポイントを補足します。

日程調整のツールを使う。 メールやメッセージのやり取りだけで日程を決めようとすると、往復が多くなり対象者の負担になります。カレンダー共有ツールで空き時間を提示し、相手に選んでもらう形にすると、調整の手間を減らせます。

通信環境のトラブルに備える。 音声が途切れる、接続が切れるといったトラブルは珍しくありません。録音・録画に加えて、要点だけは手元でも簡単にメモを取っておくと、後からの確認がしやすくなります。

謝礼の渡し方を先に決めておく。 オンラインの場合、謝礼をその場で手渡すことができません。電子ギフト券をメールやSNSのDMで送る、後日振込を行うなど、渡し方をあらかじめ決めておき、インタビューの案内文に明記しておくことをおすすめします。

相手の環境に合わせてツールを選ぶ。 対象者がビジネス向けのビデオ会議ツールに不慣れな場合もあります。普段使っているSNSの通話機能や、電話でのインタビューに切り替える柔軟さも持っておくと、対象者の母集団を広げやすくなります。

インタビューの回数とタイミングの考え方

ユーザーインタビューは、一度だけ実施して終わりにするものではありません。構想段階、MVP（実用最小限の製品）を検討している段階、実際に公開した後の段階など、立ち上げの各フェーズで、目的を変えながら繰り返し実施する価値があります。

構想段階では、この記事で解説した「悩みの実在確認」が中心になります。次に、サービスの方向性がある程度固まった段階では、具体的な機能案を見せながら「この機能があれば、先ほどの悩みは解消されそうか」を確認するインタビューに移行します。この段階では、ある程度サービス案を開示して意見を求めることになりますが、それでも「良いと思いますか」ではなく「この機能を使うとしたら、今の対処法のどの部分が変わりそうですか」といった、具体的な行動の変化を尋ねる形にすることをおすすめします。

公開後は、実際の利用者に対して「使ってみてどうだったか」「使わなくなった理由は何か」を聞くインタビューが有効になります。これは需要検証とは異なる目的（利用継続・改善のための調査）になりますが、根っこにある「事実を聞く」姿勢は共通しています。

このように、ユーザーインタビューは一度きりの通過儀礼ではなく、立ち上げの各段階で繰り返し使う基本的な道具として捉えることをおすすめします。最初の一歩でつまずいた経験があっても、質問の設計や対象者の選び方を見直すことで、次の機会に精度を上げていくことができます。

インタビューを重ねても一人で抱え込みすぎていると感じたら、アイデアを一人で練り続けるのをやめるタイミングも読んでみてください。

この記事の次に読みたい記事

• 作る前に「本当に欲しいか」を確かめる、ランディングページ検証の仕方
• キーワードの検索需要を、無料ツールだけで確認する方法
• 本当に「買いたい」人がいるか。フェイクドアテストという検証手法