機能要望管理とは？収集・整理・優先順位付けの基本
目次
機能要望管理とは、営業・カスタマーサポート・ユーザーから寄せられる「こういう機能が欲しい」という声を収集・整理し、開発の優先順位に反映するまでの一連の仕組みを指します。単に要望を溜めておくメモではなく、どの要望を、なぜ、いつ着手するかを説明できる状態を作ることが目的です。
- 機能要望管理の目的は、どの要望を・なぜ・いつ着手するかを説明できる状態を作ること
- 進め方は「収集チャネルの一本化 → 重複統合 → 判断基準の明文化」の3ステップ
- 優先順位の基準はRICE・事業インパクト・投票数などを組み合わせ、ルールとして明文化する
なぜ機能要望管理が必要か
要望が個々のSlackスレッドやスプレッドシートに散らばっていると、次のような問題が起きます。
- 同じ要望が別の言葉で何度も届き、実際の要望数が見えなくなる
- 声の大きい一部の顧客・部署の意見が、事業インパクトを検証しないまま優先される
- 「なぜこの機能を後回しにしたか」を後から説明できず、営業やCSとの摩擦が生まれる
これらは要望が少ないうちは表面化しませんが、プロダクトが成長し要望の数と発信元が増えるほど、開発チームの意思決定コストを押し上げます。
収集・整理・優先順位付けの3ステップ
1. 収集チャネルを一本化する
Slack、メール、商談メモ、アプリ内フィードバックなど、要望が発生する経路は複数あります。まずはこれらを1つの受け皿（要望管理ツールやシート）に集約し、どこから来た要望かという出所（部署・顧客・担当者）を記録できるようにします。出所が残っていないと、後で「本当に事業インパクトが大きい要望か」を検証できません。原文・判断理由・次の回答日を残す受け皿には、顧客要望の管理表テンプレートを使えます。営業・CSが背景を添えて開発へ渡すときは、受付フォームと記入例を使えます。経路の棚卸しから受け皿の選び方、既存の状態からの移行手順は「機能要望の収集を一本化する方法」で解説しています。
2. 重複を統合し、粒度を揃える
集まった要望は、同じ課題を指しているのに表現が違うものが大量に発生します。これを統合せずに件数だけ見ると、票数や件数が実態より分散し、優先順位の判断材料として機能しません。統合する際は「解決したい課題」を軸にまとめ、機能案そのものではなく課題単位でグルーピングするとぶれにくくなります。重複を見分ける3つの視点と、粒度をそろえる手順は「機能要望の重複統合・粒度そろえの実践Tips」で扱っています。要望が数百件を超えて手作業の分類が追いつかなくなったら、「機能要望をAIで分類する方法」で分類軸の決め方とAIに任せる工程の線引きを解説しています。
アンケートの担当者が自由記述を報告用に整理する手順は、自由記述のまとめ方で、原文・回答IDを残す方法から件数と代表例の示し方まで確認できます。
3. 判断基準を決めて優先順位をつける
要望を集めて終わりにせず、何を基準に順位をつけるかをチームで先に決めておきます。代表的な基準を比較します。
| 基準 | 何を見るか | 向いている場面 |
|---|---|---|
| RICE | Reach・Impact・Confidence・Effort の4軸でスコア化 | 定量データがある程度揃っている組織 |
| 事業インパクト | 契約金額・解約リスクなど売上への影響 | 商談・解約に直結する要望が多いBtoB |
| 投票数 | ユーザーからの投票・リアクション数 | ユーザー数が多く、定性判断がしづらい場面 |
いずれか1つに寄せきるのではなく、「事業インパクトを主軸にしつつ、同点なら投票数で判断する」のように優先順位のルールを明文化しておくと、担当者が変わっても判断がぶれません。5件の架空要望を比較し、着手・追加確認・見送りを決める評価表と、RICE・Kano・MoSCoWなどの使いどころは「開発する機能の優先順位を決める方法」で詳しく解説しています。
運用でつまずきやすいポイント
アーコレの開発・顧客ヒアリングを通じて、特に相談が多いのは次の2点です。
声の大きい顧客の要望を優先し続けると、他の多くの顧客に刺さる要望が後回しになりやすくなります。個別要望と全体傾向は分けて評価する必要があります。
なぜ声の大きい要望ほど上に来てしまうのか、その構造と、要望を断らずに扱う運用の型は「声の大きい顧客の要望を優先すると失敗する理由」で解説しています。
優先順位を一度決めても、営業や経営からの差し込みで簡単に覆ります。判断基準と、決定した優先順位を記録・共有する場所がないと、同じ議論を繰り返すことになります。
受け皿をスプレッドシートやNotionで始めた場合、どこで運用が回らなくなるか、乗り換えの判断基準は「要望管理をNotion・スプレッドシートで行う限界」で整理しています。専用ツールを検討する段階なら、「CannyとProductboardの違い」で代表的な2つのツールの設計の違いを比較しています。
FAQ
機能要望管理とは何ですか？
営業・カスタマーサポート・ユーザーから寄せられる「こういう機能が欲しい」という声を収集・整理し、開発の優先順位に反映するまでの一連の仕組みです。どの要望を、なぜ、いつ着手するかを説明できる状態を作ることが目的です。
機能要望の優先順位付けにはどんな基準がありますか？
代表的な基準にRICE・事業インパクト・投票数があります。いずれか1つに寄せきるのではなく、「事業インパクトを主軸にしつつ、同点なら投票数で判断する」のようにルールを明文化しておくと、担当者が変わっても判断がぶれません。
機能要望管理はいつから仕組み化すべきですか？
要望が少ないうちは重複や判断のブレが表面化しませんが、プロダクトが成長し要望の数と発信元が増えるほど意思決定コストが上がります。収集チャネルの一本化と出所の記録は、要望が少ないうちから仕組み化しておくのがおすすめです。
まとめ
曖昧な言葉の背景を確かめる質問は、顧客要望を具体化する方法で紹介しています。
顧客自身が入力する窓口を用意する場合は、要望フォームの項目と記入例を参照してください。
導入するツールを選ぶときは、要望管理ツールの比較方法で、同じ要望を受付から回答まで試す手順を確認できます。
Cannyからの移行を検討している場合は、Canny代替の選び方と移行の確認点を参照してください。
担当者が票の集まり方と顧客の背景を確かめる手順は、機能要望への投票の使い方で解説しています。
顧客へ判断を返す文章を用意するときは、機能要望への返信文例を参照してください。受付・追加確認・保留・見送り・代替案を、実際の状況に合わせて書き分けます。
運用中につまずいた場合は、顧客の声が届かないときの確認、止まった要望管理の立て直し方、不具合と要望の切り分けも参照してください。
機能要望管理は、収集チャネルの一本化・重複統合・判断基準の明文化という3つのステップに分けて考えると設計しやすくなります。開発の優先順位を実際にどう決めるか、判断基準の使い分けは「開発する機能の優先順位を決める方法」で、決めた順位をどう形にして伝えるかは「プロダクトロードマップの作り方」で解説しています。
