契約形態とは？雇用・業務委託・請負の種類と違いを分かりやすく解説

システム開発における契約形態の基本

システム開発を外部に委託する際、どの契約形態を選ぶかは、プロジェクトの責任範囲、費用、リスク分担に直結する重要な判断です。2025年現在、経済産業省の調査によると請負契約が全体の約60〜70%を占めていますが、アジャイル開発の普及に伴い準委任契約の採用も増加傾向にあります。まずは、主要な4つの契約形態の特徴を正しく理解しましょう。

請負契約のメリット・デメリット

請負契約は、受注者（開発会社）が特定の成果物を完成させて引き渡す義務を負う契約形態です。民法第632条に基づき、仕事の完成を目的としているため、発注者にとっては「何が、いつまでに、いくらで納品されるか」が明確になるという大きな安心感があります。

請負契約の最大のメリットは、予算と納期が確定することです。例えば、ECサイトの構築を総額3,000万円、納期6ヶ月という条件で発注した場合、開発会社は契約で定めた仕様通りのシステムを完成させる義務を負います。また、納品後に不具合が発見された場合も、瑕疵担保責任（契約不適合責任）により、一定期間は無償で修正を求めることができます。要件が明確に固まっている業務システムの置き換えや、予算が厳格に管理されているプロジェクトに最適な契約形態といえるでしょう。

一方、デメリットとしては、開発途中での仕様変更が難しい点が挙げられます。仕様変更が発生すると追加契約が必要となり、その都度費用と工数の再見積もりが発生します。2023年の東京地裁判決では、仕様が曖昧なまま請負契約を締結したことで検収トラブルに発展し、受注者が敗訴した事例もあります。請負契約を選ぶ際は、事前に仕様書を詳細に作成し、変更時の費用算定ルールを契約書に明記しておくことが重要です。

準委任契約のメリット・デメリット

準委任契約は、受注者が業務の遂行を誠実に行う義務を負う契約形態です。請負契約とは異なり、成果物の完成を保証するものではなく、「ベストエフォート型」の契約といえます。民法第656条に準拠しており、2020年の民法改正により「履行割合型」と「成果完成型」の2種類に分類されるようになりました。

履行割合型は、作業時間や工数に応じて報酬が支払われる形態で、アジャイル開発やPoC（概念実証）のように、要件が流動的なプロジェクトに適しています。例えば、AIチャットボットの開発でスプリントごとに機能を検証・改善していくような場合、準委任契約であれば柔軟に方向性を調整できます。新規事業の立ち上げやMVP（最小限の実用可能な製品）の構築など、試行錯誤が前提となるプロジェクトでは、準委任契約が有効な選択肢となります。

しかし、準委任契約には成果物が完成しないリスクがあります。工数ベースで費用が発生するため、想定以上に作業が長引くと予算オーバーになる可能性があります。JETROの2024年調査によると、準委任契約のプロジェクトで工数超過が発生する割合は約25%に上ります。このリスクを軽減するためには、週次での進捗報告を義務付けたり、工数の上限を設定したりするなど、契約時にコントロール手段を確保しておくことが重要です。

派遣契約のメリット・デメリット

派遣契約は、労働者派遣法に基づき、派遣会社から技術者を受け入れて業務を行わせる契約形態です。請負契約や準委任契約との最大の違いは、発注者（派遣先企業）が派遣されたエンジニアに対して直接指揮命令を行える点にあります。

派遣契約のメリットは、自社のチームに組み込む形で開発を進められることです。社内のプロジェクトマネージャーが直接作業指示を出せるため、細かな調整やコミュニケーションが取りやすくなります。また、一時的な人員増強が必要な場合や、特定のスキルを持つエンジニアをピンポイントで確保したい場合にも有効です。社内にシステム開発の知見があり、マネジメント体制が整っている企業にとっては、柔軟にリソースを確保できる選択肢となります。

