SES・派遣・業務委託の違いとは？発注者が知るべき調達方法の選び方

エンジニアを外部から調達しようとしたとき、「SES」「派遣」「業務委託」「請負」といった言葉が飛び交い、どれを選べばよいのか迷った経験はないでしょうか。

実は、これらの言葉の定義や使われ方は業界内でも曖昧なことが多く、特にSESと派遣の違いについては「どちらも外部のエンジニアに来てもらうこと」という程度の認識で契約を進めてしまうケースが少なくありません。

しかし、契約形態の選択ミスは、偽装請負という法的リスクや、プロジェクト管理のトラブル、想定外のコスト増加につながります。

本記事では、発注者（企業側）の視点に立ち、SES・派遣・業務委託（請負）の違いを法的な根拠とともに整理します。さらに、プロジェクトの特性に応じてどの調達方法を選ぶべきかの判断基準を具体的に解説します。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

SES・派遣・業務委託の契約形態と法的な違い

エンジニアを外部調達する際の契約形態には、大きく分けて3つのカテゴリがあります。それぞれが異なる法律に基づいており、特に「指揮命令権の所在」と「成果物責任の有無」が重要な違いです。

SES（準委任契約）とは——指揮命令権はどこにある？

SES（System Engineering Service）は、民法上の「準委任契約」に分類されます。SES契約では、エンジニアをプロジェクトに参画させることに対して報酬が発生し、指揮命令権はSES会社側（ベンダー）にあります。

つまり発注者は、SESエンジニアに直接「今日はこの作業をやってください」という指示を出すことができません。業務の内容・進め方・勤怠管理は、あくまでSES会社が行います。

また、成果物（完成したシステムや機能）に対する責任は発注者側が負うのが原則です。SES契約は「労働力の提供」に重きが置かれており、エンジニアが作業した結果に欠陥があっても、SES会社は原則として瑕疵担保責任を負いません。

派遣契約との違い——発注者が直接指示できるかどうか

労働者派遣は、「労働者派遣法」に基づく契約形態です。SESと最も大きく異なるのは、指揮命令権が発注者（派遣先企業）にある点です。

派遣エンジニアは発注者の指揮のもとで働くため、「毎日9時に出社してこの業務を担当してほしい」「今週はこのタスクを優先してください」といった直接指示が可能です。これはSES契約では許されない行為です。

一方で、派遣には「3年ルール」（同一業務への派遣は原則3年まで）などの法的制約があります。また、派遣スタッフの選定は派遣会社が行い、発注者が特定の個人を指名して継続雇用することには制限があります。

請負契約との違い——成果物責任の有無

請負契約（受託開発）は、民法上の「請負」に基づきます。SESや派遣と最も異なるのは、「成果物を完成・納品することに対して報酬が発生する」点です。

発注者は「このシステムを作ってください」という形で依頼し、開発会社は完成物を納品する義務を負います。仮に欠陥があった場合には、開発会社が修正義務・損害賠償責任を負います（瑕疵担保責任・契約不適合責任）。

指揮命令権は開発会社側にあり、発注者は日常的な業務指示を出せません。ただし、要件や仕様の確認・変更要求は発注者が行います。

3つの契約形態まとめ比較表

発注者視点でのメリット・デメリット比較

法的な違いを踏まえた上で、発注者にとって実際に重要なコスト・管理工数・品質保証の観点から比較します。

コスト構造の違い（単価・時間精算・成果物固定）

SES・派遣（時間精算型）のコスト構造

SESと派遣はともに「時間精算型」であり、エンジニアが稼働した時間に応じて費用が発生します。2025年時点の相場として、SESエンジニアの月単価は経験年数によって50〜200万円以上と幅があり、平均的には60〜120万円程度が一般的です（PRONIアイミツ）。

時間精算型のメリットは、要件変更や仕様追加が発生しても追加費用の交渉がしやすい点です。一方で、プロジェクトが長引けばその分コストが増加するリスクがあります。

請負（固定費型）のコスト構造

