MVPを「全部入り」にして失敗する｜小さく出す判断を誤る理由

「MVPなので最小で。」——キックオフの言葉。スライドの次のページには、競合にある機能がすべて並ぶ。ステークホルダー全員の要望が「初版必須」になり、最小は最大になる。

MVPの失敗で多いのは、技術力不足ではない。削る意思決定ができなかったことだ。遅く出して学習ゼロなら、それはMVPではなく遅延した全機能開発だ。

MVPで守るのは機能の数ではなく、検証したい仮説を1つにすることだ。

典型失敗

1. 全員満足の初版: 反対を消すために機能を足す
2. 競合模倣: 「あの機能がないと売れない」が検証前に固定される
3. 内部向けの過積載: 管理画面と権限が本体より厚い
4. 期限だけ先に決まる: スコープが減らず、品質が削られる
5. 成功指標が複数: どれが外れても「まだ足らない」になる

深掘り事例：6ヶ月遅延で学習ゼロ

匿名化した一例。新規の予約系サービス。当初「8週間で予約→決済の縦スライス」が合意されていた。営業・CS・経営から要望が入り、ポイント、帳票、複雑なキャンセルポリシー、管理画面の一式が初版に追加。開発は6ヶ月に延び、リリース時点で「何を検証したいか」がチーム内で一致していなかった。

初期ユーザーの反応は「だいたい使える」。だが仮説が複数あったため、次の投資判断に使えなかった。分岐点は2週目のスコープ会議だ。成功指標を「初回予約完了率」1つに固定し、他を明示的にv2へ送れていれば、8週間で学習を回収できた。

全部入りMVPは、失敗しても何が失敗か分からない。 それが最も高いコストだ。

構造的原因

• 「小さい」が美德で、「削る」が政治コストになる
• 発注・開発が機能リスト消化で評価される
• 仮説より完成度の見た目が社内説明に使われる

回避の判断軸

残す	落とす（v2以降）
仮説検証に直結する一本のユーザー行動	社内向けの便利機能
法務・決済など止められない制約	競合追随の見た目機能
計測に必要な最小のログ	「あったら良い」の付加

成功指標は1つ。2つ目を足した瞬間、スコープ交渉は再び開く。

次に確認すること

1. 検証したい仮説は一文か
2. 成功指標は1つか
3. 載せないもののリストは経営と合意したか
4. 初版の期限と品質のどちらを守るか決めたか
5. ステークホルダー要望の退避先（v2）はあるか

まとめ

MVPを全部入りにする失敗は、欲張りというより削る場を設計していない失敗だ。仮説と指標を1つに固定し、残りは明示的に後へ送る。小さく出せて初めて、次に何を足すかが分かる。

---

MVP・新規開発のスコープ設計の相談は、お問い合わせフォーム からどうぞ。