IT開発の派遣・準委任・請負を正しく理解する
指揮命令・3年ルール・偽装請負の実務

1. 外部エンジニアが参加する開発現場

ある企業が基幹システムを刷新するとします。自社の開発者だけでは人手が足りず、別会社からエンジニアに来てもらうことになりました。そこでプロジェクトマネージャー（PM）は、毎朝の朝会で担当チケットを直接割り当てています。これは許されるでしょうか。

答えは「相手がどんな契約で働いているか」と「実態として誰が指揮命令しているか」で変わります。同じオフィスで、同じGitリポジトリを使い、同じ開発チームに所属しているように見えても、契約によって管理のあり方は異なります。

2. 派遣・請負・準委任の違い

まず登場人物を整理しましょう。A社がシステム開発を発注する側、B社が外部人材や開発サービスを提供する側、エンジニアがB社に雇用される労働者だとします。

民法上の請負と準委任は、仕事の完成を目的とするか、業務の遂行を委ねるかという契約上の違いがあります。ただし、派遣と請負等の境界を考える場合には、契約書の見出しよりも、現場の実際の指揮命令関係が重要です。

3. 「指揮命令」とは具体的に何を指す？

指揮命令は、単なる情報共有や仕様の相談と同じではありません。たとえば「この機能は来週までに必要」という発注内容の調整と、「B社の田中さん、今日はこのチケットを先に実装してください」という個人への直接の業務指示では、性質が違います。

「朝会への参加」や「Slackでの連絡」がそれだけで違法と決まるわけではありません。技術的な連携なのか、受託者の労働者に対する実質的な指揮命令なのか、業務の独立性などを含めて判断します。

出典：厚生労働省「労働者派遣・請負を適正に行うためのガイド」「37号告示関係疑義応答集」。

4. SESという呼び方だけでは判断できない

IT業界では「SES（System Engineering Service）」という言葉がよく登場します。ただし、SESは労働者派遣法や民法が定めた独立の契約類型ではありません。実際の契約は準委任などの形を取る場合があり、派遣に当たるかどうかは就業の実態で判断されます。

「SES契約と書いてあるから直接指示してもよい」「準委任と書いてあるから派遣法は関係ない」という考え方は危険です。営業上の呼称と法的分類を分けて扱いましょう。

5. 派遣先は候補者を面接して選んでよい？

プロジェクト責任者としては「React経験者がほしい」「業務システム開発に慣れている人が必要」と考えるでしょう。必要な業務内容やスキルを派遣元に伝えることと、特定の候補者の履歴書を出させて事前面接し、採否を決めることは分けて考える必要があります。

通常の労働者派遣では、派遣先による特定目的行為（派遣前の面接、履歴書提出要求、若年者に限定する指定など）は原則として行えません。一方、将来の直接雇用を予定する紹介予定派遣では例外が認められています。また、労働者自身の自発的な事業所訪問等まで一律に禁じる趣旨ではありません。

6. 3年ルールは「誰が・どこで」の2種類

「派遣期間は最長3年」とだけ暗記すると、制度を誤解します。原則として、派遣先の事業所単位の期間制限と、同じ派遣労働者が同じ組織単位で就業する個人単位の期間制限があります。

たとえば、A社の開発部で2年経過した事業所へ、新しい派遣エンジニアが入る場合、その人自身の個人単位の期間制限だけでなく、事業所単位の抵触日にも注意しなければなりません。事業所単位の延長がされなければ、単純に「新しい人だからそこから3年」とはなりません。

無期雇用派遣労働者や60歳以上の労働者など、期間制限の対象外となる例外も存在します。また、契約期間を3年に設定すること自体と、具体的な受入れが適法であることは別問題です。就業開始日・組織単位・抵触日・手続・例外を総合して確認します。

7. 苦情対応を派遣元に丸投げしてはいけない

派遣エンジニアから「A社のPMが契約外の夜間作業を繰り返し命じる」と相談されたとします。雇用主はB社だからといって、A社が「B社に話してください」と突き返して終わりにすることはできません。

労働者派遣法第40条は、派遣先が派遣就業に関する苦情を受けたとき、派遣元へ内容を通知し、密接に連携して誠意をもって遅滞なく適切・迅速に処理することを定めています。指揮命令を行う主体である以上、派遣先にも対応責任があります。

8. 偽装請負はなぜ起こる？

発注書には「準委任」と書かれていても、A社のPMがB社のエンジニアへ出勤時間・残業・個別タスク・作業順番を直接指示し、B社が自社の業務を独立して管理していない場合は、実態として労働者派遣に該当する可能性があります。これが偽装請負の典型的なリスクです。

一方、「発注元からの連絡が少しでもあったら偽装請負」という理解も正確ではありません。業務上の必要な連絡、仕様の説明、成果物の検収などは当然あり得ます。誰が労務管理や業務遂行方法を決めているかを含め、厚生労働省の37号告示や疑義応答集に沿って実態を判断します。

9. 具体例で判断を整理する

10. 契約・受入れ前に確認したいこと

法務担当だけでなく、IT部門の管理者、調達、現場PMが同じ前提を持つことが大切です。とくにプロジェクト開始時と体制変更時に、次の観点を確認します。

• 派遣契約なのか、請負・準委任なのかを明確にし、実際の指示系統と一致させる
• 現場で指示を出してよい人、作業依頼の窓口、責任者を明確にする
• 派遣先での事前面接・候補者指定などを行っていないか確認する
• 事業所単位・個人単位の抵触日、延長手続、期間制限の例外を確認する
• 業務範囲、就業条件、苦情処理の窓口と連携体制を定める
• 就業開始後も、Slack・チケット管理・朝会などの運用が契約実態と矛盾していないか見直す

案件ごとの契約解釈や法的判断は、最新の法令・行政通達を確認し、必要に応じて社会保険労務士や弁護士など専門家と検討してください。

11. 操作ラボ：契約形態と現場判断

文章だけでは混同しがちな「雇用関係」と「指揮命令」を図で切り替えます。その後、IT開発現場の6つの場面で、自分なら適切・不適切のどちらと判断するか試してみましょう。

12. まとめ：契約名称ではなく、現場で誰が何をするか

IT開発ではさまざまな契約で外部エンジニアと協業します。重要なのは、「派遣では派遣先が業務上の指揮命令を行う」「請負・準委任では受託側の独立性を保つ」「派遣には事前人選・期間・苦情処理に関するルールがある」という違いです。

特に3年ルールは、原則として事業所単位と個人単位の2つを確認します。人選の制限は紹介予定派遣の例外にも注意し、苦情は派遣先と派遣元が連携して扱います。法制度を知ることは、エンジニアが安心して働ける開発チームづくりにも直結します。