PoC × MVP。引き算で作るMVP

通常のMVP開発は「最小限の機能から積み上げる」発想ですが、要件定義が進むにつれて機能が膨らみがちです。PoCで一度「全部入り」を作り、現場で削ぎ落としてMVPを決める逆算のアプローチを紹介します。

通常のMVPは「小さく作って早期にリリースする」ことが前提のため、本アプローチは厳密にはMVPとは言えません。しかし、開発コストを抑えつつ現場の使いやすさを最優先にしたい場合には有効な方法です。

通常のMVPが抱える問題

MVPの本来の意味は「実用最小限のプロダクト」です。最小限の機能だけを実装して早期にリリースし、現場の反応を見ながら機能を追加していく、というのが基本的な考え方です。

ところが実際の要件定義では、議論を重ねるほど「この機能も必要」「あの画面も外せない」という話が積み上がります。最初は小さくするつもりだったMVPが、気づけば機能盛りだくさんの開発計画になっている、というのはよく起きます。

原因は「何を外すか」の判断が難しいことにあります。機能に名前がついた段階で、それを除外する判断は難しくなります。現場を経験していない状態で「これは不要」と言い切るには、相応の根拠が必要です。

このアプローチは、通常のMVPとは逆の順序で進めます。

1. PoCとして「全部入り」のプロトタイプを作る
要件定義の段階で思いついた機能をひととおり盛り込んだプロトタイプを作成します。完成度は問いません。現場で試せる水準であれば十分です。

2. 現場で実際に使ってみる
実際の担当者に使ってもらいながら、業務の流れに沿って動かします。このとき注目するのは「どの機能が使われているか」だけでなく、「どの機能が使われていないか」です。

3. 不要な機能・後回しでいい機能を除外する
実際に使ってみることで、「この機能は業務では使わない」「これは半年後でいい」という判断が、根拠を持ってできるようになります。除外の判断が「憶測」ではなく「実体験」に基づくため、関係者の納得感も得やすいです。

4. 残った機能だけをMVPとして本開発する
現場の検証を経て生き残った機能だけを、本番システムとして開発します。この時点で残っている機能は、現場が「実際に必要だと確認した機能」です。

通常の要件定義では、「必要かどうか」の判断を想像で行います。このアプローチでは、その判断を「現場での実体験」に移します。

結果として：

特に、利用部門が多い・業務フローが複雑・社内調整に時間がかかるプロジェクトで効果が出やすいです。

このアプローチの最大のデメリットは、検証に時間がかかることです。

PoCを現場で試す期間は、最低でも数週間から数ヶ月かかります。業務サイクルによっては、月次・四半期の業務を一通り経験しないと「必要かどうか」が判断できない機能もあります。

「早くシステムを本稼働させたい」という状況には向きません。スケジュールに余裕があるプロジェクト、もしくは長期的な業務改善を目的としたプロジェクトに適した方法です。

「早くリリースしてフィードバックを得る」という正統なMVPのアプローチが合わない場面、たとえば業務システムのように定着が重要で、使いにくければ現場に定着しないプロジェクトでは、このアプローチが現実的な選択肢になります。