MVPから本開発は作り直し？引き継げる部分と見直す点
MVPで手応えを得たあと、「このまま本開発に進めるのか、それとも一から作り直しなのか」で迷う場面は少なくありません。この記事では、MVPから本開発へ進むときに引き継げるものと見直すべきもの、その見分け方を整理します。作り直しの範囲を事前に見通せれば、本開発の計画や社内の説明も組み立てやすくなります。
結論：丸ごと作り直しになるとは限らないが、そのまま使えるとも限らない
先に結論を書くと、「全部作り直し」と「全部そのまま」のどちらかになることは多くありません。実際には、引き継げる部分と見直す部分が混ざります。
MVP（Minimum Viable Product）は、事業の仮説を確かめるために必要最小限の機能で作る製品のことです。目的は、売上や運用に耐える完成品を作ることではなく、「顧客が本当に使うか」「この課金の形で成り立つか」といった仮説を確かめることにあります。
この目的の違いが、本開発との間に差を生みます。
- MVPは、確かめたいことに絞って作る。それ以外は意図的に省いている
- 本開発は、事業として継続的に運用する前提で作る。省いていた部分も扱う
したがって「作り直しになるのか」という問いは、「MVPで何を省いたのか」「省いた部分が本開発でどれだけ必要になるのか」という問いに置き換えられます。MVP、プロトタイプ、モックの違いから整理したい場合は、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けもあわせてご覧ください。
作り直しが起きやすい3つの理由
作り直しが話題になるときは、多くの場合、次の3つのどれか（または複数）が背景にあります。
1. MVPの段階で、割り切った作りにしていた
検証を早く進めるために、あえて割り切った実装にすることがあります。たとえば次のようなものです。
- 管理画面を作らず、データを直接書き換えて運用する
- 決済や通知など一部の処理を、人が手作業で代行する
- 利用者が少ない前提で、データの持ち方を簡素にしておく
こうした割り切りは、MVPとしては正しい判断です。ただし、利用者や取引が増えた段階では、手作業の代行や簡素なデータ構造が運用の妨げになります。この部分は、本開発で作り込む必要があります。
2. 想定していなかった規模や使われ方が見えてきた
検証が進むと、最初の想定と違う使われ方が見えてくることがあります。想定していた利用者とは別の層が使っていた、機能の優先順位が入れ替わった、といった具合です。
これは失敗ではなく、検証の成果です。ただし、土台となるデータ構造や画面の流れが当初の想定に強く依存している場合、その部分は見直さざるを得ません。
3. 検証用の部分と、本番に必要な部分が分けられていなかった
MVPのコードや設計の中で、「検証のために仮置きした部分」と「そのまま使える部分」が整理されていないと、本開発に入ってから切り分けの作業が発生します。どこが仮置きだったのかを誰も説明できない状態だと、安全のために広く作り直す判断になりがちです。
作り直しの大きさは、技術的な出来の良し悪しよりも、「何が仮置きなのかが整理されているか」に左右されることが多いといえます。
引き継げるもの：コードより先に「確かめた中身」
引き継げるものを考えるとき、まずコードに目が向きがちです。しかし、新規事業で最も価値のある引き継ぎ資産は、コード以外にあります。
検証で分かったこと
MVPの最大の成果物は、システムそのものよりも、検証で得た知見です。
- どの機能が使われ、どの機能が使われなかったか
- 利用者がどこでつまずいたか
- 想定した価値が、実際に伝わったか
- 事業として続ける判断の根拠になる数字や声
これらは本開発の機能の優先順位を決める材料になります。検証の指標を事前にどう決めておくかは、MVP検証の指標を先に決める方法｜判断基準の作り方で扱っています。
要件と画面の設計
実際に触って確かめられた画面の流れや、業務のルールは、そのまま本開発の要件のたたき台になります。言葉だけで決めた要件と違い、「使ってみて確かめた」という裏付けがあるため、要件の抜け漏れや食い違いが起きにくくなります。要件定義の進め方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。
データ構造の考え方
どんな情報を、どんな単位で持つかという設計の考え方は、検証を通じて磨かれます。実際のテーブル構造をそのまま使うかどうかは別として、「どの情報が事業の中心か」という整理は引き継げます。DB設計の役割分担については、AI設計でDB設計はどこまで任せる？役割分担の考え方で触れています。
外部サービスとの連携の選定
認証、決済、メール配信、地図など、外部のサービスを使って済ませた部分は、本開発でもそのまま使えることがあります。ただし、利用規約や提供条件、利用量が増えたときの扱いは、本開発の前に確認が必要です。決済や認証を自作するか外部サービスを使うかの考え方は、新規事業の決済システム開発｜外部サービスと自作の分け方で整理しています。
コードそのもの：条件つきで引き継げる
コードについては、次の条件がそろうほど引き継ぎやすくなります。
- 役割ごとに部品が分かれていて、仮置きの部分を切り離せる
- 仕様や設計の意図が、文書や記録として残っている
- 自動テストがあり、変更しても壊れていないか確認できる
- 第三者が読んで理解できる
なお、AIが生成したコードも、人が書いたコードと同様に、保守できる状態かどうかで判断します。確認点はAI生成コードの保守は可能か｜引き継ぎと改修の確認点にまとめています。
見直すべきもの：MVPで省きやすかった部分
次に、本開発の前に見直しておきたい部分です。MVPでは後回しにしやすく、本番では欠かせないものが中心です。
| 見直す部分 | 本開発で確認したいこと |
|---|---|
| 認証・権限 | 利用者の種類ごとに、見せる情報と操作を分けられるか |
| セキュリティ | 個人情報や取引情報の扱い、脆弱性への対応は十分か |
| 性能と規模 | 利用者や取引が増えても、速度や安定性を保てるか |
| データの移行 | MVPで集めたデータを、新しい構造へ安全に移せるか |
| 運用の仕組み | 監視、バックアップ、障害時の連絡、問い合わせ対応は整っているか |
| テスト | 重要な機能を、変更のたびに確認できる状態か |
| 手作業の代行部分 | 人が裏側で代行していた処理を、システム化する必要があるか |
| 管理機能 | 運営側が日々の運用に使う画面や集計が必要か |
セキュリティは、MVPの出来にかかわらず見直す
MVPは限られた利用者で検証することが多く、セキュリティの確認が簡易になりがちです。本開発で利用者が増える、あるいは決済や個人情報を扱うようになる場合は、MVPの出来にかかわらず、あらためて確認する必要があります。AIを使って作ったコードでも同じです。確認点はAI生成コードのセキュリティ｜確認点と人の役割で整理しています。
技術的負債という考え方
MVPで割り切った部分は、「技術的負債」と呼ばれることがあります。これは、短期的な速さを優先して後回しにした作りが、将来の修正の手間として残ることを借金にたとえた言葉です。
負債があること自体は悪いことではありません。検証を早く進めるために意図的に背負ったものであれば、むしろ合理的な判断です。大切なのは、「どこに負債があるのか」を把握し、本開発の計画に返済の作業として組み込んでおくことです。
引き継ぐか作り直すかを決める手順
判断の基準を、順に確認する形で整理します。
1. 事業として続ける判断が先に固まっているか
本開発の前提は、検証の結果、事業を続ける判断ができていることです。判断の基準が曖昧なまま本開発に進むと、PoC（概念実証）で止まったままになる原因にもなります。この点はPoC失敗で終わる新規事業の共通点と本開発への進み方で詳しく扱っています。
2. 仮置きの部分を洗い出す
MVPの開発で割り切った箇所を、一覧にします。手作業で代行していた処理、簡素にしたデータ構造、省いた機能などです。一覧にすれば、見直す範囲が見えてきます。
3. 部分ごとに「引き継ぐ・手直しする・作り直す」を分ける
システム全体を一つの塊として判断せず、部分ごとに分けます。
- 引き継ぐ：検証で問題がなく、本番でもそのまま使える部分
- 手直しする：基本の作りは使えるが、権限やテスト、性能などを加える部分
- 作り直す：データ構造や前提が事業の実態と合わなくなった部分
多くの場合、全体の中で「作り直す」に入るのは一部になります。ただし、その一部が土台に当たる場合は、周辺にも影響が及びます。
4. 今後の変更の頻度を考える
今後も頻繁に仕様が変わりそうな部分は、凝った作り込みを急がない方がよいことがあります。逆に、事業の中心で変わりにくい部分は、早めに堅牢に作っておく価値があります。
5. 権利と引き継ぎの条件を確認する
MVPを作った会社と本開発を担う会社が異なる場合、ソースコードの権利や、設計書などの引き継ぎ資料の扱いが問題になります。契約前に確認しておくと安心です。システム開発の著作権帰属は誰のもの？契約前の確認点と、システム開発会社の乗り換え前に確認したい引き継ぎの要点が参考になります。
作り直しを小さくするために、MVPの段階でできること
作り直しの大きさは、MVPを作る段階の工夫である程度抑えられます。
絞るときに、後で必要になるものを記録しておく
機能を絞ることはMVPの基本ですが、絞るときに「何を、なぜ後回しにしたか」を残しておくと、本開発の計画が立てやすくなります。絞り方の基準は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準で扱っています。
仮置きの箇所を、仮置きと分かる形にしておく
手作業で代行する部分や、簡易な実装にした部分は、文書や記録に残します。コードの中でも、他の部分と分けておくと、あとで切り離しやすくなります。
設計の意図を残す
なぜこの画面の流れにしたのか、なぜこのデータの持ち方にしたのかを、短くてもよいので残します。検証で分かったことと一緒に整理しておくと、後から参加する人も判断しやすくなります。
最低限のテストを用意する
すべてを自動で確認する必要はありませんが、事業の中心となる機能だけでも確認できる仕組みがあれば、本開発での変更が安全になります。AIを使ったテストの考え方は、AIのテスト自動生成｜任せる範囲と人が見る確認項目で整理しています。
仕様変更が起きる前提で進める
検証を通じて仕様が変わるのは自然なことです。変更を前提にした進め方は、システム開発の仕様変更への対応｜追加要望の扱い方にまとめています。
本開発に入ったあとも、システムは育てていく
本開発に進んだあとも、システムは完成して終わりではありません。利用者の反応や事業環境の変化に合わせて、機能を足したり、見直したりする状態が続きます。MVPから本開発への移行を「一度きりの作り直し」ととらえるよりも、「検証で分かったことを反映しながら、段階的に整えていく流れ」ととらえる方が実態に近いといえます。納品後の改善の考え方は、システムは納品後の改善で育てる｜新規事業の考え方で扱っています。
まとめ
MVPから本開発へ進むとき、全体が作り直しになるとは限りません。ただし、MVPのままそのまま使えるとも限りません。要点は次のとおりです。
- 作り直しの範囲は、MVPで「何を省いたか」と、それが整理されているかで決まる
- 引き継げる最大の資産は、検証で得た知見、要件、画面の流れ、データ構造の考え方
- コードは、仮置きを切り離せる、設計意図が残っている、テストがある、といった条件で引き継ぎやすくなる
- 認証・権限、セキュリティ、性能、データ移行、運用の仕組みは、本開発の前に見直す
- 判断は、システム全体ではなく、部分ごとに「引き継ぐ・手直しする・作り直す」と分ける
- MVPの段階で、仮置きの箇所と設計の意図を残しておけば、作り直しは小さくできる
私たちJustFitは、「先に作って、後から決める」という考え方のもと、構想をもとに約1ヶ月で動くプロトタイプを用意し、実物を見てから契約を判断していただく受託開発サービスです。契約後は、毎月ひとつの機能追加まで月額で対応し、納品後も業務に合わせてシステムを育てていきます。MVPの次の進め方で迷われている場合は、JustFitのサービス紹介もご覧ください。