「SES契約」は存在しない?SIとの違いを契約形態と指揮命令権から解説

IT業界で日常的に使われる「SES(システムエンジニアリングサービス)」という言葉。しかし、法的な観点から見ると、厳密な意味での「SES契約」という独立した法律上の契約形態は存在しません。

一般的に「SES会社」と呼ばれている企業の多くは、後述するとある理由から民法上の「準委任(じゅんいにん)契約」をメインとしているためそう呼ばれやすいだけで、実際には案件や顧客の要望に応じて「労働者派遣契約」も使い分けています。

この記事では、システム開発における「SI(システムインテグレーション)」と「SES」の違いを契約形態の観点から解説し、業界で問題視されやすい「一人常駐」や「なぜSESは準委任契約を結んでいるのか」という商流の問題までを解説します。

1. 契約形態から見る「SI」と「SES」の違い

SIとSESの最大の違いは、契約の「目的(何を対価としてお金を支払うか)」と「指揮命令権(誰が指示を出すか)」にあります。

一般的にSI(システムインテグレーター)は「請負契約」を主軸とし、SES(通称:SES企業)は「準委任契約」または「派遣契約」を主軸としています。それぞれの特徴を整理してみましょう。

契約形態の比較一覧

項目請負契約(一般的なSI)準委任契約(本来のSES)労働者派遣契約(IT派遣)
契約の目的成果物の完成(システム納品)業務の遂行(稼働時間・技術力)労働力の提供(稼働時間・技術力)
指揮命令権受託側(自社)受託側(自社)発注側(客先・クライアント)
完成責任あり(瑕疵担保/契約不適合責任)なし(善管注意義務はあり)なし
報酬の対象完成したシステムや成果物稼働した「時間」や人員稼働した「時間」や人員

SI(請負契約)の特徴

SIが担う請負契約は、「システムを完成させて納品すること」が目的です。
発注者は成果物に対してお金を払うため、極端な話、受託側が何時間働こうが関係ありません。
また、完成したシステムに不具合があれば、受託側が責任を持って修正する「契約不適合責任」を負います。

SES(準委任契約・派遣契約)の特徴

一方でSESが扱う契約は、「技術力や労働時間を提供すること」が目的です。
システムが完成しなくても、決められた時間(例: 月140〜180時間)稼働すれば報酬が発生します。

ここで重要になるのが、「SESと言われている会社でも、実は派遣契約を結んでいることが良くある」という事実です。なぜなら、現場の状況によって指揮命令権の所在を変えなければならないからです。

2. 指揮命令権の2つの側面:労務管理と業務指示

契約の適法性を語る上で外せないのが「指揮命令権」です。これには「労務管理(雇用主としての責任)」と「業務指示(仕事の進め方への命令)」という2つの側面があります。

① 労働者派遣契約:客先メンバーと一体となり、労務管理も委ねられる

派遣契約の最大の特徴は、「客先のメンバーと一緒に作業をし、実質的な労務管理も客先が行える」という点にあります。

日々の具体的なタスク指示(業務指示)はもちろん、現場での残業の要請や、日々の始業・終業といった勤怠の実質的なコントロール(労務管理の一部)を客先が直接行うことが合法的に認められています。チームの一員として客先の指示通りに動く働き方です。

② 準委任契約:本来は「自己マネジメント能力」が必要な高難度契約

一方で、準委任契約(SES)は実はエンジニア個人において、難易度が高い契約形態です。
なぜなら、客先から指示を受けるのではなく、「自分自身(または自社のリーダー)で業務をマネジメントする能力」が不可欠だからです。

本来は、客先から「この領域の課題を解決してほしい」という大枠の依頼(注文)を受けたら、それをどうブレイクダウンし、どう時間を配分して成果を出すかは、すべてエンジニア側が自律的に管理・コントロールしなければなりません。

そもそも委任契約とは?
委任契約とは、「法律行為」を伴う業務を他人に委託する契約です(民法第643条)。
「成果物の完成」ではなく「業務の遂行」に対して報酬や責任が発生する点(善管注意義務など)は準委任契約と全く同じですが、扱う対象が法律に絡むものに限定されます。
具体的な例:
・弁護士への裁判手続きや示談交渉の依頼
・税理士への確定申告や税務署への申請依頼
・不動産業者への売買契約の代理依頼

「委任」と「準委任」の違い
システム開発(SES)で行われるプログラミングや設計、要件定義などは、法律に関係のない事務作業(技術的な業務)です。
そのため、法律行為「以外の」業務を委託する契約として、頭に「準」がついた「準委任契約」が使われます。

委任契約: 弁護士や税理士など、法律行為を任せる契約
準委任契約: エンジニアやコンサルタントなど、法律行為以外の業務を任せる契約

まとめると、「やっていることの本質(労働時間や技術の提供)は同じで、扱うテーマが『法律系』なら委任契約、『それ以外(ITやビジネスなど)』なら準委任契約になる」という違いです。

3. 「一人常駐」が違法化するメカニズム

準委任契約において、最もトラブルになりやすく、法的なグレー(あるいは完全なブラック)ゾーンとなりがちなのが「一人常駐」です。

