ピボット時のコードの扱い：MVPの資産を残す設計の考え方

MVPの検証の結果、事業の方向を変える、いわゆるピボットを決めたとき、それまでに作ったコードをすべて捨てる必要はありません。結論から言えば、認証、管理画面、課金、データの記録と集計の基盤、運用の仕組みといった「どの事業の方向でも必要になる土台」は、多くの場合そのまま再利用できます。作り直しが必要になるのは、方向転換で変わる中心の機能、つまり誰の、どんな課題を、どう解くかに直接関わる部分です。

そして、どこまで再利用できるかは、ピボットの時点ではなく、MVPを作り始める時点の設計でかなり決まります。中心の機能と土台を分けて作っておけば、方向を変えても土台は残ります。逆に、すべてが絡み合った作りにしていると、一部を変えるだけでも全体の作り直しになりがちです。

この記事は、MVPを作ろうとしている、あるいはMVPを公開して方向転換を検討している事業責任者・新規事業担当者に向けたものです。ピボットで残る部分と変わる部分の見分け方、MVPの段階で資産を残すための設計、ピボットを決めたときのコードの扱い方の手順、よくある失敗を整理します。

ピボットとMVPのコードの関係

ピボットとは、検証の結果を踏まえて、事業の方向を変えることです。対象とする顧客を変える、解決する課題を変える、提供の形を変える、収益の取り方を変える、など、さまざまな種類があります。MVPは仮説を確かめるためのものなので、ピボットはMVPの失敗ではなく、検証がうまく働いた結果です。

ピボットの多くは、利用者の行動や声から「当初の想定とは違う使われ方をしている」「別の顧客層の反応の方が強い」と気づくところから始まります。たとえば、想定していた機能はあまり使われていないのに、おまけのつもりで付けた機能が繰り返し使われている、といった兆候です。こうした兆候に気づけるかどうかは、MVPの段階でどれだけ行動を記録し、利用者と話しているかにかかっています。そして、気づいた後にすばやく方向を変えられるかどうかは、コードの作り方にかかっています。

ただ、ピボットのたびにシステムを一から作り直していては、時間も費用も足りません。新規事業では、何度か方向を変えながら事業の形を探ることが珍しくないからです。そこで大切になるのが、方向を変えても残る部分をあらかじめ意識した作り方です。

MVPの作り直しをどう判断するかについては、MVPから本開発へ移るとき：作り直すか育てるかの判断基準でも詳しく扱っています。この記事では、特に方向転換の場面に焦点を当てます。

ピボットの種類と、コードへの影響

ピボットの種類によって、コードへの影響の大きさは変わります。次の表は、代表的なピボットの種類と、影響の目安です。

たとえば「課題の絞り込み」のピボットでは、多くの機能のうち一つに集中するだけなので、コードの多くは残り、使わない機能を外すことが中心になります。一方、「課題の変更」では中心機能のほとんどを作り直すことになりますが、それでも認証や管理画面などの土台は再利用できます。

再利用しやすい部分と作り直しが必要な部分

では、具体的にどの部分が再利用しやすいのでしょうか。一般的な傾向を整理します。

再利用しやすい部分

認証・利用者の管理：ログイン、登録、パスワードの再設定などは、事業の方向が変わってもほぼそのまま使えます。対象顧客が個人から法人に変わる場合は、組織単位の管理を追加する必要が出てきますが、利用者の管理そのものは残ります。

管理画面の枠組み：運営者がデータを確認し、操作するための管理画面は、表示する項目は変わっても、一覧、検索、編集、権限といった枠組みは再利用できます。

課金の仕組み：決済サービスとの連携、支払い状態の管理、利用できる機能の切り替えといった仕組みは、料金プランが変わってもそのまま使えることが多い部分です。

データの記録と集計の基盤：利用者の行動を記録する仕組みや、それを集計して見る仕組みは、ピボットの判断材料を得るためにも、次の検証のためにも必要です。記録する出来事の種類は変わっても、記録と集計の仕組みは残ります。

