システム開発を外部に発注する際、最も重要な判断の一つが「契約形態の選択」である。請負契約、準委任契約、SES契約の3つは、責任範囲、費用構造、リスクの所在がまったく異なる。契約形態を誤ると、「完成物が納品されない」「追加費用が際限なく発生する」「品質に問題があっても責任を追及できない」といったトラブルに発展する。
本記事では、3つの契約形態の違いを法的根拠まで踏み込んで解説し、フェーズごとの使い分け方、実際のトラブル事例と対策を具体的に示す。
目次
- 3つの契約形態の基本
- 比較テーブル：7つの観点で徹底比較
- 請負契約の詳細
- 準委任契約の詳細
- SES契約の詳細
- フェーズごとの契約形態の使い分け
- トラブル事例と対策
- 契約書チェックポイント
- よくある質問（FAQ）
1. 3つの契約形態の基本
請負契約
民法第632条に基づく契約。受注者（ベンダー）が「仕事の完成」を約束し、発注者がその完成に対して報酬を支払う。成果物（システム）の完成義務と瑕疵担保責任（2020年民法改正後は「契約不適合責任」）がベンダー側にある。
準委任契約
民法第656条・第643条に基づく契約。ベンダーが「善良な管理者の注意をもって事務を処理する」ことを約束する。仕事の完成義務はなく、作業時間や工数に対して報酬を支払う。2020年の民法改正で「成果完成型」の準委任契約も認められた。
SES契約（システムエンジニアリングサービス）
法律上の独立した契約類型ではなく、実態としては準委任契約の一形態。エンジニアを発注者先に常駐させ、技術力を提供するサービスである。労働者派遣法との関係で「偽装請負」のリスクがある点に注意が必要である。
2. 比較テーブル：7つの観点で徹底比較
| 観点 | 請負契約 | 準委任契約 | SES契約 |
|---|---|---|---|
| 完成義務 | あり（ベンダーが負う） | なし | なし |
| 報酬の対象 | 成果物（完成したシステム） | 作業時間・工数 | エンジニアの稼働時間 |
| 費用構造 | 固定価格（事前に確定） | 時間単価 × 稼働時間 | 月額単価 × 人数 |
| 費用リスク | ベンダーが負担（超過してもベンダー持ち） | 発注者が負担（工数が増えれば費用増） | 発注者が負担 |
| 品質責任 | ベンダー（契約不適合責任） | 善管注意義務のみ | 善管注意義務のみ |
| 指揮命令権 | ベンダーが保持 | ベンダーが保持 | ベンダーが保持（※注意点あり） |
| 途中解約 | 発注者可（損害賠償あり） | 双方可（いつでも可能） | 双方可（契約条件による） |
リスク対照表
| リスク | 請負契約 | 準委任契約 | SES契約 |
|---|---|---|---|
| 費用超過のリスク | 低い（ベンダー負担） | 高い（工数増=費用増） | 高い（期間延長=費用増） |
| 品質不足のリスク | 低い（責任追及可能） | 中程度（善管注意義務違反で追及） | 高い（品質保証なし） |
| 要件変更への柔軟性 | 低い（変更は追加費用） | 高い（スプリント単位で変更可） | 高い（都度対応可） |
| 納期遅延のリスク | 低い（遅延はベンダー責任） | 高い（完成義務なし） | 高い（完成義務なし） |
| コミュニケーションコスト | 低い（ベンダー主導） | 中程度（密な連携が必要） | 高い（自社でのマネジメント必要） |
| 偽装請負のリスク | 低い | 低い | 高い（要注意） |
3. 請負契約の詳細
メリット
- 費用が確定する：見積もり段階で合意した金額が最終的な支払額となる。予算の管理がしやすい
- 完成責任がベンダーにある：納品物が仕様を満たさない場合、ベンダーに修正を求められる
- 契約不適合責任：納品後に発見されたバグや仕様との不一致について、ベンダーに責任を追及できる（2020年改正民法では期間制限なし、ただし契約で定めるのが一般的。1年間が目安）
デメリット
- 要件変更が困難：開発途中での仕様変更は「追加見積もり」となり、費用と納期が増加する
- ブラックボックス化：開発プロセスがベンダー内部で進むため、進捗が見えにくい
- 見積もりにバッファが含まれる：リスクをベンダーが負う分、見積もり金額にリスクプレミアムが上乗せされる（10〜30%程度）
適用場面
| 適している | 適していない |
|---|---|
| 要件が明確に定まっている | 要件が曖昧・変更が多い |
| 予算の上限が厳密 | アジャイル開発を採用する |
| 標準的な業務システム | R&D・実験的なプロジェクト |
| 過去に類似の開発実績がある | 技術的な不確実性が高い |
費用相場
請負契約の場合、人月単価にリスクプレミアム（10〜30%）が上乗せされるのが一般的である。
| 役割 | 準委任での単価 | 請負での単価（目安） |
|---|---|---|
| SE（上級） | 100〜120万円/月 | 110〜150万円/月 |
| SE（中級） | 80〜100万円/月 | 90〜120万円/月 |
| PG（上級） | 70〜90万円/月 | 80〜110万円/月 |
| PG（中級） | 60〜80万円/月 | 70〜100万円/月 |
4. 準委任契約の詳細
メリット
- 要件変更に柔軟：仕様変更や優先順位の変更に追加費用なしで対応できる（ただし全体の工数枠内）
- 開発プロセスの透明性：発注者がスプリントレビュー等に参加し、進捗を直接確認できる
- リスクプレミアムが不要：完成義務がないため、ベンダーの見積もりにリスク上乗せがない
デメリット
- 費用が確定しない：工数が増えればそのまま費用が増加する。予算管理が難しい
- 完成の保証がない：「努力はしたが完成しなかった」場合でも、報酬の支払い義務がある
- 発注者のマネジメント力が必要：優先順位の判断、スコープの管理を発注者側で行う必要がある
適用場面
| 適している | 適していない |
|---|---|
| アジャイル開発 | 予算が厳密に決まっている |
| 要件が不確定な段階 | 発注者にITの知見がない |
| 要件定義・コンサルティング | 丸投げしたいプロジェクト |
| 継続的な保守・改善 | 一括納品を求めるプロジェクト |
費用管理のポイント
準委任契約で費用を管理するために、以下の仕組みを契約に含めることを推奨する。
| 管理手法 | 内容 | 効果 |
|---|---|---|
| 月次上限の設定 | 月あたりの稼働上限時間を契約で定める | 費用の青天井を防止 |
| マイルストーン報告 | 2週間ごとに進捗と残工数を報告 | 早期の逸脱検知 |
| スコープの書面管理 | 対応範囲の変更を都度書面で合意 | スコープクリープ（範囲の拡大）を防止 |
| 中間レビュー | 四半期ごとに成果と費用対効果を評価 | 継続・終了の判断材料を得る |
5. SES契約の詳細
メリット
- 必要な時に必要なスキルを調達できる：自社で雇用するリスクなく、専門スキルのエンジニアを確保できる
- 柔軟なチーム構成：プロジェクトの進行に合わせて、人数やスキルセットを変更できる
- 単価が比較的安い：完成義務や品質保証がないため、請負契約より単価が低い傾向がある
デメリット
- 品質保証がない：エンジニアの稼働時間に対して報酬を支払うため、成果物の品質は保証されない
- マネジメントは自社で行う必要がある：PM、技術レビュー、品質管理を自社で担う必要がある
- 偽装請負のリスク：発注者がSESエンジニアに直接指揮命令すると「偽装請負」に該当し、労働者派遣法違反となる
偽装請負の判断基準
SES契約では、以下の行為を発注者が行うと偽装請負と見なされるリスクがある。
| 行為 | 偽装請負に該当？ | 正しい対応 |
|---|---|---|
| SESエンジニアに直接作業指示 | 該当する | ベンダーのリーダーを通じて依頼 |
| SESエンジニアの出退勤管理 | 該当する | ベンダーが管理 |
| SESエンジニアの服務規律の管理 | 該当する | ベンダーが管理 |
| 作業場所・時間の指定 | グレーゾーン | 契約書に明記、ベンダーの判断で調整 |
| 技術的な質問への回答 | 該当しない | 通常のコミュニケーションとして許容 |
SESの費用相場
| スキルレベル | 月額単価 | 備考 |
|---|---|---|
| ジュニア（経験1〜3年） | 40〜60万円 | 指導が必要、定型作業向き |
| ミドル（経験3〜7年） | 60〜85万円 | 自走可能、設計〜実装 |
| シニア（経験7年以上） | 85〜120万円 | 技術リーダー、アーキテクチャ設計 |
| スペシャリスト（AI・クラウド等） | 100〜150万円 | 特定技術領域の専門家 |
6. フェーズごとの契約形態の使い分け
システム開発プロジェクト全体を1つの契約形態で通す必要はない。フェーズごとに最適な契約形態を選択する「ハイブリッド方式」が実務上の最適解である。
| フェーズ | 推奨契約形態 | 理由 |
|---|---|---|
| 企画・構想 | 準委任 | 要件が未確定。検討結果に対して報酬を支払う |
| 要件定義 | 準委任 | 要件を固める工程。成果物は「要件定義書」だが、完成の定義が曖昧 |
| 設計 | 請負 or 準委任 | 要件が固まっていれば請負。並行して要件調整が続く場合は準委任 |
| 開発（実装） | 請負 | 要件・設計が確定した後の実装は、請負で完成義務を負わせる |
| テスト | 請負 | テスト計画に基づく実行。完了基準が明確 |
| 保守・運用 | 準委任 | 継続的な対応。月額固定の準委任が適する |
| 技術支援・増員 | SES | 自社チームの補強。短期的なリソース確保 |
ハイブリッド方式の費用イメージ
中規模の業務システム開発（全体12ヶ月）を想定した費用配分例は以下の通りである。
| フェーズ | 契約形態 | 期間 | 費用 |
|---|---|---|---|
| 企画・要件定義 | 準委任 | 3ヶ月 | 300万円（SE 1名 × 100万円 × 3ヶ月） |
| 設計 | 請負 | 2ヶ月 | 250万円 |
| 開発・テスト | 請負 | 5ヶ月 | 1,200万円 |
| 導入・移行 | 請負 | 1ヶ月 | 150万円 |
| 安定化支援 | 準委任 | 1ヶ月 | 100万円 |
| 合計 | 12ヶ月 | 2,000万円 | |
| 保守運用 | 準委任 | 月額 | 30万円/月 |
7. トラブル事例と対策
事例1：請負契約で「完成」の定義が曖昧
状況：請負契約で業務システムを発注。納品後に「要件通りに動作しない」と指摘したが、ベンダーは「仕様通り」と主張。要件定義書の記載が曖昧で、どちらの解釈も可能だった。
原因：要件定義書における機能の記載粒度が粗く、「完成」の判定基準が明確でなかった。
対策：
- 受入テストの合格基準（テスト項目とパス条件）を契約書に添付する
- 要件定義書のレビューに社内の業務担当者を必ず参加させる
- 「仕様書に記載のない事項」の取り扱いルールを契約書に明記する
事例2：準委任契約で費用が2倍に膨張
状況：準委任契約でWebシステムを開発。当初6ヶ月・1,200万円の見込みが、要件の追加・変更が重なり12ヶ月・2,400万円に。
原因：発注者側のスコープ管理が甘く、「ついでにこれも」の依頼が頻発。月次の費用確認も行っていなかった。
対策：
- 月次の稼働報告書で「累計費用 vs 予算」を可視化する
- スコープ変更はすべて書面で合意し、追加工数を明示する
- 月額上限を設定し、超過時はアラートを上げる仕組みを構築する
事例3：SES契約で偽装請負を指摘された
状況：SES契約でエンジニア3名を受け入れ。自社のPMが直接タスクを割り振り、勤怠も管理していた。労働局の調査で「偽装請負」と指摘された。
原因：SES契約の形式だが、実態は労働者派遣と同じ運用をしていた。
対策：
- ベンダー側にリーダーを配置し、タスクの割り振りはリーダーを通じて行う
- 勤怠管理はベンダーが実施する
- SESではなく労働者派遣契約に切り替える（派遣法の適用を受ける）
8. 契約書チェックポイント
全契約形態共通
- [ ] 契約形態（請負/準委任/SES）が明記されているか
- [ ] 対象業務の範囲（スコープ）が明確か
- [ ] 報酬の金額・支払条件・支払時期が明記されているか
- [ ] 秘密保持条項が含まれているか
- [ ] 知的財産権（著作権）の帰属が明記されているか
- [ ] 再委託（下請け）の可否と条件が定められているか
- [ ] 損害賠償の上限額が定められているか
- [ ] 反社会的勢力の排除条項が含まれているか
請負契約特有のチェック項目
- [ ] 納品物の一覧と仕様が明確か
- [ ] 検収手順と検収期間が定められているか
- [ ] 契約不適合責任の期間が定められているか（1年以上を推奨）
- [ ] 納期遅延時のペナルティ（遅延損害金等）が定められているか
準委任契約特有のチェック項目
- [ ] 報酬の計算方法（時間単価 × 稼働時間等）が明確か
- [ ] 月次の稼働報告書の提出義務があるか
- [ ] 月額上限またはプロジェクト全体の予算上限が設定されているか
- [ ] 中途解約の条件と予告期間が定められているか
SES契約特有のチェック項目
- [ ] 指揮命令権がベンダー側にあることが明記されているか
- [ ] エンジニアの交代（スキル不足等の場合）の条件が定められているか
- [ ] 偽装請負に該当しない運用ルールが付属しているか
9. よくある質問（FAQ）
Q1. 初めてのシステム開発にはどの契約形態が適しているか？
「要件定義は準委任、開発は請負」のハイブリッド方式を推奨する。 要件が固まっていない段階で請負契約を結ぶと、見積もりにリスクプレミアムが大きく上乗せされるか、開発開始後に「これは要件外」としてトラブルになる。まず準委任契約で要件定義を丁寧に行い、要件が確定した段階で請負契約に切り替えるのが最もリスクの低いアプローチである。
Q2. SES契約と派遣契約の違いは何か？
法的な位置づけと指揮命令権の所在が異なる。 SES契約は準委任契約の一形態であり、指揮命令権はベンダー側にある。派遣契約は労働者派遣法に基づき、指揮命令権は派遣先（発注者）にある。実務上の違いとして、SESではエンジニアに直接業務指示を出すと偽装請負に該当するが、派遣では発注者が直接指示を出すことが認められている。派遣は法律で定められた手続きや費用（社会保険等）が発生するため、SESより単価が高くなる傾向がある。
Q3. 準委任契約で「成果完成型」と「履行割合型」はどう使い分けるか？
2020年の民法改正で認められた「成果完成型」の準委任契約は、要件定義フェーズに適している。 成果完成型は、成果物（例：要件定義書）の完成を報酬の条件とする準委任契約である。完成義務はないが、成果物が完成しなければ報酬が発生しないため、発注者のリスクが低い。一方、「履行割合型」は稼働時間に対して報酬を支払う従来型であり、保守・運用やコンサルティングに適している。
Q4. 契約形態によって費用総額はどのくらい変わるか？
同じプロジェクトでも、契約形態によって10〜30%の差が出ることがある。 請負契約はベンダーがリスクを負うため、見積もりに10〜30%のリスクプレミアムが上乗せされる。準委任契約はリスクプレミアムが不要だが、スコープ管理が甘いと工数が膨張する。SES契約は単価が最も安いが、PMやレビューを自社で行う必要があるため、社内コストを含めると差は縮まる。結局、どの契約形態でも「発注者側の管理能力」が総額を左右するのが実態である。
Q5. 契約書のレビューは弁護士に依頼すべきか？
初めてのシステム開発であれば、IT分野に詳しい弁護士のレビューを強く推奨する。 レビュー費用は5〜20万円程度（契約書の複雑さによる）だが、数百万〜数千万円のプロジェクトにおける保険と考えれば安い投資である。特に、知的財産権の帰属、契約不適合責任の期間、損害賠償の上限、再委託の制限については、専門家の確認なしに署名するのはリスクが高い。IT紛争に強い弁護士事務所を事前にリストアップしておくことを推奨する。
GXO実務追記: システム開発・DX投資で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- [ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
- [ ] 必須要件、将来要件、今回はやらない要件を分けたか
- [ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
- [ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
- [ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
- [ ] リリース後3ヶ月の改善運用と責任分界を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
システム開発の契約形態比較｜請負・準委任・SESの違いと選び方ガイドを自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。