MVP開発の会社は「範囲を一緒に絞れるか」で選ぶ
MVP開発を外注する会社を選ぶとき、最初に見るべき点は、技術の種類や会社の規模ではなく、作る範囲を発注側と一緒に絞れるかどうかです。
MVPは、事業の仮説を確かめるために最小限を作るものです。発注する時点では、何が正しい仕様なのかを発注側も知りません。その状態で「仕様を決めてくだされば、そのとおりに作ります」という関わり方の会社に依頼すると、発注側が仕様を決め切れずに時間がかかるか、念のための機能が積み上がって大きくなるかの、どちらかになりやすくなります。
反対に、「その機能は、今回確かめたいことに必要ですか」と問い返してくれる会社であれば、範囲は小さくなり、検証は早く始まります。会社選びの中心は、この問い返しができる相手かどうかを確かめることにあります。
通常の受託開発と、新規事業のMVP開発の違い
通常の受託開発と、新規事業のMVP開発やPoC開発では、前提が違います。優劣ではなく、向いている仕事が違う、という整理です。
- 仕様の確かさ：通常の受託開発は、業務の手順や要件が決まっている仕事に向いています。要件を正確に実現することが品質です。MVP開発では、要件そのものが仮説であり、途中で変わることを前提にします。
- 成功の定義：受託開発では、合意した仕様どおりに、期日までに納めることが成功です。MVP開発では、仮説について判断できる材料が得られることが成功です。仕様どおりに完成しても、何も学べなければ目的を果たしていません。
- 発注側の関わり方：受託開発では、要件を渡した後の発注側の関与は、確認と受け入れが中心です。MVP開発では、発注側の判断者が短い間隔で動くものを見て、範囲と優先順位を決め続ける必要があります。
- 変更の扱い：受託開発では、変更は追加費用と期日の見直しの対象です。MVP開発では、変更は学びの結果として起きるものなので、あらかじめ変更の余地と決め方を契約に入れておきます。
- 納品の後：MVPは公開してからが検証の本番です。公開後に使われ方を見て直す期間が、計画に含まれている必要があります。
これらの違いを踏まえずに、通常の受託開発と同じ基準で会社を比べると、見積もりの安さと機能の多さで選ぶことになり、MVPの目的から離れていきます。契約の形の考え方は開発契約を変更と引き継ぎまで含む運用ルールにする考え方で扱っています。
面談で確かめる質問
候補の会社との面談では、実績の紹介を聞くだけでなく、自社の案件について具体的に質問します。答えの内容だけでなく、答え方から進め方が分かります。
- 「この依頼内容のうち、最初の検証では作らなくてよいと思うものはどれですか」。範囲を絞る提案ができるかを見ます。すべてを作る前提で話が進むなら、MVPの進め方に慣れていない可能性があります。
- 「開発の期間中、私たちは何を、どのくらいの頻度で確認しますか」。動くものを短い間隔で見せる進め方かどうかを確かめます。最後にまとめて見せる進め方では、途中で方向を直せません。
- 「途中で優先順位が変わった場合、どう扱いますか」。変更の決め方と、費用や期日への反映の仕方が説明できるかを見ます。
- 「利用状況の計測は、どこまで含まれますか」。検証のためのMVPである以上、何回使われ、どこでやめたかが分かる仕組みが必要です。依頼しなければ含まれない場合があります。
- 「実際に担当するのは誰ですか。その人と話せますか」。面談に出る人と作る人が違うことがあります。設計を担う人と直接話し、事業の内容への質問が出るかを見ます。
- 「検証の後、私たちは何を受け取りますか」。プログラム、設計の資料、各種の管理権限の扱いです。次の段階で自社開発や別の会社に切り替えられる状態になるかを確かめます。
- 「この案件で、もっとも不確かだと思う点は何ですか」。危険を先に言葉にできるかどうかで、見積もりの前提をどこまで考えているかが分かります。
会社の種類ごとの向き不向き
外注先にはいくつかの種類があり、それぞれ向いている状況が違います。
- 開発を専門とする会社：要件が比較的固まっていて、作る力を求める場合に向いています。事業の仮説や範囲の判断は、発注側が担う必要があります。
- 戦略の支援を専門とする会社：仮説の整理や検証の計画には向いていますが、開発は別の会社に依頼することになり、計画と実装のあいだで意図が抜け落ちないよう、発注側がつなぐ役割を担います。
- 検証と開発の両方を担う会社：仮説から範囲を決め、作り、結果を見て直すまでを一続きで依頼できます。一方で、体制が小さい場合は、大規模な本開発まで同じ会社で続けられるかを確認します。
- 個人の開発者：小さな範囲を素早く作るのに向いています。担当者が一人であることの危険（病気や多忙で止まる）と、引き継ぎの資料が残るかを確認します。
どれが正しいということはなく、自社に何が足りないかで決まります。事業の仮説を自分たちで整理でき、判断者が時間を使えるなら、開発の専門会社や個人で十分です。自社で作るか既存のサービスを使うかの判断がまだであれば、先に自社開発かSaaSかを差別化と運用負担で決める方法を確認してください。
依頼書の作り方
会社を比べるには、同じ依頼書を各社に渡すことが前提です。口頭の説明だけで見積もりを取ると、会社ごとに受け取り方が違い、提案を比べられません。依頼書には次の内容を書きます。
- 事業の概要と、今回確かめたい仮説
- 対象の顧客と、利用の場面
- 利用者が価値を得るまでの流れ
- 作りたいもの、今回は作らないもの、まだ決められていないこと
- 外部連携、利用者区分、扱う情報の種類
- 希望する時期、予算の目安、発注側の体制（判断者と、使える時間）
- 提案に含めてほしいこと（範囲の絞り方の提案、進め方、体制、内訳、前提条件、引き継ぎの内容）
「まだ決められていないこと」を正直に書くのが要点です。決まっていないことを隠すと、各社は想像で補い、提案の前提がばらばらになります。決まっていないことに対して、どう決めていくかを提案してもらうほうが、その会社の進め方が分かります。
書き込める形のMVP見積依頼書テンプレートを無料で用意しています。見積もりの読み比べ方は見積もりを比べる前に発注の条件をそろえる方法にまとめています。
よくある質問
Q. 何社に声をかけるのがよいですか。
決まった数はありません。各社との面談と提案の読み込みには、発注側の時間がかかります。依頼書を丁寧に作り、種類の違う会社を少数選んで深く話すほうが、多くの会社から浅い提案を集めるより、判断の材料になります。
Q. 付き合いのある既存の開発会社に頼むのは、よくないですか。
よくないとは限りません。自社の業務やシステムを理解している利点があります。確認したいのは、要件が固まっていない仕事の進め方に合わせられるか、という点です。上の質問を同じように投げかけ、範囲を絞る提案や短い間隔での確認に応じられるかを見てください。
Q. 契約の形は、請負と準委任のどちらがよいですか。
範囲が固まっている部分と、変わる前提の部分で、適した形が違います。どちらにするか、あるいは組み合わせるかは、案件の内容と双方の責任の分け方によるため、契約書の具体的な判断は法務の担当者や専門家に確認してください。形より先に、変更の決め方、検収の条件、成果物の扱いを言葉にしておくことが実務では重要です。
Otsumuに相談できること
Otsumuは、新規事業開発のコンサルティングとMVPシステム開発を、戦略と開発を分けずに、構想から運用までひとつのチームで支援する会社です。上の種類でいえば、検証と開発の両方を担う立場にあたります。PoC / MVP Sprintは税別300万円〜、6週間を目安に設計し、検証目的・機能範囲の合意から、検証用のPoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針までを成果物としています。機能数・外部連携・セキュリティ要件で変動し、正式な見積もりは相談後です。秘密保持、成果物の取り扱い、契約・検収の条件は、相談時に確認のうえ合意します。
Otsumuも候補の一社として、この記事の質問をそのまま投げかけてください。合わないと判断された場合や、自社と既存の取引先で進められる場合は、それで問題ありません。30分の無料診断では、依頼書のどこが決まっていないかの整理からお手伝いします。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21