通知・メール送信の仕組み：メールや通知を送る仕組み、送信の記録などは、事業の内容に関わらず使えます。

運用の仕組み：公開の手順、監視、障害時の通知、データのバックアップなどの運用の仕組みは、ほぼそのまま引き継げます。

作り直しが必要になりやすい部分

中心の機能と、その画面：利用者が価値を感じる中心の機能は、ピボットで最も大きく変わる部分です。

中心の機能に固有のデータ構造：中心の機能のために設計したデータの形は、課題が変わると合わなくなることが多くあります。

利用者向けの紹介ページや文言：誰に何を届けるかが変われば、伝え方も変わります。

MVPの段階で資産を残すための設計

ピボットのときに土台を残せるかどうかは、MVPの作り方で決まります。次の点を意識しておくと、方向を変えたときの作り直しを小さくできます。

土台と中心の機能を分けて作る

認証、課金、管理画面、記録、通知といった土台の部分と、中心の機能の部分を、プログラムの中で分けて作ります。中心の機能が土台を利用する関係にしておき、土台の側が中心の機能の事情を知らない作りにするのが理想です。そうすれば、中心の機能を入れ替えても、土台に手を入れる必要がほとんどありません。

利用者と組織の構造は少し先を見て作る

対象顧客の変更は、ピボットの中でもよくある種類です。特に、個人向けから法人向けへの変更はよく起こります。MVPの段階から、利用者が「組織」に所属できる構造を持たせておくと、法人向けへの切り替えが楽になります。最初は1人1組織として扱えばよく、画面に組織の機能を出す必要はありません。

外部サービスを積極的に使う

認証、決済、メール送信、ファイルの保管などは、外部サービスを使うことで、自社で作る土台そのものを小さくできます。自社で書いたコードが少ないほど、ピボットで捨てるものも少なくなります。技術の選び方はMVPの技術スタックの選び方で詳しく扱っています。

管理画面を作り込みすぎない

管理画面は再利用しやすい部分ですが、中心の機能に合わせて細かく作り込むと、ピボットのときに作り直しが必要になります。MVPの段階では、汎用的な一覧と編集ができる程度に留め、運用の多くを手作業や既存のツールで補う考え方が有効です。詳しくはMVPの管理画面は最小限でよいかを参照してください。

記録は「事業の問い」に答えられる形で残す

ピボットの判断には、利用者がどのように使ったかの記録が欠かせません。どの機能が使われ、どこで離れたかを後から分析できるよう、イベントログの形で行動を記録しておきます。この記録は、ピボットの判断材料になると同時に、ピボット後の新しい検証でもそのまま使えます。

説明を残しておく

設計の意図や、なぜこの作りにしたのかを短く残しておくと、ピボットのときに「どこが再利用できるか」を判断しやすくなります。特に、開発の担当者が入れ替わる可能性がある場合は重要です。長い文書は必要ありません。主要な部品の役割、データの構造の考え方、外部サービスを選んだ理由、あえて後回しにしたことを、それぞれ数行で書いておけば十分です。後回しにしたことの一覧は、ピボットの後に「どこに手を入れるべきか」を判断するときの手がかりにもなります。

ピボットを決めたときのコードの扱い方

実際にピボットを決めたときは、次の手順でコードの扱いを判断します。

1. ピボット後の検証したい仮説を書く：新しい方向で何を確かめたいのかを一文で書き、MVPで必要な機能を洗い出す
2. 既存の機能と部品を一覧にする：今あるコードを、土台の部分と中心の機能の部分に分けて書き出す
3. それぞれを「そのまま使う」「直して使う」「使わない」に分ける：新しい仮説の検証に必要かどうかで判断する
4. データの扱いを決める：既存の利用者やデータを新しいサービスに引き継ぐか、別に保管するか、削除するかを決める。利用者の同意や規約の扱いも確認する
5. 使わない部分を整理する：使わない機能は、画面から外すだけでなく、コードやデータの整理も計画する。残しておくと、後の開発で混乱の元になる
6. 作り直す部分の範囲と期間を見積もる：直して使う部分と、新しく作る部分の手間を見積もる
7. 作り直しか継続かを最終判断する：手間を比較し、土台を残して作り直す方が速いか、全体を作り直す方が速いかを判断する

