「どんな機能が欲しいですか？」

この質問、プロダクト開発をしているとプロダクトマネージャーやエンジニアが聞いているのを良く耳にします。
お客さんに質問してしまっているケースもよく見ます。でも僕は、この質問は意味はなく、無駄だと考えています。

なぜ「欲しい機能」を聞くのが悪手なのか

聞かれたら何か答えなきゃいけない心理

ユーザーインタビューで「欲しい機能ありますか？」と聞かれたら、ユーザーは何か答えなきゃいけないと思ってしまいます。

実際、僕も他社のサービスについてインタビューを受けた時、同じ経験をしたことがあります。特に困ってないけど、聞かれたから「あったら便利かも」程度のことを答えてしまう。でも、それにお金を払うかと言われたら、絶対に払いません。

この「聞かれたから答える」という機能要望は、本当のニーズとは全く違うものです。

ユーザーは自分が欲しいものを知らない

ヘンリー・フォードのこの言葉が全てを物語っています。ユーザーは今ある世界の延長線上でしか考えられません。自動車という概念がない時代に、自動車が欲しいとは言えないのです。

ソリューションではなく問題を語ってしまう

ユーザーは問題ではなく、自分なりに考えたソリューションを語ります。

「検索機能を強化してほしい」という要望の裏には、「目的の情報にたどり着けない」という問題があります。でも、その解決策は検索機能の強化ではなく、情報設計の見直しかもしれません。

では何を聞くべきか

目的を聞く

下記、画像のように「◯◯がしたい」と言われていても「なぜ◯◯をしたいのですか？」と聞くこと、が重要です。

例えば、僕は下記のように聞くことが多いです。

• 「昨日、このツールを使って何をしましたか？」

• 「その作業の目的は何でしたか？」

• 「その作業にどれくらい時間がかかりましたか？」

• 「その結果、何が得られましたか？」

行動を聞くことで、ユーザーの実際のワークフローが見えてきます。目的を聞くことで、本質的な課題が見えてきます。

困っていることを具体的に聞く

「困っていることはありますか？」という漠然とした質問ではなく、下記のような具体的な場面を聞きます。

• 「最後にイライラしたのはいつですか？何が原因でしたか？」

• 「締切に遅れそうになった時、何がボトルネックでしたか？」

• 「同じ作業を何度も繰り返していると感じる瞬間はありますか？」

• 「ミスが起きやすいのはどんな作業ですか？」

代替手段を聞く

今使っているツール以外でどう解決しているかを聞くことも重要です。

• 「このツールがない時、どうやってその作業をしていましたか？」

• 「他に併用しているツールはありますか？なぜ使い分けているんですか？」

• 「紙とペンでメモを取ることはありますか？どんな時ですか？」

代替手段を聞くことで、現在のツールに足りない機能が見えてきます。

頻度と時間で価値を測る

僕自身、BtoBサービスの開発に携わることが多いのですが、BtoBサービスの開発で最も重要なのは、ROIを最大化することです。そのために、作業の頻度と時間を必ず聞きます。

開発投資の判断基準

計算式を使って判断基準の1つとするという方法があります。
例えば下記のような計算式があります。

削減時間 = 頻度 × 短縮時間 × 利用者数

例えば

• 年1回2時間の作業を自動化 → 年間削減時間：2時間

• 毎日10分の作業を5分に短縮 → 年間削減時間：約20時間

• 毎日10分の作業を100人が実施、5分に短縮 → 年間削減時間：約2,000時間

大通りを大事にしろ

下記の樫田さんが書かれているnoteのように「一番の大通り」に施策を打つのが最も効果が良いです。

たしかに、AIを使った機能や派手な新機能はわかりやすさといった意味ではいいかもしれません。
ですが、地味だけど大半のユーザーが使う機能を改善する方が全ユーザーとしては価値を高くしてくれるのです。

また、下記のようなものを意識しておくと良いです。
まずやるべきは右上の毎日の重い作業から改善を目指すべきです。

必ず聞くべき4つの質問

1. 頻度: 「この作業、どのくらいの頻度でやりますか？」

2. 所要時間: 「1回あたり何分くらいかかりますか？」

