プロダクト開発におけるVoC会のススメ
こんにちは。STORES でプロダクトマネージャーをしている伊東です。
今回は先日実施したVoC（Voice Of Customer）会についてご紹介できればと思います。
VoC会とは？
VoC会とは、言葉の通りオーナーさんからの要望（Voice of Customer）を
1日かけて集中的に対応する会のことで、日々オーナーさん対応の最前線にいるサポートチームと開発チーム合同で実施しています。STORES 予約では定期的にVoC会を実施しており、例年はオフライン（サポートチームの多くが仙台オフィスに在籍しているため）で実施していましたが、今年はオンラインで実施しました。
もちろん、日々の機能開発においてもオーナーさんの意見は積極的に取り入れて改善するサイクルを回しています。一方で、直接的に事業成長に繋がるわけではないが、多くのオーナーさんが躓いてしまっている細かい箇所の改善については、これまで一定の改善は実施していたものの十分に取り組めてはいませんでした。オーナーさんがSTORES 予約を使う上で少しでも躓くポイントを減らすこと、加えてサポートチームへの問い合わせ対応負荷を少しでも減らすべく、今年もVoC会を実施しました。
他にも、開発チームが認識できていないそれぞれの課題が及ぼす影響やインパクトを正確に理解したいという背景もありました。
VoC会の開催に向けた進め方
1. 会を実施する目的を明確にする
一概にVoC会といっても、実施時点での要望対応の状況に応じて目的は変化すると思います。まずはなぜVoC会を実施するのか？ということをPMが主体となって（必要に応じて運営メンバーを募りながら）クリアにすることから始めましょう。今回実施したVoC会では、下記の目的を掲げていました。
主目的：サポート要望への対応
・特に2023年は注力プロジェクトに戦略的にフォーカスしていたため、VoC要望にこれまで一定の改善は実施していたものの十分に取り組めてはいない状況
・サポートチームに課題の優先順位を整理してもらうことで、開発チームが認識できていないそれぞれの課題が及ぼす影響やインパクトを正確に理解したい。
サブ目的：交流の強化
・サポートチームとは緊急のバグ対応等で共に作業をする機会があるが、普段なかなか交流する機会が少ないためVoC会を通じて直接的なつながりを深めたい。
今回はPM1人、デザイナー1人、エンジニア6人の計8名でVoC会を実施しました。また、オンライン上でより深い交流を図るためチーム制を採用し、3チームに分けて進めました。
2. 要望を整理してもらう
次に、実際にサポートチームにオーナーさんからの要望をまとめてもらいました。ここで注意すべきは、どういう要望をどういうフォーマットで用意して欲しいかという期待値をしっかりと擦り合わせることです。
どういう要望を？については、前提としてVoC会は1日限りであり、開発に数sprint必要な機能改善が難しいです（そのような機能改善は目的ではないというのもありますが）。そのため、もちろん具体的な見積もりは開発陣で実施しているのですが、1日限りという前提のもとサポートチームの方にも軽微な文言追加や修正、機能の改修をメインに要望を収集してもらいました。
また、要望を集める軸についても、新規MRRやチャーンレート等直接的に事業数値に寄与するか？という軸ではなく、サポートチームにおける重要指標である問い合わせ数の減少や対応満足度の向上に必要か？という軸で集めてもらうようにしました。
どういうフォーマットで？については、例えば単純にこういう機能が欲しい！というまとめを共有されただけでは、誰が / なぜ / どういう時に困っているのか？ということがわからず、方針の検討が難しいと思います。そのため、どういう業種 / 規模のオーナーさんがなぜそれを必要としているのか？というのがわかるようなフォーマットで整理してもらいました（実際にはサポートチーム主体で機能検討がしやすいフォーマットで整理してもらいました。PMをはじめとした開発陣をとても考えてくれている素敵なチームです）
機能が必要な背景を事細かに記載してくれています。
3. 各要望の対応可否 / 見積もりを整理する
サポートチームが整理してくれた要望を、各チームに分かれて対応可否の検討と見積もりを実施しました。僕らの場合、サポートチームの方とも事前に会話した結果「一つでも多くの改善がリリースされると嬉しい！」ということだったので、1日の中でいかにリリースするか？という前提のもと、改善の優先順位やチームごとの見積もりを実施しました。対応方針を検討する中で「これはどういう方針で進めるべきなのだろうか？」というものも当然発生していたので、サポートチームと認識を揃えたい点については事前にドキュメントに整理しておきました。
実際に実施してみた結果
当日は下記のタイムスケジュールで進めました。エンジニア陣から「朝9時早すぎだろ！」という声はありましたが、問い合わせ対応の都合上どうしてもということで9時から開始しました。
1 .自己紹介タイム（9:00-9:15）
2. 解決策のブレスト（9:15-10:00）
3. 開発タイム①（10:30-14:30）
4. 中間共有（14:30〜15:00）
5. 開発タイム②（15:00-17:30）
6. 成果発表会（17:30-18:00）
午前中は主に、事前に上げてもらった要望と対応方針を擦り合わせ、この進め方で問題がないか？ということを議論しながら実装方針を検討しました。
また、今回はチーム制を採用したこともあり、方針検討にPMやデザイナーが必要な要望がチーム横断で散らばっていました。そのため、PMとデザイナーは全チームの要望に目を通した上で、対応の優先度を整理していました。
事前準備の反省として、事前にPMやデザイナーのリソースが必要となる要望を見分け、それを前提とした見積もりやチームごとの要望配分ができれば
よりスムーズに開発に着手できたと思っています。
午後も引き続き実装を進めてもらいつつ、対応が完了したものについてはレビューをいただいたり、午前中検討したデザインや文言案についてサポートチームの方と議論する時間になりました。サポートチームの方に「一つの文言でここまで議論するのか…！」と驚かれながらも、リアルな機能開発の現場を見てもらえたのはとても良かったのではないかと思っています。また「オフラインで実施した時よりもオンラインの方がむしろ気軽に意見を言えて嬉しい！」という声ももらえてとても嬉しかったです。
最後にチームごとに成果発表会を実施したのですが、結果1日でなんと10個の機能改善をリリースすることに成功しました！サポートチームの方からも「こんなに改善してもらえると思ってなかったのでとても嬉しい！」と言っていただき、無事会を成功で終えれることができました。
VoC会をオススメする3つの理由
開発メンバーで「オーナーさん目線の」共通認識を持てる
開発メンバーは中々オーナーさんとの接点が多くない中で、VoC会ではサポートチームを通じてとても多くの要望、オーナーさんの考え方に触れることができます。1つ1つの改善の実装工数自体はそれほどだったり、中には1日での対応が難しい要望もあったりしましたが、1日の中でたくさんの要望、考え方に触れた結果、開発チーム内で「こういう点でオーナーさんは躓く可能性があるのか」というの共通認識を持てたことは今後の開発にも活きるとても良かった点だと思います。
実際に改善した成果として1つ共有しておくと、STORES 予約では予約のキャンセル期限の設定（何時間前 / 何日前 / キャンセル不可）をすることができます。そこでキャンセル期限を1日前と設定したオーナーさんから「キャンセル期限の1日前は、前日の23:59までなのか、予約日時の24時間前なのかどちらなのか教えて欲しい（実際には24時間前までの仕様）」という問い合わせが多く届いているようでした。予約管理をされるオーナーさんにとって、ユーザーがいつまでキャンセルできるかというのは非常に重要な点です。そこで今回は、キャンセル期限の設定で「日前まで」が選択された際には、1日前=24時間前を示すというテキストが表示されるように改善しました。細かい点ですが、開発メンバーがオーナーさんが思わず戸惑ってしまう箇所を認識して改善できた、とても良い事例だと思っています。
開発 ⇔ サポート間の距離感がグッと縮まる
従来、開発メンバーとサポートチームは、日々オーナーさんからの問い合わせ対応のためオンライン上かつ非同期で交流することはあっても、今回のVoC会のように同期的にコミュニケーションを図る機会は多くありませんでした。そのため、VoC会のサブ目的として交流の強化は掲げていたのですが、とはいえオンラインでの開催ということもありオフラインに比べてどうしても密度の濃い時間を過ごすことは難しいかもな…と正直当初は思っていました。
ですが、（思いもよらず）逆にオンラインで実施したことで、とても嬉しい意見をサポートチームからもらうことができました。今回のVoC会はSpatialChatという、普段開発メンバーで利用しているチャットツールにサポートチームの方をお招きし、その中で主にコミュニケーションを図っていました。これまで、開発メンバーとサポートチーム間のコミュニケーションは非同期で行われていたのですが「ちょっとした会話でコンテキストを伝えられて、開発の方に相談するハードルが下がる！」と言ってもらえたのはとても嬉しかったです。他にも、VoC会の終了後には「問い合わせ対応業務の効率化でこんなことできないんですか？」というラフな会話が生まれていました。サポートチームの方がテキスト情報だけでオーナーさんの状況を伝えるのに苦労されていた中で、開発 ⇔ サポートチーム間で、同期的にラフなコミュニケーションが図れる場を提供することの価値を再認識できました。
要望を改善してもらえる場！として認識してもらえる
上述していますが、セールスやカスタマーサクセスと密に連携を取りながら機能開発のサイクルは回せている開発チームは多くあると思います。
一方で、事業成長を優先する上で、一定の改善は実施していたものの、中々サポートチームに届く細かな問い合わせ内容改善の優先度を上げれず、つい対応を後回しにしてしまっているケースはよくあるのではないでしょうか。僕らもそういった現状があり、結果として「Issueはあげているけど…どこに要望をあげたら改善してもらえるんだろう…？」という感情を抱かせてしまっていたと思います。
VoC会を実施する目的は、もちろんもらった要望を改善する場でもありますが、同時に「VoC会に要望を持ってくれば改善してもらえるかも！」という場として認識してもらえることの価値は非常に大きいなと個人的に思っています。要望が発生してから改善に至るまでのサイクルはどうしても長くなってしまいますが、定期的に改善を検討してもらえる場があるというのはサポートチームが要望に向き合う上でとても重要です。断言はできませんが、改善検討してもらえる場があることで、よりVoCが組織に集約されていくのではないかと思っています。
この記事を読んでくれた皆様もぜひ、VoC会を開催してみてください！
※この記事はSTORES Advent Calendar 2023 の30日目の記事です。
この記事が気に入ったらサポートをしてみませんか？