5の「使わない部分の整理」は省かれがちですが、重要です。使われなくなった機能やデータが残っていると、新しい機能を作るときに、影響の範囲を調べる手間が増えます。

作り直しか継続かの判断基準

全体を作り直すか、土台を残して中心の機能を作り直すかは、次の観点で判断します。

ピボット後の開発を進めるときの注意点

コードの扱いを決めたら、ピボット後の開発に入ります。この段階で気をつけたいのは、次の点です。

新しい仮説の検証に必要な最小限から作る：土台が残っていると、つい以前と同じ規模の機能を作りたくなります。しかし、ピボット後の方向も、まだ仮説の段階です。最初のMVPと同じように、検証したい行動に必要な機能だけに絞って作ります。

既存の土台の弱点をこの機会に直す：最初のMVPで後回しにしていた土台の弱点、たとえば管理者の権限の分け方が粗い、記録の項目がそろっていない、といった問題は、ピボットのタイミングで直しておくと、その後の検証が楽になります。ただし、直す範囲は新しい検証に影響する部分に限ります。

データの名前と意味を見直す：方向が変わると、データの名前と実際の意味がずれることがあります。たとえば「店舗」という名前のデータに、実際には「本部」の情報を入れるような使い方を続けると、後で混乱の元になります。意味が変わったデータは、名前や構造を見直します。

関係者に変更の内容を共有する：開発の担当者だけでなく、運営や営業の担当者にも、何が残り、何が変わったのかを共有します。特に、管理画面の項目や運用の手順が変わる場合は、運営の担当者が戸惑わないよう、変更点をまとめて伝えます。

次のピボットの可能性も意識する：一度方向を変えたからといって、それが最後とは限りません。新しく作る中心の機能も、土台と分けて作る原則を守っておくと、次の変化にも対応しやすくなります。

具体的な場面の例

架空の例で考えてみます。ある会社が、個人の飲食店主向けに、仕入れ先との発注をスマートフォンで行えるサービスのMVPを作りました。しかし、数か月運用したところ、個人店主の利用は定着しませんでした。一方で、複数の店舗を持つ飲食チェーンの本部担当者から、「店舗ごとの発注を本部でまとめて確認したい」という声が多く寄せられました。そこで、対象を飲食チェーンの本部に変えるピボットを決めました。

この会社は、MVPを作る段階で、認証、管理画面、通知、記録の仕組みを中心の機能と分けて作っていました。また、利用者が「組織」に所属できる構造を最初から持たせていました。そのため、ピボットでは次のように扱いを決められました。

• 認証と利用者の管理：そのまま使い、組織の中に店舗を作れるように直す
• 通知の仕組み：そのまま使う
• 記録の仕組み：そのまま使い、記録する出来事の種類を追加する
• 管理画面：枠組みはそのまま使い、表示する項目を変える
• 発注の画面：本部が複数店舗の発注を確認・承認する画面として作り直す
• 個人店主向けの紹介ページ：作り直す

結果として、作り直しの範囲は中心の機能とその画面に限られ、新しい方向での検証を短い期間で始めることができました。もし最初から個人の利用者だけを前提に、すべてが絡み合った作りにしていた場合、組織の構造を後から入れるために、全体を作り直す必要があったかもしれません。

よくある失敗と避け方

最初から作り直しを前提に雑に作る：「どうせ作り直すから」とすべてを場当たり的に作ると、ピボットのときに何も残りません。中心の機能は手早く作っても、土台の部分は分けて作ることを意識します。

