ユーザーの改善要望の集約とビジネスチームとの連携（1）
サービスを運営する中で、プロダクトマネージャー（本稿ではPMとします）のみなさんは日々たくさんの改善要望を目にされていると思います。プロダクトの初期フェーズでは、要望一つひとつに目を通しプロダクトロードマップに施策を組み込み改善のサイクルを回せていたのに、いつからか日々の業務や、より重要な課題が出てきて、全ての要望に目を通せなくなった経験はありませんか？
前回の記事では御守一樹（STORES事業責任者）から、PMが社内の信頼関係構築に責任を負わなければならないという話をしました。今回はSTORESプロダクトマネージャー 重山由香梨より、幅広いユーザーからいただく改善要望をどう集約し、ビジネスチームとどう連携しているか、弊社での試行錯誤を具体的に紹介していきます。
改善要望を吸い上げる仕組み「カジュアルアイディア」
現在、ネットショップ開設サービス「STORES」のプロダクトでは「カジュアルアイディア」という仕組みがあります。これは、heyに所属している社員であれば、誰でも気軽に改善要望を投稿できる要望フォームです。直接ユーザーさんからいただいた要望だけでなく、社員が使いづらいと感じたところなどを、プロダクトチームと普段話す機会がないメンバーでも、気軽に伝えることができます。
1日に平均5件以上、多い時は数十件の投稿があり、フォームに追加された要望はSlackを通じてPMやデザイナー、エンジニアが目を通します。スレッド内で改善策を議論するシーンも多々見かけます。
このほかにもSlackにはユーザーさんから送られてきたご意見を見られるチャンネルがいくつもあり、課題やユースケースにアクセスしやすい環境にあります。
- カジュアルアイディア
- CSに届いた要望の原文を見られるチャンネル
- STORES管理画面からユーザーさんが投稿した改善要望が見られるチャンネル
全てを合わせると月に1000件近くの改善要望がプロダクトチームに届いています。
組織の拡大に従って、改善要望の運用がしづらくなる
私が入社した2020年10月には、PMチームで週に1回ほど、カジュアルアイディアから投稿された要望に目を通して改善策を考える時間が確保されていました。PMがクリティカルだと判断したものは、ロードマップに追加することができていました。しかし、組織がある程度小さい規模の頃には上手く回っていたこの方法も、組織が拡大していく中では運用しづらい状態になっていました。
「これ前ももらった要望だよね」「以前誰かが検討した気がするけど」という会話が増え、改善要望や議論した内容、経緯がストックできていないことで、プロダクトメンバー内でも認識のずれがあり、要望を上げてくれたメンバーには経緯を追いづらい状態となっていました。また、新しいメンバーが入ってきたときのキャッチアップコストが高いという課題もありました。そこで、運用方法をアップデートすることにしました。
要望のフローをストックへ変更して整理
STORESは2012年にサービスをローンチしてから9年近く経っていることもあり、これまでのプロダクト開発における経緯を理解した上で仕様を理解し、改善要望に向き合う必要があります。
まずは、Slackとスプレッドシートで管理していた改善要望を、「Zapier」というノーコードツールを利用し投稿時に自動issue化することで、要望をストックできる形に変更しました。
issue化した要望は機能カテゴリごとに分類し、PMメンバーで議論した内容はissueにコメントする運用に変更することで、後で閲覧した時に経緯を把握しやすい形になります。また、重複しているケースを把握できるため、機能のどこにボトルネックがあるのかを認識しやすくもなります。
実際の運用
- 要望フォームに記入
- Slack・issueに同時投稿
- 週1でPMが要望を確認
- エンジニアに共有し、対応策と工数感まで出しておく
入社直後だったこともあり、月に1000件近くある改善要望を一つひとつ見ていても、どこにボトルネックがあるのか理解できなかったため、課題をマッピングし階層化を進めました。
課題が単独であることはまれで、多くはほかの課題と関連していました。実際にマッピングしてみると、特定の課題を解決すると下層にある問題も合わせて解決できることが分かってきます。また、図に起こすことでなぜこの改善をやるべきなのか、なぜやらないのかについて、プロタクトチーム内外で認識を合わせるのに都合がよかったです。
前述の通り要望をマッピングすると、複数の要望を1つの課題に集約することができるケースがあるため、その中からやるべきことをピックアップしていました。こうした整理によって大きなリリースの合間にタイムラグなく改善策を実施できるようになりました。
もちろん、最優先は全体のロードマップです。リソースが増えたとしても、そのタイミングでやるべきことは次から次へ出てきます。現状のリソースでも着手しやすい仕組みを作ることで、要望対応の停滞を回避できると考えました。
