システム開発の契約種類と違い｜請負・準委任・SESを発注者視点で比較

発注側が契約形態を理解すべき理由——「任せたはずが責任を負う」事態を防ぐために

システム開発を外注する際、契約書の内容を十分に確認しないまま「あとはお任せします」と進めてしまうケースは少なくありません。しかし、契約形態の違いを理解していないと、開発が完了しても想定外のコストが発生したり、品質上の問題が生じたときに誰が責任を負うのかが曖昧になったりする事態を招きます。

たとえば、準委任契約で開発を依頼した場合、ベンダーには「作業を誠実に行う義務」はありますが、成果物の完成を保証する義務はありません。発注者が「完成して当然」と思い込んでいると、納品トラブルが発生したときに法的な根拠を持って対応できなくなります。これは契約形態への無理解が直接引き起こすリスクです。

システム開発の契約形態には、大きく分けて次の3種類があります。

• 請負契約：成果物の完成をベンダーが約束する形態
• 準委任契約：作業プロセスの遂行を委託する形態
• SES（システムエンジニアリングサービス）：エンジニアの稼働時間を確保する形態

この3種類は、成果物の保証範囲・責任の所在・費用の発生タイミングがそれぞれ根本的に異なります。どの契約形態を選ぶかによって、プロジェクトの進め方や発注者が負うリスクの大きさも変わってきます。

本記事では、各契約形態の定義と特徴を整理したうえで、発注者視点での比較・選定基準、そして契約締結前に確認すべきポイントまでを順に解説します。システム開発の外注を検討している情報システム担当者や経営者が、ベンダーとの交渉・発注判断を自信を持って行えるようにするための判断軸を提供します。

システム開発の契約形態は大きく3種類——まず全体像を把握する

請負契約・準委任契約・SESの位置づけ

システム開発の外注契約は、大きく請負契約・準委任契約・SES（システムエンジニアリングサービス）の3形態に分類されます。それぞれの根拠法と典型的な利用シーンを押さえておくことが、発注判断の出発点になります。

請負契約は民法632条を根拠とし、成果物の完成を受注者が約束する契約です。要件が固まっている開発フェーズや、納品物が明確なシステム構築案件で多く用いられます。

準委任契約は民法656条（643条準用）を根拠とし、作業プロセスそのものを委託する形態です。要件定義・コンサルティング・保守運用など、成果物を事前に確定しにくいフェーズで選ばれるケースが少なくありません。

SESは労働者派遣法ではなく民法上の準委任契約の一形態として位置づけられます。ただし、エンジニアが発注者先に常駐して稼働する点が特徴で、人材の稼働時間を確保したいケースや、内製チームの補強に活用されます。指揮命令権は受注者（SESベンダー）側に留まる点が、派遣契約との法的な相違点です。

3形態を一目で比較する——報酬・責任・指揮命令の観点から

3形態の違いは、報酬の発生条件・受注者の責任範囲・指揮命令権の所在という3つの軸で整理すると理解しやすくなります。

• 報酬：請負は成果物の完成が条件。準委任・SESは作業時間や稼働量に応じて発生します。
• 責任：請負は成果物に対する瑕疵担保責任（契約不適合責任）を負います。準委任・SESは善管注意義務の履行が求められますが、成果物の完成は保証されません。
• 指揮命令：請負・準委任・SESのいずれも、指揮命令権は原則として受注者側にあります。発注者が直接エンジニアに業務指示を出すと、偽装請負として労働者派遣法違反になるリスクがある点に注意が必要です。

後続のセクションでは、各契約形態の特性・リスク・選び方を発注者視点でさらに詳しく掘り下げていきます。

請負契約——成果物の完成を約束する契約形態

請負契約の仕組みと報酬体系

請負契約とは、ベンダーが「仕事の完成」を約束し、発注者がその対価として報酬を支払う契約形態です。民法第632条に規定されており、システム開発においては「要件定義書・設計書に基づいたシステムを納品する」ことが契約上の義務になります。

