「声の大きい顧客」にプロダクトを壊されるな。機能要望のスコアリング・マトリクス

導入前の課題（摩擦のピーク）

SaaSやソフトウェアビジネスにおいて、顧客から毎日寄せられる「こんな機能が欲しい（Feature Request）」。 多くの組織では、これを**「営業の声の大きさ」や「提案してきた顧客が払っている金額（ARR）」という極めて偏ったノイズ（政治的圧力）**によって開発優先順位を決めています。 「月額100万円払ってくれているA社が欲しいって言ってるから、来月までに何とか作って！」というセールスの押し込みにより、開発チームはロードマップを狂わされます。その結果、A社しか使わないニッチで複雑な機能（技術的負債）がどんどんツギハギされ、プロダクト全体が「誰にとっても使いにくい、重くてダサい万能ナイフ（UI/UXの崩壊・デッドロック）」へと成り下がっていきます。

アルゴリズム化された「余白生成」へのアプローチ

1. 「優先順位」のスコアリング関数（RICEフレームワーク等）の導入 「誰が言ったか（属人的なシキ）」を完全に破棄します。 全ての機能要望を、定位置（Jira等のバックログ管理ツール）に集約し、冷徹な**数式（アルゴリズム）のフィルターを通さないと開発ラインに入れない絶対のルール（シキ）**をハードコードします。

   • R (Reach): その機能は、全顧客のうち何%が恩恵を受けるか？（1社ならスコア1、全社なら10）
   • I (Impact): それを作ればチャーン低下やアップセルにどれくらい繋がるか？
   • C (Confidence): その予測（RとI）に対するデータやヒアリングの確信度は？
   • E (Effort): 開発にかかる工数（人月）はどれくらいか？（割る数） 【 スコア ＝ (R × I × C) ÷ E 】という数式で全てを採点します。

2. 「No（作らない）」と言うための透明な防波堤 経営陣や営業が「A社のために作れ」と言ってきた時、PM（プロダクトマネージャー）は感情で言い返すのではなく、この数学的なスコア（事実）を盾（防波堤）にして迎撃します。 「その機能のRICEスコアは『2』ですが、現在開発中のB機能はスコア『80』です。A社の機嫌を取るために、会社全体の数千万円の利益（B機能）を吹き飛ばしても良いという事ですね？」と、意思決定の代償（トレードオフ）を可視化・コンパイルします。

削除された摩擦と、創出された余白

| 項目 | 導入前（摩擦） | 導入後（余白） | | :--- | :--- | :--- | | 開発会議の議論 | 「あれもこれも大事」という結論の出ない感情的な大声大会（政治的摩擦） | 「スコアが50以上のものだけを上から順に取る」という0.1秒の論理的決定 | | プロダクトの方向性 | クレーマーや大口案件に振り回され、コアバリューがブレブレになる（肥大化バグ） | ターゲット市場の「ど真ん中」のペインだけを鋭く突き刺す、美しいアーキテクチャの保持 | | PMと営業の対立 | プロダクト側が「作らない」と言うと、営業から「顧客の事を考えてない」とキレられる | 「スコア化」という共通言語（プロトコル）があるため、怒る対象が人から計算式に移動する |

ROI（投資対効果）

「お客様の要望は全て聞くべきである」という奴隷的なおもてなしの誤謬（バグ）を破棄し、「プロダクトのビジョンと数式（ROI）に合致する要望『だけ』を抽出し、それ以外はノイズとして切り捨てる」という知的なフィルター機構へとシステムをアップグレードしました。

「何を作ればいいのか」という迷いや、社内政治の折衝にかかる膨大なコミュニケーション・コスト（摩擦）が**排除（ゼロ化・設計への集中という余白）**されます。不要な機能を作らないことで、開発エンジニアの貴重なリソース（数千万〜数億円のコスト）が温存され、本当に市場にインパクトを与える「クリティカルな機能」だけに全エネルギーが投下されるようになります。