MVPから本開発へ移るとき：作り直すか育てるかの判断基準

MVPで手応えを得たあと本開発へ移るとき、作り直すか育てるかは「感覚」ではなく、コードの状態、技術選定、利用者とデータの規模、そして次の1年で何を作るかの4点で判断できます。多くの場合、全面的な作り直しより、問題のある部分を順番に置き換えながら育てるほうが、事業を止めずに済み、失敗の幅も小さくなります。作り直しが正解になるのは、土台の技術が事業の要件と根本的に合わない場合や、誰もコードを安全に変更できない場合に限られます。

この記事は、MVPを公開して一定の反応を得た新規事業の責任者、プロダクト担当者、本開発の発注を検討している方に向けたものです。開発会社から「作り直したほうが早い」と言われて迷っている場合や、逆に「このまま続けて大丈夫か」と不安な場合の判断材料になります。

読み終えると、MVPから本開発へ移る際の判断基準、作り直しと段階的改善それぞれの進め方、移行時に失いやすいものと守り方、判断を誤りやすい場面が分かります。

MVPから本開発へ移るタイミングをどう見極めるか

本開発への移行を考える前に、そもそも移行する段階にあるのかを確認します。MVPはあくまで検証のための版です。検証が終わっていないのに本開発に進むと、前提が変わったときに大きな投資が無駄になります。

移行を検討してよい状態は、おおむね次のようなものです。

• 主な仮説（課題がある、この解決策で解ける、続けて使う）について、判断できるだけの利用実績がある
• 有料で使ってもらえている、または支払いの意思を具体的に確認できている
• 次に作るべき機能が、利用者の行動や声から明確になっている
• 事業として継続する意思決定が、社内で正式になされている

逆に、利用者がまだ少なく仮説が判定できていない段階で「本開発」という言葉が出てきたら、それは本開発ではなく、検証の延長として次の版を作る段階です。この区別をあいまいにすると、検証のつもりで大きく作り込んだり、本開発のつもりで場当たり的な追加を続けたりすることになります。

MVP公開後の判断と開発の優先順位は、MVP公開後の開発の優先順位でも詳しく扱っています。

作り直すか育てるかを決める4つの判断軸

作り直し（リプレイス）と段階的な改善のどちらを選ぶかは、次の4つの軸で整理します。

コードの状態：変更できるかどうかが分かれ目

MVPのコードは、速さを優先しているのでテストが少なかったり、設計に粗さがあったりするのが普通です。それ自体は作り直す理由になりません。見るべきは「安全に変更できるか」です。変更したときの影響範囲を開発者が説明でき、手作業でも確認手順が決まっているなら、テストを足しながら改善していけます。

反対に、MVPを作った人がすでにおらず、仕様書もなく、触るたびに別の場所が壊れるような状態なら、作り直しの検討に値します。ただしその場合も、まずは現状把握に時間を取るべきです。仕様書がないブラックボックス化したシステムの現状把握の方法の考え方は、MVPにもそのまま当てはまります。

技術選定：制約に当たっているかどうか

ノーコードツールやローコードツールでMVPを作った場合、権限の細かい制御、外部システムとの連携、大量データの処理などで限界に当たることがあります。この場合は、ツールの制約が次に作りたい機能を妨げているかどうかで判断します。制約に当たっていないなら、無理に移行する必要はありません。移行の判断と手順はノーコードの限界はどこかで整理しています。

一般的な言語やフレームワークで作られているなら、技術選定を理由に作り直すことはあまりありません。「新しい技術で作り直したい」という開発側の希望は、事業上の理由とは分けて考えます。

規模と性能：構造の問題か、部分の問題か

利用者が増えて画面が遅くなった、という問題の多くは、特定の処理の改善やインフラ構成の見直しで解決できます。作り直しが必要になるのは、データの持ち方そのものが事業の形に合っていない場合です。たとえば、1社で使う前提で作ったものを複数の企業に提供する形に変える場合、マルチテナントの設計を後から入れる必要があり、影響が全体に及ぶことがあります。

次に作るもの：延長線上か、別物か

検証の結果、対象顧客を個人から法人に切り替える、Webから業務端末向けに変えるなど、事業の形が大きく変わることがあります。このときは、今のMVPは「検証のための道具」としての役割を終えたと考え、新しい形に合わせて設計し直すほうが合理的な場合があります。

「作り直したほうが早い」と言われたときに確認すること

開発会社やエンジニアから作り直しを提案されることは珍しくありません。提案自体が間違っているとは限りませんが、判断する前に次の点を確認します。

1. 作り直す理由を、事業上の問題として説明してもらう：「コードが汚い」ではなく、「この機能を追加するのに、今の構造だとどれだけかかり、作り直すとどう変わるか」という形で説明してもらう。
2. 作り直しの期間中、今のMVPをどう運用するか確認する：作り直している間も利用者は使い続ける。並行して改修が必要になる場合、二重の負担になる。
3. データの移行計画を確認する：利用者のデータをどう新しいシステムに移すか、移行の当日に何が起きるか。データ移行は作り直しで最も見落とされやすい工程です。
4. 段階的に置き換える案と比較する：全面的な作り直しだけでなく、問題のある部分から順に置き換える案の見積もりも出してもらう。
5. 作り直した後に何が良くなるかを、利用者の視点で書き出す：利用者から見て何も変わらないなら、その期間は事業が止まっていることと同じです。

