請負と準委任の違い｜システム開発での使い分けと注意点
「開発会社から、要件定義は準委任、開発は請負で契約したいと言われたが、何が違うのかわからない」「準委任だと、完成しなくても費用を払わなければならないのか」。システム開発の契約形態は、発注者にとってわかりにくいものの、責任の所在や費用の払い方を大きく左右する重要なポイントです。
この記事では、請負契約と準委任契約の違いを比較表で整理し、システム開発の工程ごとの使い分け方、それぞれの契約で発注者が注意すべき点を解説します。
- 請負は「完成」に対して報酬を払う契約、準委任は「業務の遂行」に対して報酬を払う契約
- 請負は開発会社に完成責任と契約不適合責任があり、準委任には完成責任がない代わりに善管注意義務がある
- システム開発では、要件定義は準委任、設計〜テストは請負、運用保守は準委任という使い分けが一般的
- どちらの契約でも、発注者が開発会社の担当者に直接指揮命令すると偽装請負になるおそれがある
目次
請負契約と準委任契約とは
請負契約とは、受注者が仕事の完成を約束し、発注者がその完成した結果に対して報酬を支払う契約です（民法第632条）。システム開発では、「仕様書どおりに動くシステムを完成させて納品する」ことが仕事の中身になります。
準委任契約とは、法律行為以外の事務（業務）の処理を委託する契約です（民法第656条）。受注者は業務を専門家として適切に遂行する義務を負いますが、必ずしも成果物の完成を約束するものではありません。システム開発では、要件定義の支援や運用保守、技術支援などで使われます。
請負と準委任の違いを比較
請負契約と準委任契約の比較
| 比較項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 契約の目的 | 仕事の完成 | 業務の遂行 |
| 報酬の対象 | 完成した成果物 | 業務を行ったこと（時間・期間）または成果 |
| 完成責任 | あり | なし |
| 受注者の主な義務 | 契約どおりの成果物を納品する | 善管注意義務（専門家として通常求められる注意を払う） |
| 契約不適合責任 | あり（修補・減額・損害賠償・解除） | 原則なし（義務違反があれば債務不履行責任） |
| 費用の超過リスク | 主に受注者が負う | 主に発注者が負う |
| 仕様変更への対応 | 変更契約が必要で手続きが重い | 柔軟に対応しやすい |
完成責任の違い
請負契約では、開発会社は約束したシステムを完成させる責任を負います。途中で想定以上に工数がかかっても、原則として追加費用なしで完成させる必要があります。準委任契約では、専門家として適切に作業を行っていれば、成果が期待どおりでなくても契約違反にはなりません。
契約不適合責任の違い
請負契約で納品されたシステムが契約内容に適合しない場合、発注者は修正や代金の減額、損害賠償、契約の解除を求めることができます。準委任契約にはこの責任がないため、品質の担保は作業の進め方や報告の仕組みで確保することになります。
準委任には2つのタイプがある
2020年4月に施行された改正民法では、準委任契約の報酬の支払い方として、2つのタイプが整理されました。
履行割合型
- 作業した時間や期間に応じて報酬を払う
- 月額や人月単価×稼働時間で精算することが多い
- システム開発の準委任では一般的な形
成果完成型
- 業務の成果に対して報酬を払う
- 成果の引き渡しと同時に報酬を支払う
- ただし完成義務は負わない点が請負と異なる
成果完成型の準委任は、請負と似ていますが、成果物の完成を約束するものではありません。契約書に「準委任」とあっても、どちらのタイプかで支払い条件が変わるため、報酬の条項を確認しましょう。
システム開発の工程ごとの使い分け
システム開発では、1つの契約形態ですべての工程を契約するのではなく、工程の性質に合わせて契約形態を分ける「多段階契約」が一般的です。
工程別の契約形態の例
- 要件定義（準委任）何を作るかを発注者と一緒に決める工程。成果の内容を事前に確定できないため準委任が向く
- 基本設計（準委任または請負）要件が固まっていれば請負、まだ流動的なら準委任を選ぶ
- 詳細設計〜テスト（請負）作るものが明確になっているため、完成責任を負う請負が向く
- 移行・導入支援（準委任）発注者側の作業と一体で進むため準委任が多い
- 運用保守（準委任）継続的な業務の遂行が中心のため準委任が一般的
要件が固まっていない段階で一括請負にすると、開発会社はリスクを見込んで見積もりを高くしたり、後から仕様変更による追加費用が多発したりしがちです。要件定義を準委任で先に行い、その成果をもとに開発を請負で見積もる方法は、発注者にとっても費用の見通しが立てやすくなります。
どちらを選ぶか迷ったときの判断基準
工程ごとの一般的な使い分けに当てはまらない場合は、次の観点で判断すると整理しやすくなります。
契約形態の判断基準
| 判断の観点 | 請負が向く | 準委任が向く |
|---|---|---|
| 作るものの明確さ | 仕様や画面が文書で確定している | 進めながら内容を決めていく |
| 変更の頻度 | 大きな変更は想定していない | 試行錯誤や方針変更がありうる |
| 予算の考え方 | 金額を確定させたい | 期間や工数で予算の枠を決めたい |
| 発注者の関与 | 要所での確認が中心 | 日常的に一緒に検討する |
どちらか一方に決めきれない場合は、最初の工程を準委任で小さく始め、内容が固まった段階で請負に切り替える方法も検討できます。この場合、準委任で作成した資料（要件定義書など）を請負契約の仕様として位置づけ、両者のつながりを契約書上で明確にしておくことが大切です。
契約形態ごとの発注者の注意点
請負契約の注意点
- 完成の基準を明確にする：何をもって完成とするか、仕様書と検収基準を具体的に決める
- 仕様変更の手続き：変更の申し入れ、見積もり、合意の手順を契約に定めておく
- 契約不適合責任の期間：検収後の通知期間と起算点を確認する
準委任契約の注意点
- 作業内容と報告方法：何をどこまで行うか、作業報告書の提出頻度を決めておく
- 工数の上限と精算方法：想定を超えた場合の扱いを事前に取り決める
- 成果物の扱い：作成された資料の権利や引き渡しの有無を明記する
よくある質問
- 準委任契約で成果物が完成しなかった場合、費用は払う必要がありますか？
- 履行割合型の準委任では、作業を行った分の報酬は原則として支払う必要があります。ただし、開発会社が善管注意義務に違反していた場合は、債務不履行として責任を問える可能性があります。
- 発注者にとっては請負の方が有利ですか？
- 完成責任を開発会社が負う点では安心ですが、要件が不確かな段階ではリスク分が見積もりに上乗せされやすくなります。工程の性質に合わせて使い分けることが、結果的に発注者にとっても有利です。
- 契約書に請負か準委任か書かれていない場合はどうなりますか？
- 契約の名称ではなく、実際の業務内容や報酬の決め方などから判断されます。トラブルを避けるため、契約形態と完成責任の有無は契約書に明記してもらいましょう。
まとめ
請負契約は仕事の完成に対して報酬を払う契約で、開発会社に完成責任と契約不適合責任があります。準委任契約は業務の遂行に対して報酬を払う契約で、柔軟性が高い反面、費用超過のリスクは発注者が負いやすくなります。システム開発では、要件定義や運用保守は準委任、要件が固まった後の開発は請負という使い分けが一般的です。契約形態ごとの注意点を押さえ、自社のプロジェクトに合った契約を選びましょう。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
