MVP開発会社の選び方 ― 検証の設計ができる会社を見分ける5つの基準

MVP（検証用の最小限の製品）の開発を外部に頼もうとすると、会社の数は多いのに、何で比べればよいかが分かりにくい。規模、価格、実績の数。比べやすい項目で選ぶと、MVPに必要な「検証の設計」ができる会社かどうかが見えないまま契約することになる。

この考え方を広めたエリック・リースは、MVPを「最小の労力で、顧客についての検証による学びを最大限に得られる新製品のバージョン」と定義している。目的は製品を小さくすることではなく、学ぶことだ。MVP開発とは何かとPoCとの違いは別の記事にまとめたので、ここでは外注先の選び方に絞る。

この記事では、外注する前に確かめる5つの基準を、初回の打合せで聞くことと答えの見本まで含めて整理した。費用が変わる条件、権利と名義、会社のタイプも扱う。当社がプロジェクト管理ツール「projectAI」を自社で作り、お客様の新規サービスを立ち上げてきた経験をもとにしている。

MVP開発で起きやすい失敗

MVPの失敗は、技術より発注の段階で決まることが多い。よくあるのは次の三つだ。

• 機能一覧から見積もりを取り、検証に要らない機能まで作ってしまう。
• 公開して終わりになり、利用者の反応を見て直す体制がない。
• 追加や本番化の費用が最初に決まっておらず、途中で膨らむ。

事業が止まる理由を見ても、作り込みより「求められているか」が先に来る。CB Insightsが2023年以降に事業を止めたVC出資企業431社を分析した調査では、最多の資金切れ（70%）は最後の死因であって根本の原因ではないとされ、市場に合う製品を作れなかったこと（43%）が、より示唆的な原因に挙げられている。

MVP開発会社を選ぶ5つの基準と、初回の打合せでの答え

基準ごとに、初回の打合せで聞くことと答えの見本を挙げる。見本は当社の見方である。

1. 仮説と検証指標から話を始めるか

• 聞くこと。何を確かめるMVPか。何が分かれば続けるのか。
• 良い答え。仮説を一文で言い直し、見る数字を2〜3個挙げ、続ける・直す・やめるの基準を公開前に決めようと言う。
• 危険な答え。「まず機能一覧をください」「基準は公開してから一緒に見ましょう」。

2. 機能を減らす提案があるか

• 聞くこと。外せる機能はどれか。作らずに確かめる方法はあるか。
• 良い答え。機能名を挙げて、仮説の判定に要らない理由を言う。認証、個人情報、決済の保護は削らないと言う。
• 危険な答え。「ご要望どおり全部入れられます」「MVPなのでセキュリティは後で」。

3. 費用が変わる条件が明確か

• 聞くこと。費用が変わるのはどんなときか。本番化はいくらの見込みか。
• 良い答え。追加、方向転換、本番化の三つを契約の形ごとに説明し、本番化の概算と前提を書面に残す。
• 危険な答え。「その都度お見積もりします」「本番化は作ってから考えましょう」。

4. 公開後も続けられ、いつでも移れる状態にするか

• 聞くこと。公開後は誰が続けるのか。別の会社に移るなら何を受け取れるのか。
• 良い答え。担当者と体制を具体的に言い、コード、名義、資料、データを渡す条件をその場で言う。
• 危険な答え。「保守は別チームです」「アカウントは当社名義で取ります」。

MVPを作った会社が本開発にも合うとは限らない。同じチームで続けられることと、いつでも移れることは、両方そろえておく。

5. 同じ型の検証の実績があるか

• 聞くこと。同じ型の検証で、何を外し、何を測り、どう判断したか。
• 良い答え。需要、継続利用、業務への適合、技術的な実現性のどれを確かめた事例かを言い、外した機能と見た数字まで話す。
• 危険な答え。「同じ業界の実績が何件あります」「公開しました」で終わる。

検証の設計を一枚に書くと

検証の設計は、難しい資料ではない。次の五つが埋まっていれば足りる。説明用の例で、基準の数字に根拠はない。

• 仮説。電話で予約している教室の保護者は、スマホの予約に切り替える。
• 相手と期間。既存の1教室の保護者、公開から4週間。
• 見る数字。スマホ経由の予約の割合、2回目の予約の有無、電話の件数。
• 判断。5割以上で続ける、2〜5割で導線を直す、2割未満でやめる。
• 作らないもの。決済、通知の細かい設定、管理者の権限分け。

打合せでこの五つを一緒に埋められる会社なら、検証の設計ができると見てよい。

費用の決まり方と、費用が変わる条件

MVPに限った中立の統計は、探した範囲では見つからなかった。公開されている相場は書き手によって前提が違うので、金額だけを並べても比べられない。金額を動かすのは画面の数、利用者の立場の数、外部サービスとの連携、スマホアプリの有無、公開後の運用の範囲といった前提だ。考え方はMVP開発の費用の節に詳しく書いた。

金額より先に見るのは、費用が変わる出来事である。契約の形で扱いが変わる。

仕様が動くMVPでは準委任が基本になる。経済産業省とIPAのアジャイル開発版モデル契約も、固定対価の請負には追加や変更を抑える動機が生じうるとして、準委任を前提にしている。ただし準委任は、期間を延ばせば費用が増える。成果物と期限を固定できる範囲なら請負も選べる。

権利と名義の確認

引き継ぎで止まりやすいのは、技術より権利と名義だ。契約の前に、次の六つを書面で確かめる。