全面的な作り直しは、期間が読みにくく、完成するまで価値が届かないという性質を持っています。この点を理解したうえで判断します。

育てる場合の進め方：段階的な改善の手順

改善を続けると決めた場合、場当たり的な修正の積み重ねにならないよう、次の手順で進めます。

1. 現状を棚卸しする：機能一覧、画面、データの構造、外部サービスとの連携、運用の手作業を書き出す。MVPの段階では文書が少ないことが多いので、まずここを整える。
2. 問題のある箇所に優先順位を付ける：障害が多い、変更に時間がかかる、性能が足りない、の順で、事業への影響が大きいものから並べる。
3. テストを足す：特に変更頻度が高い部分と、お金やデータの正しさに関わる部分から自動テストを加える。回帰テストの仕組みがあると、改善のたびに既存機能が壊れていないか確かめられる。
4. 新機能の追加と改善を同じ計画に入れる：改善だけの期間を長く取ると事業が進まない。新機能の開発の中に、関係する部分の改善を組み込む。
5. 置き換える部分は境界を決めて切り出す：たとえば決済や認証、通知など、まとまりのある部分から新しい作りに置き換える。全体を一度に変えない。

この進め方は、事業を止めずに品質を上げられる一方で、改善の効果が目に見えにくいという面もあります。どの部分を、いつまでに、どの状態にするかを計画として書き出し、定期的に進み具合を確認します。

作り直す場合の進め方と注意点

作り直しを選ぶ場合は、次の点に注意します。

• 範囲を最初の版より広げない：作り直しのついでに新機能を大量に入れると、期間が読めなくなる。まずは今のMVPと同等の機能で置き換え、その後に新機能を足す。
• MVPで分かったことを仕様に反映する：MVPで使われなかった機能は作り直しの対象から外す。利用ログや問い合わせ履歴を見て、実際に使われている流れを優先する。
• 切り替えの方法を決める：一斉に切り替えるか、一部の利用者から段階的に移すか。段階的に移せば問題が起きたときの影響を小さくできる。
• 旧システムを止める日を決める：二つのシステムを並行して動かし続けると、運用の負担が倍になる。

作り直しの計画は、新規開発というよりリプレイスとして扱うほうが実態に合います。既存の利用者とデータがあるという前提で、移行計画を立てることが重要です。

本開発への移行時に失いやすいものと、その守り方

作り直す場合でも育てる場合でも、MVPから本開発へ移る過程では、目に見えにくいものが失われがちです。代表的なものと守り方を挙げます。

特に見落とされやすいのが計測の連続性です。MVPの段階で取っていた利用ログやイベントが、作り直しによって別の名前や別の単位に変わると、移行前後で数字を比べられなくなります。その結果、「本開発で使いやすくなったのか」を確かめられません。移行の計画に、計測の引き継ぎを一つの作業として含めておきます。

運用の工夫も同様です。MVPでは、運営担当者が毎朝データを確認して手で修正したり、特定の利用者だけ設定を変えたりと、システムの外で補っていることがよくあります。こうした手作業は仕様書に書かれていないため、本開発で抜け落ちやすくなります。移行前に、運営担当者へ「毎日・毎週・毎月やっていること」を聞き取って一覧にしておくと安全です。

本開発の体制をどう組むか

本開発に移ると、開発の量も関わる人も増えます。MVPのときの少人数体制をそのまま続けるか、体制を広げるかも、作り直しか改善かと同じくらい重要な判断です。

MVPを少人数で作れたのは、範囲を絞り、意思決定者が近くにいたからです。本開発でも、この二つの条件を保てるなら、体制を急に大きくする必要はありません。むしろ人数を増やすと、情報共有や調整に時間がかかり、開発の速さが落ちることがあります。

体制を広げるべきなのは、並行して進めたい開発の流れが複数ある場合（例：利用者向けの機能追加と、管理側の業務効率化を同時に進める）や、障害対応や問い合わせ対応を常時行う必要が出てきた場合です。このときも、一度に人を増やすのではなく、役割を一つずつ足していくほうが混乱が少なく済みます。

判断を誤りやすいよくある失敗

失敗1：検証が終わる前に本開発を始める

社内の承認が下りたことで、検証が不十分なまま本開発に進むことがあります。避け方は、本開発に進む条件（どの数字がどうなったら進むか）を、MVPの計画段階で決めておくことです。

失敗2：作り直しの間に事業が止まる

作り直しに数か月かかり、その間は新機能も改善もなく、利用者が離れてしまう失敗です。避け方は、作り直し中も最低限の改善を続けられる体制を確保するか、段階的な置き換えを選ぶことです。

失敗3：MVPを作った人がいなくなり、知識が失われる