報酬体系は固定費用型が基本です。契約時点で総額を合意するため、発注者は予算を確定しやすく、稟議や社内調整が通しやすいという実務上のメリットがあります。一括請負（プロジェクト全体を一契約で発注）のほか、要件定義・基本設計・詳細設計・開発・テストといったフェーズごとに契約を分割する「フェーズ分割型」も採用されるケースが少なくありません。

発注者が得るメリット——成果物保証と費用の予見性

請負契約における発注者の最大のメリットは、成果物の完成義務をベンダーに負わせられる点です。ベンダーは納品物が契約内容を満たさない限り、報酬を請求する権利を得られません。作業時間ではなく「完成した成果物」に対して対価を支払う構造であるため、発注者にとっては成果物の品質を担保しやすい形態といえます。

また、費用の予見性が高いことも大きな利点です。プロジェクト開始前に総額が確定するため、コスト超過リスクを一定程度ベンダー側に転嫁できます。

請負契約で発生しやすいリスク——要件変更と追加費用の構造

一方で、請負契約には発注者が注意すべきリスクも存在します。固定費用型である以上、契約後に要件が変更・追加された場合は、別途変更契約（追加発注）が必要になります。要件定義が不十分なまま契約を締結すると、開発途中で仕様の解釈が食い違い、追加費用の請求や納期遅延、最悪の場合は訴訟に発展するケースもあります。

特に注意が必要なのは、発注者側の要件定義の精度がそのまま契約リスクに直結する点です。「なんとなくこういうシステムが欲しい」という状態で請負契約を結ぶと、ベンダーとの認識齟齬が生じやすく、費用・品質・納期のすべてで問題が顕在化しやすくなります。

契約不適合責任（旧：瑕疵担保責任）とは何か

請負契約には、契約不適合責任が発生します。2020年の民法改正以前は「瑕疵担保責任」と呼ばれていたもので、納品された成果物が契約の内容に適合しない場合、発注者はベンダーに対して以下の対応を求めることができます。

• 追完請求：不具合の修正や不足機能の追加を求める
• 代金減額請求：不適合の程度に応じて報酬を減額する
• 損害賠償請求：損害が生じた場合に賠償を求める
• 契約解除：重大な不適合がある場合に契約を解消する

ただし、契約不適合責任が機能するには「何をもって契約に適合しているか」が契約書や要件定義書に明確に記載されている必要があります。曖昧な仕様書のまま発注した場合、不適合の判断基準が定まらず、責任の所在が不明確になりがちです。請負契約の保護機能を実際に活用するためにも、要件定義の精緻化は発注者側の重要な事前作業といえます。

準委任契約——作業プロセスを委託する契約形態

準委任契約の仕組みと善管注意義務

準委任契約は、成果物の完成ではなく、一定の業務を誠実に遂行することを約束する契約形態です。民法上の「委任」に準じた契約であり、受託者には善管注意義務（善良な管理者の注意義務）が課されます。

善管注意義務とは、その業務の専門家として期待される水準の注意を払って作業にあたる義務のことです。つまり、成果物が完成しなくても契約違反にはなりませんが、専門家として不適切な作業をした場合は責任を問われる可能性があります。

請負契約との最大の違いは、「何を作るか」ではなく「どのように働くか」を委託する点にあります。発注者は作業の過程や方向性に関与しやすい一方、成果物の完成を契約上の義務として求めることはできません。

履行割合型と成果完成型——2020年民法改正で明確になった2つの区分

2020年の民法改正（債権法改正）により、準委任契約は「履行割合型」と「成果完成型」の2種類に明文化されました。

• 履行割合型：作業した時間・工数に応じて報酬が発生する。成果物の完成は問わない。月次の稼働時間に対して費用が精算される形式が典型例。
• 成果完成型：一定の成果（例：要件定義書の納品）が達成された時点で報酬が発生する。成果物の完成責任は問わないが、成果が出なければ報酬請求ができない。

