以前の記事で、エンジニアからPdMになって、プロダクトディスカバリに対する考え方がどのように変わったのかを書きました。
その中で、「解決策から入る」のではなく、「課題に向き合うこと」そのものが仕事である、という話をしました。
今回はその続きとして、
顧客から日々寄せられるフィードバック（FB）を、どのように「課題」として整理し、チームで共有し、最終的に優先順位や仕様に落としているのか、実際の運用について紹介します。
顧客FBは、そのままでは「要望」「不満」「質問」「依頼」などが入り混じった情報の集合体です。
それらをどう扱うか次第で、プロダクトの意思決定は大きく変わります。
本記事では、PdMとして実践している
- 顧客FBの整理のしかた
- 課題への変換プロセス
- チームでの認識の揃え方
について、具体的な方法を紹介します。
なぜ「顧客FBの扱い方」を見直したのか
プロダクトのリリース当初は、顧客から寄せられるFBに対して、「要望にどう応えるか」「どの機能を作るか」という視点で向き合っていました。
具体的な要望が含まれるFBほど仕様に落とし込みやすく、優先的に対応することも多くなっていました。
この状態自体が悪いわけではなく、顧客にとっては、要望した内容がすぐに実装される、良い状態でもあったと思います。
しかし、そのやり方を続けるうちに、中長期的な目線でプロダクトを見たとき、少しずつ方向性がぶれていっているような感覚を覚えるようになりました。
- 機能は増えていくのに、根本的な課題が解決されている実感が薄い
- 顧客ごとの個別要望に引っ張られ、判断に一貫性が持てない
- 「なぜこの優先順位なのか」がチーム内で共有しづらい
その原因を振り返ってみると、顧客FBを「課題」ではなく「要望の集合」として扱っていたことにあったと感じています。
要望にどう応えるか、という発想が先に立ち、「なぜその要望が出てきたのか」「その背景にどんな業務課題があるのか」という部分まで、十分に深掘りできていませんでした。
このままでは、声の大きい要望に振り回され続けてしまう。
プロダクトとして本当に向き合うべき課題を見失ってしまう。
そうした状況から、少しでも課題に向き合えるようにするために、顧客FBの扱い方そのものを見直す必要があると、強く感じるようになりました。
ここから、「FBをそのまま要望として扱う」のではなく、一度すべてを“課題”として捉え直す運用へと切り替えていきました。
顧客FBは「そのまま課題にしない」
しかし、ただFBを課題に変換するのでは意味がありません。 課題として捉えるために、すべてのFBに対して、いったん次のように分解して考えるようにしました。
- なぜ、このようなFBを伝えてきたのか
- ユーザーは、どんな状況でこのFBを出しているのか
- どのような業務フローの中で発生したFBなのか
表に出ている言葉だけを見るのではなく、その裏側にある業務の流れや、詰まっているポイントを探ることを意識するようにしました。
例えば、
「業種で絞り込んだ際に、その業種の事業をしていない企業が含まれる」というFBがあった場合でも、
それをそのまま「データの精度を見直す」という課題にするのではなく、その背景を整理していきます。
- 検索結果に対する違和感や不信感がありリストとして利用して問題がないか不安
- 絞り込んだ業種での売上が大きい企業のリストを作成したい
- 結果に出た企業を一社ずつ精査していくのは時間がかかるので難しい
これらを整理したうえで、初めて「解くべき課題」を定義していきます。
まずは実際にデータとして誤りが多いのか、それとも他の原因があるのかを検証しました。その結果として、データ自体に誤りは少ないものの、主力事業ではない業種がついていることがあることが分かりました。 これらの情報から、業種で絞り込んだ際に表示される企業と、ユーザーが認識している「その企業の業種」との間にズレがあることで、問題が起きているという背景が見えてきました。
企業DBの検索としては、その業種を含む企業をすべて表示する仕様になっている一方で、それがメインの業種なのか、副次的な業種なのか、という点で認識のズレがあったのです。
このFBの本質的な課題としては、「データの誤り」ではなく、「検索体験の改善が必要である」という結論になりました。
このように、
FB → 要望 → 背景 → 課題
というワンクッションを必ず挟むことで、
「何を作るか」ではなく、「何に向き合うべきか」から考えられる状態を作ることを目指しました。
課題はNotionで管理し、チームの共通言語に
FBをそのまま課題にしない、という整理の仕方に切り替えたことで、次に必要になったのが、「整理した課題をどう管理し、どう共有するか」という点でした。
整理した課題はすべてNotionに集約し、「誰でも見られる」「今どういう状態なのかが分かる」状態で管理するようにしました。
開発チームでは以前からNotionを使用していたこともあり、管理ツールとしてNotionを採用しています。
Notion上では、各課題について次の項目を整理するようにしています。
- 背景（事実）：どんなFBがあり、どんな状況で発生しているのか
- 本質的な課題：表に出ている要望の奥にある、本当に解くべき問題は何か
- ゴール（解決している状態）：この課題が解決されたと言えるのは、どんな状態か
- 定量指標：解決できたかどうかを、何で判断するのか
FBの内容だけを並べるのではなく、「なぜそれが課題なのか」「何が解決できればよいのか」までを言語化し、チームで共通認識を持てるようにしています。
また、ゴールの状態や定量指標までを整理したことで、成功・失敗の判断や、課題に対する施策の検討において、「どの状態を目指しているのか」が明確になりました。
その結果、認識のずれや、実装したものの効果が不明確になるといったことを、防げるようになったと感じています。
この形で課題を整理するようになってから、優先順位の判断や、開発チーム・CSチームとの認識合わせの仕方も大きく変わりました。
以前はFBをもとに「次に何をやるか」という議論になっていましたが、現在は「どの課題を解決すべきか」という話から入るようになっています。
単に「この機能を作りたい」「この要望に対応したい」という話ではなく、「この課題の背景は何か」「このゴールに対して、今どれくらいインパクトがあるのか」といった、“課題”を起点とした会話が、チーム内で増えていきました。
結果として、プロダクトとして今取り組んでいる課題がチーム全体で共有されるようになり、優先順位の判断や、その理由の説明もしやすくなりました。
本質的な課題とゴールを整理し、明記しておくことが、チームで課題に向き合っていく上で非常に重要だと感じています。
まとめ：顧客FBは「要望」ではなく、「課題に向き合うための入口」だった
顧客FBは「そのまま応えるべき要望」ではなく、「本質的な課題に向き合うための入口」であるということに気づかされました。
FBの言葉だけをそのまま受け取ってしまうと、どうしても「何を作るか」「どう実装するか」という話に意識が向きがちになります。
しかし一度立ち止まって、「なぜこのFBが出てきたのか」「その背景にどんな業務や違和感があるのか」といった部分まで掘り下げていくことで、初めて本当の課題が見えてきます。
また、課題をNotionで整理し、背景・本質的な課題・ゴール・定量指標といった形で構造化しておくことで、チーム全体で向き合うものに変わっていきました。
顧客FBの扱い方を変えたことにより、プロダクトに対する向き合い方や、チーム内での会話の質が大きく変わったと感じています。 今後も、FBから課題発見、プロダクト改善というサイクルを回し続けながら、プロダクトとして本当に向き合うべき課題を探し続けていきたいです。