MVPを外部に頼んでいて、本開発で別の会社に切り替える場合に起こりやすい失敗です。コードは残っても、なぜそう作ったかという判断の経緯が失われます。避け方は、切り替え前に引き継ぎの期間を設け、設計の意図や既知の問題を文書に残してもらうことです。MVPを外注から内製へ引き継ぐの手順は、外部の会社を切り替える場合にも使えます。

失敗4：MVPの粗さを放置したまま機能を足し続ける

育てると決めたのに、改善の時間を取らず機能追加だけを続けると、変更のたびに時間がかかるようになり、最終的に作り直しを迫られます。避け方は、開発の時間の一定の割合を改善に充てるという運用ルールを決めることです。

本開発への移行判断のチェックリスト

最後に、移行を判断する前に確認しておきたい項目をまとめます。

• 検証の結果を数字と利用者の声で説明できる
• 次の1年で作るべき機能の候補が、優先順位付きで並んでいる
• 今のコードを変更したときの影響範囲を、開発者が説明できる
• テストや動作確認の手順が、少なくとも中核の機能について存在する
• 想定する利用者数・データ量に対して、どこが足りなくなるか見当がついている
• 使っている技術を保守できる人を、社内外で確保できる
• 作り直す場合のデータ移行と切り替えの方法を検討した
• 段階的な改善案と作り直し案の両方を比較した
• 移行期間中の運用体制（障害対応、問い合わせ対応）が決まっている
• 本開発の体制（社内で持つか、外部と組むか）を決めた

具体的な場面で考える：架空の業務支援SaaSの例

架空の例として、中小の建設会社向けに「現場写真と日報をまとめて管理するサービス」をMVPとして公開した場面を考えます。数十社が有料で使い始め、継続率も悪くない一方で、写真が増えるにつれて一覧画面が遅くなり、利用企業から「協力会社にも見せたい」という要望が多く寄せられています。

開発会社からは「協力会社に権限を分けて見せるには、データの構造から変える必要があるので作り直したほうが早い」と提案されました。

ここで4つの軸を確認すると、コードは一般的なフレームワークで書かれ、開発者は変更の影響範囲を説明できる状態でした。性能の問題は画像の読み込み方と一覧の取得方法の改善で対応できる見込みです。協力会社への共有は、権限の仕組みを追加する必要があるものの、既存の企業・ユーザーの関係を拡張する形で実現できることが分かりました。

結論として、作り直しではなく、まず性能改善を行い、次に権限の仕組みを段階的に追加する計画にしました。全面的な作り直しよりも早く利用者に価値を届けられ、既存のデータ移行も不要になります。

このように、作り直しの提案を受けたら、その理由を事業の要件に分解し、部分的な対応で済まないかを一つずつ確かめることが大切です。

よくある質問

Q. MVPはどうせ作り直すものだと聞きましたが、本当ですか？

必ずしもそうではありません。最初から作り直す前提で作れば、使い捨ての版になります。検証で終わる可能性も高いので割り切りは必要ですが、一般的な技術で、最低限の構成を整えて作っておけば、そのまま育てられることも多くあります。

Q. 本開発は、MVPを作った会社に続けて頼むべきですか？

経緯をよく知っている点では有利です。一方で、体制や得意分野が本開発の規模に合うかは別に確認が必要です。続けて頼む場合も、本開発に入る前に体制と進め方を改めて合意し直すことをおすすめします。

Q. 作り直しと改善、どちらが費用を抑えられますか？

一概には言えません。作り直しは一度に大きな費用がかかり、改善は継続的に費用がかかります。比較する際は、同じ期間で利用者に届けられる価値と、移行に伴うリスクを含めて考えます。両方の案で見積もりを取り、内訳を比べるのが確実です。

Q. ノーコードで作ったMVPは必ずスクラッチで作り直す必要がありますか？

必要ありません。ツールの制約が事業の成長を妨げていなければ、使い続けて問題ありません。外部連携や一部の機能だけを別に開発して組み合わせる方法もあります。

Otsumuに相談できること

MVPを作った開発者が社内に残っていて、コードの状態と次に作るものが明確なら、この記事の判断軸に沿って社内で判断できます。改善の計画を立て、テストを足しながら機能追加を続けるやり方は、多くのチームで実践できるものです。

判断が難しいのは、作った人がいない、開発会社の提案の妥当性を確かめられない、事業の方向性と技術の判断を同時に行う必要がある、といった場面です。こうしたときは、事業側と技術側の両方の視点で現状を見られる第三者が入ると、判断の材料がそろいやすくなります。

Otsumuは、構想から開発・運用・改善までを一気通貫で手がけています。新規事業の爆速MVPシステム開発では、MVPの次の版の計画づくりや、既存コードの状態確認を踏まえた改善・置き換えの方針づくりを支援できます。全面的な置き換えが必要な場合は、システムのリプレイスとしての進め方もご相談いただけます。

作り直すか育てるかで迷っている段階でも、まずは30分の無料相談で現状をお聞かせください。判断に必要な情報が何かを一緒に整理するところから始められます。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01