AIによって実装のスピードが上がり、MVPにも機能を追加しやすくなりました。しかし、作れる機能をすべて盛り込むと、何がユーザーに価値をもたらしたのか分からず、検証の焦点がぼやけてしまいます。 wildcardがPoCやMVPの現場で重視しているのは、「作れるか」ではなく「検証に必要か」という基準です。機能候補を「価値・安全・計測・保留」の4つに分け、中心仮説の検証に必要なものだけを残します。 この記事では、私たちが実践のなかで培ってきた、AI時代のMVPを盛りすぎないための判断基準と、具体的な機能の絞り方を紹介します。
この記事のポイント
- 機能は「価値・安全・計測・保留」の4分類で判断する
- 入れるのは、後回し以外の3分類にあたる機能だけ
- AIですぐ作れることは、機能を追加する理由にならない
- 絞るのは機能数だけではない。ユーザー、データ、連携、例外も限定する
AI時代に「盛りすぎ」が起きやすい理由
BeforeAIには、工数という物理的なブレーキがありました。AfterAIでは追加実装が速くなり、「せっかくだから」が積み上がります。
しかし、消えないコストがあります。説明、テスト、権限設計、運用、計測、そして将来の変更。実装が速くなっても、これらは残ります。
検証への影響はもっと直接的です。機能が10個あれば、ユーザーが使い続けている理由はどの価値なのか分かりません。一つの中心価値に絞れば、結果を解釈できます。足すほど、測定はぼやけます。
MVPに入れる機能を決める4分類
| 分類 | 判断する問い | 提案書作成支援の例 |
|---|---|---|
| 価値 | ないと中心価値を体験できないか | 提案書の下書き生成 |
| 安全 | ないと実業務で安全に使えないか | 権限、出典、人による確定 |
| 計測 | 仮説の成否を観測できるか | 利用ログ、修正率、再利用 |
| 保留 | 今回の仮説・安全・計測に関係するか | 多言語、全CRM連携、装飾テンプレート |
注意したいのは、セキュリティや権限の扱いです。「価値機能ではないから後回し」にはできません。
対象ユーザーやデータを絞って、実装範囲を小さくするのは構いません。ただし、その範囲で必要な安全条件は必ず満たします。
機能以外にも絞る5つの軸
盛りすぎは、機能数だけで起きるわけではありません。次の5つも明示的に限定します。
- ユーザー：全営業ではなく、国内更新営業の担当者
- ワークフロー：提案から送付までではなく、下書き作成と確認
- データ：全顧客・全商材ではなく、既存顧客と承認済み製品情報
- 連携：全CRM機能ではなく、必要な顧客情報の取得だけ
- 例外：全ケース対応ではなく、対象外を表示して人へ戻す
スコープ設計そのものは6つの軸で扱いました。ここでは、その範囲を決めた後に機能をどう選ぶかを見ています。
このセクションは、「提案書作成MVPを例に、検証する問いと指標から必要な機能を逆算する具体例」にすると、前後の説明とつながります。
例：提案書作成MVPをどう絞るか
ここまでの4分類と5つの軸を、提案書作成MVPへ実際に当てはめてみます。
まず、検証する問いを次のように置きます。
承認済みの情報から生成した提案書の下書きは、営業担当者に反復利用され、提案準備の時間短縮につながるか。
検証範囲は、中心仮説に答えられる最小単位へ限定します。
- ユーザー：国内の更新営業担当者
- ワークフロー：提案書の下書き作成と確認
- データ：既存顧客と承認済みの製品情報
- 連携：下書き生成に必要な顧客情報の取得
- 例外：対象外の案件は生成せず、人の作業へ戻す
検証では、次の指標を観測します。
| 検証すること | 主な指標 | 判断のしかた |
|---|---|---|
| 業務で使い続けられるか | 反復利用した担当者の割合、対象案件での利用率 | 一度試したかではなく、複数の案件で繰り返し使われたかを見る |
| 準備時間を短縮できるか | 下書き完成までの時間の中央値 | 従来の作成方法と比較し、実際に時間が減ったかを見る |
| 下書きが実務で使えるか | 生成した下書きが確認・確定まで進んだ割合 | 生成回数ではなく、提案書として利用できる状態まで進んだかを見る |
| 安全に運用できるか | 出典表示率、人による確認率 | 成果指標ではなく、実業務で使うための必須条件として扱う |
この検証に必要な機能を、4分類で整理します。
| 機能候補 | 分類 | 採否の理由 |
|---|---|---|
| 限定された顧客情報の取得 | 価値 | 対象顧客に合わせた下書きを作るために必要 |
| 承認済み情報からの下書き生成 | 価値 | 中心価値そのものを体験するために必要 |
| 出典の表示 | 安全 | 内容を確認し、誤りを検知するために必要 |
| 人による修正・確定 | 安全 | 未確認の内容がそのまま使われることを防ぐために必要 |
| 利用回数・作業時間・確定状況の記録 | 計測 | 反復利用、時間短縮、実務利用を判断するために必要 |
| 新規顧客、全商材、全言語への対応 | 保留 | 今回の対象データを超え、中心仮説の検証には不要 |
| 価格承認、メール送信 | 保留 | 今回対象とする「下書き作成と確認」の外にある |
| 高度な分析画面 | 保留 | 検証に必要な指標は、まず簡易なログで確認できる |
このように、機能数を先に決めるのではなく、検証する問いへ答えるために必要か、安全に使うために必要か、結果を正しく測るために必要かで絞ります。
保留した機能は、単なる「いつか作る一覧」にはしません。今回の検証結果から対象を広げる根拠が得られたときに、改めて採否を判断します。
選択箇所は、次のまとめへ置き換えると記事全体が収束します。
作れるかではなく、検証に必要かで決める
AfterAIでは実装が速くなりましたが、機能を増やすほど検証結果は解釈しにくくなり、テストや運用、将来の変更にかかるコストも増えていきます。MVPへ入れる機能は、「すぐ作れるか」ではなく「中心仮説を検証するために必要か」で決めます。
機能候補は、価値・安全・計測・保留の4つに分類します。中心価値を体験するための機能、安全に実業務で使うための機能、結果を正しく測るための機能だけを入れ、それ以外は保留します。さらに、ユーザー、ワークフロー、データ、連携、例外も、仮説に答えられる最小範囲へ限定します。
追加要望が出たときは、次の3点を確認します。
- 今回の中心仮説の成否を判断するために必要か
- 実ユーザーが安全に価値を受け取るために必須か
- 入れなければ、学習結果を誤って解釈するか
すべてに当てはまらなければ、今回のMVPでは後回しです。一つでも当てはまる場合は、追加によって検証期間、対象範囲、または続く・払う・広がるという指標のどれが変わるかを明らかにしてから採否を決めます。
機能を絞ることは、必要な完成度まで削ることではありません。検証する範囲を明確にし、その範囲では安全に使え、結果を判断できる状態まで仕上げることです。これが「最小スコープ × 最大完成度」のMVPです。
よくある質問
MVPには何個まで機能を入れてよいですか
一律の個数では決まりません。4分類のうち「後回し」を除く3つ、つまり価値・安全・計測に必要な機能だけに絞れているかで判断します。
顧客から要望された機能は入れるべきですか
中心仮説・安全性・計測のどれに必要かを確認します。重要な要望でも、今回の問いと無関係なら次の学習後に再評価します。
AIですぐ作れる機能なら、入れても問題ないですか
実装が速くても、テスト・運用・計測・変更のコストは増えます。検証結果を曖昧にするなら入れません。
AI時代の規律は、手を速く動かすことだけではありません。作れるのに作らない基準を持つことです。