一方、派遣契約のデメリットとしては、派遣先企業の管理負担が大きくなることが挙げられます。作業指示から進捗管理まで自社で行う必要があり、社内にプロジェクト管理能力がないと十分に活用できません。また、派遣期間に上限がある点や、派遣料金には派遣会社のマージンが含まれる点から、長期的にはコストが高くなる可能性もあります。

SES契約と準委任契約との違い

SES（システムエンジニアリングサービス）契約は、IT業界で広く使われている契約形態ですが、法的には準委任契約の一形態として位置づけられます。SES契約では、受注者（SES企業）が技術者を発注者のプロジェクトに参画させ、その労務提供に対して報酬を受け取ります。

SES契約と一般的な準委任契約の違いは、主に契約の対象にあります。準委任契約は「業務の遂行」を対象とするのに対し、SES契約は「技術者の労働力の提供」に重点が置かれます。SES契約では技術者が発注者のオフィスに常駐して作業を行うケースが多い点が挙げられます。

ここで注意すべきは、SES契約と派遣契約の線引きです。SES契約において、発注者が技術者に対して直接指揮命令を行うと「偽装請負」と見なされる可能性があります。法的には、SES契約の技術者に対する作業指示はSES企業を通じて行う必要があります。SES契約を利用する際は、指揮命令系統を明確にし、契約書に作業指示の方法を明記しておくことでトラブルを回避できます。

システム開発の契約形態を選ぶ際の判断基準

契約形態の基本を理解したところで、次に重要なのは「自社のプロジェクトにはどの契約形態が適しているのか」を判断する基準です。プロジェクトの特性や自社の状況に応じて、最適な契約形態は異なります。以下のフローチャートと判断基準を参考に検討してください。

【契約形態選択フローチャート】

1. 要件定義は完了していますか？ → はい：ステップ2へ / いいえ：準委任契約（履行割合型）を推奨
2. 予算は固定で管理する必要がありますか？ → はい：ステップ3へ / いいえ：準委任契約を検討
3. 開発中に仕様変更が発生する可能性は？ → 低い：請負契約を推奨 / 高い：準委任契約（成果完成型）または段階的な請負契約を検討
4. 社内にプロジェクト管理能力がありますか？ → はい：派遣契約・SES契約も選択肢に / いいえ：請負契約または準委任契約を推奨

プロジェクトの規模や要件定義の明確さ

契約形態を選ぶ最初の判断基準は、プロジェクトの規模と要件定義の明確さです。IPA（情報処理推進機構）のガイドラインでは、要件定義の明確度を数値化し、80%以上であれば請負契約、50%未満であれば準委任契約を推奨しています。

在庫管理システムや会計システムなど、既存の業務フローが確立されており、必要な機能が明確に洗い出せるプロジェクトは請負契約に適しています。このようなプロジェクトでは、100ページ以上の詳細な仕様書を作成し、画面設計や機能一覧、性能要件まで事前に確定させることが可能です。

一方、新規事業向けのサービス開発やAI・機械学習を活用したシステムなど、開発しながら要件を詰めていく必要があるプロジェクトは準委任契約が適しています。要件定義フェーズを準委任契約で実施し、要件が固まった段階で開発フェーズを請負契約に切り替える「ハイブリッド型」も、実務では広く採用されています。このアプローチにより、初期段階の柔軟性と開発段階の予算確定を両立できます。

開発期間とコスト管理の観点

開発期間とコスト管理の観点も、契約形態選択の重要な判断基準です。特に予算が厳格に管理されている場合や、経営層への報告において総額を確定させる必要がある場合は、請負契約が適しています。

請負契約では、見積もり段階で総額が確定するため、予算管理がシンプルになります。例えば、年間予算1億円のIT投資計画の中で、ERPシステム導入に3,000万円を割り当てる場合、請負契約であれば予算内に収まることが契約上保証されます。ただし、仕様変更が発生した場合の追加費用は別途必要となるため、変更管理のルールを事前に取り決めておくことが重要です。

