この記事の結論
- 請負契約は「完成」に、準委任契約は「作業」に対価を払う契約です
- 要件が固まった工程は請負、流動的な工程や保守は準委任が向いています
- 検収の条件、仕様変更の手続き、著作権の帰属は必ず書面で確認しましょう
Webシステムの開発を依頼するとき、契約書に「請負」または「準委任」という言葉が出てきます。どちらも業務を委託する契約ですが、「何に対して対価を払うのか」という考え方が根本的に異なります。この違いを理解していないと、「完成していないのに費用を請求された」「仕様変更を頼んだら追加費用と言われた」といった行き違いが起こりやすくなります。この記事では、2つの契約形態の違いを比較したうえで、納品物に問題があったときの責任と受け入れ確認の考え方、工程ごとの使い分け、契約前に書面で確認したい項目を整理します。
請負契約と準委任契約の比較
請負契約は「仕事の完成」を約束し、完成した成果物に対して対価を払う契約です。一方、準委任契約は「業務の遂行」を約束し、作業そのものに対して対価を払う契約です。主な違いを表にまとめます。
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 対価の対象 | 成果物の完成 | 業務の遂行(作業時間) |
| 完成の義務 | あり | なし(善良な管理者の注意で業務を行う義務) |
| 費用の決まり方 | 固定(見積時に確定) | 工数に応じて変動(月額や時間単価) |
| 仕様変更の扱い | 原則として追加見積 | 作業の優先順位の入れ替えで対応しやすい |
| 検収 | 成果物の完成を確認して行う | 作業報告の確認が中心 |
| 発注側の関与 | 要件を固めて渡す | 継続的に判断・指示に関与する |
| 向いている場面 | 要件が固まっている開発 | 要件が流動的な開発、調査、保守 |
どちらが優れているという話ではなく、案件の性質によって適した形態が異なります。要件が明確で成果物を定義できるなら請負契約が、作りながら決めていく必要があるなら準委任契約が向いています。実務では、工程ごとに形態を分けることも一般的です。
契約不適合責任と検収の考え方
請負契約で重要になるのが契約不適合責任です。これは、納品された成果物が契約の内容に適合していない場合に、受注側が修補や代金減額などの責任を負う仕組みです。
ここで問題になるのが「契約の内容」とは何かです。仕様書や要件定義書に書かれていない機能は、「不適合」の判断が難しくなります。つまり、契約不適合責任を実効性のあるものにするには、何を作るかが書面で明確になっている必要があります。
検収は、納品された成果物が契約どおりかを発注側が確認し、受け入れる手続きです。検収の観点は次のとおりです。
- 検収の基準:どのテストに合格すれば検収とするか
- 検収の期間:納品から確認までの期限を書面で定めているか
- みなし検収:期間内に異議がなければ検収とみなす条項の有無
- 不合格時の扱い:修正の期限と、再検収の手続き
想定例:発注側が検収期間内に確認をせず、後になって不具合を指摘したところ、「みなし検収」条項によりすでに検収済みとされ、修正が有償扱いになった、というケースが考えられます。検収期間は自社で現実的に確認できる長さかを見て、必要なら交渉してください。検収の進め方は検収・受入テストの記事でも解説しています。
準委任契約には契約不適合責任の考え方は基本的に適用されませんが、受注側には善良な管理者としての注意義務があります。作業報告の内容や、期待した水準の作業が行われているかを確認することが、準委任契約での「検収」に相当します。
工程ごとの使い分け
Web開発は、要件定義、設計、実装、テスト、保守と工程が進むにつれて、成果物の定義しやすさが変わります。そのため、工程ごとに契約形態を分けるのが実務的です。
| 工程 | 向いている形態 | 理由 |
|---|---|---|
| 要件定義 | 準委任 | 何を作るかを決める段階で、成果物を事前に定義しにくい |
| 基本設計・詳細設計 | 請負または準委任 | 要件が固まっていれば設計書を成果物にできる |
| 実装・テスト | 請負 | 仕様が確定しており、成果物を定義できる |
| 導入・データ移行 | 請負または準委任 | 既存データの状態によって作業量が変わる |
| 保守・運用 | 準委任 | 障害対応や小さな改修など、事前に作業量を決められない |
想定例:業務システムの開発を、要件定義は準委任契約、実装とテストは請負契約、納品後の保守は準委任契約の月額として分けた場合、要件定義の段階では柔軟に議論でき、実装の段階では成果物と費用が確定し、保守では実態に応じた作業ができます。
要件を細かく区切って短い周期で作る進め方(アジャイル開発)を採る場合は、準委任契約が基本になりますが、各周期の成果物を明確にする工夫が必要です。業務効率化システム開発のように、業務の変化に合わせて改善を続けるシステムでは、この組み合わせが選ばれることがあります。
書面で確認したい項目
契約形態が決まったら、契約書や発注書に次の項目が明記されているかを確認してください。口頭の合意は、後から確認できません。
- 契約形態:請負か準委任か、工程ごとに異なる場合はその区分
- 業務の範囲:対象となる作業と、対象外の作業
- 成果物:納品物の一覧(プログラム、設計書、マニュアルなど)と納品形式
- 検収:基準、期間、みなし検収の有無、不合格時の手続き
- 費用と支払条件:金額または単価、支払時期、追加費用の算出方法
- 仕様変更の手続き:変更の申請と承認の方法、費用と納期への反映
- 知的財産権:プログラムの著作権の帰属と、発注側の利用範囲
- 契約不適合責任:責任の範囲と期間
- 秘密保持:業務で知り得た情報の取り扱い
- 契約の終了:中途解約の条件と、その時点までの費用の扱い
とくに著作権の帰属は見落とされがちです。請負契約でも、特約がなければ著作権は制作した側に残るのが原則です。将来、他の開発会社に保守を依頼する可能性があるなら、著作権の譲渡や、少なくとも改変・利用の許諾を書面に含めておきましょう。開発会社を変える際の注意点は既存システムの引き継ぎの記事にまとめています。
契約書は行き違いを防ぐ共通認識の記録
請負契約は「完成」に、準委任契約は「作業」に対価を払う契約です。要件が固まっている工程は請負、流動的な工程や保守は準委任というように、工程ごとに使い分けるのが実務的です。請負契約では契約不適合責任と検収の条件が、準委任契約では作業範囲と報告の方法が重要になります。契約書は形式ではなく、行き違いを防ぐための共通認識の記録です。不明な点は署名前に確認し、契約形態の選び方に迷う場合はお問い合わせからご相談ください。一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。
チェックリスト
- 契約形態が請負か準委任か、工程ごとに明記されているか
- 成果物の一覧と納品形式が書面にあるか
- 検収の基準・期間・みなし検収の有無を確認したか
- 仕様変更時の手続きと費用の算出方法が決まっているか
- 契約不適合責任の範囲と期間が書かれているか
- 著作権の帰属と発注側の利用範囲が明記されているか
- 中途解約の条件と費用の扱いを確認したか
よくあるご質問
準委任契約だと完成しなくても費用を払うのですか
準委任契約は作業に対して対価を払う契約なので、原則としてそうなります。ただし受注側には適切に業務を行う義務があり、作業報告で内容を確認することが重要です。
小さな案件でも契約書は必要ですか
規模にかかわらず、範囲・成果物・検収・費用を書面に残しておくことをおすすめします。発注書と請書、メールでの合意でも、記録として残る形にしてください。
一つの案件で両方の契約形態を使えますか
使えます。要件定義は準委任、実装は請負、保守は準委任というように、工程ごとに分ける進め方は一般的です。
関連する記事
- 費用・見積システム開発の見積書の読み方 — 工数・単価・前提条件のチェックポイントシステム開発の見積書は総額よりも内訳と前提条件が重要です。明細の見方、人月と単価の関係、前提条件と除外事項、仕様変更時の扱い、複数の見積を比較する手順を整理します。
- 進め方検収(受け入れテスト)で確認すべきことWebシステムの検収で発注側が確認すべきことを、検収条件の確認、テスト項目の作成、ステージングでの実施、不具合の記録と切り分け、検収書の作成の手順で解説し、契約不適合責任との関係も整理します。
- 進め方システム開発会社の選び方|4つの選択肢の違い中小企業がWebシステムの依頼先を選ぶときの判断軸を整理します。大手SIer、Web制作会社、フリーランス、小規模開発会社、ノーコードツールの向き不向きを比較し、見積り前に確認すべき質問と、避けたい選び方を解説します。
関連するサービス
関連用語: 請負契約、準委任契約、アジャイル開発、契約不適合責任、検収
監修: Unlogical Systems合同会社(杉並区・西荻窪)公開