MVP開発を外注するときの発注先の選び方と見積もりの読み方

MVP開発の外注で失敗しないためには、「何を検証するためのMVPか」を自社で決めてから発注先を探し、見積もりは金額よりも前提条件（範囲・体制・変更時の扱い）で比べることが大切です。MVPは作りながら仕様が変わる前提のものなので、変更に柔軟に対応できる進め方と契約を選べるかどうかが、発注先選びの分かれ目になります。

依頼する前に自社で決めておくこと

発注先に相談する前に、少なくとも次の点を言葉にしておきます。これがないと、発注先ごとに解釈がばらつき、見積もりを比べられません。

検証したい仮説：MVPで何を確かめたいのか（例：対象顧客が週に何回使うか、有料で使い始めるか）。作るものの考え方はPoC・プロトタイプ・MVPの違いと進め方を参照してください。
対象ユーザーと主な利用場面：誰が、どんな場面で、何のために使うのか
必須の機能と、なくてもよい機能：検証に不可欠な機能だけを「必須」とし、それ以外は優先順位をつけて並べる
期限と予算の上限：いつまでに顧客に使ってもらいたいか。予算は幅でもよいので上限を持っておく
MVP後の方針：検証がうまくいった場合、同じ発注先で本格開発に進むのか、自社で内製化するのか

特に最後の点は見落とされがちですが、ソースコードの権利、使う技術、ドキュメントの範囲に関わるため、最初に伝えておくべき条件です。

発注先の種類と向き不向き

発注先の種類	向いている場面	注意したい点
新規事業・スタートアップ向けの開発会社	仕様が固まっていない段階から一緒に考えてほしい	企画・設計の関与度によって費用の考え方が変わる
一般的な受託開発会社	作るものがある程度明確で、品質や体制を重視したい	要件を固めてから見積もる進め方が中心の場合がある
フリーランス（個人）	小規模なMVPを素早く作りたい	体制が個人に依存する。病気や離脱時の代替を確認する
ノーコード・ローコードに強い会社や個人	既存ツールの組み合わせで検証できる	ツールの制約で後から作り直しが必要になる場合がある

どの種類が良いかは、MVPの内容と自社の体制によって変わります。自前で作るか既存サービスを使うかの判断はゼロから作るか、既存のパッケージを使うかの判断基準でも扱っています。

発注先候補の見極め方

似た段階のプロダクトを作った経験があるか

実績を見るときは、業種の近さだけでなく、「仕様が固まっていない段階から、少人数で短期間に作り、公開後に改善した経験があるか」を確認します。大規模システムの実績が豊富でも、検証段階の開発の進め方に慣れているとは限りません。

提案の中で「作らない提案」が出てくるか

依頼した機能をすべて見積もるだけでなく、「この機能は検証段階では手作業で代用できる」「既存のサービスで代替できる」といった提案が出てくる発注先は、MVPの目的を理解している可能性が高いといえます。

実際に担当する人と話せるか

営業担当だけでなく、実際に開発を担当する人やプロジェクトの責任者と事前に話し、仕様の変更や優先順位の相談をどのように進めるかを確認します。担当者が途中で入れ替わる可能性や、その場合の引き継ぎ方法も聞いておきましょう。

公開後の運用・保守まで見ているか

MVPは公開してからが本番です。不具合の対応、サーバーの運用、利用状況の計測、改善の開発をどのような体制・契約で行うのかを、開発前の段階で確認しておきます。

見積もりの読み方

見積もりの金額は、前提条件によって大きく変わります。金額だけで比べず、次の点をそろえてから比較してください。なお、開発費用の一般的な相場は、機能・品質・体制によって大きく異なるため、本記事では示しません。複数の候補から、同じ前提で見積もりを取ることが最も確実な比較方法です。

1. 作業範囲（何が含まれ、何が含まれないか）

企画・要件整理、デザイン、開発、テスト、公開作業のうち、どこまで含まれているか
サーバーや外部サービスの利用料、ドメイン、アプリストアの登録などの費用はどちらが負担するか
公開後の保守・運用、不具合対応は含まれるか、別契約か

「一式」とだけ書かれている項目は、内訳と含まれる作業を確認します。