3. 関与人数: 「チーム何人くらいがこの作業をしていますか？」

4. ボトルネック度: 「この作業が遅れると、他の業務にどんな影響がありますか？」

この4つを聞けば、開発するべき機能の解像度が少しずつ高まっていきます。

頻度と時間を聞かないと起きる悲劇

「要望通り作ったのに使われない機能」の大半は、頻度と時間を確認していないことが原因です。

ユーザーは「あったらいいな」と「なくては困る」を区別して話してくれません。だから僕たちが、頻度と時間という客観的な指標で判断する必要があるんです。

実践的なインタビューテクニック

観察が最強

言葉より行動を見る。これが一番確実です。

僕はできるだけ、実際の作業を見せてもらうようにしています。「普段通りに作業してください」と言って、横で観察します。

観察のポイントは下記の通り

• 迷っている瞬間

• 画面を行き来している回数

• 別のツールを開くタイミング

これらの行動は、言葉にならない不満を表しています。

仮説検証型の質問

自分の仮説をぶつけてみることも有効です。

「もしかして、○○の作業に時間がかかっているんじゃないですか？」
「○○の時に困ること、ありませんか？」

仮説が外れても問題ありません。「いや、そこは大丈夫なんですけど、実は...」という形で、本当の課題が出てくることが多いです。

よくある失敗パターン

アンケートで機能要望を聞く

最悪なのが、アンケートで「欲しい機能を教えてください」と聞くことです。

アンケートだと、ユーザーは深く考えずに「あったらいいな」レベルのことを書きます。それを真に受けて実装しても、誰も使いません。

ヘビーユーザーの声だけを聞く

ヘビーユーザーは既に使いこなしているので、高度な機能を要望しがちです。でも、大多数のユーザーにとっては複雑すぎて使えない機能になります。

競合にある機能を要望される

「○○（競合サービス）にはこの機能があるから、うちにも欲しい」

これも要注意です。競合の機能をコピーしても、コンテキストが違うので上手くいきません。なぜその機能が必要なのか、本質を理解することが大切です。

◯◯機能がほしいというユーザーの声から目的を推測する

「◯◯機能が欲しい」、「◯◯したい」などユーザーが声を挙げてくれることはあると思いますが、そこから深堀りせずに目的を推測してしまうということがよくあります。
要望から目的を精度高く推測することは不可能です。
下記の画像のように「もっと早い馬がほしい」と言われていても
様々なパターンが存在するからです。

プロダクトマネージャーとしての心構え

ユーザーの専門家ではなく、課題解決の専門家になる

ユーザーは自分の仕事の専門家です。でも、課題解決の専門家ではありません。

僕たちの仕事は、ユーザーの専門知識を引き出し、そこから課題を発見し、ユーザーが想像もしていなかった解決策を提供することです。

小さく試して学ぶ

いきなり大きな機能を作るのではなく、プロトタイプで小さく試します。

例えば、紙でモックを作って、ユーザーに見せたり、実装前に反応を見ることで、方向性が正しいか確認できます。

データと組み合わせる

インタビューで得た定性データと、実際の利用データを組み合わせることが重要です。

「この機能をよく使う」と言っていても、ログを見ると月1回しか使っていない、なんてことはよくあります。言葉と行動のギャップを見つけることが大切です。

まとめ

「欲しい機能ありますか？」この質問をやめることから始めましょう。

代わりに聞くべきは：

1. 何をしているか（行動）

2. なぜそれをしているか（目的）

3. 何に困っているか（課題）

ユーザーは、自分が本当に必要なものを言語化できません。聞かれたから答えているだけのことも多いです。

僕たちの役割は、ユーザーの要望を実装することではありません。ユーザーが気づいていない課題を発見し、想像を超える価値を提供することです。

「もっと速い馬」を求めているユーザーに、自動車を提供する。それがプロダクト開発の本質だと僕は考えています。

次のユーザーインタビューでは、「欲しい機能」ではなく「目的や課題を見つけること」を意識すると良いなと思っています。

他にも下記のようなnoteを書いているのでよかったら見てください。

プロダクトマネジメントでお困りごとありましたら、問い合わせいただけると幸いです。