顧客の声を「最短で反映する」VoC運用設計を実践してみた話
はじめに
みなさんこんにちは、カミナシの細見（@yuta_hosomi）です。
このnoteでは、カミナシで２つ目プロダクトの顧客フィードバック（VoC = Voice of Customer）を、どのようにインプットからアウトプットに繋げていくサイクルを、いかに構築・運用したかについてご紹介します。
私自身これまで、複数のプロダクトでこのVoCサイクルを作っては止まり、改善しては迷い…を繰り返してきました。今回、新規プロダクトに関わる中で「3.4度目?の正直...」と題して、私がこれまでの失敗も踏まえた、セールスやカスタマーサクセス（ビジネスチーム）とエンジニアやプロダクトマネージャー（サービスチーム）メンバー間の配慮点や設計・運用の試みをまとめました。
<このnoteに書かれているコト>
・なぜVoCのワークフローはうまくいかなくなるのか
・顧客の声をどう聴き、捉えたのか
・集積する情報設計をどうするか
・回収後、どうプロダクトチームに届け反映させるのか
新規事業に携わる方や、特に CS（カスタマーサクセス）やマネージャー職 における「VoCの型化・言語化」は、非常に重要かつ汎用化が難しいテーマだと思っています。少しでも参考になれば嬉しいです。
前提
ここで紹介するのは、カミナシのプロダクトや組織体制 を前提としたモデルです。
特に「0→1or 1→10フェーズ」での運用を想定しているため、プロダクトの成熟度や組織状態によって課題の粒度は異なる可能性があります。
また、カミナシの特性上、受注前よりも受注後の顧客要望が圧倒的に多い ため、やや受注後の視点に偏った内容となっています。
ビジネスチームからのVoC運用が難しくなる要因
まず、非エンジニア・非PdM（サービスチームと呼称）メンバーがプロダクトのVoCを組織に共有・運用する際、私が感じた難しさを4つに分けて紹介します。
1. フィードバックの粒度が人によってバラつく
・SaaS経験や顧客折衝経験により、質問力・聴取力に差が出てしまう
・カスタマーサクセスマネージャー（主にミーティングなどのコミュニケーション）と、カスタマーサポート（非同期でのチャットやメール問い合わせ中心）など接点の違いなど、職域により情報の粒度や密度が異なってしまう
・買っていただく為のVoCと使い続けてもらう為のフィードバック属性が異なりやすいこと
これらの経験や職種により、VoCのドキュメントに記載される情報の質&量は常にばらつきが発生しやすくなる側面があると思って然るべきです。
2. 有象無象のVoCが蓄積されてカオス化する
・背景情報の少ないVoC情報（例：問い合わせフォーム経由での要望）がそのまま保管(チケット化)され、アウトプットに繋がりづらい情報のままになっている
・投稿された情報の一貫性が崩れると、視認性と活用性が急速に低下する
以前、執筆したnote(以下参照)で使われていないドキュメントを"ゾンビ化ドキュメント"と表現しましたが、VoCの情報群も同様で、視認性が低下した有象無象のVoCが少しでも混ざるとすぐに全体がノイズ化しやすくなってしまいます。
3. 投稿したVoCがその後どうなったか分からず（分かりづらく）、自分ごと化されにくい
・VoC投稿者は、リリース後にそれが反映されたかどうかを追いづらい。
・開発チームとビジネスチームで管理するツールやプロセスが異なると、どのVoCがどの実装につながったか不明瞭になりがち。
私は選挙でこの公約がいいとおもって投票した方の、その後がどうなったかその公約がどうなったかを積極的に取りに行くのがいつしか億劫になるのですが、その感覚に近いなと感じています。
4. 職種による「前提情報の非対称性」が大きい
VoC情報の非対称性が起きやす構造例
挙げるとキリはありませんが、私がIS、Sales、CS、BizDevと（薄く広くですが）それぞれの業務視点を経験させていただき、この普段扱う言語情報と思考プロセスのズレや認知の非対称性を生みやすいのでは？と感じています。
そこで、今回新規プロダクトに関わるタイミングで、「VoC情報のカオス化」を防ぐための仕組みとオペレーション設計に取り組みました。
以下では、前段の4課題に対応するために行った施策をご紹介します。
具体的に取り組んだ座組と施策
施策① 「誰でも気軽に投稿できる」VoC専用投稿チャンネルを設け、「一番閲覧しているドキュメントに蓄積し」、誰でも気軽に見やすい状態に
前述した通り、投稿への心理的・物理的ハードを少しでも軽減するために、弊社で全員が毎日利用している「Slack」にVoC投稿専用のチャンネルを新設し誰でも簡単に顧客の声（VoC）を投稿できる仕組みを整えました。営業・CS・サポートなど、顧客に接する部門が得た声をすぐに共有できるようにしています。
また、投稿されたVoCは、ワークフローを通じて、これも日常で全員が利用しているnotionに蓄積されるようになっており、いつでも誰でもアクセスできる導線に拘りました。VoCをJiraやBacklogに直接いれる方法も前職等で取り組んで見ましたがビジネスチーム全員がアカウントを持っているわけではないため、一部のメンバーのみしか情報にアクセスできない状態や普段使わないツールだと認知が低下していく要因の一つに繋がりやすいと私は感じます。
これにより、この半年間で250件以上のVoCが集まるようになりました。
基本的に同じ過去に言われたことのある機能や要望でも必ず投稿してもらうようにしています。
施策② "VoCの投稿者"と"VoCを受ける人間"と温度感がずれない共通言語をつくる
私のチームのVoCの投稿は下記のような情報を記載してもらっています。
機能要望は解決策はあくまで補足情報として、
本質を全員で捉えられる情報を頑張って記載してもらっています。
そのうち、特には以下の点を意識して構築しています。
・ 欲しい機能（インタビューの冒頭でユーザーから言われる「こういった機能がありませんか？」）よりも、As-Is(今の機能で提供している[しまっている]体験）を極力記載すること。[推理することでも◎]
・ 要望の機能や体験の重要度や緊急度の物差しを極力揃えること
私のチームでは、いただいた要望のお困り度や重要度を、投稿者や要望を承った人間の視点で、この要望が使い続けられない(≒解約されること)、人間の生存に必要な要素を比喩的にラベル分けを行ってもらっていたりします。
施策③前提の情報量と共通言語が類似している数人で、情報を精査や校正する
私のチームでは、まずVoCの溜まったNotionを毎週必ずCSチームで議論&精査し、ワークフローで投稿された一次情報の記載を校正しています。
1. Notionに集約されたVoCを週1でチェック
2. 各VoCに顧客データベースとの紐づけを実施し、どのお客様からのフィードバック可を逆引きできるようにする
3.「理想の状態の情報ブラッシュアップ」「既存代替手段の有無」などの観点で整理
4.「より緊急度高く解決必要ながVoC」かどうかラベル検討
5. 他のユーザーから同様文脈の要望があるかどうかの目線あわせ
これにより、「集めただけで終わる」状態から脱却し、サービスチームの皆さんへ判断しやすい情報として届けられる工夫をしています。今後は生成AIを活用して、理想の状態の言語化の補正や支援をできるような工夫も講じたいと考えています。
施策④ サービスチームと定期的（溜まりまくる前に）に同期的にVoCを読み合わて認識差異を小さくする
③の段階を経て、次に、プロダクトマネージャーとプロダクトデザイナーと1投稿1投稿記載されたVoCを全員で咀嚼し、共通のビジョンと言語をすり合わせします。
ここで「このVoCはこういった解釈をしましたがイメージあってますか？」や「もう少し解像度が必要なので顧客インタビューをしましょう」などと、アウトプットに利用できる情報群になるように心がけています。（今はまだ、大きくないチームなのでこれができているとは感じますが...）
この形式で対話することで、「実装ありき」ではなく、「何を解決したいのか？」を起点とした会話ができるようにしています。
要望をサービスチームとコミュニケーション取るときにいつも大事にしている前提の考え方はこの考え方(ユーザーの”Job”)を参考にするようにしています。
施策⑤ 投稿したVoCがどの顧客からいつ、言われたもので、それは今どんな開発状況なのかをすべて可視化する
③の段階前述しましたが、投稿されたVoCのNotionデータベースは、顧客情報マスタデータベースがあり、そことリレーショナルでつながっています。
また、サービスチームの開発Issue管理とも連携しており、それぞれのVoCのデータに実装ステータス情報を持ち合わせています。
これにより、機能が実装されたら、その機能のVoCをもらった顧客の逆引きができるようになっており、提供された顧客に個別提供完了報告とお礼連絡を行えるようになっています。
私は、せっかくお寄せいただいた要望に対して、可能な限り実装のご報告と、いただいた要望のお礼を送るようにしたいと考えています。今後は温かみを残しながらも、ある程度自動で個別お客様にお送りできるようなオペレーションを構築していくことを準備しています。
施策⑥ あえて優先順番を決めた、魂のVoCチケットを別で管理する
VoCは蓄積するだけでは意味がありません。月に1回、ビジネスチームでもVoCの傾向を振り返ったり棚卸しすることも重要です。私たちのチームではこのVoCの保管庫以外に、継続してお使いいただくための要望の優先順位だけを10個を常にあえて決めておくことも行っています。
VoCのデータベースに沢山溜まってくると(だいたい100個くらい投稿を超える)もう眺めているだけでは判断がつかないため、サービスチームから「詰まる所、事業拡大に一番優先度が高いのはどれですかね？」という会話がしばしば発生するようになります。
そこで、レベニュー観点で必要な上位10傑をチームで常に話し合い、必ず1〜10まであえて序列付けを行うようにしています。（あくまで各チーム観点なのでそれだけが優先されないお約束で運営しています）
あえて序列をつけている理由は以下の通りです。
序列をつけることで、どの要素がより重要かについて議論が生まれ、影響範囲や同じフィードバックがどれくらい重視されているかといった根拠を明確にしたかった。
開発サイクルでは、機能リリースにおける週ごとの着手可能な工数が異なるため、例えば空いている工数を活用して「今週は工数が空いているので、上位の項目から順にこの機能を合間に実装します！」といった形で、サービスチームがスムーズに取り組めるようにしたかった。
この様に、毎月「魂の10傑」(そう呼んでいます)をチームで議論し、優先順位を変更、追加を都度行っており、議論をスムーズに行うための準備を行っています。
実行力があるのは、『優先度』よりも『優先順位』だったりします。
施策⑦ VoC保管庫の管理者を決めて徹底する
私が大好きな図書館も、司書さんがいなければカオスになってしまうのと同じように、 「VoCのデータベースも司書さんのような役割と責任を明確にすること」や「VoCの各チケットを新鮮な鮮度状態に保つこと」は非常に重要です。そのため、門番となる人を明確に決めています。
もし手をつけなければ庭がすぐに荒れてしまうように、VoCの保管庫も定期的な管理が欠かせません。そのためには、データクレンジングの習慣を作り、それを継続することも欠かせません。
具体的には、「毎月最終金曜日に1時間を取って、この保管庫をチェックし、実装されていれば実装ステータスに変更する、など最新の状態に保つ」という取り組みを9ヶ月間欠かさず行ってきました。この取り組みがあったからこそ、いつでも「最新の状態です」と自信を持って言える状況を作り続けることができました。（結局、最後は精神的な持続力も重要です^^;）
で、どうなったのか？
このプロセスを始めてから9ヶ月が経過しましたが、250件近いVoCが投稿され、そのうち"40％はすでに実装または提供される状態"に至りました。（サービスチームの卓越した技術力、パフォーマンス、コミットメントには本当に感服しています）また、未実装のVoCチケットが減っていくことで、残りの未実装チケットがより明確になり、「次に何が最も必要か？」という視点での議論がしやすくなります。これにより、より迅速な意思決定が可能になり、良い循環が生まれてきていると感じています。
お読みいただいた皆さまが、少しでも前向きなエネルギーを得られれば幸いです！ありがとうございました！
最後に[採用の宣伝]
私達と一緒に、日本3,900万人のノンデスクワーカーの皆様の支援をしてくださる仲間を募集しております！このnoteに関することでもゆる〜くお話しましょう！XのDMでもお待ちしています！
CS以外の職も全方位お待ちしております！