2. 工数と体制

見積もりは「何人が、どれだけの期間関わるか」の積み上げで作られることが一般的です。役割（プロジェクト管理、デザイン、開発、テストなど）ごとの人数と期間が示されているかを確認し、示されていなければ内訳を依頼します。同じ金額でも、経験の浅い担当者の比率が高い見積もりと、経験者が中心の見積もりでは中身が違います。

3. 前提条件と仕様変更の扱い

見積書の前提条件の欄には、「対応ブラウザ・端末」「想定ユーザー数」「発注者が用意する素材や情報」などが書かれています。この前提が崩れると追加費用が発生するため、自社の想定と合っているかを必ず確認します。

MVPは開発中に仕様が変わることが前提です。仕様変更や機能追加をどのように扱うか（追加見積もりになるのか、決められた期間・体制の中で優先順位を入れ替えるのか）を確認してください。

4. 成果物と権利

ソースコード、デザインデータ、設計資料などの成果物が何か、著作権などの権利がどちらに帰属するかを確認します。将来の内製化や発注先の変更を考えているなら、ソースコードの引き渡しと利用の条件は特に重要です。

契約形態：請負と準委任

外部への開発委託の契約には、主に「請負」と「準委任」があります。IPA（情報処理推進機構）のアジャイル開発版「情報システム・モデル取引・契約書」の解説では、あらかじめ特定した成果物の完成に対価を払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を払う準委任契約を前提としている、と説明されています。開発の途中で機能の追加・変更や優先順位の変更に柔軟に対応するためです。

同じ解説では、アジャイル開発でユーザ企業がその利点を生かすには、プロダクトの方向性と内容を決めるための主体的かつ積極的な関与が必要で、相応の負担を伴うことも指摘されています。

一方、作るものを確定させてから開発する受託開発向けには、IPAが「情報システム・モデル取引・契約書」第二版（2020年12月22日公開）を公開しています。IPAはこれを、ユーザ企業・ITベンダのいずれかにメリットが偏らない契約書作成を目指したものと説明しています。

MVPの開発でも、仕様を固めきれない段階なら準委任、作るものが明確なら請負というように、段階に応じて使い分ける考え方があります。契約の具体的な注意点は開発会社との契約の注意点（請負と準委任）で解説しています。

発注する側に必要な体制

判断できる担当者を置く

IPAのアジャイル開発版モデル契約では、プロダクトの方向性と内容に責任を持つ「プロダクトオーナー」をユーザ企業側が選任することとし、開発チームが必要とする情報や意思決定を適時に提供する役割を明確にしています。MVPの外注でも、仕様や優先順位をその場で判断できる担当者を発注側に置くことが欠かせません。社内の承認に毎回時間がかかると、開発の速度は大きく落ちます。

契約前に共通理解をそろえる

同じくIPAは、契約前のチェックリストとして、プロジェクトの目的・ゴールとプロダクトのビジョンが明確で関係者と共有されているか、開発対象がアジャイル開発に適しているか、初期計画や完了基準・品質基準が明確か、十分な初期のバックログ（開発項目の一覧）があるか、発注側が適切なプロダクトオーナーを選任し権限を委譲できるか、などの項目を示しています。MVPの発注前の確認項目としても参考になります。

大企業と起業家で異なる点

大企業の場合

社内の調達規程や取引先登録、情報セキュリティの審査に時間がかかることがあります。新しい発注先を使う場合は、候補選びと並行して社内手続きを進めておきましょう。また、社内の標準的な契約書が請負を前提にしている場合、仕様変更が多いMVP開発に合うかを法務部門と相談しておくと、後の手戻りを防げます。

起業家・スタートアップの場合

資金に限りがあるため、最初から全機能を発注するのではなく、検証に必要な最小範囲で区切って発注し、結果を見て次の範囲を決めるほうがリスクを抑えられます。技術に詳しいメンバーが社内にいない場合は、見積もりや技術選定を第三者の技術者に見てもらうことも検討してください。

契約や取引条件は法令や個別の事情によって判断が変わります。契約の前に、必要に応じて弁護士などの専門家に確認してください。