事業インパクトで機能要望の優先順位を決める｜MRRと判断根拠の扱い方
「大きな顧客の要望だから優先したい」と言われたとき、その機能が事業にどう影響するか説明できますか。事業インパクトで優先順位を決めるには、顧客の売上規模と、機能を作ることで変わる見込みを分けて考える必要があります。
この記事では、月次経常収益を表すMRRを手がかりに、要望を比較する際の根拠の残し方を扱います。工数や依存関係も含めた判断の流れは、開発優先順位の決め方で紹介しています。
- 顧客のMRRと機能による変化を分ける
- 売上への関係と根拠を同じ条件で記録する
- 不確かな点を確認してから着手を決める
顧客のMRRは、その機能の効果額ではない
MRRは、継続課金による収益を月単位で捉える指標です。Stripeの解説も、毎月の継続的な収益と、一時的な料金などを含む総収益を区別しています。要望を比較する前に、自社ではどの契約情報と時点で集計するかをそろえておきます。
たとえば、架空の顧客が月額20万円の契約でCSV出力を希望したとします。その顧客のMRRは20万円でも、CSV出力によって20万円が新たに増えるとは言えません。契約を続ける判断に影響するのか、日常の手間を減らしたいのかも、まだ分かっていません。
顧客の売上規模は、要望の背景を調べる手がかりとして扱います。効果額として使うなら、何が変わると考えたのか、その根拠が必要です。希望を聞いただけの段階で「対応すれば解約を防げる」と書くことは避けます。
同じ顧客が複数の要望を出した場合も注意します。各要望に同じMRRを付けて見ることはできても、それらを合計して新たな事業効果として扱うと、同じ契約を重ねて数えてしまいます。
売上への関係を先に分けて記録する
要望ごとに、どの事業上の変化を期待しているかを書きます。新規の契約、既存顧客の利用拡大、契約継続などを区別すると、異なる種類の数字をそのまま比較することを避けられます。
| 確認したい関係 | 残す情報 | 避けたい読み替え |
|---|---|---|
| 新規契約 | 商談段階、必要条件、ほかの未解決事項 | 希望機能があれば受注できると断定する |
| 利用拡大 | 追加する利用範囲、判断する人、検討時期 | 現在の契約全額が増えると見積もる |
| 契約継続 | 更新の時期、困りごと、顧客の説明 | 不満が一つあれば全額を失うと扱う |
| 業務の負担 | 現在の作業、発生条件、回避策 | 作業時間を根拠なく売上額へ換算する |
この表は、本記事で提案する整理例です。標準的な会計処理や、受注確率を算出する式ではありません。社内で使う指標の定義と確認方法を決め、要望ごとに異なる計算を持ち込まないことが大切です。
金額が付かない要望も残します。顧客の作業を支える改善や、今後の開発に必要な基盤は、直接の売上と結びつけにくい場合があります。金額欄が空であることを、価値がないという判断へ置き換えないようにします。
金額と一緒に、誰が何を確認したかを残す
比較表には、確認済みの事実と担当者の見込みを別々に書きます。同じ金額でも、顧客が必要条件として説明したものと、社内で期待しているだけのものでは、次に取る行動が違うためです。
Intercomが公開したRICEの説明も、見積もりの確信度を別の要素として扱っています。ここでは式を借りて金額を掛け合わせるのではなく、根拠の確かさを分けて記録する考え方を参考にします。
たとえば、次の架空の要望を比べる場面を考えます。金額は説明用で、実在する顧客や売上の数値ではありません。
| 要望 | 売上との関係 | 確認済みの情報 | まだ分からないこと |
|---|---|---|---|
| CSV出力 | 月額20万円の既存契約 | 月末の集計に使いたいとの説明 | 契約継続の判断に影響するか |
| 承認履歴の表示 | 月額5万円相当の商談 | 導入判断で必要な条件として説明 | ほかの条件、技術的な実現範囲 |
| 入力の補助 | 金額への影響は未確認 | 操作中に迷った場面の報告 | 対象の広さ、現在の回避策 |
この表だけでは開発順を確定しません。CSV出力は金額の関係を追加確認し、承認履歴はほかの導入条件と実現範囲を調べ、入力補助は同じ困りごとがどこまで広がるかを確かめます。金額の大きい順に並べる前に、調べるべきことが見えてきます。
確認した日付、相手の役割、元の発言への参照も残すと、後から根拠を読み直せます。「営業が重要と言っていた」だけでなく、顧客が何を条件として説明したのかまで分けることが大切です。
不確かな点を調べ、工数と目標を合わせて判断する
不足する情報が分かったら、判断に影響するものから確認します。すべての要望を同じ深さで調べる必要はありません。着手の判断が変わりそうな条件を先に確かめます。
たとえば、CSV出力が既存の方法でも可能なら、使い方の案内が当面の対応になるかもしれません。承認履歴を作っても別の導入条件が満たせなければ、その商談だけを理由に急ぐ根拠は弱くなります。確認の結果は、期待した答えでなくても表へ戻します。
そのうえで、実装だけでなく設計、確認、運用まで含めた負担を比べます。関連機能への影響や、先に必要な作業も確認します。RICEの原文も、スコアを絶対的な順序にせず、依存関係などによって判断が変わると説明しています。
最終的には、今回の事業目標に対して「着手する」「追加確認する」「別の方法で対応する」「今回は見送る」を決めます。売上の見込みが更新されたら、判断を読み直す時期や条件も残しておくと、古い商談の期待だけが優先順位表に残ることを防げます。
顧客へ返す説明は、社内の売上比較をそのまま見せる必要はありません。検討した範囲、現在の判断、次に確認することを整理し、約束できる内容だけを伝えます。
よくある質問
大きな顧客の要望を優先してはいけないのですか？
重要な判断材料にはなります。ただし、契約額だけで機能の効果を決めず、顧客の困りごとと事業への関係を確認します。ほかの顧客への影響や必要な工数も合わせて判断してください。
売上が分からない要望はどう比較しますか？
金額を推測で補わず、対象の作業、困っている範囲、現在の回避策を残します。今回の目標に対して、追加で何を確かめれば判断できるかを整理します。
商談の想定金額と既存顧客のMRRを足してよいですか？
確定した継続収益と、まだ契約していない見込みは分けて記録します。単純な合計だけでは判断根拠が見えにくくなるため、条件と確認時点を添えて比較します。
まとめ
事業インパクトで優先順位を決めるには、顧客のMRRと機能による変化を分けます。売上への関係と根拠を同じ条件で記録し、不確かな点を確認してから着手を決めることが大切です。顧客の発言力による偏りも気になる場合は、声の大きい顧客の要望を優先すると失敗する理由で判断材料の集まり方を確認できます。
