はじめに
こんにちは、支払い.comでフロントエンドの領域を担当しているMurakamiです。
今回は、ユーザーの声（VoC: Voice of Customer）をチーム全員で定期的に振り返り、プロダクト改善に活かしている仕組みについて紹介します。
「ユーザーの声を大切にする」という共通認識は誰しも持っていると思います。しかし実際は、タスクに追われてフィードバックが埋もれてしまったり、担当部門だけで処理されてしまったりするケースも多いのではないでしょうか。
支払い.comでは、1ヶ月ほど前からVoCを「毎週必ず意思決定まで行うサイクル」として仕組み化しました。まだ実績は浅いものの、改善がスピーディに回り始めています。
この記事では、そのプロセスや文化的意義、エンジニアとして感じたことを紹介します。
VoCを仕組みにする必要があった理由
プロダクトに向けられるフィードバックは、新規利用時の疑問や長期利用中の課題など多岐にわたります。しかし、意識的に仕組み化しない限り、そうした声は蓄積されても活用されず、改善の機会損失になりがちです。
そこで私たちは、ユーザーの声が確実に改善に結びつくように、次のようなサイクルを構築しました：
- アクセス可能性を高める：誰もがいつでもユーザーの声に触れられるようにする（Slackへの通知）
- 振り返りの場を設ける：定期的に集まり、改善の是非や優先度を判断する（VoC定例ミーティング）
- 行動に落とし込む：決定事項を必ずタスク化する（バックログへの追加）
- 継続的に改善へ反映する：タスクを積み上げることで、ユーザー体験を磨き続ける（開発タスク化・実行）
このサイクルを通じて、「ユーザーの声が散らばって消える」のではなく、必ず改善に結びつくようになりました。
VoCの収集ルート：2つの入口
- 新規登録ユーザーへの架電（オンボーディングチーム）
初めての利用でつまずきやすいポイントや疑問を、生の声として率直に拾います。 - 問い合わせフォームからの声（CSチーム）
実使用中のユーザーから具体的な質問や課題が届きます。
これらの声のうち、改善につながりそうなものをスプレッドシートに自動で集約し、メンバーが見られるようにしています。 オンボーディングやCS経由で得られるVoCを整理・可視化することで、Biz / CS / 開発を含むメンバー全員が同じ情報を共有しながら議論できる体制を整えています。
VoC定例準備ミーティング
ユーザーから寄せられるVoCは日々たくさん届きます。ですが、それらをすべて定例ミーティングで議題にしてしまうと、時間が足りず意思決定が進まなくなってしまいます。
そこで、定例の前に短い「準備ミーティング」を設け、効率的に議論が進むよう工夫しています。ここでは：
- Slackに流れたVoCを一覧化
- 過去のデータも含め、件数が多いテーマや影響度の高いものを抽出
- 定例ミーティングでジャッジすべきトピックを決定
こうして準備を整えることで、定例ミーティングが「場当たり的な情報共有の場」ではなく、優先度の高い意思決定を効率よく行う場になっています。
毎週のVoC定例ミーティング（火曜30分）
VoC定例ミーティングには、Bizメンバー、CSチーム、オンボーディングチームが参加します。
ゴール
- 優先度高く取り組むべき施策を決める
- 現在進行中の改善タスクを共有する
内容
- 現在進行中の改善タスクの確認・共有
- 準備mtgで抽出されたトピックの「やる／やらない」、優先度の決定
- 開発タスクを作成し、すぐに着手できるものは開始。 議論が必要なものは別途テキストコミュニケーションや同期的なmtgで相談。
この流れによって、「ユーザーの声をため込まず、その週に意思決定して改善につなげる」ことが実現できています。
エンジニアがVoCを直接とりにいく意味
この取り組みで特に大きいのは、エンジニア自身がユーザーの声を直接とりにいくようになったことです。
以前はサポート経由で要望が伝わることが多く、情報が要約される過程で「なぜその声が出てきたのか」という背景まで理解するのは難しい状況でした。
しかし今では、エンジニアがSlack上でリアルタイムにVoCを目にすることで、ユーザーが置かれている状況や本当に困っているポイントまで把握できるようになりました。
その結果、ユーザー理解の解像度が上がり、改善案を検討する際も「どの課題にどう効くのか」を具体的にイメージできるようになります。これによって、改善の確度が格段に上がり、無駄のない開発ができるようになったのです。
仕組みを回して見えてきた課題
VoCを仕組み化して毎週の改善につなげられるようになってきましたが、まだ始めて1ヶ月ほどということもあり、課題もはっきり見えてきています。
- 定量化の基盤不足
現状は定性的な声が中心で、件数や影響度を数字で把握する仕組みが整っていません。そのため、やる／やらないの判断が個別の声に左右されやすく、データの裏付けが弱い状態です。
- ユーザー行動との結びつきが弱い
問い合わせや困った際のユーザーイベントログが整理されていないため、「声」と「実際の利用行動」をひもづけて分析できていません。
- 効果検証の弱さ
リリースしても「本当に効いたのか」を検証する設計が後追いになり、改善のサイクルが十分に回せていないのが現状です。
今後はこうした課題を乗り越えるために、定量化の仕組みやイベントログの基盤整備、効果検証フローの確立にも取り組み、より確度の高い改善サイクルを回していきたいと考えています。
おわりに
支払い.com開発チームでは、以下の仕組みで「ユーザーと一緒にプロダクトを育てる」ことを目指しています：
そして何よりの魅力は、支払い.comのエンジニアは「単なる開発者」にとどまらないということです。コードを書くことに加え、BizやCSをはじめとした沢山のチームと一緒にユーザーの声を聞きにいき、自分たちの手でプロダクトを磨き上げていけます。
開発そのものの楽しさに加えて、自分たちの改善がユーザー体験に直結する実感を得られるのは、大きなやりがいです。もし「プロダクトを育てるエンジニアリング」に興味がある方は、ぜひ私たちと一緒に挑戦してみませんか？
We Are Hiring !!
支払い.comをはじめUPSIDERでは現在積極採用をしています。 ぜひお気軽にご応募ください。
カジュアル面談はこちら！
Culture Deckはこちら📣
