全PMが知るべき「本当の課題」を知るユーザーヒアリング手順と失敗例まとめ

Shin

先日こちらのツイートをしたところ、大きな反響がありました。私が顧問をしている企業だけでもユーザーヒアリングで大きな間違いをしていて、せっかくやったのに良い情報が得られず時間を浪費してしまうのは超あるあるです。

ユーザーヒアリングとは歴史・手法ともに奥深く、突き詰めようとするとどこまでもやれてしまいます。

しかし、手法はあくまで目的達成のための手段です。今回は難しいフレームワークなどは使わず、プロダクト作りに関わるプロダクトマネージャー、事業開発者がやるべき「実践的なユーザーヒアリング」にフォーカスして解説します。

ユーザーヒアリングでよくある失敗5パターン

まず最初に、ほとんどの人がやってしまう失敗パターンを紹介します。そもそもな話、ユーザーヒアリングとは「ユーザーの課題を知る・推測する」というインサイトを得ることであり、それを達成するために必要な情報はすべてヒアリングしなければいけません。しかし、こういう質問をつい皆やってしまいがち、といういわゆる「ムダ質問」はよく見受けられます。なぜムダ質問がムダなのか、理由も含めてまとめました。

よくある失敗1：「〜という課題はありますか？」とあるorないかを聞く

これが最もよくある失敗で、課題を「ある」か「ない」かだけで考えてしまうことです。何がまずいかと言うと「ありますか？」と聞かれたら、だいたいの人が「あります」と答えるからです。しかし、本当に知りたいのは「その課題の大きさ・深さ」なのでYes/Noだけで測ろうとするのは非常に危険です。

これは例えば、男性に対して

「あなたは知人女性の◯◯さんのことが好きですか？」

と質問されたとしましょう。この時、よっぽど嫌いでない限りは「好きです」と答えるでしょう。しかし、好きの中にも

  • 恋愛として付き合いたいくらい好き

  • 友人として好き

  • 知人だけど嫌いじゃいくらいには好き

  • 社交辞令として好きと言っているだけ

いろいろな深さの「好き」があるわけです。これら全てを「好き」の一言だけで片付けるのは非常に認識がずれて危険であることがイメージしやすいと思います。

課題がたとえあったとしても、それは「お金を払ってでも解決したいほどの課題」なのか「無料ツールがあるなら解決したい課題」なのかでビジネスとして成立するか大きく変わります。この観点があるかないかはユーザーヒアリングを成功するかどうかを大きく左右するでしょう。

よくある失敗2：「どうすれば解決しますか？」と直接聞こうとする

これもよくある失敗パターンで、いわゆる「相手に解決策を聞いてしまう」問題です。ユーザーは自分が置かれている状況を客観的に把握しているわけではないので、ものすごく主観だけで意見を言うもの。それなのに、解決策を相手に聞いて思考が引っ張られるのは非常に危険です。

解決策を聞くのではなく、まず課題とその深さを知ること。そしてそれをどう解決するのかを考えるのがプロダクトマネージャー、事業開発の仕事です。ここが難しくも面白いところなのですが、相手に安易に聞いて言いなりになると一貫性のないプロダクトになってしまいます。

ヘンリー・フォード氏の有名な格言があります。

もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。

ユーザーは本当に自分が欲しいものは分かっていないものです。早い馬ではなく車を考えるのが仕事なので、難しい仕事ですがここから逃げてはいけません。

よくある失敗3：ヒアリング相手のペルソナがない、セグメント分けしていない

こちらはユーザーヒアリングをやる前に起きている問題で、すでに関わりのあるお客様にだけヒアリングをしてしまう問題です。関係性がすでにある人相手にヒアリングをする方が楽なのでついやってしまいがちですが、これは非常に危険です。なぜか？

そもそもユーザーヒアリングは最初にも書いたとおり、「ユーザーの課題を知る・推測する」というインサイトを得ることです。ここの「ユーザー」が誰なのか？をしっかり定義しないと、お客様じゃない人の意見に左右されてしまいます。

例えば、ToBプロダクトでユーザーペルソナをセグメントに分ける場合、このような分け方があります。

  1. 企業規模（大企業か中小企業かスタートアップか）

  2. 業界（IT業界、商社、メーカー、コンサルなど）

  3. 社歴

  4. 社員数

  5. ITリテラシーの高さ

こういったセグメントに分け、どこで切り分けるかによってヒアリングするべき相手は大きく変わるでしょう。自分たちのプロダクトのお客様が誰なのか、ここをヒアリング前に定義しないと、正しい質問内容も決められません。ユーザーの定義とヒアリングはワンセットで行うものと理解しておきましょう。

よくある失敗4：ファクト情報を集めようとしない

相手の意見を聞くことがユーザーヒアリングではありますが、その前に相手の定量情報・ファクトを知ることはとても大事です。なぜなら、ファクトがあるかどうかで、同じ情報の「解釈」が大きく変わるからです。

例えば、とある企業にヒアリングをしていて、

「社員同士の連携が取れない！なんとかしたい！」

と言われたとします。そこで

