声の大きい顧客の要望を優先すると失敗する理由｜顧客要望の優先順位の付け方
目次
「気づくと、いちばん声が届く顧客の要望から着手している」——顧客要望の優先順位づけでは、これがかなり広く起きています。しかもその多くは、担当者が判断を誤ったからではありません。声の大きい要望が上に来るのは、判断材料の集まり方そのものが偏っていることが多いからです。
この記事では、その偏りがどこから生まれるのかを分解し、優先しても事業が伸びにくい理由、そして要望を断らずに扱う運用の型を整理します。フレームワークの使い分け自体は「開発する機能の優先順位を決める方法」で取り上げています。ここではスコアの表に載らない「声の大きさ」にフォーカスしていきましょう。
- 「わかりやすい声」と「見えない声」の問題
- 機能過多・解約理由とのズレ・計画そのものの信頼低下の3つの問題
- 判断基準と変更ルールを先に決めておく
なぜ声の大きい要望を優先してしまうのか
まず、この現象を仕組みで理解していきましょう。原因は主に3つあります。
具体的な1件は、見えない多数よりわかりやすい
例えば、「A社の担当者が、この画面でこう困っている」という話には、顧客名もまさに発生しているという場所も熱量も感じ取れます。一方、同じ機能を必要としている残りの数十社は、問い合わせを送っていないとしましょう。要望を出さないユーザーは、データとして存在しないのと同じ扱いになりがちです。よって、話題が前者になることがほとんどで、つまりそちらが優先されていきます。
説明責任が生まれる
営業やCSから上がってきた要望を後回しにするには、理由の説明が必要です。逆に、要望をそのまま受け入れるときには誰も説明を求めません。説明コストが「やらない」側にだけにかかっています。つまり、要望を通すほうが常に楽な選択になっていきます。
金額が紐づく声だけが数字になる
BtoBでは「この機能がないと契約更新が危ないかも・・」という形で要望が来ることがあります。契約金額という数字がつくため、優先順位の材料として扱いやすいです。一方で、その機能を作らなかった場合に他の顧客が得られなくなる価値には、同じ精度の数字がつきません。比較の場に片方の数字だけが出てくれば、そちらが強く見えてきます。
声の大きい要望が上に来るのは、その要望が重要だからではなく、分かりやすい形で届いているからということを意識しておきましょう。優先順位づけの前に、まず情報の偏りを補正していくことが重要です。
優先しても事業が伸びにくい3つの理由
観測されやすい要望をそのまま実装していくと、何が起きているかを見ていきましょう。
プロダクトが重くなる
1社の業務に合わせた設定項目やオプションは、単体では小さな追加です。ただ、それが積み上がると、新規ユーザーが最初に触れる画面の選択肢が増え、初期設定のハードルが上がります。個々の判断はどれも妥当で、合計だけが妥当でなくなる——これが機能過多のいちばん多い成り立ち方です。
解約の理由と直結しない
「この機能がないと解約する」という声は強い動機になりますが、実際の解約理由が別の場所にあることは珍しくありません。定着していない、運用に乗っていない、費用対効果を社内で説明できない、といった要因のほうが効いている場合、要望どおりの機能を作っても解約は止まりません。要望は解約リスクのシグナルであって、原因の特定ではないという扱いが要ります。
計画の信頼性
これがいちばん見えにくいコストです。一度決めた順位が差し込みで入れ替わる状態が続くと、チームは計画を前提に動けなくなります。次に順位を決めても「また変わる」と思われるため、優先順位づけそのものが形式になっていきます。失うのは1回分の工数ではなく、決定を信じてもらえる状態です。
届いた要望をそのまま実装することは、顧客志向とは違います。要望として言語化された時点で、それは顧客が自分の見えている範囲で思いついた解決策の一案です。その背後にある課題を掘り当て、より広く効く解き方を設計するのはプロダクト側の仕事です。
要望と課題を切り分ける
対策する方法は、要望を「顧客が提案した解決策」と読み替えることです。解決策のまま扱うと選択肢は1つしかありませんが、課題まで戻せば打ち手が複数見えてきます。
| 届いた要望 | 背後にある課題 | 課題まで戻すと見える選択肢 |
|---|---|---|
| CSV出力が欲しい | 月次レポートを作るのに毎回数時間かかる | 定期レポートの自動送信、テンプレート化、BI連携 |
| この入力項目を任意にしてほしい | 現場の入力負荷が高く、運用が定着しない | デフォルト値、一括編集、項目の出し分け |
| 権限をもっと細かく分けたい | 情報を見せたくない相手が同じ組織にいる | ロールの追加、閲覧範囲の切り分け、監査ログ |
この翻訳ができると、要望の件数も違って見えてきます。表現の違う10件が同じ課題を指していたなら、それは10件の別要望ではなく、1つの課題に対する10票です。逆に、同じ言葉で届いた要望が別の課題から来ていることもあります。ここを揃える具体的な手順は「機能要望の重複統合・粒度そろえの実践Tips」で扱っています。
要望を課題まで戻すと、「作るか、断るか」の二択が「どう解くか」の設計問題に変わる。
要望を運用するやり方
要望は全体のなかに置き直して、判断を説明できる形にしていきましょう。要望が届く前に決めておくこと（ステップ1・2）から、届いた要望の扱い（ステップ3・4）へ、次の順番で仕組みを整えると進めやすいです。
判断基準を、要望が来る前に決めておく
事業インパクトを主軸にするのか、影響ユーザー数を見るのか、同点のときは何で決めるのか。要望が届いてから基準を議論すると、その要望に有利な基準が選ばれます。先に決めておけば、基準の妥当性と個別案件の判断を分けて話せます。
変更のルールも、あわせて決めておく
順位を絶対に変えない運用は現実的ではありません。どういう条件なら差し込みを認めるか、そのとき何を後ろにずらすかを決めておきます。「入れる」だけでなく「何が出るか」を必ずセットで示すと、差し込みの判断が具体的になります。
出所を記録して、同じ場所に集める
どの顧客・どの部署・どの担当者から来た要望かを残し、営業経由でもCS経由でも同じ受け皿に入れます。出所が残っていない要望は、後から事業インパクトを検証できません。受け皿の設計は「機能要望管理とは？収集・整理・優先順位付けの基本」で、営業・CSを経由して届く要望の受け取り方と返し方は「営業・CSからの機能要望をどう扱うか」で解説しています。
1件を、全体のなかの位置として見せる
「A社からの要望」を単独で議論すると強く見えます。同じ課題に何票入っているか、他にどんな課題が待っているかを並べた状態で見せると、比較の土台がそろいます。観測の偏りを補正するのは、この並べ替えの工程です。
私たちが開発している要望管理SaaS「アーコレ！」は、要望を集めて優先順位をつけるところで終わらせず、決めた優先順位を公開ロードマップとして外に見せる設計にしています。届いた要望をAIが意味ベースでクラスタリングして重複を束ねるのも、票数を本来のシグナルに戻すためです。
順位を外に出すと、変更のたびに説明が必要になります。それは運用の負荷ですが、同時に「その場の力関係で静かに順番が入れ替わる」ことへの抑止にもなります。透明性を、決定を守るための仕組みとして使うという発想です。
それでも個別に応えるべきケース
ここまでの話は、個別要望を軽く扱うという主張ではありません。声の大きさに引っ張られないための仕組みを整えたうえで、次のような要望は低スコアでも先に着手する理由があります。
- テーブルステークス：その市場で当たり前に求められる機能。SSO、監査ログ、権限管理などは、影響ユーザー数で測ると低く出るのに、ないと検討の候補から外れます。
- 契約・規制の要件：セキュリティチェックシートの必須項目や、業界固有の法令対応。判断の余地が小さく、期限が先に決まっています。
- 学習価値が大きい探索期：PMF前は事業指標がまだ材料になりません。この段階では、素早く出して反応を確かめられる要望を優先するほうが得られるものが多くなります。
- 戦略的に取りたい顧客：導入事例やレファレンスとしての価値が、単体の契約金額を超える場合があります。ただしこれは判断として明示し、記録に残すことが前提です。
例外を作ってよい。ただし、例外だと分かる形で記録する。
よくある質問
顧客要望の優先順位は何を基準に決めればいいですか？
事業インパクト（契約金額・解約リスク）、影響を受けるユーザー数、投票数などを組み合わせ、主軸と同点時の判断材料を先に決めておきます。重要なのは基準の種類より、要望が届く前に決めておくことです。届いてから議論すると、その要望に有利な基準が選ばれやすくなります。
大口顧客からの要望は優先すべきではないのですか？
契約金額が大きい顧客の要望を優先するのは、材料として妥当です。問題は、金額という数字がついた声だけが比較の場に出てきて、数字のつかない多数のニーズが議論に乗らないことです。他の課題と並べたうえで金額を材料に含めるなら、大口顧客の要望が上に来る判断は成り立ちます。
声の大きい顧客の要望を断るとき、どう伝えればいいですか？
断るのではなく、判断の位置を伝えるほうが摩擦が小さくなります。要望を受け付けた記録が残っていること、今どの課題が前にあるか、どういう条件なら順番が変わるかを示します。「やらない」という結論だけを伝えると、根拠のない拒否として受け取られます。
まとめ
声の大きい顧客の要望が上に来るのは、判断力の問題ではなく情報の偏りです。届いた1件には顧客名と温度があり、届かなかった多数には何もありません。この情報の非対称を放置したまま優先順位を議論すれば、結果は最初から傾くことが決まっています。
これに対し、要望を課題まで戻して束ね、全体のなかに並べ直すことが重要です。そして判断基準と変更ルールを、要望が届く前に決めておきましょう。個別対応そのものを禁じる必要はなく、例外を例外と分かる形で残せていれば運用はうまくいくはずです。
決めた順位を実行計画として形にし、変更を説明できる状態を保つ方法は「プロダクトロードマップの作り方」で詳しく扱っています。要望を集める段階から、決めた順位を守って伝える段階まで、続けて読むと一連の流れがつながっていくでしょう。
