ユーザーヒアリングからのアクションを「具体」「抽象」の観点から考えてみる
記事ビジネス・マーケティング
こんにちわ。
ノーコードを使用してプロダクト開発をさせていただいている蒼士と申します。
さて、ここからが本題です。
プロダクトを作っていくにあたって
・誰の
・どんな課題を解決するのか
ということを明確にすることはマストであり、そのためにペルソナへの理解を深めることが重要であります。
こちらのことに関しては、以下の記事にて詳しく書かせていただいたため、まだご覧になっていない方はご覧いただければ幸いです。
そこで、ペルソナへの理解を深めるため、また適切な解決策、機能を考えるための選択肢として「ユーザーヒアリング」を行うことになるかと思いますが、今回は当記事のタイトルにもある通り、そのユーザーヒアリングからのアクションを「具体」「抽象」の観点から考えて述べてみようと思います。
☑️読んで欲しい人
・ユーザーヒアリングへの解像度がまだ低い方
・ユーザーヒアリングからの分析をプロダクトに反映したが、あまりうまくいっていないという方
当記事を読むことで、ユーザーヒアリングをする際の少しでもお役に立てれば幸いです。
それでは早速入っていきます。
☑️「具体」「抽象」の観点から３つに分類
今回は、ユーザーヒアリングからのアクションを「具体」「抽象」の観点から考えてみるということなので、まず、その流れを大きく以下の３つに分けて考えてみたいと思います。
【１】具体→具体のアクション
【２】抽象→抽象のアクション
【３】具体→抽象→具体のアクション
【１】具体→具体のアクション
これは、いわゆる「そのまま対応する」というパターンで、ちょっと危険なやつですね。
・ユーザーから「〜機能が欲しい」と伺ったからその機能を追加する
・ユーザーから「値段が高い」と伺ったから値段を下げる
みたいなことです。
これがなぜ危険かというと、「ユーザーは自分の欲しいものを本当にわかっているわけではない」ということが大半であるからです。
スティーブ・ジョブズも実際にこのようなことを述べています。
「多くの場合、人は形にして見せてもらうまで、自分は何が欲しいのかわからないものだ。」
ユーザーからの意見というのは、現状からの改善でしかなく、「質問として聞かれたからなんとなく答えてみた」みたいなケースにもなりかねないということです。
例として
自分が幹事のパーティーにて、パーティー後にとある出席者から
「今回のパーティーって時間が短かったよね。」と言われた場合
を想定してみてください。
これに対してどのようなアクションを取りますでしょうか？
そのまま具体→具体で対処するとしたら
「次回のパーティーではもっと時間を長くする」
ということになると思います。
しかし、これで良いのでしょうか？
実際に、その後のパーティーにて時間を長くしたら、そのパーティー後に、本人から
「今回のパーティーは長かったよ...終盤の方なんて全くつまらなかった。」
と言われたらどうでしょうか。
「いやいや、あなたが長くしてって言ったから長くしたんですよ！？」
と突っ込みたくなるかと思いますが、こんなことはプロダクト開発においても実際にあることです。
いわゆる「モグラ叩き状態」ですね。
「会議が短かった」と言われて、会議の時間を伸ばす
「資料の枚数が多い」と言われて、資料の枚数を減らす
これらでも同じことが考えられるかと思いますが、実際のところは表面的な解決になってしまうこと多く、本当の問題の解決策になっていないということが考えられます。
【２】抽象→抽象のアクション
これは、あまり考える必要までもなさそうですね。
・ユーザーから「なんかいまいち満足していない」
・ユーザーから「〜がよかった」
などとということを伺い
・これから改善点に対して迅速に対応策をうつ
・何かユーザーの課題を解決する機能を作る
などと対応することです。（少し極端かもしれませんが）
確かに俯瞰して抽象的に捉える視点も持っておくべきではありますが、あくまで１つの持っておくべき視点に過ぎないと思います。
【３】具体→抽象→具体のアクション
こちらが今回ご参考にしていただきたいアクションになります。
まずは現実で起こっている事象を具体的に捉え、それを一度抽象化して俯瞰的に捉えた上で、その解決策を導くために、再度具体化するということです。
この表現も抽象的でイメージしづらいかと思うので、さきほどの例と同様に
自分が幹事のパーティーにて、パーティー後にとある出席者から
「今回のパーティーって時間が短かったよね。」と言われた場合
で考えてみます。
先ほども述べましたが
「ユーザーは自分の欲しいものを本当にわかっているわけではない」
ことが大半であるため、「言外の真意」を意識しなければなりません。
つまり、その発言の背景にあった本当の問題を考えるということです。
今回の例で言うと
・なぜ時間が短いと言ったのか？
・そもそも人間はどんな時に「時間が短い」と感じるのか？
というように、考えていくイメージです。
そして、その「事実をベースに仮説を考えていく」ということが非常に重要になります。
今回のケースで最も可能性が高いと考えられることは「時間が短かった」ということが「普通に楽しかった」こととイコールであることです。
このほかにも仮説として考えられるのは
・想定していたより多くの人と話せなかった
・話すことでいっぱいで、食事をするための時間を確保することができなかった
....
などといったことです。
このようなことから、単に時間を長くするだけでは真の課題解決にはなっていないのは明らかかと思います。
もし仮に「普通に楽しかった」ことが真意であるのなら、次に取るべきアクションは
同様の楽しさをキープするように努めること
になります。
つまり、今回の発言は褒め言葉であったと言うわけです。
ですがもし、「想定していたより多くの人と話せなかった」ことが真意であれば、解決策は
コミュニケーションを取るグループを用意し、一定の時間はそこで話してもらうこと
になるかもしれません。
また、出てきたメニューが原因で、「今回のパーティーって時間が短かったよね。」となってしまっていたなら、解決策は時間に関することではなく
用意するメニューや食事内容を改善すること
になるかもしれません。
くどいようで恐縮ですが、このように単に時間を長くすると言うことだけでは、真の問題の解決にはなっていない可能性が大変高いということです。
このように「顧客の具体的な依頼をあえて抽象度の高いニーズに一度引き上げた上で、自身の幅広い知識や経験から、再びより適切かつ具体的な解決策の提示をすること」が専門家として、お仕事をする上での本質なのではないでしょうか。
つまり、「遊園地に行きたい」という依頼に対して
「どの公共交通機関を使用する？」
という返答をすることは適切ではないということになります。（プライベートでのお話の場合は別です）
なので、ユーザーからのヒアリング内容が仮に同じだったとしても、打つ策は人それぞれ異なるということになり、また、それがプロダクト開発者としての腕、価値が最もわかりやすくあらわれる部分なのかとも思います。
よりシンプルに言えば
「ユーザーからの事実をもとに課題の推測をすること」
ここを当てることができるが最も重要であり、またネックになってくる部分かと思います。
☑️まとめ
今回は「ユーザーヒアリングからのアクションを「具体」「抽象」の観点から考えてみる」ということで、ユーザーヒアリングからのアクションを大きく３つに分けて述べてみました。
総括としては
「自分の欲しいものを本当にわかっているわけではないユーザーの依頼をそのまま聞くのではなく、その発言の背景にある事実から課題を推測することが重要」
ということになるかと思います。
特に、これからAIやロボットが発達していき、人間の仕事が代替されていく時代を生きていくにあたって
「具体的な事象を抽象化して本来のニーズを捉えること、応用を利かせること、また、それに対して確度の高い解決策を仮説として打ち出せること」
ができる人が、より希少価値の高い人材になっていくのではないのでしょうか。
当記事が、ユーザーヒアリングをされる方の少しでもご参考になれば幸いです。
また、下記記事では、ノーコードで開発できるプロダクトの一例を紹介しています。
「こんなアプリって実装可能？」
「いくらぐらいで出来るの？」
「アイデア段階でどうしよう…」など
アイディアベースでのご相談も承っておりますので、まずはお気軽にご連絡をいただければと思います。
最後までご覧いただき、ありがとうございました！
