機能要望への対応で難しいのは、実は「何を作るか」を決めることよりも、「何を作らないか」を決めることだったりします。この記事では、要望に「やらない」という判断を下すための考え方を整理します。
なぜ「やる」より「やらない」の方が難しいのか
「やる」と決める場合、その理由は比較的説明しやすいです。多くの声が集まっている、事業上のインパクトが大きい、技術的に実現しやすい、といった根拠を示せば周囲の納得を得やすいためです。
一方「やらない」と決める場合、目の前の要望を出した顧客がいて、その声に応えないという判断を下すことになります。理由を言葉にしないまま先送りすると、「検討中」のステータスの要望だけがどんどん積み上がり、いつまでも整理されないリストが残ります。やらないという判断を先送りするコストは、目に見えにくいだけで実際には発生し続けています。
「やらない」を判断する3つの軸
やらないと判断する基準を、感覚ではなく次の3つの軸で言語化しておくと、判断のブレが減ります。
- プロダクトの方向性と合っているか: 要望自体は理解できても、今のプロダクトが解決しようとしている課題の中心から外れている場合があります。方向性のズレは、機能単体の良し悪しとは別の判断材料になります。
- 対象ユーザーの広さ: 声を上げた1人には価値があっても、想定している顧客層全体で見たときに再現性のある課題かどうかです。少数の強い要望と多数の弱い要望のどちらを優先するかは、プロダクトのフェーズによっても変わります(PMF前の考え方は「PMF前のプロダクトが顧客の声とどう向き合うべきか」で扱っています)。
- 運用コストに見合うか: 実装コストだけでなく、その機能を維持し続けるための運用コスト(サポート対応・ドキュメント更新等)まで含めて見合うかどうかです。
これらの軸で「やらない」と判断できたものは、検討中のまま放置せず、早めに却下のステータスに移すべきです。
却下は"隠す"のではなく"記録して伝える"
やらないと決めた要望をどう扱うかは、チームや顧客への信頼にも関わります。Feeduryでは却下ステータスは管理画面のみで扱い、公開ボードの表示タブには出しません(公開タブは検討中〜完了までの4段階のみを表示します)。ただし、投票・コメントをした人にはステータス変更時にメールで通知が届く仕組みを持っています。
大切なのは、却下したことを黙って忘れるのではなく、記録として残し、関係者に伝えることです。理由まで丁寧に伝えられれば、声を上げた人にとっても「無視された」という印象は残りにくくなります。
一度やらないと決めた要望が、再び声を集めたら
一度却下した要望でも、時間が経ってから別の顧客から同様の声が独立して上がってくることがあります。この場合、却下の判断自体を見直す価値があります。却下は「未来永劫やらない」という確定ではなく、「今の情報では優先度が低い」という時点の判断だと捉えておくと、再検討のハードルが下がります。
似た要望をまとめて合算の共感度を見られるようにしておくと、この「声が再燃しているかどうか」に気づきやすくなります。実際の画面はデモボードで確認できます。
「先送り」と「却下」を混同しない
やらないと決めきれない要望もあります。情報が足りない、事業上のタイミングが合わない、といった理由で判断を保留したい場合は、素直に「検討中」のまま残してよいでしょう。問題なのは、判断できるだけの材料が揃っているのに、決めること自体を避けて「検討中」に留め続けることです。
この2つを混同すると、検討中のリストが「本当に検討している要望」と「実質的にやらないと決まっている要望」の両方を含む、実態のわからない置き場になってしまいます。定期的にリストを見直し、「これはまだ判断材料が足りないのか、それとも判断はもう出ているのか」を棚卸しする時間を取ることが、リストを健全に保つコツです。
まとめ
「やらない」と決めることは、「やる」と決めることと同じくらい重要なプロダクトマネジメントの仕事です。判断軸を持ち、却下を先送りせず、理由を添えて伝える。この3つを徹底するだけで、要望リストが際限なく膨らむ状態は避けられます。要望管理ツールの選び方全般は「フィードバック管理ツールとは?個人開発〜小規模SaaSのための選び方」でも整理しています。