はじめに――「課題のプレゼント」が多発するインタビュー現場
「ユーザーインタビューで出てきた課題に取り組んでいるのに、なぜか施策がうまくヒットしない…………」
こんなお悩みを抱えているプロダクトマネージャーの方は多いのではないでしょうか？その裏には、ユーザーが深い痛みを感じていないのに「一応こんな課題がありまして…」と言ってくれ、それを「解くべき課題」と設定している場合があります。
この背景には、謝礼や協力意識が強く働いています。ユーザーからすると「インタビューを受けたからには何かお役に立ちたい」と考え、たいして痛くない問題を“課題のプレゼント”として渡すのです。それ自体は悪意ではなく善意ですが、プロダクト側が真に受けると施策の方向性を誤る危険があります。
本記事では、「ユーザーがコスト（多くの時間やお金）を払わない課題に騙されない」ための視点を提供します。本当に解くべき課題かどうか、何を基準に判断すべきか。僕の経験や関連する書籍、事例などを踏まえながら、PdMの皆さんに役立つヒントをまとめます。
顧客がコストを払わない課題は本当の課題ではない
「課題＝ユーザーが本気で解決したいもの」だとしたら、そこには必ず何らかのコストを払ってでも解決したいという動機があるはずです。
- お金を投じたり、
- 時間を割いたり、
- ワークアラウンドを駆使したり、
いずれにせよ、ユーザーがすでに自力で対処しようとしているなら、本物の痛みがある可能性が高いといえます。
逆に、時間もお金もまったく投じていない課題は、深刻度がそこまで高くない可能性が高いです。とりあえず口にしてみただけだったり、インタビュー相手への“誠意”として挙げている場合が多いからです。もしその課題が解決されなくてもユーザーの生活に大きな影響がないなら、我々がそこに大きく投資する意味は薄いです。
だからこそ、ユーザーリサーチでは、まずはインタビュー中に発見した課題の“切実度”を疑う視点が大切です。本質的な痛みか、単なるプレゼントなのか。この見極めが、不必要な機能開発や間違った優先度づけを防いでくれます。
事例：費用対効果を試算すると本気度が見えてくる
以前、僕は福利厚生費を狙った、社員向けの健康促進アプリを考えていた時に「xxxの機能があったら導入を検討するんだけどね」という声をよく聞きました。それは、社員の健康促進（ex,歩数など）を管理するための人事向けダッシュボードの機能で、「社員の取り組み状態を把握したいから」という課題を挙げてくれました。
しかし、要望の中心が“あれば嬉しい”程度の内容だと感じたため、思い切ってユーザーに「では、現状はそれをどうやって解決しているのですか？」「もしこの機能を年額10万円で提供するとしたら導入を検討しますか？」と聞いてみました。結果はほぼ全社が何も取り組んでおらず、コストをかけての導入にも難色を示しました。そのためそこに大きな投資をするのはやめました。
つまり、ユーザーは本当に困っているわけではなかったのです。ここで深堀りしなければ、多くの開発リソースを費やして“実は不要な機能”を作っていたかもしれません。そう考えると恐ろしい結果です。
こうした「コストを払わない課題」に引っ張られて開発してしまうと、「いらない機能」がなぜ生まれるのか？そして、我々はどうすれば良いのか？ という問題に直結します。不要機能が増えるとプロダクトが複雑化し、ユーザーの満足度も下がる。さらにエンジニアやデザイナーの時間も浪費され、チームのモチベーションが下がる悪循環になります。
課題の真偽を見極める具体的なフレームワーク
ここからは「どうすれば、本気の課題だけを見抜けるか？」という実践的な話に踏み込みます。僕は大きく4つの観点で確認してきました。
1. 行動履歴の確認
実際にユーザーが時間やお金を投じて対策している事実があるかをチェックします。例えば有償ツールの契約履歴や自作のExcelマクロなどを使いこなしている形跡があれば、本物の痛みの可能性が高いです。一方、口では困っていると言いながら代替策を全く試していない場合は要注意です。
2. 価格感・投資意欲のテスト
ユーザーインタビューで「もしこれを解決するソリューションが年額○万円なら導入しますか？」と率直に聞いてみます。金額に驚かれたら深掘りのチャンス。ユーザーが「そこまでは払えない」と言うなら本質的ではないかもしれません。
この手法はBtoBインタビューでも有効です。社内稟議を通せるほどの優先度かどうかを聞くと、案外「うーん、通せないかも」という答えが返ってきたりします。
3. 既存ワークアラウンドの有無
本当に痛い課題なら、ユーザーは何らかのワークアラウンドを見つけて使っています。ユーザーの「裏タスク」を特定して、プロダクトグロースのチャンスを見つけるという視点にも通じます。
もしユーザーがすでに苦労してツールを自作していたり、別のサービスを組み合わせて運用していたりするなら、そこにはコストが発生しているはずです。こうした状況こそ「解決してほしい痛み」が大きい分野といえます。
4. 過去の施策や成功事例の掘り起こし
「似た課題を以前解決してもらったことはあるか？」と質問します。もしユーザーが数万円を払い外部コンサルを呼んだり、定期的に外注した実績があれば、本気度が見えます。いっぽう、軽く困っている程度なら何の対策もしないでしょう。
インタビュー設計の工夫――“課題”を直接聞かない
インタビューでは「何か困っていることは？」とストレートに尋ねがちです。これだとユーザーは「せっかく時間を割いてるし…」と課題をプレゼントしてくれる可能性が高まります。
そこでおすすめなのが、「最近どんなことに時間やお金を使いましたか？」と問うアプローチです。実際の行動を語ってもらうほうが、ユーザーはリアルに思い出すので、“かも知れない課題”を出しにくくなります。さらに
- 「手作りツールを作った」
- 「外部サービスに課金した」
- 「ツールは使っていないけど1日1時間もかかっている」
などの発言が出たら、それがヒントです。
また、困りごとを「できるだけ数値化できませんか？」と尋ねるのも効果的です。たとえば
- 「それって1日どれくらい時間を消耗していますか？」
- 「月にいくらくらいコストをかけていますか？」
などです。ユーザーが明確な数字を出せない場合、本当に痛い課題ではない可能性があります。あるいは痛い課題だけれど数字管理が曖昧なだけのケースもあるので、そこはさらに突っ込むと見極められます。
課題の痛みを可視化することで得られるメリット
ユーザーインタビューの現場で「課題に対するコスト投下状況」を意識するようになると、PdMは次のようなメリットを手にできます。
- 投資判断が明確になる：優先度が格段に定まりやすい
- ユーザー満足度が上がる：本当に痛かった問題を優先して解決するので、ユーザーが心から喜ぶ
- チームのモチベーションが保たれる：不要機能の開発を減らせるため、成果が見えやすい
また、「課題が深刻度の高い領域」にフォーカスしたプロダクトは競合優位を築きやすいともいわれています（参考：Harvard Business Review, 2023）。ここを踏まえてPdMとして施策を打つと、より効果的にユーザー満足とビジネス成果を両立できます。
参考情報
- Harvard Business Review, “Why Customers Pay for Solutions They Actually Need,” 2023
- 小林 義典『「顧客課題」の本質を見抜くマーケティング思考』(東洋経済新報社)
- Christensen, Clayton. “Competing Against Luck: The Story of Innovation and Customer Choice” (HarperBusiness)
今日から実践できるアクション
- インタビューの質問を切り替えてみる
「どんな困りごとがありますか？」ではなく、「最近、何にお金や時間をかけていますか？」や「今、どんな対策をしているんですか？」を聞く。実際の行動から課題の本気度を測る。 - 試しに“有料試用”の話をしてみる
機能アイデアがあれば「もしこの機能が有料だったら？」と仮の価格を提示し、ユーザーの反応を観察する。拒否反応が強ければそこまで痛い課題ではないかもしれない。 - 過去に対策していたかをヒアリングする
「同じ問題を以前も感じたことはありますか？」「そのときはどう解決しましたか？」と尋ねる。対策があったなら本当に痛い問題の可能性大。
Q&A
- Q1: ユーザーインタビューで失礼にならないように深掘りするコツはありますか？
- A1: 「もっと詳しく聞きたいので、具体的に教えてもらえますか？」と促すのがおすすめです。いきなり疑うような言い方をすると関係がギクシャクするため、まずはユーザーの言葉を受け止めた上で、コスト面や既存対策について柔らかく尋ねるとスムーズです。
- Q2: BtoBの場合、担当者は問題と言っても決裁者が興味ないケースが多いです…
- A2: それはよくあります。担当者レベルの困りごとを経営が課題と認識していない状況です。最終的には決裁者が予算を割くかどうかを確認しないと、本当の痛みとは言えません。早めに決裁権限者の視点もリサーチしたほうが安全です。
- Q3: 開発チームが「ユーザーがこう言ってるんだから作ろう！」と盛り上がってしまうのをどう止めればいいでしょうか？
- A3: 「この課題に対して彼らは既にどれくらいコストを払っているのか？」という観点を共有すると納得しやすいです。もし払っていないなら、おそらくそこまで切実ではないのでは？と論じる形が有効です。「いらない機能」がなぜ生まれるのか？の記事も併せて読むと議論が深まります。
コメント