「お客様の声を大切にする」と謳う企業は多いものの、実際には集めた声に振り回されて開発が迷走するケースが少なくありません。
VOC（Voice of Customer、顧客の声）を 製品開発の意思決定に使えるデータ に変えるには、設問設計と分析プロセスに工夫が必要です。
VOCをそのまま機能化してはいけない
「Aという機能が欲しい」という声を額面通り受け取るのは危険です。理由は3つ：
- 顧客は解決策ではなく問題を語っている: 「Aが欲しい」の背景に「Bという課題」がある
- 声の大きい少数派 に引きずられる: 全顧客の代表性がない
- 機能を増やすほど プロダクトの一貫性が崩れる: 個別要望の継ぎ接ぎは UX を悪化させる
VOCを設計する際は、「何を作るか より 何を解決するか を引き出す」設問構成を意識してください。
VOC収集に有効な設問構成
1. 課題（Problem）を聞く
Q1. 当社製品を使う中で、最も困っている・面倒だと感じる場面を教えてください。（自由記述）
Q2. その場面が発生する頻度はどのくらいですか？
○ 毎日
○ 週に数回
○ 月に数回
○ 月1回以下
Q3. その場面で発生する手間・時間のロスはどのくらいですか？
○ 10分以内
○ 30分以内
○ 1時間以内
○ それ以上
頻度 × 時間損失 で 課題のインパクト が定量化できます。
2. 要望（Solution）を聞く（任意）
Q4. その課題を解決するために、どんな機能や仕組みがあると良いと思いますか？（自由記述・任意）
要望は 任意 にする。書きたい人だけ書く。
3. 既存の代替手段を聞く
Q5. 現在その課題にどう対処していますか？
○ 別ツールを併用
○ 手動で対応
○ 諦めている
○ その他（自由記述）
代替手段が「諦めている」なら課題の重要度は低い、「別ツールを月額○○円で契約」なら高い、と判断材料になります。
4. 利用シーン・コンテキスト
Q6. その課題が発生する具体的な業務シーンを教えてください（自由記述・任意）
ユースケースが見えると、機能化の優先度判定が大きく変わります。
集計と優先順位付けの方法
KJ法による分類
自由記述を テーマ に分類します。50件以上集まったら、
- 似た内容のカードに切り分ける
- 似たカードをグループ化
- グループ名を付ける（「データインポート」「権限管理」「通知」など）
- グループの規模を比較
これだけでも要望のテーマ別ボリュームが把握できます。
Frequency × Severity マトリクス
各テーマに対して、
- Frequency（頻度）: 該当する課題を抱える顧客の比率
- Severity（深刻度）: 課題の業務影響度
を2軸で評価。両方が高いテーマから優先的に対応します。
Jobs to Be Done フレームワーク
「顧客は何のジョブ（仕事）を片付けようとしているか？」という観点で要望を再解釈する手法。
「データのCSV出力機能が欲しい」という要望
→ 背景のジョブ:
- 月次レポートを作る
- 外部システムにデータを移送する
- バックアップを取る
ジョブが分かれば、CSV出力以外の解決策（Slack通知、API連携、自動レポート生成）も視野に入ります。
VOC調査の頻度と運用
既存ユーザー向け（四半期ごと）
Q1. 当社製品の改善ポイントを5つ挙げるとしたら？（自由記述）
Q2. その中で最も重要なものは？
Q3. 当社製品で「もうこれなしでは困る」と感じる機能は？
満足ポイントと不満ポイントの両方を聞くのが重要。「無くなったら困る」要素は 守るべきコア機能 です。
解約者向け（解約タイミングで）
Q1. 解約の主な理由は？（複数選択）
Q2. 改善されたら継続したいと思える点は？（自由記述・任意）
Q3. 移行先のツールがある場合、決め手になった点は？（自由記述・任意）
解約理由は 新規開発の優先順位 に直結する重要なシグナル。
新規ユーザー向け（オンボーディング後30日）
Q1. 当社製品を選んだ決め手は？
Q2. 想定通りの活用ができていますか？
Q3. 改善してほしい点があれば？
期待と現実のギャップを埋めるヒント。
VOC分析でやってはいけないこと
❌ 設問数を増やしすぎる
15問以上のアンケートは、後半の回答が雑になりノイズが増える。
❌ 「総合的なご意見」だけ聞く
「ご自由にお書きください」だけだと、何を書けばいいか分からず、結果として情報量が薄い。
❌ 一部のヘビーユーザーの声だけ採用
声の大きいユーザーに引きずられないよう、回答者の 属性別集計 を必ず行う。
❌ 開発判断を100%データに依存する
VOCはあくまで 判断材料 であり、プロダクトビジョンと照らし合わせて取捨選択するのは開発側の責任。
まとめ
VOCを意思決定に使えるデータに変える4つのポイント：
- 課題（Problem）を中心に聞く、解決策（Solution）は任意
- 頻度 × 深刻度 で定量化する
- テーマ分類 で要望をまとめる
- 解約者・新規ユーザーも分けて聞く
レポアンの 製品バグ報告 と 機能要望 テンプレートは、本記事の課題ヒアリング構造を組み込んだ形で提供。
VOC運用の最大のボトルネックは「集まった声を分析しきれない」こと。レポアンの AI レポート機能（詳細）は自由記述を 「データインポート」「権限管理」「通知」 といったテーマに自動分類し、Frequency × Severity マトリクスをエグゼクティブサマリーで自動出力。月100件超の VOC でも30秒で要点が把握できます。バグ報告系ではファイル添付 でスクリーンショットも一緒に集められます。
関連記事
- VoCを集める7つの手法：VoC（Voice of Customer）の集め方
- 顧客自身も気付いていない動機：顧客インサイトの発見方法
- AI時代の自社一次データの価値：AIで全部分析できる時代に、なぜアンケートを取るのか
- n=1から事業仮説を立てる：n=1分析の使い方