📌 この記事のエグゼクティブサマリー
- フィーチャークリープの罠: 機能を増やせば増やすほどUIは複雑化し、ユーザーの定着率は低下する。リリースされた機能の約80%はほとんど使われない。
- 声の大きい顧客の偏り: 営業やCSが持ってくる「この機能がないと解約される」という要望は、特定1社の特殊事情であることが多く、全社最適を歪める。
- フレームワークの形骸化防止: RICEスコアの「確信度（Confidence）」を主観で埋めるのを防ぎ、定性インサイトで数値を裏付ける。
- プレ受容性テストの実装: エンジニアがコードを書く前に、AIペルソナを活用して機能コンセプトの受容性と不要理由を最短当日に検証。
「営業チームから『この新機能が付けば10社成約できる』と迫られ、無理して開発したのにリリース後に全く使われなかった」「大口顧客の細かいカスタマイズ要望に対応し続けた結果、プロダクトの画面が設定項目だらけで初心者お断りの迷宮になってしまった」——。多くのプロダクトマネージャー（PdM）やエンジニアリングマネージャーが、こうした開発ロードマップの迷走に頭を抱えています。
プロダクト開発の世界には、「ソフトウェアの全機能のうち、64%〜80%はほとんど、あるいは全く使われていない」という有名な調査データ（Standish Group調査等）があります。開発リソースが常に逼迫している現場において、使われない機能を作り続けることは、莫大な人件費の浪費であるだけでなく、既存機能の保守コストを増大させ、プロダクトの寿命を縮める致命的なリスクです。
本記事では、「声の大きい特定顧客」や「社内政治」に振り回されることなく、大多数の顧客が真にお金を払ってでも使いたいと望む新機能を科学的に選定・検証するためのフレームワークを徹底解説します。顧客の行動原理を解明する手法として、ジョブ理論（JTBD）インタビューやバリュープロポジションキャンバスの作り方も併せて参考にしてください。
📌 本記事で得られる実践知見
- ✓ なぜ機能追加を重ねるほど顧客体験（UX）が悪化し解約が増えるのか？
- ✓ RICEスコアリングやKanoモデルの「現場での形骸化」を防ぐ運用ルール
- ✓ 「欲しい」という顧客の言葉の裏にある「本当の緊急度」を炙り出す3つの設問
- ✓ 開発着工前にAIペルソナで新機能コンセプトをストレステストする手法
1. 新機能の8割が使われない根本原因：「フィーチャークリープ」の罠
プロダクトが成長期に入ると、セールス、CS、マーケティング、経営陣、そして一部の熱心なユーザーから、毎日無数の機能追加リクエストが寄せられます。このとき、「要望があるから」「競合の〇〇社が最近その機能を実装したから」という理由で安易にロードマップへ追加してしまう現象を、プロダクトマネジメントの世界では「フィーチャークリープ（Feature Creep / 機能肥大化の罠）」と呼びます。
| 悪循環のステップ | 発生する現象 | プロダクトと組織へのダメージ |
|---|---|---|
| Step 1：局所的要望の実装 | 特定の大口顧客や、社内で発言力の強いメンバーの意見をそのまま開発 | 開発チームが「下請け化」し、プロダクトのコア価値の研ぎ澄ましが止まる |
| Step 2：UI/UXの複雑化 | ボタン、タブ、設定画面が増殖し、どこで何を操作すべきか分からなくなる | 新規ユーザーのオンボーディング完了率が急落し、初期離脱（Day 1 Churn）が増加 |
| Step 3：技術的負債の爆発 | 使われていない死に機能（ゾンビ機能）の保守・テスト工数で身動きが取れなくなる | 新機能リリース速度が低下し、真に必要なコア機能の改善ができなくなる |
オンボーディング時の初期離脱については、SaaSの初期離脱を防ぐオンボーディング改善インタビューでも詳しく解説しています。
2. 定番フレームワークの限界：なぜRICEやKanoモデルは形骸化するのか？
機能の優先順位を決めるために、多くの組織でRICEスコアリング（Reach, Impact, Confidence, Effort）やKanoモデルが導入されています。しかし、現場ではしばしば以下のような問題が発生します。
RICEの「Confidence（確信度）」が政治の道具になる
RICEの計算式（Reach × Impact × Confidence ÷ Effort）において、開発工数（Effort）やリーチ数（Reach）はある程度客観的に算出できます。しかし、「Impact（影響度）」や「Confidence（確信度）」の数値は担当者の主観に委ねられます。その結果、「自分の推したい機能のスコアを意図的に高く付ける」というスプレッドシート上の数値合わせ合戦が始まり、客観的な優先順位付けが崩壊します。
Kanoモデルのアンケートを毎回実施する工数がない
Kanoモデル（当たり前品質・一元的品質・魅力的品質を分類する手法）は非常に論理的ですが、1つの機能候補ごとに「その機能があったらどう思うか」「なかったらどう思うか」を既存顧客にアンケートする必要があります。スピーディにスプリントを回したいアジャイル環境において、機能案が出るたびに顧客調査を設計・回収するのは現実的ではありません。
必要なのは、スプレッドシート上の架空の計算式ではなく、「開発着工前に、素早く顧客の生の反応（受容性と反論）を突き合わせて確信度（Confidence）を実証する仕組み」です。
3. 優先順位を科学的に決める「新機能ストレステスト」の4軸
新機能のアイデアをロードマップに入れるか否かを判定する際は、顧客に対して以下の4つのハードルを設けて検証します。
-
課題の頻度と痛みの強さ（Frequency & Intensity）:
「その問題は毎日発生していますか？ それとも年に1回ですか？」「その問題が起きたとき、業務が止まりますか？ それとも少し不便なだけですか？」
※年に数回しか起きない問題や、痛みの弱い要望はバックログの優先度を下げます。 -
代替手段の有無と支出の事実（Workaround & Spending）:
「今現在、その不便さを解消するために、どんな代替ツールを使ったり手作業で回避したりしていますか？ そのために追加費用を払っていますか？」
※代替手段すら講じていない顧客は、機能を作っても実際には使いません。 -
新機能の受容性と副作用（Adoption & Friction）:
「この新機能が追加された場合、日々のワークフローはどう変わりますか？ 新たに覚えなければならない操作や設定で億劫に感じる部分はありますか？」
※導入にかかる認知的負荷が高すぎる機能は、リリース後に放置されます。 -
支払い意欲（WTP）への寄与度:
「この機能が有料オプション（または上位プラン限定）だった場合でも追加料金を支払いますか？ それとも無料なら使う程度ですか？」
※支払い意欲（WTP）の測定手法については、支払い意欲（WTP）とPSM分析の活用法を参照してください。
4. AIペルソナを活用した「開発前プレスクリーニング」の実践
新機能の優先順位付けにおいて最も強力なアプローチは、「仕様書やPRD（製品要求仕様書）を書いた段階で、AIペルソナに機能概要を提示して受容性スコアを計測すること」です。
実顧客に「新機能のアイデアどうですか？」と聞くと、お世辞バイアス（The Mom Test）が働き、「あったら便利ですね！」と前向きに答えてしまいます。しかし、Persona AIのような本音キャリブレーションを備えたAIペルソナに評価させると、驚くほどシビアな回答が得られます。
【AIペルソナ50名による新機能コンセプト事前テストの事例】
検証機能: 「タスク管理ツールへの高度なガントチャート自動生成機能」
社内の予想: 「大口企業からの要望が多く、全員が喜ぶキラー機能になるはず」
AIペルソナ50名の判定結果:
・「ぜひ使いたい」: わずか12%（大手専任PMのみ）
・「不要・邪魔になる」: 68%（「操作が重くなる」「普段はカンバン方式で十分」「設定が難しそう」）
下した意思決定: 全体への標準搭載を中止。上位Enterpriseプランのみの個別アドオンとし、標準UIのシンプルさを死守した。
このように、開発に着手する前に「作っても使われないリスク」を事前に炙り出すことで、開発リソースを本当にインパクトのある機能だけに集中させることができます。コンセプト検証のフレームワークについては、コンセプトテスト完全ガイドもご参照ください。
5. まとめ：プロダクトマネジメントの真髄は「何を作らないか」を決めること
スティーブ・ジョブズの有名な言葉に、「イノベーションとは、1,000のことに『ノー』と言うことだ」という教訓があります。
顧客のすべての要望に応えようとするプロダクトは、誰にとっても中途半端で使いにくいものへと成り下がります。優れたPdMの役割は、機能を増やすことではなく、「顧客のコアな課題を、最小限の機能で最もエレガントに解決すること」です。
- 声の大きい顧客の1リクエストに惑わされず、課題の頻度と代替手段の事実を確認する。
- フレームワークの数値遊びをやめ、定性的な受容性データで客観的な確信度（Confidence）を担保する。
- コードを書く前に、AIペルソナを活用して顧客の拒絶反応や不要理由を最短当日に洗い出す。
不要な機能開発を大胆に切り捨て、本当に愛される強いプロダクトへと進化させていきましょう。
よくある質問（FAQ）
Q1. 営業チームから「この機能を作らないと大型案件を失注する」と言われたらどう対処すべきですか？
A. 感情的に反論するのではなく、その機能が他の顧客にとっても有益か（横展開可能か）を客観データで確認します。AIペルソナ等で他の見込み客50名に機能案をぶつけ、「特定1社だけの特殊要件であること」を可視化できれば、個別カスタマイズではなく標準ロードマップを守る論拠になります。
Q2. 使われなくなった既存の機能（死に機能）はどうやって削除すべきですか？
A. 利用ログから利用率の低い機能を抽出し、事前告知の上で段階的に非推奨化（Deprecate）します。その際、利用者に代替の操作手順を丁寧に案内することで、サポートの負担を最小限に抑えつつコードベースとUIをスリム化できます。
Q3. 新機能のアイデア検証は、どのくらいの粒度でAIペルソナに提示すれば良いですか？
A. 「どのような課題を、どんなアプローチで解決する新機能か」という1〜2段落の機能説明と、想定される利用シーン（ユースケース）を文章で提示するだけで十分です。画面デザインがなくても、顧客が価値を感じるかどうかの本質的な判定が可能です。
Persona AI 運営
/ シースリーレーヴ株式会社Persona AIの提供者として、AIリサーチの使い方と検証方法を紹介します。