改正前は、この2区分が法律上明確ではなかったため、報酬発生のタイミングをめぐるトラブルが起きやすい状況でした。契約書を確認する際は、どちらの類型に該当するかを必ず確認しておく必要があります。

アジャイル開発・上流工程との相性が高い理由

準委任契約は、要件定義・基本設計などの上流工程や、アジャイル開発の現場で多く活用されています。その理由は、これらのフェーズでは「最終的な成果物」を事前に確定しにくいという特性があるためです。

上流工程では、ヒアリングや調査を通じて仕様を固めていく作業が中心になります。最終的なドキュメントの内容は、プロセスを経てはじめて決まるため、着手時点で成果物を明確に定義することが難しいケースがほとんどです。

アジャイル開発においても同様で、スプリントごとに仕様を変更・調整しながら開発を進めるため、請負契約のように完成物を固定することが実態に合いません。準委任契約であれば、仕様変更が生じても契約の根拠を損なわずに対応できるという柔軟性があります。

準委任契約で発注者が注意すべきコスト管理の問題

準委任契約は仕様変更への柔軟な対応が利点である一方、発注者にとってコスト管理が難しくなるリスクをはらんでいます。

費用は時間単価（人工単価）×稼働時間で精算されるため、プロジェクトが当初の想定より長引けば、その分だけコストが膨らみます。作業が非効率であっても、受託者が善管注意義務を満たしている限り、発注者が費用を拒否する根拠は薄くなります。

この問題を防ぐために、発注者側では以下の点を確認・整備しておくことが重要です。

• 月次の稼働時間の上限（時間上限の設定）を契約書に明記する
• 定期的な進捗報告の頻度・形式を事前に合意しておく
• フェーズ区切りでの成果確認（マイルストーン）を設ける
• 成果完成型の準委任契約が適用できるフェーズであれば、その類型を選択する

準委任契約は「任せた以上は費用がかかり続ける」構造を持っています。発注者が作業の進捗と費用の関係を可視化できる仕組みを整えておくことが、コスト超過を防ぐうえで不可欠です。

SES（システムエンジニアリングサービス）——人材の稼働を確保する契約形態

SES（システムエンジニアリングサービス）は、エンジニアの稼働時間そのものを購入する契約形態です。請負契約のように「成果物の完成」を約束するものでも、準委任契約のように「業務遂行の委任」を受けるものでもありません。あくまでも「一定期間・一定時間、エンジニアの工数を確保する」ことが契約の本質です。

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

SESと準委任契約は混同されやすいですが、契約の性質は異なります。準委任契約は民法上の「委任」に基づき、受注者が善管注意義務を負いながら業務を遂行します。一方、SESは商慣行として普及した契約形態であり、法的な分類上は準委任に近い扱いをされるケースが多いものの、実態としては「エンジニアの稼働枠を確保する」という人材調達的な色合いが強くなります。

費用の算定方法も異なります。SESでは月ごとの稼働時間（例：140〜180時間）に対して単価を設定し、超過・不足分を精算する形が一般的です。成果物の品質や業務の達成度ではなく、「何時間稼働したか」が対価の基準になります。

指揮命令権の所在——発注者が陥りやすい偽装請負のリスク

SESにおいて発注者が最も注意すべきなのが、指揮命令権の問題です。SES契約では、エンジニアへの作業指示は受注側（SES会社）が行うのが原則です。発注者がエンジニアに対して直接「この作業を今日中にやってほしい」「この仕様に変更してほしい」と指示を出すと、実態として労働者派遣に該当するとみなされるリスクがあります。

これが「偽装請負」と呼ばれる問題です。労働者派遣法では、派遣として働く場合には派遣元・派遣先双方に対して一定の義務と規制が課されます。SES契約を結びながら実態が派遣であれば、法令違反となり得ます。発注者側が無意識にルールを破っているケースも少なくないため、作業指示の伝え方には慎重さが求められます。

