プロダクトフィードバックサイクルの構築

プロダクトフィードバックの仕組み自体は、以前からありました。ただプロダクトと機能が増え、関わる人が増えたことで、フィードバックが集まっても次の工程につながらなくなっていた。社内で何度も企画が立っては、続かなかった領域です。

体験を良くしたい意欲はありました。ただ改善の効果が数字で見えず、日々のオペレーションやKPIが優先されて着手できない。「なぜ今できないのか」をチームで議論して見えたのは、必要なのはアイデアではなく取り組む理由を数字で示すことでした。

「悪い体験をした後、継続意向が下がるのではないか」という仮説を置き、体験毀損の有無・その後の行動・結果としての継続意向を比較できる形にするため、設問を4つに絞りました。

不満を聞くだけでは、声の大きい意見が集まって終わります。毀損の有無と継続意向を突き合わせられる形にしたのは、必要性を事業の言葉で説明するためです。約2万事業所に配信し、約360事業所から回答（信頼度95%）。体験毀損がこのまま続いた場合の解約リスクを、金額で推定できました。さらに継続意向が低い層の毀損要因を分類すると、プロダクト機能への不満の多くは、すでに要望として社内に上がっているものでした。

最初に出てきた課題は、そのまま採用していません。現状の運用整理、定量データ、関係者へのヒアリングから課題を言語化したうえで、「どうしてそれが起きているのか／どうなるとよいのか」を関係者と議論し、整理し直しました。

巻き込み方も設計の対象として扱いました。関係者が20名規模で、部署もPdM・事業企画・サクセス・セールスにまたがっていました。

1. まず企画全体としてどこに向かうのか、理想の状態を言語化して共有した
2. ヒアリング → まとめ → 改善、を繰り返し、意見が反映される状態を作った
3. ロードマップは1〜3年先まで引き、3ヶ月ごとにOKRを設定して振り返りのたびに更新した

「自分が作ったものを配る」のではなく「みんなで作っている」状態を保つ。理想状態の言語化も課題の再定義も、関係者を集めた場を設計・進行する形で行いました。

サイクルを 収集 / 活用 / 届ける の3フェーズに分け、それぞれが次の工程につながるように構築しました。

PdMと協力し、過去の要望約1,500件を分類。要望起票フォームの記載項目とSalesforceとのデータ連携を設計し直しました。変えたのは、集める情報の中身です。 要望の言葉だけでなく、それがないと何に困るのかという背景を残すようにし、サポートの協力を得て小規模に試し、改善を5回ほど繰り返してから本格展開しました。

活用フェーズでは、各チームの開発プロセスをヒアリングし、共通の基本フローを描きました。

要望収集 → サクセスチーム内で分類 → PdM共有 → 振り分け（ロードマップに乗せる／差し込み対応／中長期で検討／やらない）→ 開発 → ユーザー連絡。振り分け先に「やらない」を明示的に置き、判断されないまま滞留する要望をなくしました。やらないと決まったことも、決まったこととして起票者に返せるようにしています。

届けるフェーズでは、要望をくれた方へリリース後に個別連絡する工程を作り、手順化。「フィードバックを伝えてからその後」のジャーニーをas-isとto-beで作成し、関係者とアイディエーションを行いました。

手順書を配るだけで運用が変わることは、まずありません。手順は浸透しないものだという前提に立ち、伴走と、続いているかを確認できる状態づくりをセットにしました。

1. 運用状況の可視化

   サイクルが回っているかを常時確認して改善できるよう、指標を設計しダッシュボード化した。

2. 組織体制の構築

   活動の必要性と必要な人員を事業部長に提案し、運用継続と改善検討の責任者をアサインしてもらった。

要望改善の連絡を行った後のアンケートで、95%がこの活動によってブランドへの信頼度が上がったと回答しました。社内で何度も企画が上がっては継続までできなかった領域ですが、関わる人を巻き込み、現場の運用も踏まえて構築したため、現在も継続しています。