請負・準委任・労働者派遣の境界を、契約書だけでなく現場の指揮命令、チケット、会議、勤怠、証跡管理まで一体で確認します。
請負・準委任・労働者派遣の境界を、契約書だけでなく現場の指揮命令、チケット、会議、勤怠、証跡管理まで一体で確認します。
IT人材活用で問題になりやすい指揮命令、契約、現場運用、証跡管理を整理します。
常駐型SESは、IT人材不足を補い、システム開発・保守・運用・インフラ構築・セキュリティ対応などを機動的に進めるための実務上重要な取引形態です。一方で、契約書の表題を「業務委託契約」「準委任契約」「SES基本契約」としていても、発注者が受託会社のエンジニアに直接作業指示を出し、勤怠・休暇・残業・担当作業・作業方法を管理していると、実態として労働者派遣に該当し、いわゆる偽装請負と評価されるリスクがあります。
この記事は、「常駐型SESで偽装請負と言われないための実務」を、企業法務、労務、IT契約、内部統制、情報セキュリティ、監査、経営管理の観点から整理するものです。対象読者は、経営者、法務担当、IT部門、購買部門、人事労務担当、コンプライアンス担当、内部監査担当、SES事業者、システム発注企業、スタートアップの管理部門、外部専門家です。法律の専門用語は、できる限り定義を付けて説明します。
なお、この記事は公開情報に基づく一般的解説です。個別案件では、契約書、見積書、発注書、作業指示書、現場のチャット、チケット、議事録、勤怠記録、要員選定過程、再委託構造、許認可の有無などを総合的に確認する必要があります。
---
請負・準委任と書いていても、発注者が人を直接使う実態があればリスクは高まります。
常駐型SESで最も重要な結論は、次の一点です。
次の強調表示は、常駐型SESの適法性を考えるときの中心命題をまとめたものです。契約書の名称だけでは判断できないため、現場で誰が誰に指示しているかを最初に確認することが重要です。発注者が要求を伝える相手と、作業者を管理する主体が分かれているかを読み取ってください。
受託会社は、自社の責任者を通じて、誰が、いつ、どの方法で、どの順序で作業するかを決め、自社の労働者を管理します。この構造が崩れると、常駐型SESは偽装請負リスクを帯びます。
厚生労働省は、労働者派遣か請負かは契約形式ではなく、「労働者派遣事業と請負により行われる事業との区分に関する基準」、いわゆる37号告示に基づき、実態に即して判断されると説明しています。
したがって、常駐型SESで偽装請負と言われないための実務は、単に契約書に「発注者は直接指揮命令しない」と書くことでは足りません。契約書、業務設計、責任者配置、コミュニケーションルール、チケット運用、勤怠管理、成果物管理、費用精算、セキュリティ手続、証跡管理が一貫していなければなりません。
実務上の合格ラインを一文で表すと、次のようになります。
この構造が崩れ、発注者が受託会社のエンジニアを自社の従業員のように使い始めると、常駐型SESは急速に偽装請負リスクを帯びます。
---
SESは法定類型ではないため、民法上の契約類型と派遣法上の評価を分けて考えます。
SESは「System Engineering Service」の略称として実務で使われる用語です。ただし、SESは労働者派遣法や民法に明文で定義された法定類型ではありません。実務上は、IT技術者が発注者のプロジェクトに参加し、システム開発、保守、運用、インフラ管理、テスト、PMO、ヘルプデスク、セキュリティ対応などの技術サービスを提供する取引を指すことが多い用語です。
次の用語一覧は、常駐型SESで混同されやすい契約類型と実務用語を整理したものです。名称が似ていても、完成責任、役務提供、指揮命令の所在が異なるため重要です。各項目で、誰が何を管理するのかを読み取ってください。
IT技術者が開発、保守、運用、PMO、セキュリティ対応などの技術サービスを提供する取引を指すことが多い用語です。
発注者の拠点や管理環境に継続的に参加し、チャット、チケット、会議体の中で業務を行う形態です。
成果物や完成した仕事を検収し、問題があれば契約に基づく修補や損害賠償を検討する構造です。
完成物よりも、調査、運用、保守、レビュー、技術支援などの専門的役務提供が中心になります。
雇用主は派遣元ですが、日々の指揮命令を派遣先が行うため、派遣法上の許可や管理台帳などの規律が問題になります。
契約上は業務委託でも、実態として発注者が受託会社の労働者に直接指揮命令している状態を指す実務上の用語です。
SES契約は、民法上の請負、準委任、またはそれらを組み合わせた契約として設計されることがあります。もっとも、法的評価は契約名だけでは決まりません。特に常駐型SESでは、発注者のオフィス、発注者指定の開発環境、発注者のチャット、発注者の会議体、発注者のセキュリティルールの中で業務が行われるため、発注者がエンジニアを直接管理しているように見えやすい点に注意が必要です。
この記事でいう常駐型SESとは、受託会社のエンジニアが、発注者の事業所、発注者の指定拠点、発注者のプロジェクトルーム、または発注者が管理するオンライン環境に継続的に参加し、発注者のシステム開発・運用等に関与する取引をいいます。
「常駐」は物理的出社に限りません。リモートワークであっても、発注者のSlack、Teams、Jira、Backlog、GitHub、GitLab、ServiceNow、Redmine、Notion等に常時接続し、発注者の社員から直接チケットを割り当てられ、作業優先順位を指示され、稼働時間を管理されている場合には、同じ問題が生じます。
請負は、仕事の完成を目的とする契約です。典型例は、システムを完成させて納品する契約、特定の機能を実装する契約、仕様書に従って成果物を作成する契約です。請負では、受託者は仕事の完成に責任を負います。発注者は完成した仕事や成果物について検収し、問題があれば契約に基づき修補、代替、損害賠償等を求めることになります。
請負において重要なのは、発注者が成果や仕様を示すことは当然許される一方で、受託者の労働者に対して、日々の作業方法、作業順序、勤務時間、休憩、残業、担当者変更などを直接指示することは、請負の構造にそぐわないという点です。
準委任は、法律行為ではない事務の処理を委託する契約です。IT実務では、システム運用、保守、調査、技術支援、PMO、設計支援、レビュー、コンサルティングなど、成果物の完成よりも専門的役務の提供が中心になる場合に使われます。
準委任であることは、偽装請負リスクを消す免罪符ではありません。準委任でも、発注者が受託会社の労働者を直接指揮命令していれば、労働者派遣と評価される可能性があります。逆に、準委任でも、受託会社が自社の専門性と責任により業務を管理し、発注者は業務目的・要件・制約条件を受託会社に伝えるにとどまるなら、適法な業務委託として運用し得ます。
労働者派遣とは、自己の雇用する労働者を、当該雇用関係の下に、かつ、他人の指揮命令を受けて、その者のために労働に従事させることをいいます。ポイントは、労働者の雇用主は派遣元であるが、日々の指揮命令は派遣先が行うという構造です。
適法な労働者派遣を行うには、労働者派遣法上の許可、派遣契約、就業条件の明示、派遣先管理台帳、期間制限、均衡・均等待遇、安全衛生上の責任分担など、派遣法上の規律を守る必要があります。
偽装請負とは、契約上は請負・準委任・業務委託などの形をとりながら、実態としては発注者が受託会社の労働者に直接指揮命令している状態を指す実務上の用語です。厚生労働省のガイドも、請負形式の契約であっても、注文主と労働者との間に指揮命令関係がある場合には労働者派遣事業に該当し、偽装請負となる旨を説明しています。
偽装請負の本質は、発注者が「労働者を使っている」のに、労働者派遣法上の手続・保護・責任分担を回避している点にあります。IT業界の常駐型SESでは、見た目が業務委託であっても、実際には発注者の上司が社内メンバーと同じようにSESエンジニアへタスクを振る、朝会で進捗を詰める、残業を依頼する、休暇を承認する、という運用が生じやすいため、特に注意が必要です。
---
行政解釈と法令を、現場ルールへ落とし込むための基礎を押さえます。
労働者派遣法は、労働者派遣事業の適正な運営と派遣労働者の保護を目的とする法律です。常駐型SESが実態として労働者派遣に該当する場合、派遣法上の許可、契約、就業条件、期間制限、派遣先の講ずべき措置等が問題になります。
次の判断の流れは、常駐型SESを法令と行政解釈に照らして確認する順番を示しています。どの資料も抽象論のままでは足りず、契約書、SOW、現場ルール、教育、監査に落とし込むことが重要です。上から順に、派遣該当性、請負区分、再委託・みなし制度のリスクを読み取ってください。
発注者が他社労働者に指揮命令していないかを確認します。
受託会社が労働者を自ら利用し、業務を独立処理しているかを確認します。
多重構造や名義貸し的な商流が労働者供給に近づいていないかを確認します。
違法派遣の受け入れが発注者側の雇用リスクにつながらないかを確認します。
発注者が「業務委託だから派遣法は関係ない」と考えていても、実態が派遣であれば派遣法の問題になります。特に、受託会社が派遣許可を持たずに、発注者の指揮命令下で労働者を働かせている場合、無許可派遣の問題が生じ得ます。
37号告示は、労働者派遣事業と請負により行われる事業との区分に関する基準です。常駐型SESの実務では、この基準が最も重要です。大枠は、次の二つです。
第一に、受託会社が自己の雇用する労働者を自ら直接利用することです。これは、業務遂行方法、労働時間、服務規律、配置等を受託会社が自ら管理することを意味します。
第二に、受託会社が請け負った業務を自己の業務として独立して処理することです。これは、資金、法律上の責任、機械・設備・材料、専門的技術・経験、企画・管理上の独立性などが問題になります。
この二つの柱を現場に落とし込むと、「発注者が人を使う」のではなく、「発注者が受託会社に業務を発注し、受託会社が自社の責任で業務を処理する」構造を作れるかどうかが核心になります。
厚生労働省は、37号告示の解釈を具体化するガイドや疑義応答集を公表しています。ガイドでは、作業工程の変更、技術指導、緊急対応、会議参加、メールのCC、セキュリティのための氏名提出、スキルシート、アジャイル開発など、実務上問題になりやすい場面について考え方が示されています。
常駐型SESの実務では、このガイドを「抽象的な行政資料」としてではなく、契約書、発注書、現場ルール、教育資料、内部監査チェックリストに落とし込むことが重要です。
職業安定法は、原則として労働者供給事業を禁止しています。 常駐型SESの多重構造、再委託、個人事業主の利用、名義貸し的な商流では、派遣法だけでなく、職業安定法上の労働者供給事業の問題が生じ得ます。
たとえば、A社がB社から人材を受け入れ、B社がさらにC社や個人事業主から人を集め、発注者であるA社が現場で直接指揮命令している場合、単なる業務委託では説明しにくい構造になります。再委託がある場合は、誰が雇用主か、誰が指揮命令者か、誰が業務責任を負うかを明確にしなければなりません。
労働契約申込みみなし制度は、派遣先等が一定の違法派遣を受け入れた場合に、派遣先等が派遣労働者に対して労働契約を申し込んだものとみなす制度です。厚生労働省資料では、いわゆる偽装請負等も対象類型として説明されています。
この制度は、発注者にとって非常に重いリスクです。単なる行政指導や契約上の損害賠償にとどまらず、発注者とエンジニアとの雇用関係が問題になり得るからです。特に、長期間にわたり同一のエンジニアを同一部署・同一プロジェクトで受け入れ、発注者が日常的に直接指示していた場合、リスクは高まります。
---
人月精算、IT開発の対話、セキュリティ管理が指揮命令に見えやすい点を整理します。
常駐型SESでは、発注者の現場担当者が「この人は当社のプロジェクトメンバー」「この人に作業を振ればよい」と認識しがちです。特に人月単価で契約し、月160時間前後の稼働を前提にしている場合、発注者の意識は「成果物を買う」よりも「労働力を買う」に近づきます。
次のリスク一覧は、常駐型SESで偽装請負と言われやすい理由を3つに分けたものです。現場ではどれか一つではなく複数が重なって見えるため、初期点検で重要です。人を借りている意識、IT開発の対話、セキュリティ管理の混同を読み取ってください。
人月単価や月160時間前後の稼働前提により、成果物ではなく労働力を買っている認識に近づきます。
要件、優先度、設計方針の協議が、個人への担当・順序・労働時間の指示に変わることがあります。
入退館、アカウント、セキュリティ教育などが、労務管理や業務遂行方法の指示に見える場合があります。
この意識のまま運用すると、発注者が受託会社の労働者に対し、社内メンバーと同じように、次のような行為をしてしまいます。
これらは、単独で直ちに必ず違法と断定されるものではないとしても、積み重なると、発注者が受託会社の労働者を指揮命令していると評価される重要な事情になります。
IT開発では、要件、仕様、バグ、優先度、設計方針、技術的制約、セキュリティ要件、リリース日程などを、発注者と受託者が密接に協議しなければなりません。特にアジャイル開発では、プロダクトオーナー、スクラムマスター、開発チーム、ステークホルダーが頻繁に対話します。
この対話自体が直ちに偽装請負になるわけではありません。厚生労働省のシステム開発に関する事務連絡でも、アジャイル型開発等における情報共有、技術的議論、協働が直ちに偽装請負に当たるわけではないという趣旨の整理がされています。
ただし、発注者が協議の名目で、受託会社の個々のエンジニアに作業方法、担当、順序、労働時間を直接決めてしまうと、指揮命令に近づきます。したがって、アジャイルだから自由に直接指示できる、という理解は誤りです。
常駐型SESでは、発注者の施設、端末、ネットワーク、本番環境、個人情報、機密情報にアクセスすることが多く、発注者が入館証、アカウント、権限、誓約書、セキュリティ教育、ログ監視、事故時報告を求めることがあります。
これらは、発注者の施設管理・情報管理として必要な場合があります。厚生労働省のガイドも、秘密保持や安全衛生のための合理的な関与が直ちに偽装請負となるわけではない趣旨を示しています。 また、注文者等が安全衛生上の指示等を行う場合の考え方についても、厚生労働省から資料が公表されています。
重要なのは、セキュリティ・安全衛生・施設管理のための指示と、業務遂行方法・労働時間・服務規律への指揮命令を混同しないことです。たとえば「この部屋では撮影禁止」「本番環境アクセスは申請制」「事故時は直ちに退避」は施設・安全・情報管理として説明しやすい一方、「今日は22時まで残って障害対応を続けてください」「Aさんはこの設計で実装してください」は業務指示・労務指示に近づきます。
---
受託会社が労働者を自ら管理し、業務を独立処理しているかが中心です。
37号告示の第一の柱は、受託会社が自己の労働者を自ら直接利用しているかです。常駐型SESでは、次の観点で確認します。
次の2つの項目は、37号告示を常駐型SESへ当てはめるときの中心軸です。どちらか一方だけでは足りないため、契約書と現場証跡の両方で確認することが重要です。労働者管理と業務独立性のどこに弱点があるかを読み取ってください。
業務遂行方法、労働時間、服務規律、配置・担当者決定を受託会社が管理しているかを確認します。
業務責任、品質管理、専門性、設備・知識、資金・事業リスクを自社の責任で負っているかを確認します。
受託会社が、どのような方法で調査、設計、実装、レビュー、テスト、リリース、障害対応を行うかを決めているかが重要です。発注者は、業務目的、要件、制約条件、品質基準、期限、受入基準を示すことはできます。しかし、受託会社の個々のエンジニアに対し、具体的な作業順序や作業手順を直接命じることは避けるべきです。
望ましい運用は、発注者が受託会社の業務責任者に「この機能について、5月末までにこの受入基準を満たす形で対応してほしい」と伝え、受託会社の業務責任者が自社メンバーに担当・順序・方法を指示する形です。
受託会社の労働者の始業、終業、休憩、残業、休日労働、有給休暇、遅刻、早退、在宅勤務の承認は、原則として受託会社が行うべきです。発注者が受託会社のエンジニアに直接「今日は残って」「明日は早く来て」「休むなら私に申請して」と言う運用は、偽装請負リスクを高めます。
発注者が必要な稼働時間帯や会議時間を契約上の業務条件として受託会社に伝えることはあり得ます。しかし、個々の労働者の勤怠管理を発注者が行ってはいけません。発注者が入退館ログやシステムログを持つ場合も、それはセキュリティ・施設管理目的に限定し、勤怠管理や評価の主資料にしない設計が必要です。
服務規律とは、職場での規律、服装、情報管理、秩序維持、懲戒、注意指導などを指します。受託会社の労働者に対する服務規律は、原則として受託会社が管理します。
もっとも、発注者の施設に入る以上、発注者が施設利用ルール、情報セキュリティルール、避難ルール、ハラスメント防止ルール、撮影禁止、機密資料の持ち出し禁止などを求めることはあります。ここでも重要なのは、発注者が直接叱責・懲戒・評価するのではなく、違反があれば受託会社の責任者に通知し、受託会社が自社の労務管理として対応することです。
誰を何の業務に従事させるか、どの担当にするか、誰を交代させるかは、原則として受託会社が決めるべき事項です。発注者が「Aさんをこのチームに入れて」「Bさんはスキルが低いから外して」「Cさんだけを継続して」と個人を指定する運用は、労働者の配置決定に発注者が関与していると見られやすくなります。
発注者は、業務に必要なスキル、経験、体制、人数の目安、セキュリティ要件を受託会社に提示することはできます。しかし、個人の採否・配属・交代を発注者が実質的に決定する運用は避けるべきです。
受託会社は、単に人を出すのではなく、委託された業務を自社の責任で処理する必要があります。請負なら成果物や完成責任、準委任なら専門家としての善管注意義務、報告義務、業務処理責任が問題になります。いずれにしても、受託会社が「人を月単価で出すだけ」で、業務内容・品質・報告・管理に責任を負わない形は危険です。
契約書と発注書には、業務範囲、役割、成果物、報告事項、品質基準、検収または確認方法、変更管理、障害対応、契約不適合・損害賠償、再委託、情報管理を定めるべきです。
37号告示では、業務の独立性の要素として、機械、設備、器材、材料、資材、専門的な技術・経験などが考慮されます。IT業務では、発注者のセキュリティ上、発注者貸与端末や発注者環境を使わざるを得ないことがあります。端末や環境を発注者が提供しているだけで直ちに偽装請負と決まるわけではありません。
しかし、受託会社が自社の管理能力、技術判断、品質管理、教育、レビュー体制、ナレッジ、ツール管理、セキュリティ管理をほとんど持たず、発注者の社員が全て管理している場合、独立性は弱くなります。発注者環境を使う場合でも、受託会社側の管理手順、レビュー、報告、教育、責任者承認を整備することが重要です。
受託会社が自己の事業として業務を処理しているかも重要です。業務上の費用負担、損害発生時の責任、再作業負担、品質保証、教育コスト、管理者コストなどが全く考慮されず、単に労働時間に単価を掛けるだけの契約は、労働力提供に近く見えます。
ただし、IT業界で人月・時間単価による精算が行われること自体が直ちに違法というわけではありません。問題は、精算単位が時間であることよりも、受託会社が業務責任を負わず、発注者が個々の労働者を直接使っている実態です。時間精算を採用する場合ほど、業務範囲、責任者、報告、品質、指示系統を明確にする必要があります。
---
直接タスク割当、勤怠管理、要員選別、一人常駐など、監査で見られやすい事情を確認します。
最も典型的な危険パターンは、発注者社員が、受託会社のエンジニアに直接「このチケットを今日中にやってください」「次はこの調査をしてください」「この順番で実装してください」と指示する運用です。
次の危険パターン一覧は、現場ログや監査で問題になりやすい行為を整理したものです。単独で直ちに結論が決まるとは限りませんが、積み重なると指揮命令性を示す事情になります。誰が担当、時間、方法、評価を決めているかを読み取ってください。
発注者がチケット、期限、優先度、作業方法を個人に直接指定する運用です。
発注者が休暇承認、残業依頼、遅刻注意、稼働率評価を個人別に行う運用です。
発注者がスキルシートや面談で個人の採用・不可を実質的に決める運用です。
組織図、評価制度、承認経路、電話帳などで発注者従業員と同じ扱いにする運用です。
契約上の責任者が実際には業務管理、品質確認、労務管理をしていない状態です。
受託会社側の別責任者を通さず、本人がすべての依頼・勤怠・緊急対応を受ける状態です。
この場合、発注者が受託会社の労働者の業務遂行方法を直接決めていると評価されやすくなります。チケットツールを使っている場合でも、チケットの作成者、担当者割当者、優先順位決定者、期限設定者、作業方法の指示者が発注者社員であれば、指揮命令性が強くなります。
望ましい運用は、発注者が受託会社責任者または窓口に要求・課題・優先順位を伝え、受託会社が自社内で担当者を決めてチケットを処理する形です。ツール上も、発注者が個人に直接アサインするのではなく、受託会社チームまたは受託会社責任者に依頼し、受託会社側で担当者を設定する運用が望ましいです。
発注者がSESエンジニアに対し、勤怠入力を求め、休暇を承認し、残業を指示し、遅刻を注意し、稼働率を個人別に評価する運用は危険です。受託会社の労働者に対する労務管理は、受託会社が行うべきだからです。
発注者が必要とするのは、業務提供可能時間帯、会議出席可能時間帯、サービスレベル、納期、対応期限などの契約上の業務条件です。これを、個々の労働者の勤務命令にしてはいけません。
発注者がスキルシートを見て、候補者と面談し、「この人は採用」「この人は不可」と判断している場合、発注者が受託会社の労働者の配置を実質的に決めていると見られやすくなります。
スキル確認が一切許されないわけではありません。発注者は、受託会社の体制が業務要件を満たすか確認する必要があります。しかし、個人の採用面接のような運用は避けるべきです。確認対象は、個人ではなく、受託会社の業務遂行体制、経験、担当ロール、チームとしての能力に寄せるべきです。スキルシートを使う場合も、個人が特定されにくい形式、業務要件との対応確認、個人選別に使わないルールが重要です。厚生労働省ガイドでも、スキルシートや事前面談に関する考え方が示されています。
発注者の組織図、評価制度、1on1、目標管理、表彰制度、勤怠管理、座席表、電話帳、チャット権限、承認フローに、SESエンジニアを発注者従業員と同じ形で組み込むと危険です。プロジェクト上の連絡先として掲載すること自体は必要な場合がありますが、発注者のライン組織の一員のように扱うことは避けるべきです。
表記上も、「所属 ― 発注者システム部」ではなく、「委託先 ― 〇〇社」「〇〇社担当チーム」「〇〇社業務責任者」といった区別を明確にする方が安全です。
契約書上は「受託者責任者」を置いていても、現場ではほとんど機能していない場合があります。たとえば、責任者が営業担当名だけで、技術的判断も労務管理もしていない、現場のエンジニアが発注者から直接指示を受けている、責任者への相談や承認記録がない、という状態です。
この場合、形式上の責任者条項は防御になりません。受託会社責任者は、実際に業務割当、進捗管理、品質確認、労務管理、休暇・残業承認、発注者との調整を行う必要があります。常駐していなくても、チャット、会議、週次報告、承認ログなどで実質的に管理していることを示せる体制が必要です。
一人だけで常駐するSESでは、偽装請負リスクが高くなります。なぜなら、受託会社の現場管理者と作業者が同一になりやすく、発注者がその一人に直接依頼せざるを得ない状況になりがちだからです。
一人常駐が直ちに違法というわけではありません。しかし、受託会社側に別の管理責任者を置き、発注者からの依頼・変更・緊急連絡・勤怠関連事項がその責任者を通るようにしなければなりません。本人が単なる窓口として情報を受け取る場合でも、業務指示・労務指示は受託会社側で判断する運用を明確にする必要があります。
---
契約名ではなく、SOW、責任者、変更管理、直接指揮命令禁止を具体化します。
契約書の表題を「準委任契約」とすれば安全、という理解は誤りです。契約書では、次の事項を具体的に定める必要があります。
次の判断の流れは、常駐型SESの契約設計を現場運用へつなげる順番を示しています。条項を置くだけでは防御にならないため、発注書、SOW、チケット、会議、証跡まで一貫させることが重要です。抽象的な業務名から、責任者と変更管理へ具体化する過程を読み取ってください。
目的、対象工程、対象外事項、成果物・報告物をSOWに書きます。
発注者の要望は受託会社責任者または指定窓口へ集約します。
範囲、優先順位、期限、体制に影響する変更は、SOWや個別契約の変更として協議します。
責任者承認、議事録、報告書、チケットログを保存します。
特に重要なのは、発注者の「業務上の要求」と、受託会社労働者への「労務上・作業上の指揮命令」を区別する条項です。
常駐型SESでは、基本契約だけで運用され、個別発注は「〇〇業務支援」「開発支援」「PMO支援」など抽象的に書かれがちです。これでは、実態として何を委託しているのか不明確になり、「人を出しているだけ」と見られやすくなります。
SOW（Statement of Work）には、少なくとも次の事項を記載します。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 項目 | 記載すべき内容 |
|---|---|
| 業務目的 | 何のために業務を委託するのか |
| 業務範囲 | 対象システム、対象機能、対象工程、対象作業 |
| 対象外事項 | 受託会社が行わない業務 |
| 成果物・報告物 | 設計書、レビュー記録、テスト結果、調査報告、月次報告など |
| 役割分担 | 発注者、受託会社、第三者ベンダーの責任範囲 |
| 受入基準 | 成果物または業務処理結果の確認基準 |
| コミュニケーション | 会議体、窓口、議事録、チケット運用 |
| 変更管理 | 業務追加、優先順位変更、仕様変更の承認方法 |
| セキュリティ | アカウント、権限、ログ、持出し禁止、事故報告 |
| 労務管理 | 受託会社が勤怠・休暇・残業・服務を管理すること |
| 証跡 | 保存すべき記録、保存期間、監査対応 |
SOWが具体的であるほど、発注者は成果・要件を受託会社に発注していると説明しやすくなります。逆に、SOWが「エンジニア1名、月160時間、Java経験3年以上」といった人材要件だけで構成されている場合、労働力提供に見えやすくなります。
以下は、常駐型SES契約に入れることが考えられる条項例です。実際の利用には、案件内容に応じた調整が必要です。
この条項は、単体では不十分です。現場のチケット運用、会議運用、チャット運用が条項と一致している必要があります。
責任者が常駐するか否かは案件によりますが、少なくとも責任者が実際に機能することが必要です。責任者不在、名ばかり責任者、営業担当だけの名義責任者は避けるべきです。
常駐型SESでは、日々の仕様変更、優先順位変更、障害対応、緊急タスクが発生します。変更管理を契約に入れないと、発注者が個々のエンジニアに直接指示してしまいます。
この条項により、発注者のセキュリティ・安全衛生上の必要な指示と、業務指示・労務指示を区別します。
---
発注者と受託者の接点を消すのではなく、接点の性質を記録可能にします。
常駐型SESでは、発注者と受託会社の接点を完全になくすことは現実的ではありません。重要なのは、接点の性質を整理することです。
次の判断の流れは、発注者から受託会社へ連絡する際の安全な経路を示しています。日々の会議やチャットは証跡として残るため、個人への命令に見えない書き方が重要です。要求、技術協議、勤怠、緊急連絡を分けて読み取ってください。
発注者は受託会社責任者またはチームへ伝えます。
受託会社が自社内で決め、必要に応じて発注者へ見込みを報告します。
発注者は承認せず、受託会社責任者が自社の労務管理として扱います。
安全・保全のための連絡は必要最小限にし、事後に理由と範囲を記録します。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 連絡内容 | 望ましい宛先 | 留意点 |
|---|---|---|
| 要件、仕様、優先順位 | 受託会社責任者または窓口 | 個人への直接作業指示にしない |
| チケット追加 | 受託会社チームまたは責任者 | 担当者割当は受託会社側で実施 |
| 技術的質問 | 受託会社担当者も参加可 | 対等な技術協議として記録 |
| 障害・緊急連絡 | 受託会社責任者、緊急窓口 | 安全・保全のための即時連絡はあり得るが、事後記録する |
| 勤怠・休暇 | 受託会社責任者 | 発注者は承認しない |
| 要員交代 | 受託会社責任者または営業窓口 | 個人の採否を発注者が決めない |
| セキュリティ違反 | 受託会社責任者 | 発注者が直接懲戒しない |
会議参加自体が直ちに偽装請負になるわけではありません。厚生労働省ガイドでも、会議やメールCC等について、発注者と請負労働者が直接接点を持つ場面があり得ることを前提に、指揮命令に当たるかどうかを実質的に見る考え方が示されています。
しかし、会議で発注者が受託会社の個々のエンジニアに対し、「あなたは今日これをやる」「この方法で作業しなさい」「明日までに残業してでも完了しなさい」と指示するなら危険です。会議の目的を、進捗共有、成果確認、仕様確認、課題確認、リスク共有に限定し、タスク割当や作業方法の指示は受託会社側で行う設計が必要です。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 会議 | リスク | 推奨運用 |
|---|---|---|
| 朝会 | 個人別に今日の作業を発注者が決めやすい | 発注者は優先課題を示し、担当割当は受託会社側 |
| 進捗会議 | 遅延理由を個人に詰めやすい | 受託会社責任者が進捗と対策を報告 |
| レビュー会議 | 技術指示と仕様確認が混在しやすい | 仕様・品質基準の確認と対等な技術協議に限定 |
| 障害会議 | 緊急時に直接命令が出やすい | 緊急保全指示と業務指示を分け、事後に責任者経由で整理 |
| レトロスペクティブ | 受託会社労働者への評価・指導になりやすい | プロセス改善を受託会社責任者と協議 |
SlackやTeamsのようなチャットでは、形式上は軽いやり取りでも、証跡としては非常に強い意味を持ちます。監査や紛争時には、チャットログから実態が判断されることがあります。
危険なチャット例は次のとおりです。
望ましいチャット例は次のとおりです。
ポイントは、個人への命令ではなく、受託会社または責任者への依頼・確認として書くことです。
チケットツールは、偽装請負リスクを下げることも高めることもあります。発注者がチケットを個人へ直接割り当て、期限や方法を細かく指示し、完了まで直接追跡するなら危険です。一方、発注者が業務要求や課題をチケット化し、受託会社が自社内で担当者を決め、対応結果を報告するなら、業務委託として説明しやすくなります。
推奨される設計は次のとおりです。
アジャイル開発では、発注者と受託者が頻繁に対話し、バックログを更新し、優先順位を調整します。このような協働は、現代のシステム開発では不可欠です。厚生労働省のシステム開発に関する事務連絡も、アジャイル開発等での発注者・受託者間の意思疎通や協働について、具体的な整理を示しています。
もっとも、アジャイルという言葉は、指揮命令を自由化するものではありません。プロダクトオーナーがプロダクトの価値、要求、バックログ、優先順位を示すことと、受託会社の個々のエンジニアに作業方法・作業順序・労働時間を命じることは別です。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 領域 | 発注者が行ってよいこと | 避けるべきこと |
|---|---|---|
| プロダクト価値 | ビジネス目的、ユーザー価値、優先順位を説明する | 個人に直接作業割当をする |
| バックログ | 要求、受入基準、優先度を提示する | 実装順序・担当者を直接命じる |
| デイリー | 課題共有、依存関係確認をする | 今日の個人別作業命令をする |
| レビュー | 成果物を確認しフィードバックする | 労働者を評価・叱責する |
| レトロ | プロセス課題を受託会社責任者と協議する | 受託会社労働者の服務・勤務態度を直接指導する |
| 技術議論 | 対等な情報交換・制約条件説明をする | 発注者が上司として実装方法を命令する |
---
必要な施設管理・情報管理を、業務指示や労務管理に変質させない設計が必要です。
発注者は、個人情報、営業秘密、ソースコード、顧客データ、認証情報、本番環境を守る必要があります。そのため、受託会社のエンジニアに対して、発注者施設やシステムの利用ルールを課すことは実務上避けられません。
ただし、セキュリティ指示は、対象、目的、範囲を明確にする必要があります。たとえば、次のような指示はセキュリティ上の合理的指示として説明しやすいものです。
一方で、次のような指示は業務指示・労務管理に近づきます。
セキュリティ上必要な緊急対応がある場合でも、可能な限り受託会社責任者を経由し、事後に理由、範囲、時刻、関係者を記録することが重要です。
発注者施設内で事故、災害、健康被害、危険作業、避難、感染症対応が問題になる場合、発注者が安全衛生上必要な指示を行う場面があります。厚生労働省資料でも、注文者等が安全衛生上の指示等を行う場合の考え方が示されています。
重要なのは、安全衛生上の必要性に基づく指示と、業務遂行上の命令を区別することです。たとえば「火災報知器が鳴ったので避難してください」「感電のおそれがあるのでそのラックに触れないでください」は安全確保の指示です。一方、「障害対応が終わるまで帰らないでください」は労働時間・業務遂行に関する指示です。
発注者が入退館管理、アカウント発行、秘密保持、個人情報保護のために、受託会社から作業者の氏名、連絡先、所属、必要最小限の情報を受け取ることがあります。これは、目的と範囲が限定されていれば、直ちに偽装請負とはいえません。
しかし、氏名提出やスキル情報が、発注者による個人選別、評価、配置決定、交代指示に使われると危険です。提出目的、利用範囲、保存期間、アクセス権限、削除手続を定め、本人面談や採否判断に使わないことを明確にするべきです。
---
時間精算そのものより、業務責任と報告の弱さが労働力提供に見える点に注意します。
IT業界では、人月単価、時間幅精算、超過控除、月次精算が一般的です。人月精算それ自体が直ちに偽装請負を意味するわけではありません。しかし、契約書や見積書に業務内容がほとんどなく、「Java要員1名」「PMO要員2名」「月160時間」「単価〇万円」といった記載しかない場合、発注者が労働力を購入しているように見えます。
人月精算を採用する場合は、少なくとも次の設計が必要です。
「140時間から180時間の範囲で精算する」といった精算幅は、SES実務でよく使われます。これを用いる場合も、発注者が個々のエンジニアの残業を命じたり、稼働不足を本人に詰めたりしてはいけません。
精算幅は、受託会社との商取引上の精算条件として扱うべきです。稼働見込みや超過可能性がある場合、受託会社責任者が発注者に報告し、業務範囲・優先順位・体制・費用について協議します。
準委任では、完成物が明確でない場合があります。その場合でも、報告物を設計することが重要です。たとえば、次のような報告物が考えられます。
報告物があることで、発注者は「人の稼働」ではなく「業務処理結果」を確認していると説明しやすくなります。
---
商流が長くなるほど、雇用主、責任者、指揮命令者の分離が重要になります。
常駐型SESでは、発注者、一次受託会社、二次受託会社、三次受託会社、個人事業主が関与する多重構造が発生することがあります。この場合、指揮命令系統、契約関係、雇用関係、再委託承諾、情報管理、責任分担が複雑になります。
多重構造で最も危険なのは、発注者が末端のエンジニアに直接指示し、中間会社が契約上の名義だけになっている状態です。この場合、業務委託の独立性は弱くなり、労働者派遣、労働者供給、名義貸し、職業安定法上の問題が生じ得ます。
再委託を認める場合、発注者は次の点を契約で管理すべきです。
「相手が個人事業主なら労働者ではないから偽装請負にならない」と単純に考えるのは危険です。形式上はフリーランスでも、実態として特定企業の指揮命令下で働き、勤務時間・場所・業務方法を管理され、代替性がなく、報酬が労務提供の対価と評価される場合、労働者性が争われることがあります。厚生労働省ガイドも、フリーランス等への再委託であっても実態に応じて判断される趣旨を示しています。
フリーランスを含むSES類似取引では、独立した事業者としての裁量、成果・業務単位の責任、代替可能性、報酬設計、指示系統、契約管理をより慎重に設計する必要があります。
---
契約書レビューだけでなく、チャット、チケット、勤怠、報告書の実態を確認します。
偽装請負リスクは、契約書レビューだけでは防げません。契約書に適切な条項があっても、現場が発注者社員とSESエンジニアを区別せずに運用していれば、実態が優先されます。
したがって、法務、購買、IT部門、人事労務、情報システム、情報セキュリティ、内部監査、経理、経営管理が連携する必要があります。
企業の内部統制としては、次の三線管理が有効です。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 線 | 主体 | 役割 |
|---|---|---|
| 第1線 | IT部門・事業部門 | 現場運用、発注、会議、チケット、コミュニケーション管理 |
| 第2線 | 法務・労務・購買・コンプライアンス・情報セキュリティ | 契約審査、ルール策定、教育、例外承認、相談対応 |
| 第3線 | 内部監査 | 契約と実態の一致、証跡、是正状況の監査 |
内部監査では、次の証跡を確認します。
監査では、「契約書に直接指揮命令禁止条項があるか」だけでなく、「実際のチケットで誰が誰に何を指示しているか」を見る必要があります。
---
発注者、受託会社、現場リーダーの視点で日々の運用を確認します。
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| No | チェック項目 | 望ましい状態 |
|---|---|---|
| 1 | 契約類型 | 請負・準委任・派遣の使い分けが明確 |
| 2 | 業務範囲 | SOWに業務範囲、成果・報告、対象外が記載されている |
| 3 | 指示系統 | 発注者は受託会社責任者へ依頼し、個人へ直接指揮命令しない |
| 4 | 受託会社責任者 | 実在し、業務管理・労務管理を行っている |
| 5 | 勤怠管理 | 発注者が休暇・残業・遅刻早退を承認していない |
| 6 | チケット | 個人への直接アサインではなく、受託会社側で担当決定 |
| 7 | 会議 | 仕様確認・進捗共有が中心で、個人への命令になっていない |
| 8 | スキル確認 | 個人採否ではなく、受託会社の体制確認として実施 |
| 9 | セキュリティ | 目的・範囲を限定し、労務指示に変質していない |
| 10 | 精算 | 人月・時間精算でも業務責任と報告が明確 |
| 11 | 再委託 | 事前承諾、責任者、指示系統、秘密保持が整備されている |
| 12 | 教育 | 現場管理者が偽装請負リスクを理解している |
| 13 | 証跡 | 契約、議事録、チケット、報告書が保存されている |
| 14 | 例外対応 | 緊急時の直接連絡について事後記録・是正ルートがある |
| 15 | 見直し | 定期監査と是正措置が運用されている |
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| No | チェック項目 | 望ましい状態 |
|---|---|---|
| 1 | 業務責任 | 単なる人出しではなく、業務処理責任を負っている |
| 2 | 責任者 | 作業指示、進捗管理、品質管理、労務管理を行う責任者がいる |
| 3 | 労務管理 | 勤怠、休暇、残業、服務、評価を自社で管理している |
| 4 | 作業指示 | 発注者からの依頼を自社責任者が受け、自社内で指示している |
| 5 | 教育 | エンジニアが「発注者の直接指示を受けない」ルールを理解している |
| 6 | 報告 | 月次・週次の業務報告を自社として作成している |
| 7 | 品質管理 | レビュー、テスト、承認、ナレッジ管理がある |
| 8 | 連絡記録 | 発注者とのやり取りを記録している |
| 9 | 再委託 | 再委託先を自社で管理し、丸投げしていない |
| 10 | 是正 | 直接指示が発生した場合に発注者へ是正を申し入れる体制がある |
次の比較一覧は、この章で扱う項目を横並びで整理したものです。判断要素の違いを同じ列で確認できるため、契約や現場運用へ落とし込む際に重要です。各行の項目と望ましい状態、留意点の対応関係を読み取ってください。
| 避けるべき表現 | 置き換え例 |
|---|---|
| 「Aさん、今日中にこれをやって」 | 「〇〇社様、この課題の対応可否と見込みをご確認ください」 |
| 「明日は9時に出社して」 | 「明日9時の会議で確認したい事項があります。〇〇社側で出席可否をご調整ください」 |
| 「残業して終わらせて」 | 「期限に影響が出るため、体制・納期・範囲の調整をご相談させてください」 |
| 「Bさんを外してCさんに替えて」 | 「必要スキルに不足があるため、〇〇社としての体制改善案をご提示ください」 |
| 「休むなら私に申請して」 | 「不在予定は〇〇社責任者から共有してください」 |
| 「この手順で実装して」 | 「この仕様・制約条件を満たす対応方針をご提案ください」 |
---
事実保全、リスク評価、業務委託の是正、派遣切替え、内製化の選択肢を整理します。
偽装請負リスクが疑われる場合、最初にすべきことは事実の保全です。チャット削除、議事録改ざん、チケット書換え、勤怠記録の後付け修正は、法務・コンプライアンス上重大な問題になります。
次の判断の流れは、偽装請負リスクが疑われたときの是正選択肢を示しています。証跡保全を先に行わないと、後から実態を説明できなくなるため重要です。業務委託として戻すのか、派遣や雇用へ切り替えるのかを読み取ってください。
契約書、SOW、チャット、チケット、勤怠、入退館ログなどを保存します。
直接指示、勤怠管理、責任者機能、再委託、期間固定化を確認します。
SOW、責任者、指示系統、会議・チケットを直します。
派遣契約、内製化、雇用、出向など適した枠組みを検討します。
保全すべき資料は、契約書、発注書、SOW、会議体、チャット、チケット、メール、勤怠、入退館ログ、アカウントログ、スキルシート、面談記録、再委託契約、請求書、月次報告書などです。
次に、次の観点でリスク評価を行います。
リスクが確認された場合、是正策は大きく三つです。
第一に、業務委託としての独立性を回復する方法です。受託会社責任者を実質化し、指示系統を変更し、SOWを明確化し、発注者から個人への直接指示を止め、会議・チケット・勤怠運用を改めます。
第二に、実態が発注者による指揮命令を必要とする業務であるなら、適法な労働者派遣契約に切り替える方法です。この場合、派遣元の許可、派遣契約、就業条件、期間制限、派遣先管理台帳、均衡・均等待遇、安全衛生責任などを整備する必要があります。
第三に、内製化または雇用への切替えです。発注者が継続的に直接管理したい人材であれば、業務委託ではなく雇用、出向、派遣など別の法的スキームを検討すべきです。
是正は、単に「今後気をつける」という通知では不十分です。次の再発防止策が必要です。
---
直接チケット割当、セキュリティ教育、アジャイル、一人常駐の実務上の違いを確認します。
発注者のプロジェクトマネージャーが、Jira上でSESエンジニア個人に直接チケットを割り当て、期限、優先度、実装方法をコメントしていました。契約書には準委任と書かれていましたが、受託会社責任者はほとんど関与していませんでした。
このケースでは、発注者が業務遂行方法と作業分担を直接管理していると評価されるリスクが高いといえます。是正策として、チケットの割当先を受託会社チームまたは責任者に変更し、発注者のコメントは要求・受入基準・制約条件に限定し、担当者割当と具体的作業指示は受託会社側で行う運用に変更します。
発注者が、常駐する受託会社エンジニアに対し、入館、アカウント利用、個人情報保護、秘密保持、事故時報告の教育を実施していました。
このケースでは、教育内容が発注者施設・情報資産の保護に必要な範囲であれば、直ちに偽装請負とはいえません。ただし、教育の中で発注者の上司の指示に従うこと、勤怠申請方法、評価制度、日々の作業命令系統まで説明している場合は危険です。セキュリティ教育と業務指揮命令を明確に区別し、受託会社の労務管理事項は受託会社から教育させるべきです。
発注者のプロダクトオーナーが、受託会社エンジニアと毎日バックログ、仕様、受入基準、技術制約を議論していました。
このケースでは、対話自体が直ちに偽装請負とはいえません。アジャイル開発では、情報共有と協働が必要です。問題は、プロダクトオーナーが「Aさんは今日これをやる」「Bさんは残業して対応する」「この実装方法でやる」と直接命じているかです。プロダクト価値、要求、優先順位の説明にとどめ、作業割当と労務管理は受託会社側が行うなら、リスクは相対的に低下します。
受託会社から一名だけが常駐し、発注者はその本人に直接タスク、休暇、残業、障害対応を依頼していました。受託会社側の責任者は営業担当で、日常的な業務管理はしていませんでした。
このケースは高リスクです。一人常駐の場合こそ、受託会社側の別責任者が必要です。発注者からの依頼はその責任者に集約し、本人への作業指示、勤怠管理、残業判断は受託会社が行う体制に変更すべきです。実態として発注者が直接管理し続ける必要があるなら、労働者派遣への切替えを検討するべきです。
---
法務、労務、IT、購買、情報セキュリティが分担してリスクを下げます。
弁護士、企業内弁護士、法務担当は、契約類型の選択、契約書・SOWの作成、派遣法・職業安定法・民法上のリスク評価、紛争時対応、行政対応を担います。重要なのは、契約書だけを見るのではなく、現場運用の証跡まで確認することです。
社会保険労務士や労務担当は、勤怠、休暇、残業、服務規律、労働時間管理、安全衛生、ハラスメント対応、派遣先・派遣元責任の整理に関与します。常駐型SESでは、発注者が受託会社労働者の労務管理をしていないかを確認する視点が重要です。
IT部門は、実際の会議、チャット、チケット、レビュー、障害対応を設計します。偽装請負リスクを最も直接的に左右するのは現場です。プロジェクトマネージャーやプロダクトオーナーは、どこまでが仕様説明で、どこからが作業指示かを理解する必要があります。
購買・経理・経営管理は、人月単価、精算幅、発注書、請求書、検収、予算管理を通じてリスクに関与します。「人を何名買う」という発注ではなく、「どの業務をどの責任範囲で委託する」という発注に変えることが重要です。
コンプライアンス部門と内部監査部門は、契約と実態の一致を確認します。とくに、チャット・チケット・勤怠・会議録をサンプル監査し、直接指揮命令の痕跡がないかを確認する必要があります。
情報セキュリティ・個人情報保護担当は、入退館、アカウント、権限、ログ、秘密保持、個人情報、委託先管理を担います。セキュリティ管理は必要ですが、労務管理や業務指示に変質しないよう、目的・範囲・記録を明確にする必要があります。
---
一般的な制度説明として、契約名、会議参加、技術助言、緊急対応の考え方を整理します。
一般的には、契約書を準委任にしただけで偽装請負リスクがなくなるわけではないとされています。ただし、契約内容、現場の指示系統、勤怠管理、責任者の機能、証跡によって評価は変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、仕様確認、情報共有、技術的議論、成果確認のための会議参加だけで直ちに偽装請負と評価されるわけではないとされています。ただし、会議で個人への作業命令や労務指示が行われると結論が変わる可能性があります。具体的な対応は、会議録や運用資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、発注者がシステム仕様、技術的制約、過去経緯、品質基準、セキュリティ要件を説明し、対等な技術的議論を行うことは必要な場合があるとされています。ただし、助言を超えて作業方法を命令していると見られる事情があると評価は変わる可能性があります。具体的な線引きは、案件資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、入退館、アカウント発行、秘密保持、個人情報保護、セキュリティ管理など合理的目的がある場合、必要最小限の情報を求めることがあります。ただし、その情報を個人選別、採否判断、配置決定に使うと評価が変わる可能性があります。具体的な運用は、目的と利用範囲を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、人月契約それ自体が直ちに違法と評価されるわけではないとされています。ただし、業務範囲、成果・報告、受託会社責任者、指示系統、労務管理、品質管理が不明確な場合は、労働力提供に近いと見られる可能性があります。具体的な契約設計は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、物理的に常駐していなくても、発注者のチャット、チケット、会議、勤怠管理の中で個々のエンジニアを直接指揮命令していればリスクがあるとされています。ただし、リモート環境の設計や責任者経由の運用で評価は変わる可能性があります。具体的には、ログや運用ルールを整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、一人常駐SESが直ちに偽装請負と評価されるわけではないとされています。ただし、受託会社側の別責任者を通さず、本人が直接作業指示、勤怠、緊急対応を受けている場合はリスクが高まる可能性があります。具体的な体制設計は、案件資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、安全確保、情報漏えい防止、システム保全、事故防止など緊急性がある場合、必要最小限の連絡や指示が行われることはあり得るとされています。ただし、緊急性、必要性、範囲を記録しないまま恒常的な直接指揮命令になると評価が変わる可能性があります。具体的な対応は、記録を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、実態として発注者が個々の労働者に指揮命令する必要がある業務では、適法な労働者派遣への切替えを検討する場面があるとされています。一方、業務委託として独立性を回復できる場合もあり、どちらが適切かは業務実態と事業上の必要性で変わります。具体的には、契約と現場証跡を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、最重要ポイントは、発注者が人を直接使うのではなく、受託会社に業務を委託し、受託会社が自社の責任で人を管理する構造を契約と現場の両方で徹底することとされています。ただし、具体的な見通しは契約内容、指示系統、証跡、再委託構造などで変わります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
---
現場で迷いやすい行動を、発注者側と受託会社側に分けて確認します。
---
棚卸しから監査改善まで、段階的に体制を整える順番を示します。
まず、自社の常駐型SES案件を棚卸しします。案件名、発注者、受託会社、再委託先、業務内容、契約類型、人数、期間、常駐場所、ツール、責任者、派遣許可の有無、契約書の有無、SOWの有無を一覧化します。
次の時系列は、常駐型SESのリスク対策を導入する順番を示しています。最初から完璧な規程を作るより、案件棚卸しから高リスク案件の是正へ進むことが重要です。各段階で残すべき記録と改善対象を読み取ってください。
案件名、商流、契約類型、人数、期間、責任者、SOW有無を一覧化します。
直接指示、一人常駐、長期固定、勤怠承認、責任者不在などで高・中・低に分けます。
直接指揮命令禁止、責任者、変更管理、セキュリティ、再委託の条項を整えます。
チャット文例、チケット運用、会議アジェンダ、緊急連絡、勤怠連絡を整備します。
議事録、報告書、責任者承認、変更管理、緊急対応記録を保存します。
チャット、チケット、勤怠、会議録をサンプル確認し、契約と実態のずれを是正します。
次に、案件を高・中・低リスクに分類します。高リスクの例は、個人への直接指示、一人常駐、長期固定、要員面談、勤怠承認、受託会社責任者不在、多重再委託、SOW不備、発注者組織への組込みがある案件です。
高リスク案件から、契約書、SOW、発注書、変更管理、責任者条項、直接指揮命令禁止条項、セキュリティ条項、再委託条項を改訂します。
チャット文例、チケット運用、会議アジェンダ、議事録様式、緊急連絡フロー、勤怠連絡フロー、要員確認手続を導入します。現場PM、プロダクトオーナー、スクラムマスター、情シス担当、購買担当に教育します。
契約、SOW、議事録、チケット、報告書、責任者承認、変更管理、緊急対応記録を保存します。証跡は、後から「適正に運用していた」と説明するための重要な防御資料です。
内部監査またはコンプライアンス部門が、定期的にサンプル案件を監査します。チャット、チケット、勤怠、会議録を確認し、契約と実態の乖離を是正します。
---
契約、SOW、責任者、会議、チャット、チケット、勤怠、証跡を一貫させます。
常駐型SESで偽装請負と言われないための実務は、契約書の文言だけで完結しません。最も重要なのは、発注者が受託会社のエンジニアを自社従業員のように直接使わないことです。発注者は、業務目的、仕様、成果、品質、期限、セキュリティ要件を受託会社に伝えることができます。しかし、誰が、いつ、どの順序で、どの方法で作業するか、勤怠・休暇・残業をどうするか、誰を配置するかは、受託会社が自社の責任で管理しなければなりません。
次の強調表示は、常駐型SESの偽装請負対策で最後に確認すべき問いを示しています。契約文言だけではなく、日々の記録で説明できるかが重要です。発注者が人を直接使っているのか、受託会社に業務を委託しているのかを読み取ってください。
発注者は業務目的、仕様、成果、品質、期限、セキュリティ要件を受託会社へ伝え、受託会社が自社の責任で人を管理します。この構造をチャット、チケット、会議録、報告書、責任者承認、勤怠運用、監査記録で示せる状態が重要です。
常駐型SESは、IT実務上、発注者と受託者が密接に協働するため、リスクをゼロにすることは容易ではありません。しかし、37号告示、厚生労働省ガイド、疑義応答集、システム開発に関する行政整理を踏まえ、契約、SOW、責任者、会議、チャット、チケット、勤怠、セキュリティ、証跡を一貫して設計すれば、リスクを大きく低減できます。
最終的には、次の問いに明確に答えられるかが実務上の分水嶺です。
この問いに対して、契約書だけでなく、日々のチャット、チケット、会議録、報告書、責任者承認、勤怠運用、監査記録で答えられる状態を作ること。それが、「常駐型SESで偽装請負と言われないための実務」の核心です。
---
公的資料、法令、行政解釈を中心に整理しています。