公開から数か月が経つと、どのチームも一度は作り直しの見積もりを取ります。いざ具体的な金額を目にすると、誰もが言葉を選びながらその場の決定を先送りにします。
逆のケースもあります。機能を一つ足すたびに別の箇所で不具合が起き、そのたびに応急処置で対応します。これが二、三度続くと、チームの内部からも「このまま機能を足し続けて大丈夫なのか」という不安の声が上がります。
どちらの状況も、結局は一つの本質的な問いに行き着きます。今のシステムを育て続けるか、それとも作り直すか。先の第1部では到達・反復・支払い・要望という四つのシグナルを扱いました。そこから方向性はある程度見えているはずです。そのシグナルをもとに、実際の意思決定を下すための具体的な基準を整理します。
何を基準に見るか
「コードが乱雑だから作り直すべきだ」という診断はよく聞かれます。短期間でスピード優先に組み上げたMVPであれば、どのプロダクトでも出てくる指摘であり、こうしたコードの整理は現在の構造を育てていく過程の中でも十分対応できます。
本当に作り直すかどうかを分ける本質的な基準は、技術的な完成度ではなく、最初に立てた仮説からプロダクトがどれだけ離れたかにあります。
ここでいう仮説とは、MVPを企画した当初に設定したターゲットユーザー、その訪問目的、そして中核価値に至る導線の設計図を指します。最近集まるユーザーの要望が、この設計図の上で枝分かれしている程度なら、既存の構造を育てれば足ります。しかし設計図そのものを描き直す必要があるシグナルなら、対応の仕方を根本から変える必要があります。
作り直しを分ける三つの問い
既存の設計図からどれだけ外れているかは、次の三つの問いで明確に検証できます。
- 中核データ（扱う対象そのものが変わったか）: 個人のスケジュールを管理していたサービスが、チーム単位のプロジェクト日程まで扱う必要に迫られる状況が代表例です。
- ユーザー種別（最初に想定した層と実際の利用者が違うか）: 個人消費者を狙って作ったはずが、企業の担当者やB2Bの問い合わせが主流になっているケースです。
- 中核フロー（登録から支払いまでの導線が変わったか）: 一度きりの決済で完結していた流れに、複数段階の社内承認プロセスが必須で挟まる状況です。
個人向けのスケジュール共有アプリを例にすると、判断のプロセスがはっきりします。公開から二か月ほどでチーム単位の登録者が増え、一つの予定を複数人で承認する機能の要望が相次ぐ状況は珍しくありません。この場合、扱うデータの対象が個人から組織に変わり、予定確定の流れに承認プロセスが加わって導線も変わっています。三つの問いのうち二つに該当するため、プロダクト構造を作り直す方向をまず検討することになります。
問いの該当数によって、判断の方向が分かれます。
| 該当した項目数 | 判断の方向 |
|---|---|
| 0〜1個 | 既存の構造を継続的に育てる |
| 2個以上 | プロダクト構造の作り直しを検討する |
一つの項目だけが変わったのであれば、現在の構造の上に機能を積み重ねる程度で対応できます。しかし二つ以上が同時に変わっているなら、DB構造と画面の骨格そのものが、そもそも違う前提の上に立っているという意味です。この状態で機能だけを足していくと、システムの継ぎ目ごとに深刻な不具合が生じます。
起こりやすい二つの誤判断
一つ目は、成果が出ているのにシステムを全面的に作り替えてしまうケースです。シグナルが良好だとチームの自信も膨らみ、予算にも余裕が生まれ、「この機会にきちんと作り直そう」という主張が勢いを増します。結果として数か月間、新機能の開発が完全に止まり、すでに検証済みのユーザーの流れまで失われます。うまく機能しているサービスの流れを止める機会費用を軽視した結果です。新しく作り直した成果物が既存サービスより優れているかどうかは、その数か月の停滞を乗り越えたあとで初めて証明されます。
二つ目は、シグナルが悪いのに固執して機能を足し続けるケースです。指標が振るわなくても、これまでかけた埋没費用への未練から作り直しを先送りにし続けます。機能を積み重ねるほど、本来検証すべき本質的な仮説はかすみ、指標がわずかに動いたときにそれが新機能の効果なのか、既存の欠陥が一時的に隠れただけなのか判断できなくなります。会議のたびに「次のアップデートでは違うはずだ」という期待を抱きますが、仮説そのものを見直すべき決定的なタイミングはそのたびに先送りされます。
部分的な作り直しという中間の道
全面的な作り直しと現状維持という両極端しかないわけではありません。中核となる特定のフローだけを新しく設計し、残りは既存システムとつなぐ部分的な作り直しも有効な選択肢です。レガシーシステムを捨てずに刷新する方法で扱ったように、機能単位でモジュールを切り分けて移行し、問題が起きたらそのモジュールだけを即座に元に戻す原則は、MVPの段階でもそのまま当てはまります。
作り直すと決めた場合は、三つの問いの中で最も差が大きかった中核フローから優先的に再設計します。ユーザーアカウントとこれまで蓄積した中核データはそのまま維持し、ずれてしまった画面とフローだけを新しい構造に移す方法です。
費用を比較するときに見落とすもの
作り直しの見積もりは一括提示される形のため、見た目の衝撃が大きくなります。一方、既存構造を維持しながらかかる保守や追加開発の費用は毎月の分割支出という形になるため、相対的に負担が軽く感じられます。
したがって二つの選択肢の費用を客観的に比較するには、必ず同じ期間で揃える必要があります。通常は6か月単位で作り直しの想定費用と、同じ期間の累積開発費用を並べてみると、最初の直感とはまったく違う分析結果になることが少なくありません。
この比較で重要なのは、目先の短期的な支出額に惑わされず、同じ観察期間を設定する分析の姿勢です。作り直しの見積書に記された大きな金額に怯んで応急処置ばかりを続ける選択も、毎月積み上がる開発費の負担を放置したまま構造診断を先送りにする選択も、根は同じ誤りから来ています。
既存構造を維持して育てる道を選んだ場合にどこまで進めるかは第3部で、作り直す道を選んだ場合に何を残すかは第4部でそれぞれ扱います。
インテグラビットがMVP構造診断を独立した段階に置く理由
インテグラビットでは、サービスの拡張と作り直しのどちらを選ぶかを決める前に、「MVP構造診断」を独立した工程として実施しています。インテグラビットが手がけていない外部のMVPプロジェクトを引き継ぐ場合も、検証の基準は同じです。中核データ、ユーザー種別、中核フローという三つの軸が、当初の仮説からどれだけ外れているかをまず把握します。前任の開発者のコードの書き方を評価するためではなく、現在のアーキテクチャが今後何サイクル持ちこたえられるかを客観的に見積もるためです。
診断の結果が既存システムを育てる方向になっても、全面的に作り直す方向になっても、その先の戦略的な判断は、依頼主組織による明確なデータに基づいた意思決定のもとで下されます。
前の記事: MVPを出したあと、何を見て次を決めるのか
次の記事: 育てると決めたら：どこまで伸ばし、いつ止めるのか
現在運用しているサービスの構造がどちらに近いか判断がつかない場合は、30分の無料相談で三つの中核的な問いを一緒に確認できます。