MVPで「最小限」を間違えるとどうなるか

MVP開発で最もよくある失敗が、「最小限」の解釈のズレです。削りすぎて意味がなくなるケースと、削れずに肥大化するケース、両方を整理します。

パターン1：削りすぎて検証にならない

「最小限にする」という意識が強くなりすぎると、本来確認したいことが確認できないレベルまで削ってしまうことがあります。

たとえば、受注管理システムのMVPを作るとして、「まずは入力フォームだけ」と決めたとします。入力したデータが一覧で確認できない、状態管理ができない、担当者への通知もない——そのような状態では、現場担当者は「これで業務を回せる」かどうかを判断できません。

使ってみた感想が「何もわからなかった」で終わるMVPは、MVPの目的を果たしていません。

判断基準：そのMVPで「業務を一通り回せるか」。一通り回せない状態では、フィードバックの質が下がります。

一方で、「最小限にしたつもりだが、いつのまにか大きくなっていた」というパターンもあります。

現場から「この機能もないと不安」「あの機能があれば便利」という声が積み重なり、スコープが広がっていきます。関係者全員の「最低限の要望」を足し合わせると、本開発と変わらない規模になってしまう——これがMVP肥大化の典型です。

MVPに機能を追加するたびに、検証の開始が遅れます。遅れた分だけ、フィードバックを得るタイミングが後ろにずれます。

判断基準：「この機能がなくても、目的の検証はできるか」で判断する。できるなら、一旦外す。

「最小限」は、削れるだけ削った状態ではありません。「目的の検証に必要な、最小限の機能セット」が正しい解釈です。

MVPで確認したいことを先に決めることで、スコープの判断がしやすくなります。

この順番で考えると、「これは必要」「これは後でいい」の判断基準が生まれます。

スコープが広がりかけているとき、有効な対処の一つは「フェーズを分ける」ことです。

フェーズ2以降を「ロードマップに入っている」と明示することで、現場の不安を和らげながらスコープを守れます。「削除する」ではなく「後で作る」として整理することが、関係者の納得を得やすくなります。