「なるほど、じゃあ連携を取れるためにコミュニケーションツールを提供すればいい！」

と考えてしまいがちですが、これは必ずしも正しいとは限りません。なぜでしょう？この会社が社員数の情報を解釈するとき、

  • パターン1：社員数10名で超忙しいスタートアップ

  • パターン2：社員数1000名で部署が多い大企業

このどちらかによって課題が大きく変わるためです。パターン1の場合は、10人しかいないのに連携できてないのは「単純に業務が多く忙しい」が本当の課題である可能性があります。この場合、コミュニケーションツールを提供しても、そもそも使う時間がなくて解決しない、というオチになってしまいます。

パターン2の場合は、業務量がそこまで多くないのであれば純粋に「コミュニケーションの機会・量が少ない」が課題になるかもしれません。この場合は、確かにツール導入で解決しやすいでしょう。

このように、同じ情報でもファクトによって解釈が大きく変わります。なのでヒアリングをする時は、意見だけでなくファクトを集めることがとても大事です。

よくある失敗5：課題を解決できない理由をヒアリングしない

課題があると回答され、それがとても深いものだったとします。それなのに、なぜ解決できていないのか？を聞かずに「よし、チャンスだ！」と考えてしまうのもあるあるな失敗です。

大きな課題があるのに行動にできていない場合は、何かしらの阻害要因がある可能性が高いのです。

  • 予算がない

  • 上司が許さない

  • 会社文化が新しいものを受け入れない

  • 業務が忙しすぎて対応できない

  • 過去にやって失敗した

などなど、様々な理由が背景にあることは珍しくありません。この背景を知らずにプロダクトを作っても、同じ轍を踏むだけです。課題があるとしても、それがなぜ解決できていないか、まで深くヒアリングすることが大事です。


ユーザーの課題を知るために効果的なユーザーヒアリングのやり方


1. ヒアリングの目的を定める

まず、ヒアリングで何の情報を得たいのか確かめましょう。

  1. お客様の課題を知る

  2. 他にもっと大きな課題がないか知る

  3. 課題の深さを知る

  4. ファクト情報が足りないから集める

などなど、目的は状況によって変わります。まずはここを認識することからスタートします。

2. 仮説を作りペルソナを具体的にする

目的を定めたら、次に「誰に聞くか」を決めます。先述したように、ビジネスであれば自分たちが提供するべき正しいお客様にヒアリングをしなければいけません。

それを知るために、セグメントに分け、ペルソナを具体的にイメージしていきましょう。

3. まずファクト情報を集める

ヒアリングする前にできるだけファクト情報を集めておきましょう。アポの前に、Googleフォームなどで定量情報を集めておくと効果的なヒアリングがしやすくなるのでおすすめです。

4. ヒアリングをしファクトを元に課題を推測する（インサイトを得る）

ヒアリングでは、相手の定量データだけでは答えられない意見・感想を集めます。ここで、ファクトを背景に「課題を推測する」ことが求められます。

大事なのは、あくまで「推測」することで、相手に解決策を聞くことでもなければ、こちらが解決策を決めつけるわけでもありません。現時点で「これならこの大きな課題を解決できるのでは？」という仮説を作り、それを元にプロダクトの仕様として落とし込むのです。

もしかしたら、推測は間違っているかもしれません。しかし、推測するまでのプロセスが正しければ、次また違う仮説を試せば良いだけなので、学習する機会になり次の失敗する確率が減るでしょう。このように、短期で素早い学習をして、プロダクトを改善することがプロダクトマネージャーの最も大事な仕事です。


5. 課題を解決するためのプロダクト機能を考える

ここからがプロダクトマネージャーの本領発揮です。課題とその解決策の推測ができたら、それを機能としてどう提供するか要件に落とし込みます。

この機能を考えるとき、プロダクトマネージャーの個性が出ます。プロダクトマネージャーが変われば、同じ課題と解決策を考えても、提供する機能は変わってくるので、ここが難しくも面白いポイントだと思っています。

ただ大事なのは、最初から機能ありきで考えないこと、課題をしっかり把握し、それが解決しきれるような機能を考えることが大事です。


おわりに：ユーザーヒアリングは学ぶ機会が少ない、しかし知っておくべき

プロダクトマネージャーにとってユーザーヒアリングはとても重要であるにも関わらず、なかなか体系的に学ぶ機会がありません。プロダクト作りのスキルも大事ですが、その前段階でユーザーヒアリングの重要さはあまり語られないので、今回整理してみました。

今回の記事はあくまで「簡易版」であり、UXリサーチャーのプロからすると抜けている項目が多いはずですが、最初から完璧にやるよりは致命的な失敗を避けつつ、まずはやってみることが結果的にユーザーの課題把握には役立つはずです。

このようなプロダクトマネージャーのスキルを向上させるコンテンツはいま私が運営するプロダクトマネージャー向けコミュニティ「PM Club」で準備しておりますので、ご興味ある方はこちらの記事をご覧ください。

記事へのご意見などあればぜひTwitterでフォローのうえリツートをお願いします！


この記事が気に入ったらサポートをしてみませんか？