請負では、合意した仕様に基づいて開発費用が固定で決まります。スコープ内であれば追加費用は発生せず、予算管理がしやすいメリットがあります。ただし、要件変更が発生した場合は追加費用の交渉が必要になります。また、仕様が曖昧な段階での請負は、発注者にとって不利なケースが多くあります。

管理工数の違い（発注者が負う業務管理の度合い）

SESは指揮命令権がベンダー側にある一方で、実際にはエンジニアがオフィスに常駐するため、発注者が「業務内容の共有」や「状況確認」を行う場面が多くなります。この管理が行き過ぎると後述の偽装請負リスクにつながります。

派遣は発注者が直接指揮できる分、日常的な業務指示・進捗管理・勤怠管理などを発注者側が担う必要があります。管理工数は3つの中で最も高くなる傾向です。

請負は、要件定義・仕様確認以外の日常的な管理はベンダーが担うため、発注者の管理工数は最も少なくなります。ただし、定期的な進捗確認と仕様変更の管理は発注者が行います。

品質・成果物責任の違い

SES・派遣では成果物の品質責任を発注者が負うため、内部での品質管理体制が必須です。エンジニアのスキルに応じた適切な業務設計と、コードレビューなどの品質チェックプロセスを発注者側で用意する必要があります。

請負では、納品物の品質を開発会社が保証します。ただし、仕様書の品質が結果物の品質を左右するため、「言ったことは作ったが思っていたものと違う」というトラブルを防ぐための丁寧な要件定義が重要です。

プロジェクト特性別——どの調達方法が最適か

「どれが一番良いか」という問いに対する答えは、プロジェクトの性質によって変わります。以下の基準を参考に判断してください。

SESが向いているケース（長期常駐・スキル補完・要件不確定）

SESが適しているのは、以下のような状況です。

• 要件が固まっていない、またはアジャイル的に開発を進めたい
• 特定のスキルを持つエンジニアをチームに組み込みたい（例: バックエンドエンジニアが1人いれば十分）
• 長期にわたってリソースを確保したい（3ヶ月〜数年単位）
• プロジェクトの方向性が変わる可能性がある

社内チームにスキルを補完する形で外部エンジニアを迎える「ラボ型」に近い運用ができます。ただし、指揮命令は必ずSES会社経由で行う必要があります。

派遣が向いているケース（短期・直接指揮が必要・繁忙期対応）

派遣が適しているのは、以下の状況です。

• 繁忙期の一時的なリソース不足を補いたい
• 発注者のチームに完全に組み込んで直接指揮したい
• 特定のスキルセットを持つ人材を比較的短期間（数週間〜数ヶ月）だけ確保したい
• 社内の指揮命令系統でエンジニアを動かす必要がある

ただし、同一業務への派遣は原則3年までという制限があることを念頭に置いてください。

請負（受託開発）が向いているケース（要件明確・成果物固定・品質保証重視）

請負が適しているのは、以下の状況です。

• 要件と仕様がすでに明確に定義されている
• 特定の機能や画面の開発を外部に丸ごと任せたい
• 成果物の品質保証を開発会社に求めたい
• 社内に開発リソースがなく、かつ品質責任を外部に移転したい

請負は「何を作るか」が明確な場合に最も力を発揮します。仕様が曖昧な段階での請負発注は、認識のズレによるトラブルの温床になります。

ラボ型開発（準委任+長期パートナー）という選択肢

SESと似た準委任契約の一形態に「ラボ型開発」があります。ラボ型では、ベンダーがチーム単位でプロジェクトに参画し、PM・ブリッジSEを置いて品質管理も担当するのが一般的です。

SESが個人単位の参画であるのに対し、ラボ型はチームとして機能する点が大きな違いです。長期的なパートナーシップを前提に、継続的な機能追加や改善を行うプロジェクトに適しています。

プロジェクト特性別 選択基準まとめ

SES活用時の注意点——偽装請負リスクとスキルミスマッチ対策

SESを選んだ場合に特に注意すべき点を解説します。

