機能要望管理とは？収集・整理・優先順位付けの基本
目次
機能要望管理とは、営業・カスタマーサポート・ユーザーから寄せられる「こういう機能が欲しい」という声を収集・整理し、開発の優先順位に反映するまでの一連の仕組みを指します。単に要望を溜めておくメモではなく、どの要望を、なぜ、いつ着手するかを説明できる状態を作ることが目的です。
- 機能要望管理の目的は、どの要望を・なぜ・いつ着手するかを説明できる状態を作ること
- 進め方は「収集チャネルの一本化 → 重複統合 → 判断基準の明文化」の3ステップ
- 優先順位の基準はRICE・事業インパクト・投票数などを組み合わせ、ルールとして明文化する
なぜ機能要望管理が必要か
要望が個々のSlackスレッドやスプレッドシートに散らばっていると、次のような問題が起きます。
- 同じ要望が別の言葉で何度も届き、実際の要望数が見えなくなる
- 声の大きい一部の顧客・部署の意見が、事業インパクトを検証しないまま優先される
- 「なぜこの機能を後回しにしたか」を後から説明できず、営業やCSとの摩擦が生まれる
これらは要望が少ないうちは表面化しませんが、プロダクトが成長し要望の数と発信元が増えるほど、開発チームの意思決定コストを押し上げます。
収集・整理・優先順位付けの3ステップ
1. 収集チャネルを一本化する
Slack、メール、商談メモ、アプリ内フィードバックなど、要望が発生する経路は複数あります。まずはこれらを1つの受け皿（要望管理ツールやシート）に集約し、どこから来た要望かという出所（部署・顧客・担当者）を記録できるようにします。出所が残っていないと、後で「本当に事業インパクトが大きい要望か」を検証できません。
2. 重複を統合し、粒度を揃える
集まった要望は、同じ課題を指しているのに表現が違うものが大量に発生します。これを統合せずに件数だけ見ると、票数や件数が実態より分散し、優先順位の判断材料として機能しません。統合する際は「解決したい課題」を軸にまとめ、機能案そのものではなく課題単位でグルーピングするとぶれにくくなります。
3. 判断基準を決めて優先順位をつける
要望を集めて終わりにせず、何を基準に順位をつけるかをチームで先に決めておきます。代表的な基準を比較します。
| 基準 | 何を見るか | 向いている場面 |
|---|---|---|
| RICE | Reach・Impact・Confidence・Effort の4軸でスコア化 | 定量データがある程度揃っている組織 |
| 事業インパクト | 契約金額・解約リスクなど売上への影響 | 商談・解約に直結する要望が多いBtoB |
| 投票数 | ユーザーからの投票・リアクション数 | ユーザー数が多く、定性判断がしづらい場面 |
いずれか1つに寄せきるのではなく、「事業インパクトを主軸にしつつ、同点なら投票数で判断する」のように優先順位のルールを明文化しておくと、担当者が変わっても判断がぶれません。
運用でつまずきやすいポイント
アーコレの開発・顧客ヒアリングを通じて、特に相談が多いのは次の2点です。
声の大きい顧客の要望を優先し続けると、他の多くの顧客に刺さる要望が後回しになりやすくなります。個別要望と全体傾向は分けて評価する必要があります。
優先順位を一度決めても、営業や経営からの差し込みで簡単に覆ります。判断基準と、決定した優先順位を記録・共有する場所がないと、同じ議論を繰り返すことになります。
FAQ
機能要望管理とは何ですか？
営業・カスタマーサポート・ユーザーから寄せられる「こういう機能が欲しい」という声を収集・整理し、開発の優先順位に反映するまでの一連の仕組みです。どの要望を、なぜ、いつ着手するかを説明できる状態を作ることが目的です。
機能要望の優先順位付けにはどんな基準がありますか？
代表的な基準にRICE・事業インパクト・投票数があります。いずれか1つに寄せきるのではなく、「事業インパクトを主軸にしつつ、同点なら投票数で判断する」のようにルールを明文化しておくと、担当者が変わっても判断がぶれません。
機能要望管理はいつから仕組み化すべきですか？
要望が少ないうちは重複や判断のブレが表面化しませんが、プロダクトが成長し要望の数と発信元が増えるほど意思決定コストが上がります。収集チャネルの一本化と出所の記録は、要望が少ないうちから仕組み化しておくのがおすすめです。
まとめ
機能要望管理は、収集チャネルの一本化・重複統合・判断基準の明文化という3つのステップに分けて考えると設計しやすくなります。次の記事では、開発の優先順位を実際にどう決めるか、判断基準の使い分けをさらに具体的に解説します。