「SESに発注したのに、現場でエンジニアに直接指示を出していた」「成果物が期待どおりに仕上がらなかったが、契約上は問題ないと言われた」——こうした発注側のトラブルが、IT業界では少なくありません。
SES（システムエンジニアリングサービス）は、多くの企業がエンジニアリソースを確保するために活用している契約形態ですが、「派遣と何が違うのか」「成果物に責任を持ってもらえるのか」といった点は、意外と正確に理解されていないことが多いのが現状です。
契約内容を曖昧なまま発注してしまうと、現場での日常的なやり取りが「偽装請負」とみなされるリスクや、期待する成果が得られなかった場合の責任の所在をめぐるトラブルに発展することがあります。これは担当者の理解不足だけでなく、会社全体に法的リスクをもたらす問題でもあります。
本記事では、SESとは何かという基本から、派遣・請負・準委任との違いを比較表で整理し、発注者が特に注意すべき指揮命令権と成果物責任の扱い、そしてSESと受託開発の使い分け判断基準までを発注者視点で解説します。「SES企業への発注を検討している」「すでに発注しているが正直よく分かっていない」という担当者の方に向けた内容です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
SESとは？システムエンジニアリングサービスの基本を理解する
SESは「System Engineering Service（システムエンジニアリングサービス）」の略称です。SES企業（受注側）が所属するエンジニアをクライアント企業（発注側）に常駐または提供し、特定の業務に従事させることで技術力を提供するサービスの総称です。
SESは「準委任契約」の一形態
法律上、SES契約は民法第656条が定める「準委任契約」に該当するのが一般的です。準委任契約とは、当事者の一方がある法律行為以外の事務処理を相手方に委託し、相手方がそれを承諾することで成立する契約です。
重要なのは、準委任契約においてSES企業側は「業務を誠実に遂行する義務（善管注意義務）」を負いますが、「成果物を完成させる義務」は負わないという点です。つまり、契約で定めた期間・時間内に誠実に業務に取り組めば報酬が発生し、仮に期待したシステムが完成しなかったとしても、それだけで契約違反にはなりません（ただし善管注意義務違反の有無は別途問われます）。
IT業界でSESが選ばれる理由
SESが広く普及した背景には、IT業界特有の事情があります。
ソフトウェア開発・運用の現場では、プロジェクトの規模や技術要件が変動しやすく、特定のスキルを持ったエンジニアを都度スポットで確保したいというニーズが高いです。SESは「必要なスキルを持ったエンジニアを、必要な期間だけ活用できる」という柔軟性から、多くの企業で利用されています。
ただし、この柔軟性の裏側には「成果物の完成保証がない」「指揮命令権の扱いが厳格」という制約があることを、発注者側は正確に把握しておく必要があります。
SES・請負・派遣・準委任の契約形態をまとめて比較する
SESを正しく理解するには、類似した契約形態との違いを整理することが不可欠です。以下の比較表で確認しましょう。
4形態の比較表（指揮命令権・成果物責任・報酬条件）
項目 | SES（準委任） | 請負 | 派遣 | 雇用 |
|---|---|---|---|---|
契約の法的根拠 | 民法656条（準委任） | 民法632条（請負） | 労働者派遣法 | 労働契約法 |
指揮命令権の所在 | SES企業（受注側） | 受注側（請負業者） | 発注者（派遣先） | 雇用主 |
成果物の完成義務 | なし（善管注意義務のみ） | あり（瑕疵担保責任あり） | なし | なし |
報酬の発生条件 | 作業時間・工数に応じて | 成果物の納品・検収後 | 就業時間に応じて | 労働時間に応じて |
発注者からエンジニアへの直接指示 | 原則不可 | 不可 | 可 | 可 |
社会保険・雇用 | SES企業が負担 | 受注側が負担 | 派遣会社が負担 | 雇用主が負担 |
この表で特に重要なのは「指揮命令権の所在」と「発注者からの直接指示の可否」の列です。派遣のみが発注者側に指揮命令権があり、SES・請負ではいずれも発注者が直接エンジニアに業務指示を出すことができません。
SESが「準委任」であることの意味と実務上の影響
SESが準委任契約である以上、発注者にとって実務上の影響は大きく2点あります。
1. 成果物の品質保証がない SES企業は「誠実に業務を行う義務」は負いますが、「このシステムを完成させる義務」は原則として負いません。もし納品されたコードに問題があっても、SES契約上は「一定の成果物の完成」を請求する根拠が弱い場合があります。
2. 指揮命令は必ずSES企業経由 「明日この機能を追加してほしい」「今週は別の業務を優先してほしい」といった指示は、直接エンジニアに伝えるのではなく、SES企業の担当者（PM等）を通じて行う必要があります。
発注者が知っておくべきSESのメリットとデメリット
SESを活用するメリット（発注者視点）
1. 柔軟な人員調整が可能 プロジェクトの規模や工程に応じて、必要なスキルを持ったエンジニアを必要な期間だけ確保できます。繁忙期に増員し、閑散期に縮小するといった対応が、正社員採用よりも迅速にできます。
2. 特定スキルへのアクセス 自社にいない特殊な技術（特定のクラウド、機械学習、レガシーシステム対応など）を持ったエンジニアを、採用コスト・育成コストをかけずに活用できます。
3. 採用・雇用リスクを回避 正社員採用と異なり、社会保険・雇用保険の負担はSES企業が行います。要員が合わなかった場合も、契約終了という形で解消できます。
SESを活用するデメリット（発注者視点）
1. 成果物の完成保証がない 最も大きなリスクです。SES契約では「エンジニアが誠実に業務を遂行すること」が義務であり、「動くシステムを完成させること」は契約上義務ではありません。成果物の品質や完成度を担保したい場合は、受託開発（請負契約）の方が適切です。
2. 直接指示ができないことによるコミュニケーションコスト 業務変更・優先順位の調整・新たな要件の追加は、すべてSES企業の窓口を通じて行う必要があります。スピードが求められるアジャイル開発では、このコミュニケーションのオーバーヘッドが課題になることがあります。
3. エンジニアのスキルにばらつきが生じやすい SES企業によって、エンジニアのスキルレベルや経験の管理品質は異なります。事前にスキルシートの確認・面談・試用期間の設定などを行うことをお勧めします。
4. 長期になるとコストが割高になる可能性 人月単価×工数の積み上げになるため、長期プロジェクトでは受託開発（一括見積もり）と比較して割高になることがあります。
5. エンジニアの引き抜きは禁止 SES契約中のエンジニアを発注者が直接採用することは、契約違反になる場合がほとんどです。契約書の条項を確認しましょう。
SES契約で発注者が特に注意すべき点（指揮命令権と成果物責任）
指揮命令権がSES企業にある——発注者が直接指示してはいけない理由
SES契約（準委任契約）では、エンジニアへの業務上の指揮命令権はSES企業（受注側）にあります。これは契約上のルールであるだけでなく、労働者派遣法上の規制にも関わる重要な点です。
発注者がSESエンジニアに対して直接・継続的に業務指示を行っていた場合、その実態は「労働者の派遣を受けている」と判断される可能性があります。これを偽装請負と呼び、労働者派遣法違反として問われるリスクがあります。
偽装請負が認定された場合の法的リスク（厚生労働省ガイドライン参照）:
- 派遣元・派遣先双方に対して「1年以下の拘禁刑または100万円以下の罰金」（労働者派遣法59条、職業安定法64条）
- 行政指導・改善命令・企業名の公表
- 外注先エンジニアとの「直接雇用みなし」——発注者がエンジニアを直接雇用したとみなされ、雇用契約が成立するリスク
偽装請負のNGパターン具体例（発注者が陥りやすいケース）
以下のような行為は、指揮命令とみなされ、偽装請負リスクを高めます。
NGパターン | 具体例 |
|---|---|
業務内容の直接変更 | 「今週はこの画面を優先してほしい」「この機能追加を追加してほしい」とエンジニアに直接伝える |
技術スタックの直接指示 | 「React でなく Vue を使ってほしい」「このライブラリを使うように」とエンジニアに直接伝える |
労働時間の管理 | 「今日は残業してほしい」「明日は午前だけでよい」とエンジニアに直接伝える |
業務評価 | SES企業を通さずに、発注者がエンジニアの業務成績を直接評価・注意・指導する |
緊急対応の直接依頼 | 障害発生時に、SES企業を通さずエンジニアに直接「今すぐ対応してほしい」と連絡する |
適切な対応: これらの事項はすべて、SES企業の担当者（PM・営業）を通じて依頼します。「SES企業のPMに連絡→PMがエンジニアに指示」という経路を守ることが、偽装請負リスクを回避する基本です。
成果物責任がない場合のリスクと契約書でのカバー方法
SES契約では成果物の完成義務がないため、「期待していたシステムが動かない」「バグが多い」といった状況でも、契約上の責任追及が難しいケースがあります。
ただし、以下の手段でリスクをある程度カバーすることが可能です。
- 作業報告書の提出を義務化する: 週次・月次で進捗報告書を提出してもらい、業務の実施状況を記録として残す
- 品質基準を個別契約書に明記する: 「コードレビューを必ず実施する」「単体テストのカバレッジ基準を設ける」等の品質要件を契約書または仕様書に記載する
- 検収プロセスを定義する: 準委任契約でも検収条件を設定することは可能です。何をもって業務完了とするかを契約書で明確にしておきましょう
- 善管注意義務違反の証拠を保全する: 問題が発生した場合は、コミュニケーション記録（チャット・メール等）を保存しておくことで、善管注意義務違反の立証に役立てられます
SESと受託開発、どちらを選ぶべきか——発注者のための判断基準
SESと受託開発（請負契約）の選択は、プロジェクトの性質によって決まります。以下の判断軸を参考にしてください。
SESが適している案件
条件 | 説明 |
|---|---|
要件が流動的で変化しやすい | 開発中に仕様が変わる可能性が高い、または段階的に要件を固めていくアジャイル型のプロジェクト（ただし指揮命令ルールに注意） |
特定スキルの人員を一定期間確保したい | 「半年間、AWSに詳しいインフラエンジニアが必要」など、期間・スキルが明確なリソース確保 |
社内に技術的な指示・レビューができる人材がいる | SESエンジニアの業務を管理できるPM・テックリードが社内にいる場合は、SESのコスト効率が活かせる |
運用・保守・テストなど継続的な業務 | 明確な成果物を定義しにくい継続業務では、準委任契約の方が実態に合っている |
受託開発（請負）が適している案件
条件 | 説明 |
|---|---|
「動くシステム」の完成が必要 | 新規システムの開発・既存システムの大規模リプレイスなど、成果物の完成を確実に求める場合 |
社内にPM・技術管理できる人材がいない | SESは社内側のマネジメント力が求められます。PM不在の場合は一括受託の方が安全 |
予算・納期が固定されている | 受託開発の固定費モデルの方が予算管理しやすい |
小規模・単発の開発 | 機能追加や改修など、スコープが明確な小規模案件 |
簡易判断フロー
Q1. 成果物の完成を発注者が確実に求めるか？
→ YES: 受託開発（請負）を選ぶ
→ NO/不確定: Q2へ
Q2. 社内にエンジニアの業務を管理できるPM・テックリードがいるか？
→ YES: SESを選ぶ（ただし指揮命令ルールを厳守）
→ NO: 受託開発（PM込みの一括受託）を選ぶ
Q3. 要件は確定しているか？
→ YES: 受託開発の方が成果物管理しやすい
→ NO（アジャイル・探索的開発）: SES（ただし指揮命令ルール管理が必要）
まとめ——発注者がSES契約前に確認しておく3つのポイント
SESとは、エンジニアの技術力を「作業時間」単位で活用する準委任契約の一形態です。派遣との最大の違いは「指揮命令権がSES企業側にある」こと、請負との最大の違いは「成果物の完成義務がない」ことです。
SES発注前の確認チェックリスト
指揮命令権の管理
- 発注者が直接エンジニアに業務指示を出さない運用ルールを社内で共有しているか
- 業務変更・優先順位の調整はSES企業のPM経由で行う体制になっているか
成果物責任の明確化
- 契約書・仕様書に品質基準や検収条件が明記されているか
- 週次・月次の作業報告書の提出を契約に含めているか
SES vs 受託開発の選択
- 自社案件に「成果物の完成保証」が必要かどうかを確認したか
- 社内にSESエンジニアの業務を管理できるPM・テックリードがいるか
SES契約は適切に活用すれば非常に柔軟で効果的なリソース確保手段です。一方で、指揮命令権や成果物責任についての誤解から生まれるトラブルは珍しくありません。本記事のチェックリストを参考に、発注前・契約締結前に体制を整えてから進めることをお勧めします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
