MVPを作る前に決めておくこと

MVPはロードマップ上のあらゆる着想を小さくしたものではありません。定義された人々が重要な業務フローをやり遂げられる最小の有用なプロダクトであり、次の判断のための根拠をチームに与えるものです。

その「根拠」という語こそ、立ち止まる価値があります。

CB Insightsの スタートアップが失敗する理由の分析 （新しいタブで開きます）は2026年3月に公開され、2023年以降に公に事業を終えた431社のベンチャー投資先を調べました。資金の枯渇が70%、プロダクトと市場の適合の不足が43%でした。

より有用なのは、適合の失敗が いつ 起きるかについての指摘です。「プロダクトと市場の適合の失敗の3分の2は、市場を見つけられなかった初期段階の企業だった」。

資金は終わり方です。十分に速く学べないことが、しばしばその理由です。同じ原則は社内向けの業務ツールにも当てはまります。その最初のリリースは、重要な業務フローが一つ良くなったことを示すべきです。

つまり最初のリリースは、野心の披露ではありません。何かを知るための道具です。以下の判断が、それを果たせるかどうかを決めます。

MVPではないもの

三つの読み違えが被害の大半を生みます。計画を始める前に名前をつけておく価値があります。

• 完成品を安く作ったもの。 全体の品質を落とすと、誰にも評価できないものが残ります。代わりに範囲を削り、残ったものをきちんと作ります。
• 試作。 試作は設計上の問いに答えたら捨てられます。MVPは実在の利用者を持つ本物のソフトウェアであり、保守できなければなりません。
• 恒久的な設計。 最初のリリースは変われるべきです。取り消すのに費用がかかる判断は、そうでない判断より熟慮に値します。

有用な問いは「最小限どれだけ作れるか」ではありません。「最小限どれだけ作れば、それでも行動に移すだけのことを学べるか」です。

そもそも受託開発が必要か

受託開発の範囲を決める前に、本当にもう必要なのかを問う価値があります。

受託開発が正解になるのは、業務フローが本当に固有であるとき、結果を自分たちで所有する必要があるとき、あるいは既製の道具では自社の働き方どおりに接続できないときです。

逆に、ノーコードの道具や表計算、既存のプロダクトで今週のうちに同じ仮説を試せるなら、最初の答えとしては誤っていることが多いのです。

有用な順序は、まず最も安い方法で需要を確かめ、どの部分が本当に必要かが分かってから受託開発に進むことです。

成功したプロダクトの多くは、手作業の工程や寄せ集めの道具として始まります。受託開発になるのは、その寄せ集めが痛み始めた箇所だけです。

早すぎる受託開発は、はるかに安い検証で分かったことを証明するために予算を使います。遅すぎる受託開発は、もう合わなくなった道具と戦い続けることになります。

その問いには、範囲を決め始める前に正直に答えておきます。

利用者の業務フローから始める

技術の話をする前に、誰がその製品を使うのか、どんな状況にいるのか、何を終わらせたいのかを書き出します。そこが曖昧なままだと、その曖昧さはすべての画面と機能についてまわります。

主要な流れは短い連なりとして書きます。たとえば、顧客が依頼を出し、担当者が確認し、システムが判断を記録し、両者が次の一歩を見られる、というように。

英国政府デジタルサービスは、これをディスカバリーの段階として定めています。その サービス手引き （新しいタブで開きます） は順序について率直です。「サービスを作ると決める前に、解決すべき課題を理解する必要がある」。

そのディスカバリーの期間はおよそ4〜8週間が典型とされ、そもそも成り立つサービスがあるのかという明示的な判断で終わります。

本当の可否判断を伴う短く区切られた調査は、5か月目に同じことを知る開発より安く済みます。

範囲に入るものを定義する

次に、絶対に要るものと、あとで役に立つものを分けます。ログイン、権限、決済、通知、レポート、外部連携、管理画面。どれも大事かもしれませんが、最初のリリースでそのすべてを同じ作り込みで持つ必要はありません。

良い範囲は、機能ごとに理由を持っています。次のいずれかを満たすとき、その機能を最初のリリースに残してください。

