「まずはMVPで」「試作だけ作りたい」「本開発まで見積もってほしい」。開発会社に相談しようとすると、似た言葉がいくつも出てきて、どこまで頼めばよいのか迷いやすくなります。

最初から大きく作りすぎるのは怖い。でも、小さくしすぎて意味のないものになっても困る。そんな不安があると、相談文を書く前に手が止まってしまいます。

この記事では、MVP、試作、本開発を「作る量」ではなく、何を判断するために作るのかで分けて整理します。開発会社に相談する前に、今の自分がどの段階にいるのかを見分けるための実践メモです。

最初にどこまで作るかで迷うのは自然です

「小さく始めたいけれど、何を削ってよいのか分からない」

開発を依頼する前は、完成形を考えるほど不安が増えます。ログイン、入力フォーム、管理画面、通知、決済、外部連携、CSV出力。思いつく機能を並べると、どれも必要に見えてきます。

一方で、最初から全部を作ると費用も期間も大きくなります。だから「まずはMVPで」と考えたくなりますが、MVPを単に「機能を減らした安い版」と捉えると、かえって判断しにくくなります。

Agile AllianceのMinimum Viable Product解説では、MVPは新規プロダクト開発における「学習」を重視する概念として説明されています。つまり、MVPは小さいこと自体が目的ではなく、顧客や業務の前提を検証するための最小単位と考える方が実務では扱いやすいです。

先に結論

開発会社へ相談する前に決めたいのは、「MVPか、試作か、本開発か」という言葉ではありません。先に決めるべきなのは、次のどの判断をしたいかです。

  1. アイデアや業務課題が本当に解くべきものか確認したい
  2. 画面や使い勝手を見せて反応を確かめたい
  3. 限定した利用者に実際に使ってもらいたい
  4. 安定運用できる正式版として作りたい

このうち、1と2に近いなら「試作」、3に近いなら「MVP」、4に近いなら「本開発」と考えると整理しやすくなります。

もちろん実際の案件では境界が重なることもあります。ただ、最初の相談では「完成版を作りたい」のか「次の判断材料がほしい」のかを分けるだけで、見積もりや提案の前提が大きく変わります。

MVP・試作・本開発の違い

言葉の定義は会社や開発チームによって揺れます。ここでは、開発会社に相談する前の整理として、次のように分けます。

区分主な目的向いている状態作り込みの目安
試作見せて、触って、前提を確認する画面・導線・業務フローがまだ曖昧捨てる前提の簡易実装や画面モックでもよい
MVP限定した相手に使ってもらい、継続判断する最初の利用者と検証したい価値が見えている品質は保ちつつ、範囲を絞った実利用版
本開発正式な運用に耐える形で提供する対象者、業務、運用担当、継続要件が固まりつつある保守、セキュリティ、例外処理、運用まで含める

表の「作り込みの目安」は、相場や固定ルールではありません。実務上の目安です。特にMVPは、品質を落としてよいという意味ではなく、検証に不要な範囲を削る考え方です。

試作が向いているケース

試作は、まだ作るべきものが固まっていない段階で使いやすい選択肢です。たとえば、次のような状態です。

  • 相談相手に見せる画面イメージがない
  • 社内メンバーが業務フローをうまく説明できない
  • 申込フォーム、予約導線、管理画面の優先順位が決められない
  • 既存ツールで足りるのか、個別開発すべきか迷っている
  • 本開発の見積もりを取る前に、前提を揃えたい

GOV.UK Service ManualのAlpha phaseでは、発見した課題に対して複数の解決案を試し、リスクの高い仮説を検証するために、必要な最小限の複雑さでプロトタイプを作る考え方が示されています。また、alphaで作るものは本番品質のコードではなく、最後には捨てる可能性もあると説明されています。

Ready Mockでいう試作も、完成版の縮小コピーではありません。「これなら伝わるか」「この業務フローで回るか」「次に投資してよいか」を確かめるための材料です。

MVPが向いているケース

MVPは、最初の利用者と検証したい価値がある程度見えている段階で向いています。

たとえば、イベント申込の自動化なら「既存顧客向けの1回のイベントで、申込、通知、管理者確認まで回るか」を見る。予約システムなら「1店舗、1サービス、既存顧客だけで運用負荷が下がるか」を見る。新規サービスなら「説明資料ではなく、実際の入力体験を通じて申込意思があるか」を見る。

Agile Allianceは、MVPのよくある落とし穴として、MVPを「提供できる最小機能」とだけ捉え、事業上の妥当性を学ぶ観点が抜けることを挙げています。小さく作っても、何を学ぶのかが決まっていなければ、MVPとしての意味は弱くなります。

実務上の目安として、MVPを相談するときは次の3つを先に書くと話が進みやすくなります。

  1. 誰に最初に使ってもらうか
  2. 何が起きたら続ける判断ができるか
  3. 何は初回から作らないか

本開発が向いているケース

本開発は、単に機能を増やす段階ではありません。正式な運用に耐えるために、品質、保守、例外処理、セキュリティ、運用担当、リリース後の改善まで含めて考える段階です。

GOV.UK Service ManualのBeta phaseでは、alphaで選んだ案を実際に作り始め、限定した利用者からフィードバックを得ながら改善し、規模を広げていく考え方が説明されています。これは小規模な民間案件でも参考になります。正式版に近づくほど、利用者サポートや運用体制も一緒に考える必要があります。

