請負と準委任の違いは、ひとことで言うと「完成を約束するかどうか」です。請負は、開発会社がシステムを完成させることを約束する契約です。準委任は、開発会社がプロとして作業をきちんと行うことを約束する契約で、完成までは約束しません。
システムを発注する側から見ると、この違いで「いつ支払うか」「途中で仕様を変えたいときどうなるか」「納品後に不具合が見つかったら誰が直すか」が変わります。この記事では、IT に詳しくない会社の経営者・担当者の方に向けて、2つの契約の違いと、システム開発のどの段階でどちらを選ぶか、契約前に確認したい点を解説します。
なお、この記事は一般的な説明です。実際の契約書の判断は、弁護士などの専門家にご相談ください。
目次
請負と準委任の違いは？「完成」を約束するかどうか
民法では、請負は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払う」契約とされています（民法第632条）。システム開発に当てはめると、「決めた仕様どおりのシステムを完成させて納める。発注者は、その完成したシステムに対して代金を払う」という形です。
準委任は、法律行為ではない事務（作業）を任せる契約です（民法第656条。もとになる委任は第643条）。要件の整理や保守など、システム開発の作業を「完成」を約束せずに任せる場合がこれにあたります。開発会社は「善良な管理者の注意」、つまりその道のプロとして当然求められる注意を払って作業する義務を負います（第644条）。ただし、完成までは約束しません。
- 請負：約束するのは「完成」。完成したもの（成果物）に対して支払う
- 準委任：約束するのは「プロとしてきちんと作業すること」。作業（または決めた成果）に対して支払う
「業務委託契約」は請負と準委任のどちら？
「業務委託契約」は民法の契約の種類の名前ではなく、実務でよく使われる呼び方です。業務委託契約書という名前でも、中身は請負のこともあれば準委任のこともあります。契約書の名前ではなく、「完成を約束しているか」「何に対して支払うのか」が書かれた条文を確認しましょう。
発注者から見た違いは？支払い・変更・中止・不具合の4つ
発注者にとって大きく変わるのは、次の4つです。ここで紹介するのは民法の原則で、実際の契約では条文で変えていることが多い点に注意してください。
いつ支払うか
請負の代金は、原則として完成したものの引き渡しと同時に支払います（第633条）。実際には「着手時に一部、納品・検収後に残り」のように分けて払う契約もよくあります。検収とは、納められたシステムが約束どおりかを発注者が確認し、合格とする手続きです。
準委任の報酬は、原則として作業をした後に支払います（第648条）。月額のように期間で報酬を決めた場合は、その期間が終わった後に支払います。
成果に対して払う準委任もある
2020年4月1日に施行された民法の改正で、準委任でも「作業の成果に対して報酬を払う」形が条文に書かれました（第648条の2）。この形では、成果の引き渡しと同時に支払います。名前は準委任でも支払い方が請負に近いので、どちらの形なのかを契約書で確かめることが大切です（改正の内容は法務省の解説ページにまとまっています）。
途中で仕様を変えたいとき
請負では、最初に決めた仕様が「完成」の基準になります。途中で機能を足したり変えたりすると、費用や納期を決め直す必要が出てきます。そのため、変更を申し込む手続き（変更管理）を契約で決めておくのが一般的です。
準委任では、決めた作業の範囲や時間の中で、何を優先して作業するかを入れ替えやすくなります。ただし、作業時間が増えれば、その分の費用も増えます。
途中でやめたいとき・完成しなかったとき
請負では、システムが完成するまでの間、発注者は損害を賠償すればいつでも契約を解除できます（第641条）。途中までの成果が分けて使え、発注者がそれで利益を受けるときは、その割合に応じて代金を払います（第634条）。
準委任は、発注者・開発会社のどちらからでもいつでも解除できます。ただし、相手に不利な時期に解除した場合などは、やむを得ない理由がない限り損害を賠償する必要があります（第651条）。途中で終わった場合も、それまでに行った作業の割合に応じて報酬を払います（第648条第3項）。つまり、準委任では、システムが完成しなくても、行った作業の分は支払いが発生しうるということです。
納品後に不具合が見つかったとき
請負では、納めたシステムが契約の内容に合っていない場合、開発会社は「契約不適合責任」を負います。2020年の改正で、それまでの「瑕疵担保責任」から変わった考え方です。発注者は、修正（追完）、代金の減額、損害賠償、契約の解除を求められます（第559条で売買の規定を準用。第562条〜第564条）。
ただし、発注者は不具合を知った時から1年以内に開発会社へ伝える必要があります（第637条）。また、発注者が出した指示が原因の不具合は、原則として責任を問えません（第636条）。
準委任には、この契約不適合責任はありません。開発会社がプロとしての注意を怠った場合に、通常の契約違反（債務不履行）として責任を問う形になります。
比べると
- 約束すること：請負は完成／準委任はプロとしてきちんと作業すること
- 支払いのタイミング：請負は完成品の引き渡し時／準委任は作業の後（月額なら毎月）
- 途中の変更：請負は費用・納期の決め直しが必要／準委任は範囲内で優先順位を変えやすい
- 完成しなかったとき：請負は原則として代金なし（使える部分は割合で支払い）／準委任は作業した分を支払う
- 納品後の不具合：請負は契約不適合責任あり／準委任はなし（注意を怠った場合の責任のみ）
システム開発では、どの工程をどちらで結ぶ？
一般的には、何を作るかがまだ決まっていない工程は準委任、作るものが決まった工程は請負と考えます。請負は、作業を始める前に完成の基準を決められることが前提だからです。
IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」では、工程ごとに次のように整理しています。
- 企画・要件定義（何を作るかを決める）：準委任
- 外部設計（画面や操作など、使う人から見える部分の設計）：準委任または請負
- 内部設計・プログラミング・テスト：請負
- システムテスト（業務の流れに沿った全体の確認）：準委任または請負
- 受け入れ・導入の支援：準委任
- 運用・保守：準委任または請負
また、作りながら機能や優先順位を見直していく「アジャイル開発」向けのモデル契約書は、準委任を前提にしています。
小さな会社の発注では、どう考えればよい？
IPA のモデル契約書は、大手企業と開発会社の取引や、工程を順番に進める開発を想定して作られています。少人数の会社がシステムを頼む場合は、工程をここまで細かく分けず、次の3つの段階で考えるとわかりやすくなります。
- 何を作るか決まっていない：要件の整理や、小さな試作から始める。作るものが決まっていないので、準委任が向いている
- 作るものが決まった：決めた仕様のシステムを完成させて納めてもらう。請負が向いている
- 使い始めた後の改善・保守：直したいことが毎月変わるので、月額の準委任が向いている
私たち ZenJun の場合、仕様を決めて作る受託開発は請負契約、公開後の月額の開発・改善サポートは準委任契約でお受けしています。本開発の前に、必要な機能に絞って試す「試作（小さく始める）」のプランもあります。
「請負なら安心」とは限らない
請負は「完成」を約束してもらえるので、発注者には安心に見えます。ただ、IPA のモデル契約書の解説では、請負にすると発注者が「丸投げ」の意識を持ちやすいことが指摘されています。
何を作るかを決めるのは、仕事の中身を知っている発注者の役割です。要件があいまいなまま請負で頼むと、完成の基準そのものがずれてしまいます。また前述のとおり、発注者の指示が原因の不具合は、請負でも責任を問えません。契約の種類にかかわらず、要件を決める場には発注者も参加する必要があります。
契約の前に確認したい7つのポイント
契約書や見積書を受け取ったら、次の点を確認しましょう。わからない言葉があれば、遠慮なく開発会社に聞いてください。説明をはぐらかす会社は要注意です。見積書の読み方は「システム開発の費用相場と見積もりの見方」で解説しています。
- 契約の種類：請負か準委任か。工程ごとに分けているなら、それぞれどちらか
- 何を作るか・何の作業をするか：請負なら完成させるもの、準委任なら作業の範囲と時間の目安
- 完成の確かめ方：検収の方法と期限。「期限までに連絡がなければ合格とみなす」という条文がないか
- 支払いの時期と方法：一括か分割か、月額か。準委任なら作業時間の上限や、超えたときの扱い
- 仕様を変えたいときの手続き：誰に、どう申し込み、費用と納期をどう決め直すか。口頭でなく書面に残す決まりがあるか
- 納品後の不具合の扱い：契約不適合責任の期間と範囲。無料で直す不具合と、有料の保守・改修の境目
- 作ったものの権利と、その後の保守：プログラムの著作権がどちらに属するか。ほかの会社に保守を頼めるか
準委任の場合は、作業の状況をいつでも報告してもらえる点も覚えておきましょう。民法では、発注者が求めたときは作業の状況を報告する義務が開発会社にあります（第645条）。
相手のエンジニアへの直接の指示に注意
請負でも準委任でも、開発会社のエンジニアへの作業の指示は、開発会社が行うのが原則です（IPA のモデル契約書でも、開発会社の従業員には開発会社が指揮命令を行うと定めています）。発注者が相手のエンジニアに直接細かく指示を出し続けると、実態は派遣と見られ、「偽装請負」として問題になるおそれがあります。派遣か請負かは、契約の形ではなく実態で判断されます（厚生労働省の解説）。要望は、開発会社の窓口や責任者を通して伝えましょう。
よくある質問
発注者にとって有利なのは、請負と準委任のどちらですか？
一概には言えません。作るものがはっきり決まっていれば、完成を約束してもらえる請負が向いています。何を作るかを探りながら進めるなら、作った分だけ払い、方向を変えやすい準委任のほうが、むだな費用を抑えやすくなります。
保守の契約は、どちらになりますか？
IPA のモデル契約書では、保守は準委任・請負のどちらもありうるとしています。毎月の問い合わせ対応や小さな改善は準委任、「この機能を追加する」とはっきり決まった改修は請負、のように分けることもあります。
他社で作ったシステムの保守を頼むときに気をつけることは？
まず、プログラム（ソースコード）や設計書、サーバー・ドメインなどの管理権限が自社の手元にあるかを確認しましょう。あわせて、プログラムの著作権がどちらにあるか、元の開発会社との契約に引き継ぎの決まりがあるかも確かめます。これらがそろっていないと、引き継ぎの前の調査に時間と費用がかかることがあります。
まとめ
- 請負は「完成」を、準委任は「プロとしてきちんと作業すること」を約束する契約です
- 発注者から見ると、支払いのタイミング、途中の変更、完成しなかったときの支払い、納品後の不具合の責任が変わります
- 何を作るか決まっていない段階は準委任、作るものが決まったら請負、使い始めた後の改善は月額の準委任、と段階で使い分けるのが基本です
- どちらの契約でも、要件を決めるのは発注者の役割です。契約書では、契約の種類、検収、変更の手続き、不具合の扱い、権利を確認しましょう
- 実際の契約書の判断は、弁護士などの専門家にご相談ください
「何を作るか、まだはっきりしない」という段階からご相談いただけます。私たちのシステム開発では、何を作るかの整理から開発、公開後の保守・改善まで、元エンジニアの代表が担当し、契約の形もご相談の中でご説明しています。システムを作り込む前に、今のやり方のまま一部の作業だけを自動にした例は、導入事例で紹介しています。
