仕様が変わる前提のMVP開発では、準委任契約を選び、「何を作るか」ではなく「何を達成するために、どの体制で、どの期間取り組むか」を契約で決めるのが現実的です。そのうえで、期待する成果（検証できる状態の版を公開することなど）、報告と確認の方法、範囲の変え方、終了条件の四つを、発注者と開発会社の間で文書にしておきます。準委任は完成の責任を負わない契約形態だからこそ、これらを決めておかないと「期間と費用だけが過ぎて、何も公開できなかった」という事態になりかねません。
この記事は、MVP開発を外部の開発会社に依頼しようとしている新規事業の責任者、契約の形を社内で説明する必要がある担当者、開発会社から準委任での契約を提案されて内容を確認したい方に向けたものです。法律の専門的な解説ではなく、事業側が実務で決めておくべきことを中心にまとめています。
読み終えると、MVP開発で準委任契約が選ばれる理由、請負契約との違い、契約で決めるべき項目、期待成果と終了条件の書き方、契約時のチェックリスト、よくある失敗と避け方が分かります。なお、契約の法的な扱いは個別の事情によって異なるため、最終的な契約書の内容は弁護士などの専門家に確認することをおすすめします。
MVP開発で準委任契約が選ばれる理由
システム開発の契約には、大きく分けて請負契約と準委任契約があります。一般的には、請負契約は「仕事の完成」を約束する契約、準委任契約は「業務の遂行」を約束する契約と説明されます。
MVP開発で準委任契約が選ばれることが多いのは、MVPの性質と関係しています。
- 仕様が途中で変わる：MVPは検証のための版です。開発中にテストユーザーの反応を見て、画面や機能を変えることがよくあります。最初に仕様を確定させる請負契約とは相性がよくありません。
- 作るものを事前に確定しにくい：何を作れば仮説を検証できるかが、開発を進めながら明らかになることがあります。
- 変更のたびに契約を見直すと遅くなる：請負契約で仕様を変える場合、追加の見積もりや契約変更が必要になり、短期間の開発では大きな負担になります。
一方で、準委任契約には「完成の責任を開発会社が負わない」という性質があります。発注者にとっては、期間と費用を使っても、期待した成果が得られない可能性があるということです。この点を理解したうえで、成果に近づくための仕組みを契約と運用で作っておくことが大切です。
請負契約と準委任契約の違いについては、請負契約と準委任契約の選び方で詳しく整理しています。
請負契約と準委任契約の違いをMVPの観点で比較する
MVP開発の観点から、二つの契約形態の違いを整理します。
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 約束するもの | 決められた成果物の完成 | 決められた業務の遂行 |
| 仕様の変更 | 変更には追加の見積もりや契約変更が必要になりやすい | 契約の範囲内で柔軟に変更しやすい |
| 費用の決まり方 | 成果物に対して金額を決める | 期間と体制（稼働）に対して金額を決めることが多い |
| 発注者の関わり方 | 仕様を確定させれば、後は確認が中心 | 優先順位の判断など、継続的な関与が必要 |
| 成果が出なかったとき | 完成していなければ、開発会社の責任が問われうる | 業務が適切に行われていれば、成果がなくても費用は発生しうる |
| MVPとの相性 | 範囲が明確で変更が少ない場合に向く | 仕様が変わる前提の検証に向く |
MVPでも、作るものが明確で変更が少ないと見込まれる場合は、請負契約を選ぶこともあります。たとえば、すでに検証済みの仕組みを別の顧客層向けに作り直す場合や、商談用のデモ版を決められた範囲で作る場合などです。また、最初の要件整理だけを準委任で行い、範囲が固まった開発部分を請負にする、という組み合わせもあります。
準委任でMVPを進めるときに契約で決めること
準委任契約でMVP開発を進める場合、契約書や付属の文書で次の項目を決めておきます。
業務の内容と体制
開発会社が行う業務の内容（要件の整理、設計、開発、テスト、公開作業、公開後の改善など）と、担当する人の役割、関わる頻度を決めます。「エンジニア何名」だけでなく、誰がどの役割を担うのか（プロジェクトの管理、設計、開発、デザインなど）を明記しておくと、期待のずれを防げます。
期間と費用
契約の期間と、費用の計算方法を決めます。月ごとの固定額にするか、稼働時間に応じて計算するかなど、方式は開発会社によって異なります。稼働時間に応じて計算する場合は、上限と、上限を超えそうなときの連絡の方法を決めておきます。
期待する成果
準委任は完成を約束する契約ではありませんが、発注者と開発会社が同じ目標に向かうために、期待する成果を文書にしておくことは大切です。詳しくは次の章で説明します。
報告と確認の方法
週ごとの報告の内容、定例の確認の場（頻度、参加者、確認すること）、作業の記録の共有方法を決めます。準委任では、業務が適切に行われているかを発注者が確認できることが重要です。
範囲の変え方
開発中に機能を追加したり外したりするときの手順と、判断する人を決めます。
成果物の権利と引き渡し
ソースコード、設計の文書、各種サービスのアカウントなどの権利が誰に帰属するか、どのような形で引き渡されるかを決めます。MVPの後に別の会社や社内の体制に引き継ぐ可能性があるなら、特に重要です。
終了条件
契約がどのような条件で終わるか、終了時に何を引き渡すかを決めます。
期待成果の決め方：完成ではなく「検証できる状態」を定義する
準委任契約で最も工夫が必要なのが、期待成果の決め方です。請負契約のように「この仕様の成果物を完成させる」とは書けませんが、何も決めないと、発注者と開発会社の間で「どこまでやれば十分か」の認識がずれます。
MVPの場合、期待成果は「検証できる状態」として定義するのが実務的です。たとえば次のような書き方が考えられます。
- 主仮説の検証に必要な主要な流れ（登録から中核機能の利用まで）を、対象の利用者が実際に使える状態で公開する
- 判定指標の計算に必要な行動が、計測として記録されている
- 公開後の一定期間、重大な不具合への対応を行う
- 公開した版のソースコードと、構成や運用の手順をまとめた文書を引き渡す
これらは「完成の保証」ではなく、発注者と開発会社が共有する目標です。契約書の本体に書くか、別紙の業務計画書に書くかは、開発会社や法務担当と相談して決めてください。
期待成果を決めるときは、次の手順で進めるとまとまりやすくなります。
- 検証したい仮説と判定指標を発注者が書く：何を確かめるためのMVPかを、開発会社に伝わる形で書く。
- 主要な流れと機能の範囲を一緒に描く：作るもの・作らないものを、MoSCoW法などで整理する。
- 期間と体制で実現できる範囲かを開発会社が確認する：収まらない場合は、範囲か期間を調整する。
- 期待成果を文章にする：「公開」「計測」「公開後の対応」「引き渡し」の観点で、目指す状態を書く。
- 途中で範囲を変えたときの扱いを決める：期待成果のどの部分が変わりうるか、変わったときにどう合意し直すかを決める。
報告・確認と範囲変更のルール
準委任契約では、発注者が継続的に関わることが前提になります。報告と確認の仕組みを決めておくことで、業務の進み具合と成果への近づき方を確認できます。
週次の報告と確認
週に一度、次の内容を報告してもらい、動く画面を見ながら確認する場を設けます。
- 今週行った作業と、その結果（動く画面で確認する）
- 来週予定している作業
- 期待成果に対する進み具合と、遅れやリスク
- 発注者が判断すべきこと
- 稼働の実績（稼働時間で計算する場合）
報告は資料の作成に時間をかけすぎず、動くものを見ることを優先します。週次の確認の進め方はMVP開発会社との進め方で詳しく説明しています。
範囲を変えるときのルール
準委任契約は仕様の変更に柔軟ですが、無制限に機能を追加すれば、期間内に期待成果に届かなくなります。次のようなルールを決めておくと、変更の議論が短く済みます。
- 範囲の変更は、発注者側の判断者が決める（開発会社の担当者や、発注者側の他の関係者が個別に追加を依頼しない）
- 機能を追加するときは、同程度の工数の機能を外すことを原則にする
- 期間や費用の上限に影響する変更は、文書で合意する
- 変更の内容と理由を記録に残す
仕様変更への対応の考え方は、開発途中の仕様変更にどう対応するかでも整理しています。
準委任でも費用の見通しを立てる方法
準委任契約は、期間と体制に対して費用を払う形が多いため、「最終的にいくらかかるのか分からない」という不安を持たれがちです。費用の見通しを立てるには、次のような工夫が役立ちます。
- 期間と体制から上限を決める：「この体制で、この期間」と決めれば、費用の上限はおおむね計算できます。一般的には、関わる人ごとの稼働量と単価を掛け合わせて算出します。まずは上限を決め、その中で達成できる範囲を考える順番にすると、費用が膨らみにくくなります。
- 段階に分けて契約する：最初に要件の整理と画面の流れの設計だけを短い期間で契約し、その結果を見て開発の段階の契約を結ぶ方法です。最初の段階で範囲と期間の見通しが立つため、開発の段階の費用を判断しやすくなります。
- 途中で判断する時点を決める：期間の半ばに、期待成果に対する進み具合を確認し、範囲を縮小するか、計画どおり進めるかを判断する時点を設けます。
見積もりを比較するときは、総額だけでなく、体制（誰がどの役割で関わるか）、期間、期待成果、公開後の対応の有無を並べて比べます。金額が同じでも、公開後の対応や引き渡しの内容が含まれているかどうかで、実質的な範囲は大きく異なります。
終了条件と引き継ぎの決め方
MVP開発の準委任契約では、終了条件を最初に決めておくことが特に大切です。終了条件が曖昧だと、期間が延長され続けたり、逆に発注者の想定より早く体制が縮小されたりします。
終了条件として考えられるのは、次のようなものです。
- 契約期間の満了
- 期待成果の達成（検証できる状態での公開と、公開後の対応期間の終了）
- 検証の結果、事業の方向を変える、または中止すると発注者が判断した場合
- どちらかが一定の予告期間をもって終了を申し出た場合
あわせて、終了時に引き渡すものを決めておきます。ソースコード（リポジトリの権限の移管を含む）、設計や構成の文書、インフラや外部サービスのアカウント、運用の手順、既知の不具合や今後の課題の一覧などです。
MVPの後に社内で開発を引き継ぐ場合や、別の開発会社に依頼する場合に備え、引き継ぎの期間を設けておくことも検討します。引き継ぎの進め方はMVPを外注から内製へ引き継ぐで詳しく扱っています。
MVP開発の契約でよくある失敗と避け方
失敗1：準委任なのに発注者が関与しない
準委任契約を結んだあと、開発会社に任せきりにして、週次の確認にも参加しない失敗です。優先順位の判断が行われず、開発会社が推測で進めた結果、検証に使えない版ができあがります。避け方は、発注者側の判断者を決め、週次の確認に必ず参加することです。
失敗2：期待成果を決めずに契約する
「MVPを作る」とだけ書いて契約し、期間の終わりに発注者は「公開まで」、開発会社は「開発作業まで」と考えていたことが分かる失敗です。避け方は、公開、計測、公開後の対応、引き渡しの観点で期待成果を文書にすることです。
失敗3：ソースコードやアカウントの権利を確認していない
開発会社のアカウントでサーバーや外部サービスを契約していて、契約終了後に移管に時間がかかったり、移管できなかったりする失敗です。避け方は、主要なアカウントは発注者の名義で作るか、移管の方法を契約時に決めておくことです。
失敗4：稼働時間の上限を決めていない
稼働時間に応じて費用を計算する契約で、上限を決めておらず、想定以上の費用が発生する失敗です。避け方は、月ごとの上限と、上限に近づいたときの連絡のルールを決めておくことです。
失敗5：終了条件を決めずに延長を繰り返す
「もう少しで公開できる」という状態が続き、契約の延長を繰り返す失敗です。避け方は、終了条件と、延長を判断する基準（範囲を縮小してでも公開するか、など）を最初に決めておくことです。
失敗6：公開後の対応を契約に含めていない
契約期間の終わりと公開日が重なり、公開直後に見つかった不具合や利用者からの問い合わせに対応できる体制が残っていない失敗です。MVPは公開直後に修正が必要になることが多く、その時期に開発会社が離れてしまうと検証の質が下がります。避け方は、公開後の一定期間を契約期間に含め、その期間に行う対応の範囲（重大な不具合の修正、軽微な画面の修正など）を決めておくことです。
MVP開発の契約チェックリスト
- 請負と準委任のどちらが自社のMVPに合っているかを検討した
- 業務の内容と、担当者の役割・関わる頻度が明記されている
- 期間、費用の計算方法、稼働の上限が決まっている
- 期待成果が「検証できる状態」として文書になっている
- 週次の報告の内容と、確認の場の頻度・参加者が決まっている
- 範囲を変えるときの判断者と手順が決まっている
- ソースコード、文書、アカウントの権利と引き渡しの方法が決まっている
- 終了条件と、終了時に引き渡すものが決まっている
- 秘密保持の範囲と期間を確認した
- 契約書の内容を、必要に応じて専門家に確認した
具体的な場面で考える：架空の地域向け予約サービスの例
架空の例として、地方の観光協会が、地域の体験プログラムをまとめて予約できるサービスのMVPを、外部の開発会社に依頼する場面を考えます。
当初、観光協会は請負契約で依頼しようと考え、思いつく機能をすべて盛り込んだ要件書を作りました。しかし開発会社との打ち合わせで、検証したいのは「観光客が複数の体験をまとめて予約するか」「地域の事業者が予約の受付を任せるか」の二点であり、要件書の多くの機能はその検証に直接関わらないことが分かりました。また、事業者の反応によって予約の流れが変わる可能性も高いと判断しました。
そこで、三か月の準委任契約とし、期待成果を「体験の一覧と予約の流れを、対象地域の数事業者の体験で実際に使える状態で公開する」「予約の完了と事業者の確認の行動を計測する」「公開後一か月の不具合対応を行う」「ソースコードと運用手順を引き渡す」と定めました。週次の確認には観光協会の担当者が必ず参加し、範囲の変更は担当者一人が判断することにしました。
開発中、事業者から「予約の受付は電話でも併用したい」という声があり、事業者向けの管理機能の一部を外して、予約の通知をメールで送る仕組みに入れ替えました。期待成果に照らして判断できたため、変更の議論は短時間で済みました。
よくある質問
Q. 準委任契約だと、開発会社が手を抜くのではないかと不安です。
準委任契約でも、開発会社には業務を適切に行う義務があります。そのうえで、週次の報告と動く画面での確認、期待成果に対する進み具合の共有を仕組みにしておけば、業務の質を確認しやすくなります。
Q. ラボ型開発とは何が違いますか？
ラボ型開発は、一定期間、専属の体制を確保して開発を進める形態を指すことが多く、契約形態としては準委任に近いものが一般的です。呼び方は開発会社によって異なるため、契約の中身（業務内容、期間、体制、成果物の扱い）を確認してください。
Q. 成果報酬型で依頼することはできますか？
事業の売上に応じて開発会社に報酬を支払う形などもありますが、成果の定義や事業のリスクの分担など、検討すべき点が多くあります。注意点は開発会社とのレベニューシェアで整理しています。
Q. 契約書のひな形は開発会社のものを使ってもよいですか？
使っても構いませんが、期待成果、範囲の変え方、成果物の権利、終了条件など、この記事で挙げた項目が自社の意図どおりに書かれているかを確認してください。判断に迷う点は、弁護士などの専門家に相談することをおすすめします。
Otsumuに相談できること
社内に契約の確認ができる法務担当者がいて、検証したい仮説と判定指標が明確で、発注者側の判断者が週次の確認に参加できるなら、この記事の項目に沿って自社で開発会社と契約の内容を詰めていけます。期待成果と終了条件を文書にするだけでも、契約後のすれ違いは大きく減ります。
一方で、何を期待成果にすればよいか分からない、開発会社の提案する契約の内容が妥当か判断できない、範囲と期間の見通しが立たない、といった場合は、事業と開発の両方を理解している相手と一緒に整理すると、契約前の段階で多くの問題を防げます。
Otsumuは、自らも事業を手がける立場から、目的から逆算して範囲と期待成果を決める進め方を大切にしています。新規事業の爆速MVPシステム開発では、仮説の整理と範囲の決定から、AIを活用した少人数・短期間の開発、公開後の改善まで一気通貫で支援します。期間と範囲を決めて進める形として、6週間を目安に設計するPoC / MVP Sprint（300万円〜、税別・参考価格）もご用意しています。秘密保持や契約条件は、相談時に確認のうえ合意します。
契約の形に迷っている段階でも構いません。30分の無料相談で、検証したいことと進め方のご希望をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01