VOC（顧客の声）の活用方法｜届いた声を読み落とさない3つの習慣
VOC（Voice of the Customer、顧客の声）の活用方法を調べると、アンケートやインタビューの集め方についてよく紹介されていることが分かります。ただ、実際のBtoB SaaSの現場で足りていないのは、たいてい声の量ではありません。問い合わせや商談メモ、定例会の議事録という形で、声はすでに届いています。
その声が消えるのは、担当者が1人で読んで要約した瞬間です。この記事では、すでに届いている声を読み落とさないための3つの習慣を紹介します。
- 要約せず、届いた言葉のまま読む
- 1人ではなく、立場の違う複数人で読む
- 月1回30分など、短い時間で何度も読む
VOCは新しく集めなくても、もう手元にある
VOCの教科書的な手順では、まず20〜30人にインタビューをします。消費財のように潜在顧客が多い分野なら、それができます。
BtoB SaaSでは事情が違います。私たちが支援に入った現場でも、既存顧客が20社に満たないプロダクトは珍しくありませんでした。そこで「まず30人に話を聞きましょう」と提案しても、そもそも人数が足りず、日程調整だけで数週間が過ぎてしまいます。
代わりに見るべきなのは、すでに届いている記録です。例えば以下のようなところに既に声がん残っている可能性があります。
- サポートへの問い合わせ
- 営業の商談メモ
- 定例会やQBRの議事録
- 解約時のやり取り
これらは、すでに終わったインタビューの記録のようなものです。新しく人を集めるより、手元にあるものを読み直すほうが速く済みます。BtoB SaaSのVOC活用は、集めることより既存の声を読むことから始めていきましょう。
1人で要約した時点で、半分が消える
ここで問題になるのが読み方です。
VOCの方法論を整理したGriffinとHauserの研究（1993年）に、次のような実験があります。同じインタビューの書き起こしを7人に別々に読ませ、顧客ニーズをどれだけ拾えるかを比べました。結果、**1人が拾えたのは平均54%**でした。7人分を重ねると、ほぼ全件に届きます。
意外なことに、いちばん少なかったのは定性分析の専門家でした。研究が挙げる理由は先入観です。詳しい人ほど内容を先に想定して読んでしまい、想定外の発言を見落とします。
この実験はインタビュー記録が対象なので、問い合わせや商談メモでも同じ比率になる保証はありません。ただ、日常業務の記録は「もう知っている内容」に見えるため、読み飛ばしはむしろ起きやすいと考えられます。
声を集める仕組みを整えたあと、読む工程を1人に任せる形はよく見かけます。しかし上の数字を前提にすると、その時点で半分近くを捨てていることになります。
その担当者が優秀かどうかの問題ではありません。1人で読むこと自体に限界があります。
ここからは、この取りこぼしを防ぐための3つの習慣です。
習慣1. 生のまま読む
1つめは、要約やダッシュボードではなく、届いたままのテキストを開くことです。
同じ研究に、「1日パソコンを使うと何もかもぼやける」という発言を「適切なエルゴノミクス」というラベルに置き換えてしまう例が出てきます。整理された言葉のほうが扱いやすく見えますが、どんな場面で困っていたのかという手がかりは落ちています。「UI改善の要望が3件」という集計値も同じで、その3件が同じ課題なのか別物なのかは分かりません。
もうひとつ注意したいのは、解決策の形で届く声です。「CSV出力の機能をつけてほしい」のような要望は、そのまま残しつつ、その裏にある困りごとを1行添えておきます。
| 区分 | 記録の例 | 扱い |
|---|---|---|
| 届いた言葉 | CSV出力の機能をつけてほしい | そのまま残す |
| 裏にある困りごと | 月末に上司へ報告する資料を、手作業で作っている | 1行添える |
解決策だけを記録すると、CSV以外の選択肢が見えなくなります。困りごとが残っていれば、レポート画面をそのまま共有できればCSVは不要かもしれない、といった別の解き方も後から検討できます。元の言葉を残す考え方は、機能要望の収集を一本化する方法でも触れています。
習慣2. 読む人を増やす
2つめは人数です。
顧客が20社しかいないなら、20社ぶんの記録を3人で読みます。人数の制約は顧客側にありますが、読み手の数はこちらで決められます。
読む人は、PMだけでなく開発や営業、CSが混ざっているほうがよいです。先の研究でも、拾えた量が多かったのは専門家ではなく開発チームでした。立場が違う人が読むと、拾う箇所がずれます。そのずれが、1人では見えなかった部分を埋めます。
習慣3. 短く、何度も読む
3つめは頻度です。始め方として現実的なのは、月1回30分程度の「読む会」を定例に置くことです。
直近の要望20件ほどを、3人で読みます。 各自が気になった1件を挙げ、なぜ気になったかを一言ずつ話します。準備も議事録も要りません。
この形で見つけやすいのは、同じ課題を指している別の言い方です。営業が聞いた「一覧が見づらい」と、サポートに届いた「どこに何があるか分からない」は、同じ画面の話である可能性があります。言葉が違うので検索では見つからず、1人で読むと別件として処理されがちですが、複数人で読むと同じ課題ではないかと気づけます。1件ずつでは優先度が低くても、まとめれば順位が変わります。重複の見分け方は機能要望の重複統合・粒度そろえの実践Tipsで扱っています。
30分で終わる規模にするのは、続けるためです。四半期に1度の大掛かりなVOC分析会は、準備が重くなって回数が減り、やがて開かれなくなります。1回を軽くし、回数で拾う形のほうが長続きします。
よくある質問
VOCの集計ダッシュボードがあれば、生のまま読まなくてもよいのでは？
ダッシュボードは、すでに分かっている課題の量を追うのに向いています。一方で、まだ名前のついていない課題は集計の軸に存在しないので、数字には出てきません。新しい課題を見つける工程と、既知の課題の量を追う工程は別物です。ダッシュボードは後者に使い、前者は生のテキストを読む場を別に持つのが現実的です。
読む会で気になった声が出たあと、どう扱えばよいですか？
その場で優先順位を決める必要はありません。気になった1件を要望管理の受け皿に、元の言葉と気になった理由を添えて登録するところまでが読む会の範囲です。同じ課題を指す声が複数あれば、この時点でまとめておきます。何を先に作るかの判断は、別の工程として月次のロードマップ検討などで行います。判断の進め方は「開発する機能の優先順位を決める方法」を参照してください。
インタビューはやらなくてよいということですか？
そうではありません。手元の記録を読んで「この課題を詳しく聞きたい」という見当がついてから、その顧客に話を聞きに行く、という順番が自然です。見当がない状態で30人に聞くより、聞きたいことが決まった状態で3人に聞くほうが、BtoB SaaSでは実行しやすく、得られる情報も濃くなります。
まとめ
BtoB SaaSでは、VOCは集める前にもう届いています。その声が消えるのは、1人で要約したときです。
要約せずに生のまま読み、読む人を増やし、短い時間で何度も読む、という3つを回すだけで、手元の声から拾える量は変わります。拾った声から何を先に作るかは、開発する機能の優先順位を決める方法にまとめています。
