ユーザーの声をプロダクトに反映する

「ユーザーの声を大切にしましょう」
プロダクト開発において、繰り返し強調されてきた考え方であり、今では常識に近いものとなっています。
一方で、実際にプロダクトを作っていく過程ではいろいろな人のいろいろな声が混在しており、それらに全て対応することはできません。
この記事では自分の経験をもとに、ユーザーの声をプロダクトに反映していくプロセスで、どんなところに気をつけるといいかについて紹介します。

誰の声なのか

サッカーについて野球選手に聞いてもあまり参考になりません。
当たり前ですが、「誰が言っているのか」はオピニオンマネジメントの観点で非常に重要です。

上記の例は極端ですが、例えば採用サービスや教育系のサービスなど、みんながなんとなくわかる領域では良かれと思って意見を言ってくれる人がたくさんいます。
限られたリソースの中で、
- 所属
- 役職や経験
- 年齢
...etc
さまざまな観点から本当の「ユーザー」を定義し、ユーザーの声に向き合っていくことが大切です。
なので、ユーザーの声を集め、共有する際は必ずどんな属性の誰が言っているのかという情報もセットで共有しましょう。

探索と検証を分ける

今自分たちが
- ユーザーの事を知り、課題を深掘っていく探索
- 仮説を立て、それが正しいのかの検証
どちらをやっているのかは明確に区別すべきです。

探索フェイズは発散でもあり、さまざまな声をもらって意外な発見ができることが価値です。
一方で検証フェイズでは仮説が正しいか間違っているかを確かめるタイミングなので、それ以外の声はある種ノイズになります。

もちろん探索→検証といった単純なステップではなく、実際は両者を反復しながら進めていくことになります。ただし両方を同時にはやらないことが混乱を防ぎ、結果的にスピードを早めることに繋がります。

生の声と意見を混ぜない

ユーザーの声をチームに共有する際に、自分の言葉で変換や要約してしまうのはやめましょう。そこには絶対にバイアスがかかり、本来の意図とは違う声となってしまう可能性があります。

理想的には
- 生の声（テキストならできれば前後含めコピペやスクショ。口頭の場合もなるべく発言したままの書き起こし）
- ↑を聞いた上での考察（本当はこういうことを言いたかったんじゃないか）
がセットになっていると良いと思います。

要望より感想

そもそもユーザーは本当に欲しいものを自身で理解できていないケースも多いです。「○○が欲しい」といった声はズバリそのものが欲しいというよりも、それによって解決される課題は何なのか、それはもっと良い手段で解決できないのか考える必要があります。一方で、「この機能は使いにくい」といった実際のプロダクトに対するフィードバックは事実をもとにした感想なので、真摯に受け止め解消に努めています。

声はあくまでインプット

実際のプロダクト開発では、さまざまなユーザーの声と自分たちの実現したい世界観、技術的な投資などのバランスの中で優先順位を決定していきます。

ユーザーの声はあくまで一つのインプットであり、声を聞くのはユーザーの視点を自身に憑依させ、肌感を持って意思決定するためです。

声をくれるユーザーへの感謝を忘れずに、サービスの価値で恩返しできるよう、ユーザーの声だけでなく自分の声も大切に、今後も試行錯誤していきます。