• 指示はエンジニア個人ではなく、SES会社の担当者（エンジニアリングマネージャーなど）を経由して伝える
• 「どのタスクをどの順番でやるか」という作業管理は受注側に委ねる
• 発注者は要件・優先度を伝えることに徹し、具体的な作業指示は控える

上記のような運用を徹底することが、偽装請負リスクを回避するうえでの基本的な対応になります。

SESが適しているケースと適していないケース

SESは、以下のような場面で機能しやすい契約形態です。

• 内製チームの一時的な補強：自社に開発チームはあるものの、特定フェーズだけ人手が足りない場合に、工数を外部から補う目的で活用できます。
• 特定スキルの短期調達：セキュリティ診断やインフラ構築など、自社に知見のない専門スキルを一定期間だけ借りたいケースに向いています。
• 開発規模が流動的なプロジェクト：仕様が固まっておらず、請負契約として成果物を定義しにくい段階での開発補助にも使われます。

一方、SESが適しにくいケースもあります。プロジェクト全体の設計・管理・完成責任を外部に求めたい場合は、SESでは対応できません。また、発注者側にエンジニアリングの知識がなく、作業管理・要件整理をすべて受注側に任せたいのであれば、SESよりも請負や準委任のほうが契約の目的と実態が一致します。SESは「発注者がある程度、開発の文脈を理解したうえで工数を活用できる」ことが前提になる契約形態です。

3形態の詳細比較——責任・費用・リスクを発注者視点で整理する

3つの契約形態はそれぞれ定義が異なるだけでなく、発注者が負うリスクの種類と大きさも異なります。以下では、意思決定に直結する4つの軸で整理します。

比較軸①　成果物の完成責任

請負契約では、受注者が成果物の完成を法的に義務付けられています。仮にシステムが動作しない状態で納品された場合、発注者は修補請求・代金減額・損害賠償を求めることができます。

一方、準委任契約とSESは「作業・稼働の提供」が契約の目的です。成果物の完成は義務ではなく、プロジェクトが途中で停止しても受注者側の債務不履行にはなりません。「任せたはずなのに完成しなかった」というトラブルの多くは、この区別の理解不足から生じています。

比較軸②　費用精算の方式と予見性

請負契約は原則として固定報酬です。見積金額が上限となるため、予算管理がしやすい反面、要件が曖昧なまま発注すると追加費用の交渉が発生しやすくなります。

準委任契約とSESは月額・時間単価による変動精算が一般的です。作業量に応じて費用が増減するため、長期プロジェクトでは総額が読みにくくなるケースがあります。

比較軸③　仕様変更への対応コスト

請負契約では、契約締結後の仕様変更は原則として追加費用・納期延長の交渉を要します。変更のたびに契約変更手続きが発生するため、要件が固まっていないフェーズでは運用コストが高くなります。

準委任契約とSESは稼働時間を購入する形式に近いため、方向転換や仕様変更への対応は相対的に柔軟です。ただし、変更対応に追加工数がかかれば費用は増加します。

比較軸④　法的リスク（契約不適合責任・偽装請負）

請負契約では、納品後に不具合が判明した場合、民法上の契約不適合責任が発注者の権利として発生します。ただし、発注者が仕様を細かく指示していた場合は責任の所在が曖昧になることもあります。

SESで注意すべき法的リスクが「偽装請負」です。SESは本来、受注者側の企業が労働者を指揮命令する形態です。発注者が直接エンジニアに作業指示を出すと、労働者派遣法違反とみなされるリスクがあります。SESエンジニアに対して日常的に業務命令を出している場合、意図せず法令違反の状態になっているケースは少なくありません。

以下に4軸の比較をまとめます。

• 成果物の完成責任：請負は「あり」、準委任・SESは「なし」
• 費用精算：請負は固定報酬、準委任・SESは変動精算（時間・月額）
• 仕様変更対応：請負は都度交渉が必要、準委任・SESは比較的柔軟
• 主な法的リスク：請負は契約不適合責任、SESは偽装請負リスク

