請負契約と準委任契約とは

請負契約と準委任契約とは

システム開発を外部の会社へ委託するときに締結する、代表的な2つの契約形態です。
請負 は開発会社が仕事の完成を約束し、完成した成果物を支払いの対象とする契約です。
準委任 は開発会社が専門家として作業を担当し、作業の遂行を支払いの対象とする契約で、完成は約束しません。

注文住宅の場合は図面どおりの家の建築と引き渡しが請負、家づくりの相談と設計の支援を建築士に依頼するのが準委任にあたります。

項目	請負	準委任
支払いの対象	完成した成果物	作業した期間や工数
完成の責任	開発会社が負う	負わない。専門家に通常求められる水準の注意で作業する善管注意義務を負う
引き渡し後の不具合	契約で定めた期間内なら、発注側は無償の修正、代金の減額、損害賠償を請求できる	作業に手落ちがあった場合だけ責任を追及できる
仕様の変更	契約の変更と追加の見積もりが必要	契約で定めた業務の範囲内なら、期間中に作業内容を変更できる
途中での解除	発注側は完成前ならいつでも解除できるが、開発会社の損害を賠償する必要がある	民法上は双方がいつでも解除できるが、相手に不利な時期の解除は損害賠償の対象になりうる
費用の上限	契約金額で確定する。仕様を変更すれば追加の費用が発生する	期間と体制に応じて変動し、延長すれば増加する

システム開発の契約書では、請負は一括請負、準委任は技術支援やラボ型開発といった名前で記載されることも多くあります。
ラボ型開発は開発会社の固定人数のチームを一定期間確保して作業を依頼する形を指します。
名前に関係なく、完成を約束するかどうかで区分します。

契約を工程ごとに区分する理由

システム開発には開発前に中身を確定できない部分があります。
業務の現場からの要望は要件定義の途中で変化し、画面を操作して初めて判明する不足もあります。

開発全体を最初から一括請負の契約にすると、未確定の部分をめぐって発注側と開発会社が対立します。
発注側は最初から含まれていたはずと主張し、開発会社は追加の作業だと主張します。
反対にすべてを準委任にすると、完成の責任を誰も負わないまま期間の延長が継続し、当初の予算を超過しても中止の基準がありません。

そこで工程の性質に応じて契約を区分します。
中身を決定する工程は準委任にして発注側が開発会社の支援のもとで決定し、確定した中身を開発する工程は請負にして開発会社に完成を約束してもらいます。
IPA（情報処理推進機構）が公開する契約書のひな形 情報システム・モデル取引・契約書 も、この考え方で工程ごとに契約の形を設定しています。

発注側が負う手間と費用

請負

• 契約前に開発するものを一覧にして合意する手間がかかる。要件定義の期間中は発注側の業務部門の時間を継続して確保する必要がある
• 仕様の変更のたびに見積もりと契約の変更が発生し、発注側と開発会社が変更に合意するまで数週間かかることもある
• 金額には開発会社の予備分が含まれ、仕様が確定しているほど予備分は少額になる
• 成果物の契約適合を確認する受け入れテストの体制を発注側で整備する必要がある
• 引き渡し後の不具合を開発会社が無償で修正するのは契約で定めた期間だけ。責任の期間は契約で定め、検収の完了日を起点にすることが多い。期間の経過後の修正と機能追加は、別途締結する保守契約の費用になる
• 紙の契約書で締結する場合は請負の契約書は印紙税の課税文書にあたり、契約金額に応じた収入印紙の貼付が必要になる。電子契約で締結すれば印紙税はかからない。準委任の契約書は原則として課税されない

準委任

• 進捗を確認し、開発の優先順位を決定する担当者が発注側に必要。担当者の不在時は作業の進捗と関係なく事業に必要な機能から完成するとは限らない
• 作業の手落ちを理由に賠償を請求するときは、手落ちの箇所の立証責任を原則として発注側が負う
• 開発会社の担当者が交代すると、業務を再度理解する時間が費用に加算されやすい。主要な担当者の継続を契約で約束してもらうかを事前に決定する
• 稼働後の運用と保守も準委任で継続することが多く、月々の固定費になる

共通の条項

• 損害賠償の上限。モデル契約 は賠償の総額を個別契約で定めた金額までに制限する条項を規定している。システムの停止による事業の損害が委託料を超過しうるなら、上限の金額と、故意や重大な過失のときに上限が適用除外になるかを発注側で確認する
• 開発したシステムの中身を理解している人は開発会社の側に偏在する。ソースコードと設計書の権利の帰属と引き渡しを契約書に定め、将来に保守の担い手を変更できるようにしておく

偽装請負にならない運用

契約の形式は請負や準委任なのに、実態は発注側が開発会社の技術者を直接指揮する労働者派遣になっている状態を偽装請負と呼びます。
発注側の担当者が開発会社の技術者へ直接作業を指示する運用や、勤務時間と出退勤を管理する運用は偽装請負に該当しえます。
実態が労働者派遣に該当すれば、開発会社は許可のない労働者派遣事業として、発注側は許可のない事業者からの派遣の受入れとして、それぞれ労働者派遣法の違反に該当しえます。

厚生労働省の 労働者派遣事業と請負により行われる事業との区分に関する基準 は、業務の進め方の指示、労働時間の管理、人の配置の決定を開発会社が自ら行っていることを、請負と派遣を区分する条件としています。
同省の アジャイル型開発についての疑義応答集 は、準委任にもこの基準が適用され、契約の形式より実態を基準に認定されると明記しています。

発注側が開発会社の技術者へ要望を伝達すること自体は禁止されていません。
要望は開発会社の責任者を経由するか、チームとして受領してもらう形にし、誰が何時に何をするかの決定は開発会社の側で行ってもらいます。

契約の形を気にしなくてよい場面

• 市販のクラウドサービスの申し込みと利用だけなら、締結するのは利用規約に基づく利用契約で、請負か準委任かを選択する場面は発生しない
• 既存システムの小規模な改修で、変更の中身が見積もりの時点で確定し、数週間で完了するなら、請負の単発の発注で対応できる
• 開発会社との取引が長く、毎月の作業量がほぼ一定の保守なら、準委任の月額契約で対応できる。毎年の更新時に、作業の実績と体制に対して費用が相応かを確認する

よくある誤解

請負にすれば任せきりにできる

請負にしても開発対象の決定と合意は発注側の責任で、開発会社に任せきりにはできません。
発注側の指示が原因の不具合は 開発会社の責任になりません。
例外は開発会社が指示の不適切さを認識しながら発注側に通知しなかった場合です。
モデル契約の解説 も請負の場合に発注側で丸投げの意識が生じ、要件定義での社内調整の責任が曖昧になりやすいと指摘しています。

準委任なら開発会社は何の責任も負わない

準委任でも開発会社は専門家に通常求められる水準の注意で作業する善管注意義務を負います。
作業に手落ちがあれば発注側は再作業や損害賠償を請求できます。
開発会社が責任を負わないのは、未完成という結果そのものだけです。

契約書の題名が契約の性質を決定する

業務委託契約という題名でも、完成を約束して成果物を支払いの対象とする条項なら請負に該当します。
解除、責任の期間、賠償の上限といった民法の定めの多くは、契約の条項で変更できます。
契約の性質を決定するのは題名でなく、支払いの対象と約束の内容を定めた条項です。