開発を発注する際、契約書に「請負契約」あるいは「準委任契約」という言葉が出てくることがあります。この違いを理解せずに契約すると、後から「思っていたのと違う」というトラブルにつながることがあります。この記事では、個人が開発を発注する際に知っておきたい、請負契約と準委任契約の基本を解説します。
この記事で分かること
請負契約と準委任契約は、どちらもシステム開発の契約形態ですが、責任の範囲や適した場面が異なります。この記事では、それぞれの特徴と、自分のケースでどちらが向いているかの判断基準を紹介します。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- 請負契約は「完成させる」ことを約束する契約
- 準委任契約は「業務を遂行する」ことを約束する契約
- 仕様が固まっているかどうかで、向き・不向きが分かれる
個人で複業・スピンオフのサービスを立ち上げる場合、契約書を細かく読み込む時間も、法務の専門知識も十分にないことが多いはずです。それでも「請負」と「準委任」という2つの言葉の意味だけは理解しておくと、開発会社との会話が一気に噛み合うようになります。逆にこの区別を知らないまま契約すると、「完成するはずだと思っていたのに、時間で契約が切れて終わった」「途中で仕様を変えたら追加費用を請求された」といった、双方にとって不本意な行き違いが起きやすくなります。
請負契約とは何か
請負契約は、発注者が指定した仕様通りの成果物を、完成させることを開発会社が約束する契約です。「完成」が契約の目的であるため、途中で仕様が変わらない前提であれば、発注者にとって分かりやすい契約形態です。
MVP開発など、あらかじめ機能の範囲が明確に決まっている場合、請負契約が向いています。完成した成果物を、決められた金額で受け取れるという安心感があります。
請負契約の大きな特徴は、開発会社が「仕事の完成」について責任を負う点です。仮に予定より工数がかかってしまったとしても、原則として、契約時に決めた金額のまま完成させる義務があります（発注者側の追加要望による範囲拡大は別）。この「完成保証」に近い性質があるからこそ、発注者は「決めた金額で、決めた機能が手に入る」という前提で予算計画を立てやすくなります。
一方で、請負契約には「仕様が固まっていることが前提」という制約もあります。契約後に「やっぱりこの機能も欲しい」「この画面の動きを変えたい」という要望が出てくると、それは当初の契約範囲外の追加作業とみなされ、追加費用や追加期間が発生することが一般的です。つまり、請負契約の安心感は、裏を返せば「最初に決めたことを変えにくい」という制約でもあります。
請負契約が向いているケースの具体例
- 個人で複業として始める予約管理アプリで、画面数・機能一覧・入力項目までワイヤーフレームに書き出せている
- 店舗のオペレーションを想定した業務ツールで、現場の作業フローがすでに固定化されており、変わる見込みが薄い
- 既存の紙の業務やExcel運用を、そのままデジタル化するだけの案件で、新規に発生する判断要素が少ない
これらのケースでは「何を作るか」がすでに明確なので、請負契約で「いつまでにいくらで完成させるか」を固定するメリットが大きくなります。
準委任契約とは何か
準委任契約は、成果物の完成そのものではなく、一定の業務を遂行することを約束する契約です。仕様がまだ固まりきっていない開発や、公開後の保守・運用業務でよく使われます。
準委任契約では、「完成」を約束するものではないため、開発の途中で要望が変わっても、柔軟に対応しやすいという特徴があります。ただし、その分、最終的にどこまでの機能が実現するかが、契約時点では明確でないという側面もあります。
準委任契約は「善良な管理者の注意をもって業務を遂行する義務（善管注意義務）」を負う契約であり、「完成させる義務」を負う請負契約とは、責任の性質そのものが異なります。開発会社は、専門家として適切な進め方をする義務は負いますが、「必ずこの機能が動く状態まで仕上げる」という完成の保証はしません。この点を理解していないと、「準委任契約なのに、思っていた機能が全部完成しなかった」という不満が生まれやすくなります。
準委任契約が向いているケースの具体例
- サービスの方向性は決まっているが、画面構成や機能の細部はまだ発注者自身も固めきれていない
- MVPを検証しながら、ユーザーの反応を見て機能を調整していきたい
- 公開後の保守・運用フェーズで、不定期に発生する改修や問い合わせ対応を依頼したい
- 専門分野の業務知識を反映するツールで、要件が開発会社との対話の中で徐々に具体化していく
準委任契約は、時間単位・月単位の稼働に対して費用が発生する「時間契約」に近い形で運用されることが多く、契約書にも「本契約に基づく業務は、成果物の完成を目的とするものではない」といった一文が明記されているのが一般的です。この一文があるかどうかは、契約書を確認する際の分かりやすい目印になります。
請負と準委任、どちらが安いのか・どちらが高くつくのか
「請負のほうが安心だから、いつも請負にすればいい」というわけではありません。仕様が固まっていない状態で請負契約を結ぶと、開発会社側は「仕様変更のリスク」をあらかじめ見積もりに含めるため、見積金額が高くなりがちです。逆に、仕様が固まっている状態で準委任契約を結ぶと、時間単価の積み上げになるため、想定より稼働がかかった場合に総額が膨らむリスクがあります。
つまり、「契約形態そのもの」に安い・高いの優劣はなく、「自分の状況にどちらが合っているか」で、結果的にトータルコストが変わってくるという捉え方が実態に近いです。仕様が固まっていないのに請負を選ぶと、見積もりに含まれる「仕様変更バッファ」の分だけ割高になり、仕様が固まっているのに準委任を選ぶと、本来固定できたはずの金額が稼働時間に応じて変動するリスクを抱えることになります。見積書の内訳（工数・単価・バッファ）の読み方については、別記事で詳しく解説しています。
なお、見積もりの中には保守・サポートの範囲や期間も含まれていることが多く、この部分を契約前に確認しておくことも同じくらい重要です。特に既存システムを使い続ける前提の案件では、契約時に確認すべきサポート期限の考え方も参考になります。
どちらを選ぶべきか：仕様が固まっているかどうか
請負契約と準委任契約、どちらを選ぶべきかの最も基本的な判断基準は、開発を始める時点で、仕様がどれだけ固まっているかです。
自分の作りたいものが、機能や画面のイメージまで具体的に決まっている場合は、請負契約が適しています。一方、「作りたい方向性はあるが、細部はこれから開発会社と一緒に決めていきたい」という場合は、準委任契約のほうが柔軟に進めやすくなります。
自分でチェックできる簡易判断リスト
以下の項目に、いくつ「はい」と答えられるかで、大まかな目安がつきます。
- 画面の数と、それぞれの画面でできることを箇条書きで書き出せる
- ユーザーがサービスに登録してから使い終わるまでの流れを、順番に説明できる
- 「これは今回作らない」という機能の範囲も、はっきり決めている
- 開発期間中に、仕様を大きく変える予定がない
4つとも「はい」と言える場合は、請負契約で進めやすい状態です。2つ以下しか「はい」と言えない場合は、準委任契約で仕様を固めながら進めるほうが、結果的にスムーズです。3つ程度で迷う場合は、次に紹介する「途中で切り替える」進め方を検討する余地があります。
契約形態が、途中で変わることもある
最初は準委任契約で仕様を固めながら進め、仕様が明確になった段階で、残りの開発を請負契約に切り替える、という進め方も現実的です。特に、MVPの検証段階では仕様が固まっていないことが多いため、この組み合わせは、非エンジニアにとっても扱いやすい進め方です。
開発会社に相談する際、この組み合わせの可能性についても、確認してみることをおすすめします。
この「準委任→請負」の切り替え型は、実務ではよく使われるパターンです。最初のフェーズ（要件定義・仕様の具体化）を準委任契約で進め、成果物として「仕様書」や「画面設計書」を確定させます。その仕様書をもとに、次のフェーズ（実装・テスト・リリース）を請負契約として別途契約する、という2段階の進め方です。この方法であれば、「仕様が固まっていないのに請負契約を結んでしまい、後から揉める」というリスクを避けながら、最終的には「完成の保証」というメリットも得られます。
逆に、「請負→準委任」の切り替え、つまり、いったん完成した成果物を、その後の保守・運用フェーズで準委任契約に移行するというパターンも一般的です。公開後の運用は、不定期な改修や問い合わせ対応が中心になるため、完成を約束する請負契約ではなく、稼働に応じた準委任契約のほうが実情に合っています。
個人が発注する際、契約書で確認すべきこと
契約形態がどちらであっても、契約書には次の点を確認しておくことをおすすめします。
- 納品物の範囲（ソースコード・設計書などが含まれるか）
- 検収の基準（何をもって完成とするか）
- 知的財産権の所在（作られたものの権利は誰のものか）
- 契約不適合責任（納品物が契約内容と異なっていた場合の対応）
これらの点は、契約形態にかかわらず確認すべき基本的な内容です。契約書で必ず確認したい条項（知的財産権・検収・保守）については、別記事でも詳しく解説しています。
よくある失敗パターンとその防ぎ方
個人が発注者として契約書を確認する際、実際によく見られる失敗パターンを紹介します。
失敗パターン1: 「検収基準」が書かれていない、または曖昧なまま契約してしまう
請負契約では、「何をもって完成とするか」が明確でないと、発注者と開発会社の間で「完成した」の認識がずれてしまいます。「動作すること」だけが基準になっていると、見た目の細部やユーザー体験の質については、後から「それは完成の定義に入っていない」と言われてしまう可能性があります。検収基準は、できるだけ具体的な項目リストの形で、契約書または別紙の仕様書に落とし込んでもらうことをおすすめします。
失敗パターン2: 準委任契約なのに「完成」を期待してしまう
準委任契約は業務遂行を約束するものであり、完成を保証するものではありません。しかし、発注者側が「準委任契約でも、最終的にはちゃんと動くものが仕上がるはず」と暗黙に期待してしまい、契約期間が終わった時点で「思っていたものができていない」と感じるケースがあります。準委任契約で進める場合は、「今回の契約期間で、どこまで進める予定か」を、開発会社とこまめに確認し合う姿勢が重要になります。
失敗パターン3: 知的財産権の帰属を確認せず、後から「使えない」と気づく
開発してもらったソースコードやデザインの著作権が、契約書上、開発会社側に残る条項になっているケースもあります。個人での複業・自社サービスとして育てていきたい場合、著作権や利用権が自分（発注者）に帰属するのか、それとも開発会社に留保されるのかは、事業の継続性に直結する重要な確認事項です。
失敗パターン4: 「口約束」で仕様変更を積み重ねてしまう
契約形態にかかわらず、メールやチャットでの「ちょっとこれも追加でお願いします」という依頼を繰り返してしまうと、後から「どこまでが契約範囲内だったか」が分からなくなります。仕様の変更や追加が発生した場合は、都度、書面（メールでも構いません）で記録を残しておくことをおすすめします。
専門知識を活かしたツールの場合、契約形態の選び方
専門分野の業務知識を反映したツールを開発する場合、仕様が固まりきっていないことが多く、準委任契約から始めることをおすすめします。専門的な要件は、開発会社との対話を重ねながら、少しずつ具体化していくことが多いためです。
要件が十分に固まった段階で、残りの開発を請負契約に切り替える、という進め方を検討することをおすすめします。
たとえば、士業や医療・介護などの専門職の方が、自分の業務知識をもとにした業務支援ツールを作る場合、その業界特有の判断基準やルールを、開発会社が最初から正確に理解することは難しいのが実情です。最初の数週間〜数ヶ月を準委任契約とし、専門知識の共有や画面のプロトタイピングを繰り返しながら仕様を固め、その後、確定した仕様書をもとに請負契約へ切り替える、という進め方が現実的です。専門用語が多い業界の場合は、事前に用語集を渡しておくと、開発会社との対話がさらにスムーズになります。
契約形態を、開発会社に確認する際の伝え方
契約形態について自分から詳しく理解していなくても、開発会社に「この開発は、請負契約と準委任契約、どちらが向いていると思いますか。その理由も教えてください」と聞いてみることをおすすめします。
丁寧に理由を説明してくれる開発会社であれば、契約形態への理解も深く、信頼して進めやすい相手だと判断できます。逆に、契約形態についての説明が曖昧、あるいは一方的に決められてしまう場合は、契約内容について、より慎重に確認する必要があります。
質問の仕方としては、次のような聞き方も有効です。
- 「今回の仕様は、請負契約で進めるにはどのくらい固まっている状態だと思いますか」
- 「途中で準委任から請負に切り替える進め方は可能ですか。その場合、どのタイミングで切り替えるのが一般的ですか」
- 「検収の基準は、契約書のどの部分に、どのくらい具体的に書いていただけますか」
これらの質問に対して、具体的かつ根拠のある回答が返ってくるかどうかは、その開発会社が契約実務に慣れているかどうかを見極める、簡易的な指標になります。
個人フリーランスへの発注でも、契約形態は同じように考える
開発会社だけでなく、個人フリーランスへ発注する場合も、請負契約・準委任契約の考え方は同じように適用されます。個人だからといって、契約書を作成せずに口約束だけで進めることは避けるべきです。
個人フリーランスへの発注であっても、この記事で紹介した契約書の確認ポイントは、同様に適用されます。個人開発者への発注については、開発会社を見極めるために、提案書で見るべきポイントでも詳しく解説しています。
フリーランスへの発注では、開発会社と比べて契約書のフォーマットが用意されていないことも多く、発注者側が契約書のひな形を用意する、あるいは簡易な契約書テンプレートを一緒に確認する、という進め方になる場合があります。この場合も、「請負か準委任か」「検収基準」「知的財産権の帰属」「契約不適合責任」の4点は、必ず書面に残しておくことをおすすめします。
具体例で比較する：同じ「予約管理アプリ」でも契約形態で進め方が変わる
抽象的な説明だけでは分かりにくいため、同じ「個人経営の店舗向け予約管理アプリを作りたい」という相談を例に、請負契約と準委任契約でどう進め方が変わるかを比較してみます。
ケースA：仕様がほぼ固まっている状態で相談したパターン
すでに「予約カレンダー画面」「顧客情報の登録画面」「当日の予約一覧を確認する画面」の3画面が必要で、それぞれの入力項目まで書き出せている状態で開発会社に相談したケースです。この場合、開発会社は要件定義の手間が少なく、見積もりを出しやすいため、請負契約で「3ヶ月・総額いくら」という形で契約を結びやすくなります。発注者側も、完成時期と総額が事前に分かるため、資金計画が立てやすくなります。
ただし、開発が進む中で「やっぱり予約のキャンセル機能も欲しい」と気づいた場合、それは契約時点の仕様に含まれていないため、追加費用・追加期間の相談が必要になります。請負契約は「決めたことを守る」契約なので、決めていなかったことは原則、別料金になるという点を理解しておく必要があります。
ケースB：方向性は決まっているが、細部が固まっていない状態で相談したパターン
「予約管理をデジタル化したい」というところまでは決まっているものの、「そもそも電話予約とオンライン予約を両方受け付けるべきか」「顧客情報をどこまで詳しく管理するか」といった細部が固まっていない状態で相談したケースです。この場合、いきなり請負契約を結ぶと、開発会社は「仕様がまだ変わる可能性がある」というリスクを見積もりに含めるため、想定より高い見積もりが出てくることがあります。
このケースでは、まず1〜2ヶ月程度の準委任契約で、開発会社と一緒に仕様を固める期間を設けるほうが合理的です。この期間中に、画面のワイヤーフレームや機能一覧が確定したら、その時点で残りの実装作業を請負契約に切り替える、という2段階の進め方が現実的です。
ケースC：公開後の運用・改修フェーズ
すでにアプリを公開しており、月に数件、軽微な改修や問い合わせ対応が発生するというケースです。この場合、毎回小さな請負契約を結ぶのは手間がかかりすぎるため、月額固定の準委任契約（稼働時間の上限を決めた保守契約）で運用するのが一般的です。
チェックリスト：契約前に確認しておきたい項目
契約書を受け取ったら、次の項目を一つずつ確認していくことをおすすめします。個人で発注する場合、法務の専門家に毎回相談する時間や費用が確保できないことも多いため、自分自身でも最低限のチェックができるようにしておくと安心です。
- [ ] 契約書のどこかに「請負」または「準委任」という言葉、あるいはそれに相当する記述があるか
- [ ] 「完成」を約束する契約なのか、「業務の遂行」を約束する契約なのか、自分の理解と契約書の記述が一致しているか
- [ ] 検収の基準が、具体的な項目リストや別紙の仕様書として明示されているか
- [ ] 納品物にソースコード・設計書・デザインファイルなどが含まれるか、範囲が明記されているか
- [ ] 知的財産権（著作権）の帰属先が明記されているか。自分（発注者）に譲渡されるのか、開発会社に留保されるのか
- [ ] 契約不適合責任（納品物に不備があった場合の対応）について、期間や範囲が明記されているか
- [ ] 途中で契約形態を切り替える場合の条件や手続きが、口頭ではなく書面で確認できているか
- [ ] 契約金額に、仕様変更や追加要望への対応が含まれているのか、別料金になるのかが明確か
- [ ] 準委任契約の場合、想定される稼働時間・稼働期間の目安が示されているか
- [ ] 契約解除の条件（どちらか一方から契約を終了する場合のルール）が明記されているか
このチェックリストで「分からない」「書かれていない」という項目が複数見つかった場合は、契約前に開発会社へ質問し、必要であれば契約書に追記してもらうことをおすすめします。すべての項目をその場で完璧に理解する必要はありませんが、少なくとも「確認すべき項目がある」ということを知っておくだけで、後のトラブルを大きく減らすことができます。
Q&A：個人が発注するときによくある疑問
Q. 契約書に「請負」「準委任」という言葉が明記されていない場合、どう見分ければいいですか。
A. 言葉そのものが書かれていなくても、契約書の中に「完成」「検収」という言葉があれば請負契約に近い性質、「業務の遂行」「稼働時間」「善良な管理者の注意をもって」といった言葉があれば準委任契約に近い性質と判断できます。分からない場合は、開発会社に「この契約は請負と準委任のどちらに近い内容ですか」と直接確認するのが確実です。
Q. 個人で予算が限られている場合、どちらの契約形態のほうがリスクを抑えられますか。
A. 一概にはいえませんが、仕様がまだ固まっていない状態であれば、いきなり請負契約で大きな金額を確定させるよりも、まず小さな準委任契約で仕様を固める期間を設け、その後に請負契約へ切り替えるほうが、結果的に予算超過のリスクを抑えやすい傾向があります。最初から大きな金額の請負契約を結んでしまうと、仕様変更のたびに追加費用が発生し、当初の予算感から大きくずれてしまうことがあります。
Q. 準委任契約で進めている途中、思ったように進んでいない気がする場合、どう対応すればいいですか。
A. 準委任契約は完成を保証するものではないため、進捗の確認は発注者側からも定期的に行う必要があります。「今回の契約期間で、どこまで進める予定か」「現時点での進捗はどうか」を、契約開始時と、期間中の節目ごとに開発会社と確認し合う運用にしておくと、「思っていたように進んでいない」という不満を早期に発見しやすくなります。改善が見られない場合は、契約の更新タイミングで、進め方や体制の見直しを相談することも検討してください。
請負契約と準委任契約、法律上の位置づけの違いをもう少し詳しく
契約実務の細部まで理解する必要はありませんが、なぜ請負契約と準委任契約でこれほど責任の重さが違うのか、その背景を知っておくと、契約書を読むときの理解が深まります。
請負契約は、民法上「仕事の完成」を目的とする契約として位置づけられています。仕事が完成しなければ、原則として報酬を請求できないという性質があり、開発会社側にとっては、完成に至るまでの責任とリスクを引き受ける契約形態です。この「完成しなければ報酬が発生しない」という緊張感があるからこそ、開発会社は仕様を固める段階で慎重になり、見積もりにもリスクを織り込みます。個人の発注者からすると「なぜ簡単な機能追加なのにこんなに時間がかかるのか」と感じることもありますが、それは開発会社が「完成の約束」を背負っているからだと理解すると、進め方への納得感が変わってきます。
一方、準委任契約は「事務の処理」を目的とする契約で、完成ではなく、専門家としての適切な業務遂行そのものが契約の対象になります。医師や弁護士への相談・依頼と同じ枠組みで理解すると分かりやすく、「治療の結果を保証する契約」ではなく「適切な治療行為を行う契約」であるのと同様に、システム開発における準委任契約も「動くシステムを保証する契約」ではなく「専門家としての適切な開発行為を行う契約」という位置づけになります。この違いを理解しておくと、準委任契約で「なぜ完成が保証されないのか」という疑問への納得感が生まれます。
発注前に、自分の状況を整理しておくと会話がスムーズになる
契約形態の判断は、最終的には開発会社との対話の中で決まっていくものですが、相談に行く前に、自分の状況を簡単に整理しておくと、初回の打ち合わせがぐっとスムーズになります。次のような項目を、メモ程度でも書き出しておくことをおすすめします。
- 今回作りたいものの目的（誰の、どんな悩みを解決するためのものか）
- すでに決まっている機能・画面のリスト
- まだ決まっていない部分、迷っている部分
- 想定している予算の上限、あるいは予算感
- 完成までに希望する期間
- 公開後、運用や改修をどのくらいの頻度で想定しているか
このメモを持って相談すれば、開発会社側も「この案件は仕様がどのくらい固まっているか」を早い段階で把握でき、請負契約と準委任契約のどちらが向いているか、根拠を持って提案しやすくなります。逆に、何も整理せずに相談に行くと、開発会社側も手探りで契約形態を決めることになり、結果として発注者にとって不利な条件（仕様変更バッファを多めに積んだ請負契約など）になってしまう可能性もあります。
まとめ：契約形態は「仕様の固まり具合」で選び、迷ったら組み合わせる
この記事で紹介した内容を、もう一度整理すると次のようになります。
- 請負契約は「完成」を約束する契約であり、仕様が固まっている案件に向いている
- 準委任契約は「業務の遂行」を約束する契約であり、仕様がまだ固まっていない案件や、保守・運用フェーズに向いている
- どちらか一方だけを選ぶ必要はなく、「準委任で仕様を固めてから請負に切り替える」という2段階の進め方も現実的な選択肢
- 契約形態にかかわらず、検収基準・知的財産権の帰属・契約不適合責任などは必ず契約書で確認する
- 開発会社に「なぜこの契約形態を提案するのか」を質問し、納得できる説明が返ってくるかどうかで、その開発会社の契約実務への理解度も見極められる
個人で複業やスピンオフのサービスを立ち上げる場合、契約書の細部まで完璧に理解する必要はありません。しかし、「請負」と「準委任」という2つの言葉の意味と、それぞれが向いている場面を知っておくだけで、開発会社との会話の質が大きく変わります。契約は、トラブルを未然に防ぐための道具でもあるため、少し手間はかかっても、契約前にこの記事のチェックリストを一通り確認しておくことをおすすめします。
この記事の次に読みたい記事
契約形態の基本を理解したら、次は契約書で確認すべき詳細な条項についても確認しておきましょう。あわせて次の記事も参考にしてください。
