MVPを作ったあとはどうする？作り直すか拡張するかの判断基準

まず、検証結果をどう読むか

結果がはっきりしない場合は、検証の方法（利用者の集め方、見る数字、期間）が適切だったかを振り返ります。大きな開発を始める前に、検証をやり直すほうが合理的なこともあります。

よくある3つの状況

考え方をつかむための例です（特定の企業の事例ではありません）。

状況A：使われているが、利用者が増えて動作が重くなってきた

教室向けの予約サービスのMVP。教室と生徒の両方に使われ、継続利用もある。ただ、教室の数が増えるにつれて、予約一覧の表示が遅くなってきた。データの持ち方そのものは、今後のサービスの形にも合っている。

この場合は、拡張が基本です。遅くなっている部分（一覧の表示、検索）を重点的に改善し、土台はそのまま使い続けます。

状況B：企業ごとに権限を分けたいという要望が強い

中小企業向けの業務管理サービスのMVP。検証段階では、利用者全員が同じ画面を使う簡易的な作りにしていた。導入企業が増え、「部署ごとに見られる範囲を分けたい」「取引先にも一部を見せたい」という要望が強くなっている。

この場合は、権限とデータの持ち方という土台に関わる変更のため、部分的な置き換え、場合によっては作り直しを検討します。権限の考え方は社内ツールの権限設計で解説しています。

状況C：想定とは違う使われ方をしている

個人向けに作った記録サービスのMVPが、実際には小さな事業者の業務管理に使われている。個人向けの機能はあまり使われていない。

この場合は、技術的な判断の前に方向を変えるかどうかを決めます。事業者向けに切り替えるなら、新しい仮説を立てて、必要な機能を絞り込み直すところから始めます。考え方はMVPとは？機能の絞り込み方を参照してください。

「続ける」と決めたら：今の状態を確認する

• 機能を追加しようとすると、毎回想定以上に時間がかかる
• 利用者が増えると、動作が遅くなる、止まることがある
• データの持ち方が、今後のサービスの形に合っていない
• セキュリティや権限の作りが、検証段階の簡易的なままになっている
• 作った人以外には、全体の構成が分からない

当てはまる項目が少なければ拡張、土台に関わる項目（データの持ち方、権限、全体の構成）が多ければ、置き換えや作り直しを検討する目安になります。

3つの選択肢の比べ方

全面的な作り直しは、きれいな状態から始められる一方で、その間はサービスの改善が止まりやすく、移行の負担も大きくなります。問題のある部分から段階的に置き換える方法が、事業を止めずに済む現実的な選択になることも多くあります。

部分的に置き換える場合の進め方

1. 問題のある部分を特定する：遅い、直しにくい、今後の形に合わないなど、問題が集中している部分を洗い出す
2. 置き換える順番を決める：事業への影響が大きく、他の部分への影響が小さいところから
3. 新旧を並行させる期間を決める：置き換えた部分を確認できるまでは、旧来の部分も動かせるようにしておく
4. データを移す：置き換えた部分で使うデータを移行し、利用者への影響がないかを確認する

判断のために、開発会社に確認すること

• 今の構成と課題を、非エンジニアにも分かる言葉で説明してもらう
• 拡張・部分的な置き換え・作り直し、それぞれの費用と期間の目安
• 作り直す場合のデータと利用者の移行方法
• 選んだ方法で、今後の機能追加がどの程度しやすくなるか

MVPを作った会社とは別の会社に相談する場合は、まずソースコードや資料、アカウントを確認するところから始めることになります。引き継ぎの考え方は外注したシステムを自社で持ち続けるためにで解説しています。既存の仕組みを作り直すかどうかの一般的な判断基準は古い社内ツールを作り直すべきか？、費用の配分はスタートアップのMVP開発費用はどう考える？もご覧ください。

相談のときに用意したいもの

• 検証で分かったこと（利用者の数と反応、よく使われている機能、使われていない機能）
• 利用者から多い要望と、運営で困っていること
• 今のMVPの構成が分かる情報（ソースコード、使っているサービス、アカウント）
• 今後半年〜1年で目指すサービスの形

次の段階でも「小さく、順番に」

本格的な開発に進む段階でも、すべてを一度に作る必要はありません。状況A〜Cのように、検証で分かったことによって次の一手は変わります。Tailboneでは、今のMVPの構成と課題、検証で分かったことを伺い、拡張・部分的な置き換え・作り直しのどれが合うかを一緒に整理します。他社で開発したMVPの場合も、ソースコードや資料がそろっていなければ、現状の把握から始めます。