発注者にとって重要なのは、これらのリスクが「どの契約形態を選ぶか」だけでなく「契約書の中身をどう設計するか」にも左右される点です。契約形態の選択は、リスク管理の出発点に過ぎません。

発注者はどの契約形態を選ぶべきか——プロジェクト特性別の判断基準

契約形態の特性を理解したうえで、次に問われるのは「自社のプロジェクトにどれを選ぶか」という実務判断です。「要件が固まっていれば請負、探索的なら準委任、スキル補強ならSES」という整理は概ね正しいものの、実際のプロジェクトはこの単純な分類に収まらないケースが少なくありません。以下では、判断に影響する5つの軸を示したうえで、フェーズごとに契約形態を組み合わせる設計例にも触れます。

要件の確定度で選ぶ——ウォーターフォール型は請負、アジャイル型は準委任が基本

最初に確認すべきは、要件がどの程度固まっているかです。画面仕様・機能一覧・非機能要件まで文書化できている場合は、成果物の完成責任をベンダーに負わせる請負契約が機能します。開発範囲と納期を契約に明記できるため、予算管理がしやすくなります。

一方、要件が流動的な場合や、ユーザーインタビューを繰り返しながら仕様を固めていくアジャイル型の開発では、請負契約は適しません。スプリントごとに仕様が変わる状況で「成果物の完成」を約束させることは、ベンダー側のリスクを高め、結果として見積もりが膨らむか、品質が犠牲になるかのどちらかになりがちです。この場合は、作業プロセスそのものを委託する準委任契約のほうが実態に合っています。

フェーズ分割で契約形態を組み合わせる——上流は準委任・開発本体は請負の設計例

実務でよく機能するのが、フェーズごとに契約形態を切り替えるアプローチです。たとえば以下のような設計が考えられます。

• 要件定義・基本設計フェーズ（準委任）：ベンダーの知見を借りながら要件を整理する段階。成果物を確定できないため、工数単位で委託する準委任が適切です。
• 詳細設計・開発・テストフェーズ（請負）：要件が固まった段階で請負に切り替え、成果物の完成責任をベンダーに負わせます。予算の上限も明確になります。
• リリース後の保守・運用フェーズ（準委任またはSES）：発生ベースの対応が中心になるため、月次工数での準委任か、継続的な内製サポートが必要であればSESが選択肢に入ります。

このフェーズ分割の設計は、要件定義の質がそのまま請負フェーズのリスク管理に直結するという意味でも、発注者にとって合理的な選択です。

内製チームを持つ企業がSESを活用する判断基準

SESが有効に機能するのは、自社にある程度の技術的判断能力がある場合です。具体的には、以下のような状況が該当します。

• 内製チームが存在するが、特定技術領域（例：クラウドインフラ、セキュリティ設計）のスキルが一時的に不足している
• プロジェクトのピーク期だけリソースを追加したい
• 正社員採用では対応が難しいニッチなスキルセットが必要な期間が限られている

逆に、内製チームを持たず技術的な指示出しができない場合にSESを選ぶと、エンジニアの稼働管理が発注者側に委ねられる構造上、プロジェクトが機能しないリスクがあります。SESは「リソースの調達手段」であり、「プロジェクト推進の手段」ではない点を押さえておく必要があります。

システム開発の契約形態の選び方は、プロジェクトの性質・フェーズ・自社のリソース構成という3つの要素を組み合わせて判断するのが実態に即したアプローチです。単一の契約形態にこだわるよりも、フェーズごとに最適な形態を設計する発想が、発注者のリスク管理につながります。

契約締結前に発注者が確認すべきポイント——トラブルを防ぐチェックリスト

契約形態を選んだあとも、締結前に細部を確認しておかなければ、後から「聞いていなかった」「想定と違った」というトラブルに直面するケースは少なくありません。以下の3点は、システム開発の契約で特に見落とされやすい論点です。