• ソースコードの著作権の帰属。
• コードを置く場所（リポジトリ）の所有者。
• ドメイン、サーバー、アプリストアの名義。
• 決済、メール、分析など外部サービスの契約名義。
• 利用データの持ち出し。
• 渡される設計資料と構成図の範囲。

著作権を譲り受ける契約では、著作権法61条2項により、翻案などの権利（27条・28条）は明記しないと譲渡した側に残ると推定される。「著作権を譲渡する」の一文で済ませず、条文まで書かれているかを見る。契約全体の確認点は受託開発とはにまとめている。

会社のタイプ別の向き不向き

MVP開発を掲げる会社は、進め方でおおむね4つのタイプに分かれる。費用の形にも傾向があるので、タイプで当たりをつけてから打合せで確かめるのが現実的だ。

• 大手一括型。企画から本開発までを一社で進める。大企業の新規事業に向く。請負の見積もりが多いので、MVPの段階で範囲を絞る提案が出るかを確かめる。
• 新規事業支援型。事業の構想や検証の設計から入る。社内に開発の相手がいない事業部門に向く。準委任や月額が多く、本開発を別の会社に渡す前提のこともある。
• 少人数高速型。ノーコード専門の会社や個人を含む。小さく出して早く判断したいスタートアップに向く。本番化で作り直しになるか、公開後の体制があるかを最初に確かめる。
• 共創型。発注者と受注者ではなく、同じチームとして事業を立ち上げる。事業の成否を一緒に負う相手を探している企業に向く。成果に連動した費用の形を含むことがあり、対象と条件を確かめる。

どのタイプを選ぶかは、MVPの後をどうしたいかで決まる。

当社がMVPを共創型で進める理由

当社は、MVPを「作って納める仕事」にしないために、共創型で進めている。毎週動くものを見ていただき、優先順位と作らないものをその場で一緒に決める。決めたことはお客様と同じ画面で見られるプロジェクト管理の仕組みに記録するので、後から経緯を追える。

費用の形は案件で異なる。事業の立ち上げでは、導入までの費用をいただかず、公開後に月額とレベニューシェアでいただく形をとることもある。それが成り立たない場合は、お見積もりで進める。

実例を三つ挙げる。

• Q&Aサービス「Question Market」は、仮説の検証に必要な機能だけに絞り、構想から約3か月で公開した。
• 入試マッチングサービス「年内入試ナビ」は、公開後も同じチームで、生成AIを使った機能を段階的に足している。運営会社の発表では利用者数が前年比11倍に伸びた。
• 少年サッカークラブの会員管理システムは、基盤を数日で組み、現場の要望20件超を約1か月で取り込んだ。

他の事例は新規事業・スタートアップの開発事例に、進め方はMVP開発・PoC開発に、本開発まで続ける場合はシステム開発にまとめている。

よくあるご質問

MVP開発を外注するメリットとデメリットは？

メリットは、開発の体制を持たなくても検証を始められることだ。デメリットは、判断まで任せると学びが社内に残らないことで、仮説と判断は自社で持つ必要がある。

MVP開発の費用はいくらですか？

MVPに限った中立の統計は見当たらない。金額は画面の数や外部連携などの前提で動くので、前提をそろえて見積もりを比べる。当社では、無料の見積もり相談で前提を整理してお伝えする。

大手と小規模の会社、どちらに頼むべきですか？

MVPの後をどうしたいかで分かれる。本開発まで同じ会社なら大手一括型、小さく出して早く判断するなら少人数高速型、事業の成否を一緒に負う相手を探すなら共創型が合う。

契約は請負と準委任のどちらが良いですか？

仕様が変わる前提のMVPでは準委任が多い。成果物と期限を固定できる範囲なら請負でもよい。どちらでも、費用が変わる条件と成果物の権利は最初に確認する。

MVPだけ頼んで、その後を別の会社にできますか？

できる。ただし、コードと設計資料、各サービスの名義、権利の帰属を最初に決めておかないと、引き継ぎで止まる。

まとめ

MVP開発会社を選ぶときに見るのは、規模や価格よりも、検証の設計ができるかどうかだ。仮説から入り、機能を減らす提案があり、費用が変わる条件と権利の扱いを先に言える会社ほど、MVPが「作って終わり」になりにくい。

初回の打合せで5つの基準を聞き、答え方で会社を見分ける。当社も同じ5つにその場で答えるので、無料の見積もり相談で担当PMに聞いていただきたい。進め方を先に相談したい場合はお問い合わせから受け付けている。

関連する記事とページ

• MVP開発とは何か ― 進め方、費用の考え方、PoCとの違い
• PoCとMVPの違いとは ― 目的・期間・進め方の比較
• 共創でつくる、が意味するもの ― 発注者と受注者をやめると開発はどう変わるか
• 受託開発とは何か ― 契約の形と、発注前に決めておくこと
• MVP開発・PoC開発 ― 新しいサービスを小さく始めて確かめる
• 無料の見積もり相談 ― 担当PMと話すだけで内容と費用感がわかる

出典

• Eric Ries「Minimum Viable Product: a guide」2009年8月3日
• CB Insights「The top 9 reasons startups fail」2026年3月5日
• 独立行政法人情報処理推進機構・経済産業省「アジャイル開発外部委託モデル契約（解説付き）」2020年3月31日（2025年4月改訂）
• e-Gov法令検索「著作権法（昭和四十五年法律第四十八号）」