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

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

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

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

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

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

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

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

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

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

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

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

• 友人として好き

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 社歴

4. 社員数

5. ITリテラシーの高さ

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

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