結論:一人で送ること自体は違法ではないが、実態が違法になりやすい

法律上、準委任契約でエンジニアを1人だけで客先のオフィスに常駐させること自体は禁止されていません。
しかし、前述の「自己マネジメント」という準委任の前提が現場で崩壊するため、結果として違法(偽装請負)になるケースが後を絶ちません。

なぜ一人常駐の準委任は違法化するのか?

準委任契約(SES)でエンジニアが1人で客先に行くと、現場には「業務指示を出すべき自社の上司」がいません。
一方で、エンジニア自身に高度な自己マネジメント能力や客先と対等に交渉する力が不足している場合、現場の指示に100%従うことになります。

結果として、客先のプロパー社員から直接「次はこの機能を実装して」「明日は9時にこの会議に出て」と直接指示を受け、客先のコントロール下で働くようになってしまいます。

  • 契約の建前: 自己マネジメントに基づく「準委任」
  • 現場の実態: 客先の指示で動く「実質的な派遣」

このように、実態が派遣(客先が業務指示を出す)であるにもかかわらず、書類上だけを準委任にしている状態を「偽装請負」と呼び、労働基準法や労働者派遣法違反となるのです。

4. 現実は「真逆」:それでもSESが「準委任契約」と言われる商流の闇

本来の定義から言えば、エンジニアの能力が「客先のメンバーと共に指示通りに動くレベル」であれば派遣契約を結ぶべきであり、「自律して動けるレベル」であれば準委任契約を結ぶべきです。
しかし、実際のSES業界ではこれが完全に反転しています。
そこがSES=準委任契約と言われる所以です。

実態は客先の指示通りに動く「派遣」のような働き方なのに、なぜ契約書は「準委任契約」ばかりなのでしょうか。そこには「深い商流」という業界の構造的な問題があります。

原因は「多重請負」と「二重派遣の禁止」

多くのSES企業は、エンドユーザー(発注元)から直接案件を受注する営業力を持っていません。
そのため、「元請け(大手SIer)→ 二次請け → 三次請け → 四次請け(自社)」というように、間に何社も挟まる深い商流(多重請負構造)の中で生きています。

ここで法律の壁が立ちはだかります。
日本の労働者派遣法では、「二重派遣(派遣された労働者を、さらに別の会社へ派遣すること)」が禁止されています。

もし、四次請けのSES企業が「現場の実態に合わせて派遣契約にしよう」としても、派遣契約を結べるのは直近の「三次請けの会社」に対してだけです。
その三次請けの会社が元請けにエンジニアを送り出す段階で、それは違法な「二重派遣(あるいは三重・四重派遣)」になってしまいます。

派遣契約に「できない」から準委任と言い張る

つまり、商流の途中に何社も挟まっている以上、どれだけ現場の実態が「派遣」であっても、法律上、絶対に派遣契約を締結することができないのです。

そのため、途中に挟まる中間マージン抜きの会社たちは、二重派遣の摘発を免れるために、書類上だけは「これは派遣ではなく、業務委託(準委任契約)です」という体裁を取り繕うしかありません。
これが、「SESと言われている会社が、頑なに準委任契約だと言い張る(言わざるを得ない)」本質的な理由です。

まとめ:業界の構造を知り、実態を見極める

「SES」についてまとめると以下のようになります。

  • 派遣契約は、客先メンバーと一体化し、業務指示も労務管理も客先が行える合法的な形態。
  • 準委任契約は、本来はエンジニア側が高レベルな「自己マネジメント能力」を発揮して自律的に動くべき形態。
  • しかしSES業界では、自社の営業力が低く商流が深すぎるため、二重派遣の違法リスクを避けるために「準委任契約」という名目を被せているだけの現場が非常に多い。

エンジニアとして働く側も、プロジェクトを発注する側も、この「反転してしまっている業界のリアル」を正しく理解しなければなりません。
SESだから「準委任契約」と納得するのではなく、自社が置かれている商流の深さと、現場での指揮命令系統のあり方に違法性がないかを認識することが重要です。

SESにおいて営業1人で100人を担当するのは美談か

近年、エンジニアの間で「高還元SES」というワードが注目を集めています。「案件単価の80~90%以上を給与として還元!」「搾取からの解放!」といったキーワードは、これまで多重下請け構造による低賃金に苦しんできたエンジニア […]

(続)上流工程へ上がるべき理由:「PMフェーズ」で求められるスキルについて

前回のコラムでは、「要件定義~詳細設計」までに必要なスキルや一人称で作成できるべき成果物について解説しました。今回は、更に上流のPMフェーズについてです。10チーム・総勢50名を超えるような超大規模案件や、複雑なドメイン […]

上流工程へ上がるべき理由と今後起きる「フルスタック化とAI普及のバッティング」について

現在、多くのITエンジニアが「フロントエンドもバックエンドもインフラも、すべて一人でこなせるフルスタックエンジニア」を目指して日々の学習や業務に励んでいます。プレゼンテーション層・アプリケーション層・DB層を横断し、一人 […]

Comments are closed