検収基準と瑕疵対応期間の明文化

請負契約では成果物の「完成」が報酬の支払い条件になります。しかし契約書に検収基準が記載されていないと、「完成」の定義をめぐってベンダーと発注者の認識が食い違うリスクがあります。

契約書には、検収期間（例：納品後2週間以内）・検収手順・合否判定の基準を具体的に明記してください。あわせて、検収後に発覚した不具合への対応期間（瑕疵担保責任期間）も設定します。民法上の規定はありますが、システム開発では契約で個別に期間を定めるのが実務上の慣行です。

知的財産権（ソースコード・設計書）の帰属を明確にする

システム開発で見落とされがちなのが、ソースコードや設計書の著作権がどちらに帰属するかです。契約書に明示がない場合、著作権は制作者（受託側）に残るのが原則です。発注者が納品物を自社で改修・流用しようとしたとき、権利上の問題が生じる可能性があります。

また、開発に使われるオープンソースソフトウェア（OSS）や第三者ライブラリのライセンス条件も確認が必要です。ライセンスの種類によっては、ソースコードの公開義務が生じるものもあります。受託側にライブラリの使用一覧と各ライセンスの開示を求めることを推奨します。

• ソースコード・設計書・テスト仕様書の著作権を発注者に譲渡する旨を明記する
• 利用するOSS・サードパーティライブラリの一覧と、各ライセンス条件の確認を求める
• 「成果物」の定義を契約書に列挙し、範囲を曖昧にしない

再委託・SES活用時の偽装請負リスクを契約で防ぐ方法

ベンダーが業務の一部を別会社に再委託したり、SESエンジニアを組み合わせてチームを構成したりするケースは珍しくありません。しかし発注者がSESエンジニアに直接指揮命令を行うと、偽装請負と判断されるリスクがあります。これは労働者派遣法違反にあたり、発注者側も責任を問われる可能性があります。

契約書には以下の事項を盛り込んでおくことが有効です。

• 再委託の可否と、可とする場合の事前承認義務を明記する
• SESを活用する場合は、指揮命令系統がベンダー側にあることを契約上・運用上ともに徹底する
• 途中解約の条件と、その際の費用精算ルール（作業済み分の取り扱いなど）を事前に合意しておく

これらの条項は、交渉段階でベンダーに確認・修正を求めることができます。契約書のひな形をベンダーが用意するケースが多いですが、発注者側がレビューできる体制を整えておくことが、システム開発におけるリスク管理の基本です。

まとめ——契約形態の理解は発注者のリスク管理の起点になる

請負契約・準委任契約・SESの3形態は、それぞれ「成果物の完成責任を負うか」「作業プロセスを委託するか」「人材の稼働を確保するか」という点で本質的に異なります。発注者にとって重要なのは、この違いがコスト・品質・納期のリスク配分を直接左右するという事実です。

選び方の基本的な判断軸は次の3点に集約されます。

• 要件が固まっているか——明確なら請負契約、曖昧なまま進めるなら準委任契約が現実的です
• 成果物の完成責任を求めるか——求めるなら請負契約、プロセス支援が主目的なら準委任契約を選びます
• 人材の継続的な確保が優先か——内製支援や長期常駐が必要な場面ではSESが適しています

契約形態の選択を「ベンダーに任せる判断」と捉えている発注者は少なくありませんが、それ自体がリスクの入口になります。トラブルが起きた後に契約書を確認するのではなく、発注前の段階でベンダーと契約形態について議論することが、コスト超過・品質問題・納期遅延を防ぐ根本的な手段です。

CLANEがプロジェクトに関与する際も、要件の確度やプロジェクト性格に応じて契約形態を発注者と事前に整理することを重視しています。契約形態の理解は、発注者がベンダーと対等に交渉するための前提知識であり、リスク管理の起点となります。