顧客課題の解像度を揃えることで実現した、成果につながるプロダクト改善

こんにちは、開発室の佐々木です。

企画段階では筋の通った案に見えても、いざリリースするとユーザーには使われず、事業インパクトにつながらない。
こういった悩みを抱える開発者の方も多いのではないでしょうか？

私の担当するプロダクトでも同じような悩みを抱えていましたが、取り組み方を見直した結果、受注にも解約抑止にも効く改善を実現できました。

今回は、直近の半期で取り組んできたプロジェクトを振り返りながら、事業部と開発が“同じ顧客課題”を見ることの重要性についてまとめていきます。

企画メンバー内だけで議論が閉じていた課題感

これまでのプロダクト改善では、事業部と開発から選ばれた企画メンバーのみで議論を進めていました。一見すると効率的に見えるものの、実際には日々顧客に向き合っている営業やCSの一次情報が十分に取り込まれず、企画フェーズと現場の顧客課題にズレが生まれていた状態でした。

企画書上は整っているのに、リリース後に運用へ乗らないという状況が続き、事業成果にも結びつきにくくなっていました。

この状況を変えるために取り組んだのが、事業部の定例MTGに継続的に参加することでした。

こうした現場の一次情報に触れることで、企画メンバー内だけでは見えていなかった課題構造が立体的に把握できるようになり、議論の質が大きく変わりました。

開発側としても顧客を置き去りにしていたわけではなく、理想的なUXや技術的に正しい構造を考えたうえで提案していました。

しかし、現実にはCSの運用プロセスや負荷の大きさに対する解像度が不足しており、その結果、企画内容が現場と噛み合わないケースが生まれていました。

実際には、ある機能が想定以上の作業工数を発生させ、他業務を圧迫することで事業数値にまで影響を与えていたこともあり、現場インパクトの把握が欠けていたことを痛感しました。

課題構造の把握後は、Figmaを活用したユーザーヒアリングを導入しました。
画面デザインの確認にとどまらず、実際の操作を想定しながらフィードバックを得ることで、

といった重要な気づきが得られ、作らなくてよいものを早期に削ることができました。

また、プロダクトの価値が顧客に届く最後の工程として、リリースと周知をセットで実行する仕組みを整えました。

これらをリリース日と合わせて展開することで、「リリースしたのに使われない」という状況をゼロにすることができました。

今回の取り組みで特に印象的だったのは、既存顧客の解約阻止を目的に改善した機能が、新規顧客の潜在ニーズにも刺さったことです。

既存顧客の課題を深掘りして生まれた改善が、導入前の顧客にとっても魅力的な価値になっており、結果的に新規受注にも貢献する形となりました。

受注・解約の要因を整理し、改善施策との関連性を数値として把握できるようになったことで、エンジニアの評価にも事業成果を適切に反映できるようになりました。

どの改善が事業にどれだけ貢献したかを説明できる状態が生まれ、チームとして“事業に効くプロダクトづくり”がより意識されるようになりました。

今回の半期で得た大きな学びは、
事業部と開発が同じ顧客課題を見ることで、プロダクトは確実に成果へとつながる
ということでした。

議論を企画メンバー内だけで閉じず、現場の一次情報を取りにいく。
技術的な正しさだけでなく、運用負荷や顧客の利用シーンにも目を向ける。
そして、価値が届くまでの導線を丁寧に設計する。

これらを通じて、事業にもチームにも良い循環が生まれた半期でした。

効果的な機能開発には顧客理解、強いては事業部の理解も必要になります。
この記事が、同じ悩みを抱える皆さんの助けとなれば幸いです！