逆に、すべてを将来に備えて作り込む：将来のあらゆる可能性に備えた作りにすると、MVPの開発が遅れます。備えるのは、よく起こる変化（対象顧客の変更など）に対する最小限の構造に限ります。

使わなくなった機能を放置する：ピボット後も古い機能やデータが残っていると、新しい開発の妨げになります。外す計画を立て、整理します。

既存の利用者への対応を忘れる：ピボットで既存の利用者が使えなくなる場合、事前の案内や、データの扱いについての説明が必要です。利用規約や個人情報の扱いについては、必要に応じて専門家に確認してください。

ピボットの判断材料になる記録がない：どの機能が使われ、どこで離れたかの記録がないと、ピボットの方向を決める根拠が弱くなります。MVPの段階から、行動の記録を残しておきます。

MVPを作るときのチェックリスト

• 土台の部分（認証、課金、管理画面、記録、通知）と中心の機能を分けて作っている
• 利用者が組織に所属できる構造を持たせている（最初は画面に出さなくてよい）
• 認証、決済、メール送信などに外部サービスを使い、自社で作る土台を小さくしている
• 管理画面は汎用的な一覧と編集に留め、中心の機能に合わせた作り込みを控えている
• 利用者の行動を、後から分析できる形で記録している
• 設計の意図や、なぜこの作りにしたのかを短く残している
• 外部サービスとのやりとりを一か所にまとめている
• 既存の利用者のデータを、ピボット後にどう扱うかの方針を考えている

よくある質問

Q. ピボットのたびに作り直すのは悪いことですか？

悪いことではありません。中心の機能は、検証の結果に応じて作り直すのが自然です。問題になるのは、土台まで毎回作り直すことです。土台を残しておけば、作り直しの範囲を中心の機能に限定でき、次の検証を早く始められます。

Q. MVPで将来のピボットに備えるには、開発期間が長くなりませんか？

土台と中心の機能を分けて作ることは、慣れた開発者にとっては大きな追加の手間にはなりません。また、外部サービスを使うことで、むしろ開発期間を短くできる部分もあります。避けるべきなのは、起こるかどうか分からない変化のために機能を作り込むことです。

Q. ノーコードツールで作ったMVPでも、資産は残せますか？

ノーコードツールで作った場合、コードとしての資産は残りにくいものの、検証で得た学び、画面の構成、データ、運用の手順は残ります。本格的な開発に移るときは、これらを要件として引き継ぐことになります。移行の考え方はノーコードの限界はどこかを参考にしてください。

Q. 外部の開発会社に作ってもらったコードは、ピボット後も使えますか？

ソースコードの権利や引き渡しの条件を、契約の段階で確認しておくことが前提です。そのうえで、設計の説明や、開発の環境の情報を引き継げるようにしておけば、別の体制でも再利用できます。

Otsumuに相談できること

社内にコードの全体像を理解している開発者がいて、土台と中心の機能を分けて作る方針を共有できているなら、この記事の観点とチェックリストに沿って、自社でピボットに強いMVPを作り、方向転換のときも落ち着いて判断できます。

一方で、ピボットを決めたものの既存のコードのどこが使えるか判断できない、MVPの作り方が場当たり的で次の検証にどう備えるべきか迷っている、方向転換と同時に開発の体制を見直したい、といった場合は、事業の判断と技術の判断の両方を踏まえて整理できる相手と進めたほうが、無駄な作り直しを避けられます。

Otsumuは自らも事業を手がける立場から、目的から逆算して作る範囲を絞り、AIを活用した少人数・短期間の開発で、構想から検証、方向転換、本格開発までを一気通貫で支援しています。新規事業の爆速MVPシステム開発では、土台を残しやすい構成で検証を進め、ピボットの際には既存の資産の見極めから一緒に行います。事業の方向そのものを整理したい場合は新規事業開発コンサルティングもご覧ください。

方向転換を検討し始めた段階からでもご相談いただけます。まずは30分の無料相談で、いまの状況をお聞かせください。

この記事について

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

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