準委任契約は工数ベースで費用が発生するため、プロジェクトの進行状況によって最終的なコストが変動します。コスト管理の観点からは、月次での工数上限を設定したり、一定金額に達した時点で継続判断を行う「ゲート方式」を導入したりすることが有効です。短期間でのMVP構築や、試行錯誤を前提としたPoC開発では、期間を区切った準委任契約により、リスクをコントロールしながら柔軟に開発を進められます。

リスク分担と責任範囲の考慮

契約形態によって、発注者と受注者のリスク分担は大きく異なります。この点を理解した上で、自社のリスク許容度に合った契約形態を選択することが重要です。

請負契約では、成果物の完成責任は受注者が負います。納期遅延や品質不良が発生した場合、受注者は契約上の責任を問われます。発注者にとっては、リスクが限定的になる反面、受注者が抱えるリスクが大きいため、見積もり金額は高くなる傾向があります。また、受注者がリスクを回避するために、仕様変更に対して消極的になる可能性もあります。

準委任契約では、成果物の完成責任は発注者側にシフトします。受注者は誠実に業務を遂行する義務を負いますが、成果が出なくても工数分の報酬は発生します。このため、発注者には積極的にプロジェクトをマネジメントし、成果を引き出す責任が求められます。自社にプロジェクト管理の知見がない場合は、上流工程から伴走してくれるパートナーを選ぶことで、準委任契約のリスクを軽減できます。

関連記事はこちら： 実は落とし穴だらけ？中堅・中小企業のDXに潜む9つのデメリットと対応策

システム開発の契約形態で失敗しないための注意点

契約形態を選んだ後、実際に契約を締結する段階では、細部の取り決めが極めて重要になります。経済産業省の2024年報告によると、契約形態のミスマッチや契約内容の曖昧さがプロジェクト失敗の約25%の原因とされています。ここでは、契約書作成時の重要項目とトラブル事例、そして契約形態変更時の手続きについて解説します。

契約書に明記すべき重要項目

契約形態に関わらず、システム開発契約書には以下の項目を明確に記載することが不可欠です。特に「再委託の可否」「知的財産権の帰属」「瑕疵担保責任（契約不適合責任）」の3点は、トラブルの温床になりやすい項目です。

1. 再委託の可否
受注者が開発作業の一部または全部を第三者に委託できるかを定めます。再委託を認める場合は、再委託先の選定基準や、発注者への事前承認の要否、再委託先の行為に対する受注者の責任を明記します。

【条項例】
受注者は、発注者の書面による事前承認なく、本業務の全部または一部を第三者に再委託してはならない。なお、再委託を行う場合、受注者は再委託先の行為について一切の責任を負う。

2. 知的財産権の帰属
開発したシステムの著作権がどちらに帰属するかを明確にします。法律上、成果物の著作権は原則として受注者（開発会社）に帰属するため、発注者に移転させたい場合は明示的な条項が必要です。

【条項例】
本開発により生じた成果物の著作権（著作権法第27条及び第28条の権利を含む）は、対価の支払い完了時に発注者に移転する。なお、受注者は発注者に対し著作者人格権を行使しない。

3. 瑕疵担保責任（契約不適合責任）
請負契約で特に重要となります。納品後に発見された不具合について、どの範囲まで、いつまで無償修正の対象とするかを定めます。

【条項例】
受注者は、検収完了日から1年間、成果物が仕様書に適合しない場合（以下「契約不適合」という）について、無償で修正を行う義務を負う。ただし、発注者の責めに帰すべき事由による契約不適合はこの限りでない。

契約形態ごとのトラブル事例

実際にどのようなトラブルが発生しているのか、契約形態ごとの代表的な事例を確認しておきましょう。これらの事例を知ることで、契約締結時に注意すべきポイントが明確になります。

