システム開発の請負契約と準委任契約の違い｜使い分けと注意点

「システム開発の契約は請負と準委任のどちらにすべきか」——発注の場面で必ず出てくる判断です。結論から言うと、成果物の完成に責任を求めるなら請負、要件が動く前提で専門家に伴走してほしいなら準委任が向きます。ただし実務では「どちらか一方」ではなく、工程ごとに使い分けるのが定石です。本記事では、両者の法的な違い、工程別の使い分け、偽装請負の判断ポイント、契約書で必ず確認すべき項目までを、発注担当者がそのまま使える形で解説します。なお、契約は発注プロセス全体の一部です。全体の流れはシステム開発の発注完全ガイドで解説しています。

請負契約と準委任契約とは？（法的な違い）#

請負契約（民法632条）は、仕事の「完成」を約束し、完成した成果物に対して報酬を払う契約です。完成責任があり、納品物に不具合があれば契約不適合責任（旧・瑕疵担保責任）を負います。一方、準委任契約（民法656条・643条）は、一定の業務（作業）を遂行することに対して報酬を払う契約で、成果物の完成義務はなく、善管注意義務（専門家として注意して業務を行う義務）を負います。

なお2020年の民法改正で、準委任には「履行割合型」（稼働した時間・割合に応じて報酬）と「成果完成型」（成果に対して報酬）の2類型が整理されました。「準委任＝成果に責任を負わない」と単純化せず、どちらの型かまで契約で確認することが重要です。

請負と準委任の違いを比較#

主要な観点で整理すると、次のようになります。

請負は「決まったものを確実に作ってほしい」、準委任は「専門家に手を動かしながら一緒に進めてほしい」ときに向きます。

どう使い分ける？（工程で分けるのが定石）#

実務では、1つのプロジェクトを通して同じ契約にこだわらず、工程ごとに使い分けます。

典型的には、要件がまだ固まっていない要件定義フェーズは準委任で密に進め、仕様が固まった設計・開発フェーズは請負で完成責任を持たせ、リリース後の運用・保守は準委任（または保守契約）で継続的に支える、という分け方です。要件が固まっていない段階を請負にすると、仕様変更のたびに追加費用や交渉が発生し、かえって硬直的になります。「固まっていないものは準委任、固まったものは請負」と覚えると判断しやすくなります。

工程別のおすすめ契約（早見表・そのまま使える）#

工程ごとに、向く契約形態を早見表にまとめました。自社の発注の検討にそのままお使いください。

仕様が明確で動きにくい案件は全体を請負でも問題ありませんが、新規性が高い・要件が動く案件ほど、工程で分けると仕様変更の影響を抑えられます。IPAの「情報システム・モデル取引・契約書（第二版）」でも、工程ごとに契約を分ける多段階契約の考え方が示されています。

偽装請負に注意（何が問題で、何で判断されるか）#

請負・準委任では、発注側が受注側の担当者へ直接、業務上の指揮命令を行うことはできません。契約は請負・準委任なのに、実態として発注側が指揮命令している状態は「偽装請負」とされ、労働者派遣法・職業安定法の観点から問題になります。

偽装請負かどうかは、契約の名目ではなく実態で判断されます。判断のポイントは、(1) 誰が作業の指示・進め方を決めているか、(2) 勤怠・労務管理を誰が行っているか、(3) 受注側が独立して業務を遂行しているか、です。避けるには、成果物・責任範囲を明確にする、発注側が個々の担当者へ直接指示せず受注側の窓口（責任者）を通す、作業の進め方や時間の管理を受注側に委ねる、といった運用にします。発注側が直接、技術的な指示を出して人を動かしたい場合は、準委任ではなく労働者派遣など適切な形態を選びます。

契約書で必ず確認すべきこと#

契約形態を選んだら、契約書で次は必ず確認します。いずれも、後のトラブルを防ぐ勘所です。

• 検収条件：何をもって「完成・合格」とするか（検収の基準・期間）。
• 契約不適合責任：納品後の不具合対応の範囲と期間。期間は当事者間の取り決めによりますが、引渡し後の一定期間内に通知、と定めるのが通例です。
• 知的財産権：成果物の著作権が発注側・受注側のどちらに帰属するか、譲渡の有無。
• 再委託：受注側が第三者へ委託することの可否と条件。
• 中途解約・損害賠償：解約時の精算と、賠償の上限・範囲。

特に著作権の帰属と契約不適合責任は見落とされがちで、後から「ソースコードを渡してもらえない」「不具合対応が想定外の費用になる」といったトラブルになりやすい項目です。

たとえば、要件が固まっていない開発のケース#

たとえば、業務を見直しながら新しい社内システムを作りたいが、要件がまだ固まっていない、というケースを考えます。これを最初から一括請負にすると、要件が変わるたびに追加費用と再見積もりが発生します。この場合、要件定義フェーズを準委任で進めて要件を固め、固まった範囲を請負契約で開発する、と工程を分けると、手戻りと費用の膨張を抑えられます。要件の固め方は要件定義の進め方もあわせてご覧ください。

弊社（株式会社TryWith）の開発・契約のご相談について#

弊社では、システムの受託開発において、案件の性質や工程に合わせた契約形態のご提案も行っています。「要件がまだ固まっていない」「どの契約が合うか分からない」「契約書のどこを見ればいいか不安」といった段階から、開発を担う立場からご相談に対応します。社内に技術が分かる人がいない場合も、スポットCTO的な関与で、契約・見積もりの妥当性を発注側の視点で補えます。

よくある質問（FAQ）#

Q. 請負と準委任の一番の違いは何ですか？

A. 成果物の「完成義務」があるかどうかです。請負は完成・納品に責任を負い、準委任は業務の遂行に責任を負います（完成義務はありません）。

Q. どちらの契約が発注側に有利ですか？

A. 一概には言えません。仕様が固いなら完成責任のある請負、要件が動くなら柔軟な準委任が向きます。工程で使い分けるのが現実的です。

Q. 偽装請負と判断されるのはどんなときですか？

A. 契約は請負・準委任なのに、発注側が受注側の担当者へ直接指揮命令している、労務管理をしている、といった実態があるときです。名目ではなく実態で判断されます。

Q. 契約不適合責任とは何ですか？

A. 納品物が契約内容に適合しない（不具合がある）場合に、受注側が修補・代金減額・損害賠償などの責任を負うものです。対応の範囲と期間を契約で明確にします。

Q. 要件が固まっていない場合はどうすればいいですか？

A. 要件定義の段階を準委任で進め、固まってから本開発を請負で、と工程で分ける方法が有効です。

まとめ#

請負は成果物の完成に責任を負う契約、準委任は業務の遂行に責任を負う契約です。「固まっていないものは準委任、固まったものは請負」を基本に、要件定義は準委任・本開発は請負・保守は準委任、と工程で使い分けるのが実務の定石です。本記事の工程別早見表を、そのままお使いください。偽装請負を避けるため指揮命令の実態と契約をそろえ、検収条件・契約不適合責任・著作権の帰属まで契約書で確認しましょう。発注全体の流れはシステム開発の発注完全ガイド、要件の固め方は要件定義の進め方で解説しています。

（出典：民法632条（請負）・656条（準委任）／IPA「情報システム・モデル取引・契約書（第二版）」2020年12月公表）

契約形態でお悩みの場合は、現状の課題整理からお気軽にお問い合わせ・ご相談ください。