偽装請負とは——発注者が犯しやすいNG行動

偽装請負とは、形式上はSES（準委任）契約を結びながら、実態として発注者が労働者に直接指揮命令を行う状態を指します。これは労働者派遣法違反となります。

発注者が犯しやすいNG行動の例：

• 「今日はこのタスクを優先してください」と直接SESエンジニアに指示する
• SESエンジニアの勤怠（出退勤・休暇）を発注者側が管理する
• SESエンジニアを社内の会議に参加させて業務指示を与える
• 特定のエンジニアを名指しで継続契約を要求する（引き抜き）

偽装請負と判断されると、1年以下の懲役または100万円以下の罰金（労働者派遣法）の対象となります。また、発注者において「労働契約申込みみなし制度」が適用される可能性があり、SESエンジニアとの雇用関係が成立したとみなされるリスクがあります（TMI総合法律事務所）。

適切な対応： 業務の内容・目標・期限はSES会社の担当者（PM）を通じて伝える。日常的な作業指示はSES会社のPMが行う。発注者は「成果・方向性の確認」にとどめる。

スキルミスマッチを防ぐための要件定義のポイント

SES契約ではスキルミスマッチが発生しやすいリスクがあります。特定のスキルを期待していたにもかかわらず、実際のエンジニアの経験レベルが想定と異なるケースです。

これを防ぐためには、契約前に以下を明確にすることが重要です。

• 必須スキルと経験年数（例: TypeScript 3年以上、Next.js使用経験あり）
• 期待する業務レベル（設計まで担当できるか、実装のみか）
• 稼働想定プロジェクトの概要

契約書への技術要件の明記と、開始前のスキル確認面談の実施が有効です。

SESエンジニアとの適切なコミュニケーションの取り方

法的には直接指示は禁止ですが、業務上の情報共有や状況確認は必要です。適切な方法は次の通りです。

• 日次・週次の進捗確認はSES会社のPM（担当者）を窓口に行う
• プロダクトの仕様・要件はドキュメントで共有し、質疑応答はPM経由で行う
• コードレビューなどの技術フィードバックは、発注者のエンジニアからSESエンジニアへ直接行ってもよいが、「業務指示」にならないよう「技術的なアドバイス」の範囲内にとどめる

調達方法の組み合わせ戦略——コアはSES、実装は請負

実際のプロジェクト運営では、一つの契約形態に縛られる必要はありません。複数の調達方法を組み合わせることで、コスト最適化とリスク分散を実現できます。

ハイブリッド調達の実例（SES+請負の組み合わせ）

例1: コアはSES、機能開発は請負

プロダクトのコア部分（基本設計・継続運用）はSESエンジニアが長期で担当し、特定の機能追加（例: 決済機能の実装）は要件が固まった段階で請負発注する。こうすることで、変化する要件には柔軟に対応しながら、確定した機能は品質保証つきで開発できます。

例2: 初期開発は請負、運用・改善はSES

MVP（最小限の製品）の初期開発を請負で一括発注し、リリース後の機能改善・バグ修正をSESエンジニアが継続的に担当する。初期品質の保証と、その後の柔軟な改善体制を両立できます。

チーム拡大フェーズごとの調達方法の切り替え

プロダクトの成長フェーズに応じて調達方法を変えることも有効です。

• 検証フェーズ（0〜3ヶ月）: 請負で素早くプロトタイプを開発
• 成長フェーズ（3ヶ月〜1年）: SESで機動的なチームを組み、継続的に機能追加
• 安定フェーズ（1年〜）: コアメンバーの正社員採用を進めながら、専門スキルはSESで補完

外部調達と内部育成をどのように組み合わせるかは、プロダクトの性質と事業フェーズに応じて戦略的に判断することが重要です。

SES・派遣・業務委託（請負）の選択は、単なるコスト比較ではなく、プロジェクトの性質・管理体制・法的リスクを総合的に考慮して行う必要があります。本記事の比較表と選択基準を参考に、自社のプロジェクトに最適な調達方法を選んでください。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード