VoCが増えるほど迷う：機能改善を「今やる／やらない」に分ける
「この機能を追加してほしい」「あれがないと契約できない」。顧客の要望が増えるほど、何を優先すべきか決められなくなるチームは多いです。
この記事でわかること
- なぜ優先順位が決められないのか: 「声の大きい顧客」問題と判断基準の不在
- RICEスコアリングの使い方: Reach・Impact・Confidence・Effortで定量評価
- 実践ステップ: 要望リストから次のスプリントに反映するまでの流れ
基本情報
| 項目 | 内容 |
|---|---|
| カテゴリ | GTM戦略 |
| 難易度 | 中級 |
| 想定読了時間 | 10分 |
なぜ優先順位が決められないのか
「声の大きい顧客」に引っ張られる
大口顧客や、頻繁に要望を出す顧客の声が優先されがちです。しかし、その顧客が全体を代表しているとは限りません。
判断基準がない
「重要そう」「やりたい」という感覚で決めると、議論が堂々巡りになります。何をもって「優先度が高い」とするかの基準が必要です。
緊急対応に追われる
目の前の課題に対応し続けると、中長期で重要な機能開発が後回しになります。
RICEスコアリングとは
Intercom社が開発した優先順位付けフレームワークです。4つの要素でスコアを計算します。
RICE = (Reach × Impact × Confidence) / Effort
| 要素 | 説明 | 単位 |
|---|---|---|
| Reach | この機能が影響するユーザー数 | 人数/四半期 |
| Impact | ユーザーへのインパクトの大きさ | 0.25〜3のスケール |
| Confidence | 見積もりの確信度 | 20%〜100% |
| Effort | 開発に必要な工数 | 人月 |
各要素の評価基準
Reach（影響範囲）
「この機能を使う/恩恵を受けるユーザーは何人いるか」を見積もります。
| 例 | Reach |
|---|---|
| 全ユーザーが使う機能 | 1000 |
| 特定プランのみ | 300 |
| 管理者のみ | 50 |
Impact（インパクト）
ユーザーへの影響度を5段階で評価します。
| レベル | スコア | 説明 |
|---|---|---|
| Massive | 3 | 劇的な改善、これがないと使えない |
| High | 2 | 大きな改善 |
| Medium | 1 | 中程度の改善 |
| Low | 0.5 | 小さな改善 |
| Minimal | 0.25 | ほぼ影響なし |
Confidence（確信度）
見積もりがどれくらい確かかを評価します。
| レベル | スコア | 説明 |
|---|---|---|
| High | 100% | データに基づく確信 |
| Medium | 80% | 一定の根拠あり |
| Low | 50% | 仮説段階 |
Effort（工数）
開発・デザイン・QAなど、すべての工数を「人月」で見積もります。
RICEスコアリングの実践
Step 1: 要望リストを整理する
バラバラに来る要望を一元管理します。
記録する情報:
- 要望の内容
- 要望元（顧客名・セグメント）
- 課題の背景
- 同様の要望の件数
Step 2: RICEスコアを計算する
各要望に対してRICEスコアを計算します。
例: Salesforce双方向連携機能
| 要素 | 値 | 根拠 |
|---|---|---|
| Reach | 500 | Salesforceユーザーの80% |
| Impact | 2 | 手動作業が大幅削減 |
| Confidence | 80% | 顧客インタビューで確認済み |
| Effort | 3人月 | エンジニア見積もり |
計算: (500 × 2 × 0.8) / 3 = 267
Step 3: スコア順に並べる
スコアが高い順に並べ、上位を次のロードマップに入れます。
| 機能 | RICE | 判断 |
|---|---|---|
| Salesforce双方向連携 | 267 | 今スプリント |
| ダッシュボード改善 | 180 | 次スプリント |
| Slack通知強化 | 120 | 検討中 |
| 新規レポート機能 | 45 | 保留 |
Step 4: 定期的に見直す
四半期ごとにスコアを見直します。状況の変化でReachやImpactが変わることがあります。
RICEの限界と補完
限界
- 戦略的重要性を反映しない: 競合対策や将来の市場拡大など
- 依存関係を考慮しない: A機能がないとB機能が作れない
- 技術的負債を考慮しない: リファクタリングの優先度
補完する視点
| 視点 | 説明 |
|---|---|
| 戦略適合性 | 会社の戦略・ビジョンとの整合性 |
| 依存関係 | 他の機能やシステムとの関係 |
| 技術的リスク | 実装の難易度・不確実性 |
| 競合状況 | 競合が持っている/いない機能か |
ICEスコアリングとの使い分け
ICE = Impact × Confidence × Ease
RICEより簡易な手法です。Reachを省略し、Effortの代わりにEase（実施しやすさ）を使います。
| フレームワーク | 適したケース |
|---|---|
| RICE | ユーザー数のデータがあるとき |
| ICE | 素早く優先順位を決めたいとき、B2Bで顧客数が少ないとき |
「やらない」決定の重要性
明確に断る
すべての要望に応えることはできません。「やらない」と決めたものは明確に伝えます。
断り方のテンプレート
ご要望ありがとうございます。現時点では[理由]により、ロードマップに入れる予定はありません。状況が変われば再検討します。
代替案を提示する
完全に断るのではなく、代替案を提示できることもあります。
- 「○○機能は予定していませんが、△△で同様のことができます」
- 「開発優先度は低いですが、APIを公開しているので連携開発は可能です」
実践チェックリスト
- 要望を一元管理するシートを作成した
- RICEスコアの評価基準を定義した
- 直近のスプリントでスコアリングを適用した
- 「やらない」と決めた要望を顧客に伝えた
- 四半期ごとの見直しスケジュールを設定した
よくある質問（FAQ）
Q1. Reachの見積もりが難しいのですが？
ざっくりでも構いません。「全ユーザー」「特定セグメント」「少数」などの区分けでも効果があります。
Q2. 営業から「この機能がないと売れない」と言われます。
「何件中何件で言われているか」を確認します。1件の声を全体と誤認しないことが重要です。
Q3. 大口顧客の要望をどう扱いますか？
ReachではなくImpactで反映します。1社の要望でも、その1社がLTVの大きい顧客であればImpactは高くなります。
Q4. 技術的負債の解消はどうスコアリングしますか？
ユーザーへの直接的なImpactは低いですが、開発速度への影響を考慮してスコアを調整します。または、別枠で「技術的投資」として時間を確保します。
Q5. チームでスコアの評価が割れます。どうすればいいですか？
まず個別に評価し、その後すり合わせます。大きく割れた場合は根拠を議論し、必要であれば追加調査を行います。
まとめ
主要ポイント
- 感覚ではなくスコアで決める: RICEスコアリングで定量評価
- 「やらない」も決定: 明確に断り、リソースを集中
- 定期的に見直す: 状況変化に応じてスコアを更新
次のステップ
- 現在の要望リストにRICEスコアを付ける
- 上位3件を次のスプリントに入れる
関連記事
参考リソース
本記事はyap（ヤップ）のB2B SaaS GTMシリーズの一部です。
この記事を書いた人
yap編集室
株式会社yapの新規事業開発コンサルタントたちによる編集チームです。新規事業の仮説検証・PMF設計、営業推進に関する知見を、さまざまなプロジェクト支援の経験をもとに発信しています。