Scrum Guide 2020でも、インクリメントはプロダクトゴールへの具体的な一歩であり、価値を提供するには利用可能でなければならないと説明されています。つまり、本開発では「画面がある」だけでは足りません。実際に使える品質になっているかを見なければなりません。

次のような状態なら、本開発の相談に進みやすいです。

  • 対象ユーザーと利用シーンが明確になっている
  • 初回リリースの必須機能と後回し機能が分かれている
  • 運用担当者、問い合わせ対応、データ確認の流れが決まっている
  • 保存する情報や外部連携の重要度が見えている
  • リリース後に何を測るか、どの頻度で改善するかを話せる

根拠から見た分け方

ここでの分け方は、制度や費用相場の断定ではなく、開発初期の進め方に関する公的・公式・実務情報をもとにしています。

デジタル庁のデジタル社会推進標準ガイドラインでは、サービス・業務改革と政府情報システムの整備・管理に関する共通ルールや実践的な参考文書が整理されています。同ページには、要件定義書標準テンプレート、アジャイル開発実践ガイドブック、工程レビュー資料なども掲載されています。これは、開発を単なる機能実装としてではなく、サービスや業務の見直しと合わせて扱う考え方の根拠になります。

GOV.UKのDiscovery phaseでは、サービスを作り始める前に、解くべき問題、利用者、制約、改善機会を理解することが説明されています。相談前に「何を作るか」だけでなく「何を解くか」を整理する理由はここにあります。

また、Agile AllianceのMVP解説とScrum Guideは、MVPや反復開発を「小さいから安い」ではなく、学習、検査、適応、使える単位の価値として捉える助けになります。

相談前の実践メモ

開発会社に相談するときは、次のように言い換えると前提が揃いやすくなります。

「MVPで安く作りたい」より「何を検証したいか」を伝える

「MVPでお願いします」だけだと、開発会社によって解釈が分かれます。代わりに、「既存顧客に触ってもらい、申込まで進むか見たい」「社内の担当者で一定期間使い、転記時間が減るか見たい」のように、検証したいことを伝えてください。

「本開発の見積もり」でも、最初の範囲を分ける

本開発を相談する場合でも、初回リリースに必要な範囲と、後から追加でよい範囲は分けられます。特に、管理画面、通知、外部連携、細かな権限は膨らみやすいので、最初から全部入りにしない方が判断しやすいです。

「試作」は失敗ではなく、判断材料として扱う

試作の結果、「作らない方がよい」と分かることもあります。それは無駄ではありません。GOV.UKのDiscovery guidanceでも、調査結果によっては先に進まない判断が時間とお金を節約することになると説明されています。実務上も、早い段階で合わない案を止められることは大きな価値です。

どこまで作るかを決めるチェック

迷ったら、次の質問に答えてください。

  • まだ誰が使うか決まっていないなら、まずは試作
  • 使う人は決まっているが、反応や継続判断を見たいなら、MVP
  • 運用担当や例外処理まで決まり始めているなら、本開発
  • 画面を見ないと社内で合意できないなら、試作
  • 限定公開して実データで判断したいなら、MVP
  • 社外ユーザーに安定提供する前提なら、本開発

最初の相談では、このチェックをそのまま持っていけば十分です。言葉の定義を完璧に合わせるより、「今ほしいのは完成版か、判断材料か」を共有する方が大事です。

次にやること

まず、作りたいものを一文で書きます。次に、その一文の下に「試作で確認したいこと」「MVPで使ってもらう相手」「本開発で必要になる運用」の3つを書き出してください。

すべて埋まらなくても大丈夫です。空欄が多いなら、いきなり本開発の見積もりを取るより、試作や業務整理から始める方が向いている可能性があります。

もし、どこから小さく始めるか迷う場合は、先に要件が曖昧なまま相談してよい範囲を整理してください。開発前の材料を広く確認したい場合は、開発外注前チェックリストも使えます。

MVP、試作、本開発の違いは、言葉の違いだけではありません。最初にどの判断をしたいのかを決めることで、作る範囲も、相談相手に伝える内容も、見積もりの見方も変わります。

参考情報

この記事では、次の公的・公式・実務情報を確認しました。参照日はすべて2026年7月7日です。

  • デジタル庁「デジタル社会推進標準ガイドライン」: ページ最終更新日 2026年6月12日。DS-100、DS-110、DS-120は2025年6月19日更新、策定日または最終改定日 2025年5月27日。DS-121 アジャイル開発実践ガイドブックは策定日または最終改定日 2021年3月30日。
  • GOV.UK Service Manual「How the discovery phase works」: Published 4 August 2016, Last updated 21 June 2021.
  • GOV.UK Service Manual「How the alpha phase works」: Published 4 August 2016, Last updated 8 May 2019.
  • GOV.UK Service Manual「How the beta phase works」: Published 4 August 2016, Last updated 19 February 2021.
  • Agile Alliance「Minimum Viable Product (MVP)」: 公開日・更新日はページ上で確認できませんでした。MVPを学習のための概念として扱う説明を確認しました。
  • ScrumGuides.org「The 2020 Scrum Guide」: HTML版は2020年11月版PDFの直接移植として公開。ページ上に個別の更新日は確認できませんでした。