• 請負契約：「検収拒否」トラブル
  2023年の東京地裁判決では、仕様書の記載が曖昧だったために、発注者と受注者の間で「完成」の定義が食い違い、検収を巡る紛争に発展しました。仕様書には機能一覧だけでなく、性能要件（レスポンス時間、同時接続数など）、検収基準（UAT通過条件）、変更時の追加料金表を具体的に記載しておくことが重要です。
• 準委任契約：「完成義務の誤解」トラブル
  2024年の大阪高裁判決では、準委任契約であるにもかかわらず、発注者が「成果物を完成させる義務がある」と主張して敗訴した事例があります。準委任契約を締結する際は、契約書冒頭に「本契約は民法第656条に準拠する準委任契約であり、受注者は善管注意義務をもって業務を遂行するが、成果物の完成を保証するものではない」と明記することで、後の紛争を防止できます。
• SES契約：「偽装請負」トラブル
  発注者が技術者に対して直接作業指示を出すと、実態として労働者派遣とみなされ、労働者派遣法違反となる可能性があります。SES契約を利用する場合は、作業指示はSES企業の管理者を通じて行い、勤怠管理もSES企業が行う体制を明確にしておく必要があります。

途中で契約形態を変更する場合の手続き

プロジェクトの進行に伴い、当初選択した契約形態が適さなくなるケースも少なくありません。例えば、準委任契約で開始した要件定義フェーズが完了し、開発フェーズでは請負契約に切り替えたい場合などです。

契約形態を途中で変更する際は、既存契約の終了手続きと新規契約の締結を適切に行う必要があります。

1. 既存契約の精算：変更時点までの作業範囲と成果物を明確にし、精算条件を確認します。準委任契約から移行する場合、成果物（要件定義書など）の検収を行い、次期契約のベースとします。
2. 新規契約の締結：これまでの経緯を踏まえた条項を盛り込みます。特に、前のフェーズで作成した成果物の知的財産権の帰属確認や、責任範囲の切り分けを明記します。

契約形態の変更は、発注者・受注者双方にとって重要な節目となるため、第三者（弁護士やITコンサルタント）のレビューを受けることも検討に値します。

なお、契約形態の変更が頻繁に発生する場合は、当初の契約形態選択自体を見直す必要があるかもしれません。プロジェクト全体を俯瞰し、適切な契約形態とフェーズ分けを提案してくれるパートナーの存在は、このような判断において大きな助けとなります。上流工程から開発、運用・保守まで一貫して支援できる開発会社であれば、プロジェクトの各段階に最適な契約形態を提案し、スムーズな移行をサポートしてくれるでしょう。

まとめ

本記事では、システム開発における契約形態の基本から、選び方の判断基準、契約時の注意点まで詳しく解説してきました。請負契約は成果物の完成が保証され予算管理がしやすい反面、仕様変更への柔軟性が低く、準委任契約は要件変更に柔軟に対応できる反面、コスト管理や成果保証の面でリスクがあることをご理解いただけたかと思います。

最も重要なのは、自社のプロジェクト特性を正確に把握し、それに合った契約形態を選択することです。要件定義の明確度、予算管理の厳格さ、社内のプロジェクト管理能力などを総合的に判断し、必要に応じてフェーズごとに契約形態を使い分けるハイブリッドアプローチも検討してください。また、契約書には「再委託の可否」「知的財産権の帰属」「瑕疵担保責任」の条項を明確に記載し、後のトラブルを未然に防ぐことが不可欠です。

契約形態の選択は、開発パートナー選びと切り離せない関係にあります。単に開発を請け負うだけでなく、御社のビジネスを深く理解し、プロジェクトの各段階に最適な契約形態を提案してくれるパートナーを選ぶことが、DX推進成功への近道です。契約形態の選び方や開発パートナー選定でお悩みの方は、ぜひ専門家への相談を検討してみてください。