1. それがないと最初の利用者が中心の業務フローをやり遂げられない
2. すでに把握している納品上のリスクを減らす
3. 初日からチームに必要な裁量を与える
4. 外すと追加ではなく作り直しを強いる

どれも満たさないなら、それは削除ではなく後回しの判断です。そう記録しておくと、外すかどうかの議論はたいてい収まります。

うまくいったと分かる基準を決める

開発が始まる前に、どんな結果なら続行、方向転換、中止を正当化できるのかを合意してください。それがないと、どんな結果も励みに読めてしまいます。

1年分のデータを要する指標ではなく、実利用の最初の数週間で観察できる兆候を選びます。

• 手取り足取り案内しなくても、人が中心の業務フローをやり遂げる
• 促さなくても戻ってくる
• 製品が置き換えた手作業が、はっきり減っている
• 基本的な不具合の修正ではなく、次の機能を求められる

何をいつまでに見たいのかを書き出してください。それを実際に起きたことと比べることが、早く出すことの意味そのものです。

「完了」の意味を書き出す

開発が始まる前に「動く」の意味を定義してください。利用者が依頼を出せる、適切な担当者が確認できる、システムが結果を正しく記録する、といった観察可能な受け入れ基準を使います。

GDSの ユーザーストーリーの書き方 （新しいタブで開きます） に関する指針は、受け入れ基準を「サービスがその役目を果たしたことを確かめるための、確認一覧として使う結果の並び」と説明し、それぞれを ……のときに完了 という形式で書くとしています。

その価値は、作っていない人でも確かめられる点にあります。

リリース単位では The Scrum Guide （新しいタブで開きます） が完了の定義を「製品に求められる品質基準を満たしたときのインクリメントの状態を、形式的に記述したもの」と定めています。

スクラムを使うかどうかにかかわらず、この考えは持ち運べます。合意され書き出された品質の線引きが、「終わった」の意味が人ごとに違ってしまうのを防ぎます。

スキーマの前にデータの規則を決める

プロダクトが保存すべき情報と、それに触れてよい人を決めてください。プライバシー、権限、保持、バックアップ、監査の要件は、最初のテーブルや外部連携ができる前のほうが計画しやすいものです。

EU域内の人の個人データを扱う製品では、この順序で進めることは好みではなく法律上の義務です。

欧州委員会の データ保護バイデザイン・バイデフォルトに関する指針 （新しいタブで開きます） は、処理の設計の最も早い段階から適用される措置を説明し、既定値は「個人データが最高水準のプライバシー保護のもとで処理される」よう設定するとしています。

欧州データ保護会議は、2020年10月に 第25条に関する指針 （新しいタブで開きます） を最終版として採択しています。規制当局の詳細な立場が必要ならこちらを参照してください。

実務上は、書き出すべき短い一覧になります。何を集めるのか、なぜか、誰が見られるのか、どれだけ保つのか、そしてどうすれば削除してもらえるのか。

データベースを設計する前に答えておくほうが、あとから足すよりずっと安く済みます。

技術とAIを慎重に選ぶ

技術はプロダクトとその制約に合わせて選んでください。新しいフレームワークが合うこともありますが、より良い選択は利用者、データ、外部連携、納品の要件、そしてそのソフトウェアを保守する人によって決まります。

AIにも同じ規律が要ります。それを製品要件として扱う前に、中心の業務フローを支えるのか、出力が誤ったとき何が起きるのか、人がどう確認し直せるのかを決めてください。

いまでは測定に基づく慎重さの理由があります。 2025 DORA report （新しいタブで開きます）は、およそ5,000名の技術専門家の回答をもとに、「AIの導入はソフトウェア納品の安定性と負の関係を持ち続けている」と報告しています。

堅い検証と確認を欠いた速い産出は、速い納品には積み上がりません。手戻りに積み上がります。

確認、権限、引き継ぎを計画する

最初の一行を書く前に、レビューの節目を決めておきます。短いデモ、共有のタスク一覧、そして誰もが見える形で書き残した決定があれば、方向転換がまだ安いうちに方向を変えられます。

米国政府説明責任局はその Agile Assessment Guide （新しいタブで開きます）でリスクを論じています。継続的な評価を伴う漸進的な納品は「失敗する、あるいは陳腐化した技術を生むプログラムに資金を投じる危険を減らしうる」。

