SESと派遣の違い｜準委任・請負の比較と発注の判断軸

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

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

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

本記事では、発注者（企業側）の視点に立ち、SES・派遣・業務委託（請負）の違いを法的な根拠とともに整理します。さらに、違いを知るだけで終わらせず、見積の見方・契約条件・稼働後の保守運用の責任分担にどう影響するかまで踏み込み、プロジェクトの特性に応じてどの調達方法を選ぶべきかの判断基準を具体的に解説します。

—Free Download / 資料ダウンロード

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

この資料でわかること

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

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

SESと派遣の違いを一言でいうと

SESと派遣の違いは、エンジニアに直接指示を出せるのが誰か（指揮命令権の所在）です。

• SES（準委任契約）: 指示を出すのはSES会社。発注者は直接の業務指示を出せません
• 派遣（労働者派遣契約）: 指示を出すのは発注者（派遣先）。日々の業務指示や勤怠管理を発注者が担います

この違いは用語の定義にとどまりません。見積で何が「人月単価」に含まれるか、契約書で誰が何に責任を負うか、リリース後の保守を誰が担うかまで、発注判断のあらゆる場面に影響します。以降の章で、それぞれを順に整理します。

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

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

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

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

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

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

準委任契約の中身——「成果物の完成」を約束しない契約

SESの契約根拠である準委任契約は、業務の遂行そのものを委託する契約です。受託者（SES会社）は、依頼された業務を専門家として相応の注意（善管注意義務）をもって行う責任を負いますが、「システムを完成させる」こと自体は約束していません。

準委任には、民法上、次の2つの報酬の考え方があります。

一般的なSES契約は履行割合型で、稼働した期間に応じて報酬が発生します。「準委任」と書かれた見積や契約書を受け取ったら、成果物の完成までは保証されない契約であることを前提に、完成責任を誰が負うかを別途確認しておく必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

品質・成果物責任の違い

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

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

見積・契約・保守で何が変わるか——違いを発注判断に接続する

ここまでの違いは、実際の見積確認・契約締結・稼働後の運用で、次のような確認事項に置き換わります。

見積の見方（人月単価と精算条件）

SES・派遣の見積は、人月単価に稼働時間を掛ける形が一般的です。次の点を見積依頼時に確認してください。

• 人月単価に含まれる範囲: 交通費・環境費・管理費などが別立てになっていないか
• 精算の有無と幅: 月の稼働時間が一定の幅を下回る・上回った場合に単価を増減させる精算条件があるか（上下の時間幅や超過単価は契約ごとに異なります）
• 稼働の前提: 稼働日数・稼働率（フルタイムか部分稼働か）・体制変更の通知期限
• 成果物が必要な場合の追加費用: 準委任の見積に成果物の完成は含まれないため、納品物が必要なら請負見積との切り分けが必要

請負の見積は、成果物の範囲（スコープ）が価格を決めます。「何が含まれ、何が含まれないか」が見積書に書かれているかを確認しましょう。

契約条件の確認ポイント

契約書に「準委任」と書かれていても、実態として発注者が日常的に直接指示を出していれば偽装請負と判断され得ます。名称よりも運用の実態が問われる点は、契約前に社内で共有しておくべきです。

稼働後の保守・運用の責任分担

見落とされやすいのが、リリース後の保守です。契約形態によって、不具合が見つかったときの扱いが変わります。

• SES・派遣: 成果物の品質責任は発注者側にあるため、不具合対応の判断や社内での品質管理体制も発注者が担う前提で設計する
• 請負: 納品後、一定期間は契約不適合責任に基づきベンダーが修正を行う。ただし、その期間を過ぎた運用保守は別契約になるのが一般的で、保守契約の有無・範囲・費用を契約時に決めておく必要がある
• ハイブリッド（開発は請負、保守はSES）: 後述のとおり柔軟だが、「誰がどの範囲を見るか」の線引きが曖昧だと責任の空白が生じやすい

見積・契約の段階で「リリース後に不具合が出たら誰が対応し、費用は誰が持つか」を確認しておくと、稼働後のトラブルを減らせます。

SESを活用した外注と採用の使い分け

「SESエンジニアの外注で採用の手間や業務負荷を減らしたい」という検討では、次の観点で整理すると判断しやすくなります。

• 採用との違い: SESは必要な期間だけスキルを補える一方、ノウハウが社内に残りにくい。長期的に内製化したいなら正社員採用とSESの併用を検討する
• 外注で軽くなる負荷: 募集・選考・労務管理などの採用・雇用に伴う負荷。ただし要件整理と成果の確認は発注者側に残る
• 業務効率化につなげる条件: 指示窓口（PM）・情報共有の方法・ドキュメント整備を最初に決めておくこと。ここが曖昧だと、かえって確認コストが増えます

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

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

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

—Free Download / 資料ダウンロード

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

この資料でわかること

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

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。