MVPで作らないものを決める手順と判断基準

「MVPで小さく作りましょう」と言われて機能一覧を作ったら、結局60項目になった——という経験はないでしょうか。MVP（Minimum Viable Product）という言葉は浸透しましたが、「最小の機能で作る」という理解のまま進めると、ほぼ確実に肥大化します。MVPの本質は機能の少なさではなく、「検証に不要なものを作らないと決める」ことです。この記事では、何を落とすか、どう判断するかを、発注者が明日から使える手順として整理します。

なぜ機能を削れないのか

削れない理由はだいたい同じです。

• 「あった方がいい」がすべて「必要」に見える: 個別に見れば、どの機能にも理由がある。だから削る決め手がない。
• 社内の声を全部拾おうとする: 営業部門・カスタマーサポート・経営層、それぞれの要望を反映すると足し算になる。
• 検証したい仮説が複数ある: 「使われるか」「課金されるか」「継続するか」を1本のMVPで全部確かめようとすると、機能が積み上がる。
• 「後で追加が大変そう」という不安: 削って後悔するより、最初から入れておく方が安全に見える。

これらはすべて、「何を検証するためのMVPか」が決まっていないことが原因です。検証したい仮説が1つに絞れていれば、その仮説に不要な機能は自動的に削れます。要件そのものが曖昧なまま開発に入ると、機能を削る基準どころか作る基準すら関係者間でずれてしまい、後戻りのコストがさらに膨らみます。

作らないものを決める手順

1. 検証したい仮説を1文にする

「このプロダクトが解決すべき課題は何か」「その課題を持つユーザーは本当にお金を払うか、使い続けるか」を1文で書きます。複数の仮説を1本のMVPに詰め込まない。仮説が2つあるなら、検証の順番を決めて1つ目だけに絞ります。

例: 「経理担当者は、請求書の突合を手動でやっている作業を、自動化ツールに月額1万円払ってでも任せたいか」

2. 機能を3つに分類する

洗い出した機能を、次の3分類に振り分けます。

• 仮説の検証に直結する機能: これがないと、そもそも仮説が確かめられないもの
• 検証はできるが、なくても代替できる機能: 手動対応・スプレッドシート・人力オペレーションで代替可能なもの
• 仮説と関係ない機能: 「あると便利」「競合にはある」「将来必要になりそう」に分類されるもの

MVPに残すのは1つ目だけです。2つ目は「今は人力でやる」と明示的に決め、3つ目はそもそも議題に上げません。

3. 「あったら便利」を機械的に疑う

削る基準に迷ったら、次の質問を機能ごとに当てます。

• この機能がなくても、仮説は検証できるか
• この機能がないことで、ユーザーは離脱するか、それとも我慢して使い続けるか
• この機能を今作らないと、後から作るコストが跳ね上がるか(アーキテクチャに深く関わる場合のみ「今作る」理由になる)

3つとも「問題ない」なら、迷わず落とします。

フェーズ別に見る「作らなくていいもの」の具体例

判断基準が分かっても、実際にどこまで削っていいのか掴みにくいという声が多いので、機能領域ごとの目安を挙げます。あくまで「検証フェーズでは」という前提です。

• 認証: メール+パスワードの簡易ログインで十分。SNS連携・二要素認証・パスワードリセットのUIは後回しにできる。パスワードリセットは運営が手動でDBを直接書き換えて対応する運用でも、検証段階なら許容範囲。
• 管理画面: 専用のadmin UIを作らず、Railsコンソールやスプレッドシートでデータを直接操作する。ユーザー数が数十〜数百の間は、運営側の手間より開発コストの方が高くつく。
• 決済: Stripeなどの決済導入自体は早めでも、請求書発行・返金フロー・複数プラン切り替えのUIは省略し、個別対応(手動送金・手動返金)で乗り切る。「お金を払う意思があるか」を確かめたいだけなら、決済導線の入口だけあれば十分なケースも多い。
• 通知: リアルタイムのプッシュ通知やアプリ内通知センターは作らず、まずはメール1本に絞る。通知の「有無」ではなく「内容」が刺さるかを先に確かめる。
• 権限管理: 「管理者」「一般ユーザー」の2段階で始め、部署単位・ロール単位の細かい権限設計は、実際に複数ロールが必要になった顧客が出てから設計する。
• 多言語対応・アクセシビリティの作り込み: 検証対象の市場が日本語ユーザーのみなら、i18n基盤を先に用意する必要はない。後から入れると特に画面数が多い場合はコストが跳ね上がるので、「今作る」例外に該当するかだけは事前に見積もっておく。

こうした判断は、そもそもどこまでの開発工数が現実的なのかという見積もりの感覚とセットで持っておくと、削る・削らないの線引きがぶれにくくなります。

作らないと決めたものの扱い方

削った機能は「捨てる」のではなく「保留する」と扱うのが実務上のコツです。

• バックログに残す: 「検討したが今回は入れない」という判断の記録として残す。次に議論する時に、ゼロから話し合わなくて済む。
• なぜ削ったかを1行添える: 「検証仮説に不要」「手動で代替可能」など理由を書いておくと、後から蒸し返されたときに説明コストが下がる。
• 判断者を決めておく: 「削ってよいか」を毎回全員で議論すると時間がかかる。事業責任者など1人が最終判断する運用にする。
• 「後で作る」条件を先に決めておく: 「有料ユーザーが50社を超えたら権限管理を作る」「問い合わせが月10件を超えたらFAQ機能を作る」のように、再検討のトリガーを数値で決めておくと、感覚的な「そろそろ必要かも」ではなく機械的に判断できる。

この保留リストがあると、「削ったのに後で必要になったらどうするか」という不安が和らぎ、削る判断がしやすくなります。

よくある失敗パターン

MVPの機能スコープで起きる失敗は、大きく2方向に分かれます。

削れずに全部盛りになるパターン

• 「みんなが欲しいと言ったから」で機能を残す: 声の大きさと、仮説検証に必要かどうかは無関係です。
• 競合機能との比較で削れなくなる: 競合にある機能がないと不安になりますが、MVPの目的は競合に勝つことではなく仮説を検証することです。
• 技術的にきれいな設計を優先して汎用化しすぎる: 「将来の拡張性」を理由に、今使わない抽象化や設定項目を作り込むと、MVPの意味がなくなります。
• 「検証」と「本番運用」を混同する: MVPは検証のための道具です。決済・通知・権限管理など、検証に不要な運用機能を最初から本番品質で作る必要はありません。

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

• 仮説の検証に直結する機能まで削ってしまう: 「小さく作る」を「なんでも削る」と誤解し、コア体験そのものを壊してしまうケース。例えば請求書自動突合ツールで、突合精度を左右するコアロジックを「まず画面だけ作ろう」と後回しにすると、検証したい仮説(お金を払ってでも任せたいか)そのものが確かめられません。
• 削った理由を記録せずに進める: 後から「なぜこの機能がないのか」を関係者に何度も説明する羽目になり、削った判断自体が形骸化する。
• 保留と削除を区別しない: 「今回は作らない」を「もう二度と作らない」と受け取られ、次のフェーズで再提案しづらくなる。

いずれも根っこは同じで、「このMVPは何を確かめるためのものか」を関係者全員が同じ言葉で共有できていないことが原因です。機能の要不要を議論する前に、検証仮説を文章にして合意することが、実は一番の近道です。

MVP判断チェックリスト

機能一覧を前に迷ったら、次の項目を上から順に確認してください。

1. 検証したい仮説は1文になっているか(複数の仮説が混ざっていないか)
2. その仮説に、この機能は直結しているか、それとも代替可能か
3. 代替できるなら、誰が・どうやって手動対応するかが決まっているか
4. 削った機能はバックログに理由付きで記録されているか
5. 「後で作る」を判断する条件は、感覚ではなく数値で決まっているか
6. コア体験(仮説の核心部分)を削っていないか

この6つが埋まれば、機能一覧の議論は驚くほど短時間で終わります。

要件を整理する段階でこの絞り込みができていないと、MVP開発に入ってからスコープが膨らみ、期間も費用も見積もりを超えていきます。逆に、検証仮説と作らないものが最初に決まっていれば、開発は驚くほど速く進みます。

まとめ

• MVPの本質は「機能を減らす」ことではなく、「検証に不要なものを作らないと決める」こと
• 検証したい仮説を1文にし、機能を「仮説に直結」「代替可能」「無関係」の3つに分けると削る基準ができる
• 認証・管理画面・決済・通知・権限管理はフェーズごとに簡易版で代替できることが多い
• 削った機能は捨てずにバックログへ保留し、理由と「後で作る条件」を添えておくと後の判断がぶれない
• 削りすぎてコア体験まで壊す失敗もあるため、チェックリストで機械的に確認する

torcheees では、こうした機能の絞り込みを含めて「要件整理・開発診断」(1〜4週間)としてご提供しています。課題整理・優先順位付きバックログ・技術構成案・開発ロードマップを作り、そのままMVP開発へ接続できる状態にします。「機能をどこまで削っていいか判断がつかない」という段階からでも、お気軽にご相談ください。