所有権と権限は最初に合意してください。プロジェクトには、明確なソースコードの保管場所、文書化された環境、合意された配備の手順、そして誰か一人の私的なアカウントに依存しない引き継ぎ計画が要ります。

DORAの バージョン管理のケイパビリティ （新しいタブで開きます） は、そこに何が入るべきかを具体的に示しています。アプリケーションのコードと依存関係、環境構築の道具、コンテナ構成のファイル、クラウドの設定、そしてプロンプトなどAIの成果物です。

その根拠は「バージョン管理の全面的な活用が継続的デリバリーを予測することを、研究が一貫して示している」ことだとされています。

GDSの バージョン管理に関する指針 （新しいタブで開きます） は、規則のもう半分である確認を補います。「すべてのコード変更は、それを書いていない誰かが確認する」。

これらの習慣がそろって、はじめて引き継ぎが可能になります。システムの再現が誰かのノートパソコンに依存しているなら、それは納品物ではなく依存です。

日程と予算を立てる

範囲がその形に収まるなら、絞り込んだMVPは6〜8週間の納品期間を目安に計画できることが多いものです。これは計画の目安であって普遍的な約束ではありません。外部連携、承認、未知の既存システムは日程を変えます。

ソフトウェアの日程がどう外れるかを知っておくと役に立ちます。外れ方は、前後で同じではないからです。

5,392件のIT案件を対象とし Journal of Management Information Systems （新しいタブで開きます） に掲載された研究は、費用超過が正規分布ではなくべき乗則に従うことを示しました。

超過の多くは小幅ですが、「極端な超過を示す少数の案件を含む厚い裾」があります。平均を前提に計画すると、本当に効いてくる危険を見誤ります。

これはスタートアップだけの問題ではありません。GAOの 連邦ITに関する高リスク評価 （新しいタブで開きます）は2025年1月に公開され、連邦のIT投資が「あまりに頻繁に失敗し、あるいは費用超過と日程の遅れを生じさせる一方で、任務に関わる成果にはほとんど寄与していない」と記録しています。

しかも年間1,000億ドルを超える支出に対してです。規模と予算がこれを解くのではありません。範囲の規律と短い反復が解くのです。

コーディング時間だけでなく、判断にも予算を取ります。調査、設計、実装、テスト、公開、コンテンツ、外部サービス、そして公開後の手直し。そのすべてが、最初のリリースを使えるものにするための手間に積み上がります。

具体例で考える

予約プラットフォームを望む創業者を考えてみましょう。顧客が予約を取り、提供者が予定を管理し、双方が支払い、通知を受け取り、管理者が全体を見渡す。長い機能一覧を持つ、実在しうるプロダクトです。

ところが中心の業務フローは狭いのです。顧客が空きを見つけて予約し、提供者がその予約を見る。それ以外はこれを支えるか、待てるものです。

規律ある最初のリリースは、たとえばこうなります。

• 範囲に入れる： 提供者の空き状況、顧客の予約、確認の通知、そして提供者向けの今後の予約の簡単な一覧。
• 後回し： アプリ内決済（当初は手作業で内金を受け取る）、自動の通知、レビュー、複数提供者の横断検索、管理ダッシュボード。
• 先に決める： どの顧客データをどれだけ保存するか、保管場所は誰のものか、そして受け入れ基準として「予約がうまくいった」とは何を指すか。

後回しの一覧は捨てたものではありません。それがロードマップです。ただ中心を先に出すことが、早い段階で唯一重要な問いに答えます。提供者は予定を最新に保つのか、そして顧客は予約するのか。

するのなら、残りは作る価値があります。しないのなら、どんな決済連携でも救えなかったでしょう。

はじめの一歩

目的はすべてを予測することではありません。重要な前提を見えるようにし、中心の業務フローを検証し、これまでの作業を捨てずに改善できるプロダクトの土台を作ることです。

着想はあるが仕様が固まっていないなら、利用者、業務フロー、そして最初のリリースに支えてほしい判断から始めてください。この三点があれば、役に立つ計画の会話を始められます。