準委任契約と請負契約、システム開発ではどちらを選ぶべきか
システム開発を外注するとき、契約書の冒頭には「本契約は請負契約とする」「本契約の法的性質は準委任とする」といった一文が入ることがあります。この違いによって、開発会社が何に責任を負うのか、いつ報酬を払うのか、途中でやめたいときにどうなるのかが変わります。
発注側からは「完成まで責任を持ってもらえる請負の方が安心」と考えがちです。しかし、作るものが最初に決まっていない案件を請負で発注すると、仕様変更のたびに追加費用と契約変更が必要になり、かえって揉める原因になることがあります。反対に、準委任は柔軟な一方で、成果物の完成は約束されません。
どちらが有利かは一概には決まらず、案件の性質、工程、発注側の体制によって答えが変わります。一つのプロジェクトの中で、工程ごとに契約類型を使い分けるのも一般的な方法です。
この記事では、民法上の請負と準委任の違いを整理したうえで、システム開発でどちらを選ぶべきかの判断基準と、どちらを選んでも揉めないために契約書で決めておくべきことを解説します。
請負と準委任の基本的な違い
請負と準委任は、どちらも民法に定められた契約類型です。両者の違いは、約束の対象が「仕事の完成」なのか「事務の処理」なのかという点にあります。
請負は仕事の完成を約束する
民法第632条は、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています。システム開発では、合意した仕様どおりのソフトウェアを完成させて納品することが開発会社の義務になります。
完成していなければ、原則として報酬を請求できません。どれだけ作業時間をかけても、完成させられなければ約束を果たしたことにならないのが請負の特徴です。
準委任は事務の処理を約束する
準委任は、法律行為でない事務の委託について委任の規定を準用するもので、民法第656条に定められています。システム開発では、要件定義の支援、設計、開発作業、運用保守などの作業を行うこと自体が約束の対象になります。
受注者は民法第644条により、善良な管理者の注意をもって事務を処理する義務（善管注意義務）を負います。専門家として通常求められる水準の注意で作業していれば、結果としてシステムが完成しなくても、それだけで債務不履行にはなりません。
準委任には二つのタイプがある
2020年4月施行の改正民法により、準委任の報酬の決め方は二つに整理されました。作業をした時間や期間に応じて報酬を払う「履行割合型」と、作業によって得られる成果に対して報酬を払う「成果完成型」（民法第648条の2）です。
成果完成型の準委任は、成果物の引渡しと同時に報酬を払う点で請負に近くなりますが、完成義務そのものは負わず、受注者の義務は善管注意義務にとどまります。契約書に「準委任」と書かれていても、どちらのタイプなのかは報酬の条項を読まないと分かりません。
参考：民法／e-Gov法令検索
参考：民法の一部を改正する法律（債権法改正）について／法務省
報酬・責任・解除はどう違うか
請負と準委任の違いを、発注側の関心が高い項目ごとに整理します。ここに書くのは民法の原則で、契約書に別の定めを置けば多くの点は変えられます。
| 項目 | 請負 | 準委任（履行割合型） | 準委任（成果完成型） |
|---|---|---|---|
| 約束の対象 | 仕事の完成 | 事務の処理 | 事務の処理（成果に対して報酬） |
| 受注者の主な義務 | 完成義務 | 善管注意義務 | 善管注意義務 |
| 報酬の支払時期 | 目的物の引渡しと同時（第633条） | 事務を履行した後。期間で定めたときは期間経過後（第648条） | 成果の引渡しと同時（第648条の2） |
| 途中で終わった場合の報酬 | 可分な部分で発注者が利益を受けるなら、その割合に応じて請求できる（第634条） | 既にした履行の割合に応じて請求できる（第648条第3項） | 請負の第634条を準用 |
| 成果物の不具合への責任 | 契約不適合責任（追完、減額、損害賠償、解除） | 善管注意義務違反があれば債務不履行責任 | 善管注意義務違反があれば債務不履行責任 |
| 発注者からの解除 | 完成前ならいつでも、損害を賠償して解除できる（第641条） | いつでも解除できる。不利な時期の解除などは損害賠償が必要（第651条） | 同左 |
| 再委託 | 民法上の制限はない | 委任者の許諾か、やむを得ない事由が必要（第644条の2） | 同左 |
発注側にとって大きいのは、成果物に不具合があったときの扱いです。請負では、引き渡されたシステムが契約の内容に適合しない場合、修補などの追完、報酬の減額、損害賠償、契約の解除を求められます。準委任では、開発会社が専門家として必要な注意を払っていたかどうかが問われ、不具合があること自体から直ちに責任が生じるわけではありません。
一方で、請負の契約不適合責任にも期間の制限があります。民法第637条では、注文者が不適合を知った時から1年以内に通知しなければ、原則として責任を追及できません。実務の契約書では、これを「検収完了後○か月以内」などに置き換えることが多いため、期間の条項は必ず確認してください。
工程ごとに契約類型を使い分ける
システム開発は、要件定義、設計、実装、テスト、運用と工程が分かれています。工程によって「最初に成果物の中身を特定できるかどうか」が違うため、プロジェクト全体を一つの契約類型で縛るより、工程ごとに選ぶ方が実態に合います。
独立行政法人情報処理推進機構（IPA）と経済産業省が公表している「情報システム・モデル取引・契約書」（第二版、2020年12月）も、工程ごとに個別契約を結ぶ多段階契約を基本にしています。同書は、企画段階は成果物を具体的に想定できないため準委任が適切とし、内部設計以降のように着手前に成果物を特定できる工程は請負で行えるとしています。外部設計やシステムテストは発注者の業務要件に関わる部分が多く、準委任と請負のどちらもあり得る工程として選択式の条文が用意されています。
| 工程 | よく選ばれる契約類型 | 理由 |
|---|---|---|
| 企画・要件定義 | 準委任 | 何を作るかを決める工程で、成果物の中身を事前に特定できない |
| 外部設計 | 準委任または請負 | 発注者の判断に依存する部分が多いが、要件が固まっていれば請負も可能 |
| 内部設計・実装・結合テスト | 請負 | 設計書が確定していれば、完成の基準を事前に決められる |
| システムテスト・導入支援 | 準委任または請負 | 発注者の業務を使った確認が中心になる場合は準委任が合う |
| 運用・保守 | 準委任 | 継続的な作業で、完成という区切りがない |
多段階契約の利点は、前の工程の成果を見てから次の工程の見積もりと契約ができることです。要件定義が終わった時点で開発費の見積もりが大きく外れていると分かれば、範囲を絞る、別の開発会社に依頼するといった判断ができます。契約の手間は増えますが、要件が固まっていない段階で総額を確定させるよりも、発注側のリスクは小さくなります。
多段階契約にする場合は、前の工程の成果物を次の工程の開発会社が使える形で受け取っておくことが大切です。要件定義書や設計書の著作権と利用の範囲を決めておかないと、要件定義を依頼した会社以外に開発を頼みにくくなります。
参考：情報システム・モデル取引・契約書（第二版）／IPA（情報処理推進機構）
どちらを選ぶべきかの判断基準
工程ごとの使い分けを前提に、発注側が判断するときの基準を整理します。迷ったときは、次の三つの問いに順番に答えてみてください。
作るものを、着手前に第三者が検査できる形で書けるか
請負は「完成したかどうか」を判断できることが前提です。画面、機能、データ項目、性能条件などが文書になっていて、それに沿って検収できるなら請負が選べます。「使ってみながら決めたい」「業務に合うかどうかは触ってみないと分からない」という段階なら、請負で完成の基準を決めるのは難しく、準委任が合います。
途中で仕様を変える可能性はどのくらいあるか
市場の反応を見ながら機能を足していく新規サービスや、アジャイル型で短い期間ごとに作っては見直す開発は、仕様の変更が前提です。IPAが公表しているアジャイル開発向けのモデル契約も準委任を前提にしています。反対に、法令や社内規程に沿って作る帳票や、既存システムを同じ仕様で作り直す案件など、途中で変わる要素が少ないものは請負に向きます。
発注側に、作業の中身を判断できる担当者がいるか
準委任は、発注側が優先順位を決め、進捗を確認しながら進める契約です。発注側に開発の進み具合を評価できる担当者がいない場合、準委任では費用に見合う成果が出ているかを判断しにくくなります。その場合は、要件定義だけを準委任で依頼し、そこで成果物の中身を固めてから請負で開発する形が安全です。
| 状況 | 選び方の目安 |
|---|---|
| 仕様が文書で確定していて、途中で変わる見込みが小さい | 請負 |
| 何を作るかを一緒に考える段階 | 準委任（履行割合型） |
| 要件は固まりつつあるが、細部は作りながら決めたい | 要件定義と外部設計を準委任、その後を請負 |
| リリース後も継続的に改善する | 準委任（期間と体制で契約） |
| 報告書や調査結果など、作業の成果物がはっきりしているが完成保証までは求めない | 準委任（成果完成型） |
なお、準委任で開発会社のエンジニアに発注側が直接作業を指示すると、契約の形式にかかわらず偽装請負と判断されるおそれがあります。準委任を選ぶ場合も、作業の割り振りは開発会社側の責任者を通すという運用を守る必要があります。
準委任を選ぶと「費用の上限が見えない」という不安が出てきます。この不安は、契約の作り方である程度抑えられます。たとえば、1回の個別契約を1〜3か月程度に区切り、月額と想定稼働時間の上限を決めておく方法です。区切りごとに成果を確認し、続けるか、範囲を絞るか、請負に切り替えるかを判断すれば、準委任でも総額が際限なく膨らむことは避けられます。社内の稟議では、総額の見込みに加えて、この見直しの区切りをあわせて説明しておくと承認を得やすくなります。
参考：情報システム・モデル取引・契約書（アジャイル開発版）／IPA（情報処理推進機構）
どちらを選んでも揉めないために契約書で決めること
契約類型の選択より大切なのが、その類型に合った条項を契約書に入れることです。契約類型ごとに、揉めやすい点と決めておくべき内容は次のとおりです。
請負で決めておくこと
請負では、完成と検収の基準、変更の手続き、不具合への責任の範囲を明確にしておくことが中心になります。
- 完成の基準になる仕様書と、検収の方法・期間
- 検収期間内に連絡がない場合の扱い（合格とみなすかどうか）
- 仕様変更の申し入れ方法と、追加費用・納期変更の決め方
- 契約不適合責任を負う期間と、その起算点
- 発注者が提供した資料や指示が原因の不具合の扱い
民法第636条は、注文者が与えた指図によって生じた不適合については、原則として請負人の責任を追及できないと定めています。発注側の指示どおりに作った結果の不具合は開発会社の責任にならない場合があるため、仕様の決定経緯を議事録に残しておくことが大切です。
準委任で決めておくこと
準委任では、作業の範囲と報酬の根拠、作業内容を確認する方法を明確にしておくことが中心になります。
- 作業の範囲と、成果物として何を受け取るか
- 報酬が稼働時間に対してなのか、成果に対してなのか
- 想定稼働時間の幅と、超過・不足した場合の精算方法
- 作業報告の頻度と形式
- 中途解約の申し入れ期限
準委任では「何をしたか」が報酬の根拠になるため、作業報告の取り決めが特に重要です。月次の作業報告書や、チケット管理ツールでの作業記録など、発注側が作業の中身を確認できる形を決めておきましょう。
どちらの類型でも、契約書の表題や冒頭の「本契約は準委任とする」という一文だけで性質が決まるわけではなく、実際の条項の中身と運用の実態が問われます。表題と中身が食い違っている場合は、契約前に開発会社に意図を確認し、条項を揃えておくことをおすすめします。
まとめ
請負は仕事の完成を約束し、完成した成果物に対して報酬を払う契約です。準委任は事務の処理を約束し、受注者は善管注意義務を負います。成果物の不具合への責任、報酬の支払時期、途中解除の扱いが民法上それぞれ異なります。
システム開発では、作るものを着手前に検査できる形で書けるなら請負、何を作るかを一緒に考える段階や継続的な改善なら準委任が基本です。一つのプロジェクトでも、要件定義は準委任、確定した設計に基づく開発は請負というように工程ごとに使い分けると、発注側のリスクを抑えられます。
これから契約する案件があれば、まず各工程について「着手前に完成の基準を書けるか」を確認してみてください。書ける工程は請負、書けない工程は準委任とし、そのうえで検収、変更手続き、作業報告、解約の条項を類型に合わせて整えれば、契約類型が原因で揉めることはかなり減らせます。