基本は「成果物がどこまで明確か」で決まる
開発会社との契約で最初にぶつかる分岐が、請負契約にするか準委任契約にするかです。どちらも個人が開発を発注するときに知っておきたい契約の基本（請負・準委任）で扱われる話ですが、ここでは「結局どっちを選べばいいのか」という一点に絞って整理します。
判断の軸はシンプルです。発注する時点で、成果物の仕様がどこまで固まっているか。
- 画面数・機能一覧・受け入れ条件まで具体的に決められる → 請負が向く
- 「まず動くものを作りながら仕様を詰めたい」段階 → 準委任が向く
自己資金300万円という限られた予算で開発するとき、この選択を誤ると「思っていた金額で終わらない」「言った言わないでもめる」といった事態につながります。契約形態は法律用語ですが、中身は「誰が完成責任を負うか」「支払いは成果物ベースか稼働ベースか」という、お金と責任の配分ルールだと捉えると理解しやすくなります。
請負が向くケース
請負契約は、完成した成果物を納品して初めて報酬が発生する契約です。開発会社側が「完成させる義務」を負うため、発注者にとっては見通しが立てやすいのが利点です。
以下に当てはまるなら、請負が現実的な選択肢になります。
- MVPで実装する機能がすでに絞り込めている（画面遷移図や機能一覧が書ける状態）
- 開発期間が明確に区切れる（例: 2〜3ヶ月で公開まで）
- 途中で仕様が大きく変わる可能性が低い
特に、専門知識を土台にしたツールで「業務フローがすでに自分の頭の中で完成している」場合は、それを開発会社に伝えられれば請負に向きます。仕様が固まっているほど、開発会社側も見積もりの精度を上げやすく、結果として予算300万円で、現実的にどこまでの機能が作れるかという話もしやすくなります。
一方で、請負は「仕様変更＝追加契約」になりやすい契約でもあります。契約後に「やっぱりこの機能も」と思いついても、追加費用や納期の見直しが発生する前提で臨む必要があります。
準委任が向くケース
準委任契約は、成果物の完成ではなく「業務を遂行すること」自体に対して報酬を支払う契約です。開発会社は稼働した時間や労力に対して報酬を受け取り、完成責任そのものは負いません。
以下に当てはまるなら、準委任のほうが実態に合います。
- アイデアの検証段階で、仕様が固まりきっていない
- ユーザーの反応を見ながら機能を変えていきたい
- 開発会社と伴走しながら、要件そのものを一緒に作っていきたい
とくに、まだ固まっていないアイデアを、開発会社にどう伝えるかという段階、つまり仮説検証中のプロダクトでは、最初から請負で仕様を固定してしまうと、変化に対応するたびに追加契約が必要になり、かえって割高になることがあります。準委任なら「今月はこの機能を検証する」という単位で稼働を調整しやすく、小さく検証しながら進める複業・小予算検証型の進め方とも相性がよい契約形態です。
ただし準委任は「完成する保証がない」契約でもあります。稼働に対して払い続ける形になるため、進捗の可視化やマイルストーンの合意を、契約と別に必ずセットで行う必要があります。
迷ったときの相談の仕方
実際には、MVP開発の中でも「コア機能は仕様が固まっているが、周辺機能はまだ流動的」というケースが大半です。この場合、無理にどちらか一本に決めようとせず、開発会社に次のように相談するのが現実的です。
- 固まっている部分と、まだ流動的な部分を分けて伝える
- 「コア機能は請負、追加検証部分は準委任」のように契約を分割できないか聞く
- 分割が難しい場合、準委任で始めて、仕様が固まった時点で請負に切り替えられないか確認する
良心的な開発会社であれば、この相談自体を嫌がりません。むしろ「まだ仕様が固まっていないのに請負で契約したがる」会社のほうが、危険な開発会社のサインに近いと考えたほうがよいでしょう。契約形態を巡るやり取りは、そのまま開発会社を見極める材料にもなります。
詳細はコラムへ
契約書の具体的な条項や、見積もりの内訳の読み方といった実務の詳細は、この記事では扱いきれません。契約書で必ず確認したい条項（知的財産権・検収・保守）や見積書の内訳（工数・単価・バッファ）の読み方に譲ります。ここで押さえておきたいのは、「請負か準委任か」は良し悪しの問題ではなく、あなたのアイデアが今どの段階にあるかを映す鏡だということです。仕様が固まっていないのに請負を選んでも、固まっているのに準委任でだらだら進めても、どちらも予算を無駄に消耗します。今の段階を正直に見極めることが、最初の一歩になります。