偽装請負にならないための準委任契約の正しい働き方 ── 契約書の名前ではなく「指揮命令」で決まる

「うちは準委任契約だから偽装請負にはならない」

システム開発の現場で時々耳にする言い方ですが、これは誤解です。偽装請負かどうかは、契約書のタイトルが請負か準委任か業務委託かではなく、現場の実態、つまり誰がエンジニアに指揮命令しているかで判断されます。準委任契約を結んでいても、発注者が受託側のエンジニアに直接、作業のやり方や労働時間の指示をしていれば、それは偽装請負です。

この記事では、請負・準委任・労働者派遣の違いから、偽装請負の判断基準（37号告示）、開発現場でありがちなOK・NGの境界線、アジャイル開発での考え方、そして発注側・受託側それぞれが整えるべき実務までを、厚生労働省の公表資料に基づいて整理します。

先に用語を一つだけ。本文で繰り返し出てくる37号告示とは、「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）の通称です。告示の番号がそのまま呼び名になっています。偽装請負かどうかを行政が判断するときの物差しがこれで、中身は4章で詳しく見ます。

なお、この記事は制度と実務の解説であり、法的助言ではありません。個別の契約や現場が偽装請負に該当するかどうかの判断は、都道府県労働局（需給調整事業課）や弁護士に確認してください。

1．まず結論

企業間でエンジニアの労働力・役務をやり取りする形は、大きく次の3つです。違いの中心は「発注者（就業先）がエンジニアに指揮命令できるか」にあります。

請負と準委任は、どちらも発注者と受託側の労働者の間に指揮命令関係を生じさせない契約です。指揮命令をするのは、あくまでエンジニアの雇用主である受託会社です。発注者が直接指揮命令したいのであれば、選ぶべき契約は請負でも準委任でもなく、労働者派遣です。

そして、形式上は請負や準委任の契約を結びながら、実態として発注者が受託側の労働者に直接具体的な指揮命令をして働かせている状態が、いわゆる偽装請負です。厚生労働省の疑義応答集（第3集）でも、準委任契約であっても実態として指揮命令関係があれば、契約の形式を問わず労働者派遣事業に該当し、労働者派遣法の適用を受けると明確に述べられています。

つまり、「準委任だから大丈夫」も「請負だから大丈夫」もなく、大丈夫かどうかは契約書ではなく現場の毎日の働き方が決める、というのがこの記事全体の結論です。

この記事の知識マップ

請負・準委任・労働者派遣は、発注者が受託側の労働者に直接指揮命令できるかで区分され、請負と準委任はこれを禁じる一方、労働者派遣だけが合法的に指揮命令を認める仕組みである。契約書が請負や準委任であっても、発注者が業務の指示・労働時間の管理・配置の決定に直接踏み込めば偽装請負となり、その判定基準は37号告示が定める労務管理上の独立性と事業経営上の独立性のすべてを満たすかどうかにある。管理責任者を実質的に機能させて依頼の窓口を一本化し、契約に業務内容を明記して人数×単価だけの精算を避けることが実務上の対策になり、常駐や密な協働そのものは問題にならない一方、偽装請負は行政指導や刑事罰に加え、労働契約申込みみなし制度により発注者がエンジニアと労働契約を結んだとみなされるリスクを伴う。

flowchart LR
    accTitle: 偽装請負を避ける準委任契約の知識マップ
    accDescr: 請負・準委任・労働者派遣という3つの契約類型が指揮命令の所在で区分されること、37号告示の2つの独立性が偽装請負の判定基準になること、管理責任者や契約の書き方といった実務対策と労働契約申込みみなし制度のリスクの関係を示す図
    quasi_mandate_contract["準委任契約"]
    disguised_contracting["偽装請負"]
    ukeoi_contract["請負契約"]
    direct_instruction["発注者による直接指揮命令"]
    worker_dispatch["労働者派遣"]
    notification_37["37号告示"]
    labor_management_independence["労務管理上の独立性"]
    business_management_independence["事業経営上の独立性"]
    management_responsible_person["管理責任者"]
    onsite_secondment["客先常駐"]
    per_head_pricing_contract["人数×単価の契約"]
    deemed_labor_contract_offer["労働契約申込みみなし制度"]
    ses["SES(システムエンジニアリングサービス)"]
    agile_development["アジャイル開発"]
    ukeoi_contract -.->|"防止する"| direct_instruction
    quasi_mandate_contract -.->|"防止する"| direct_instruction
    worker_dispatch -->|"実装を担う"| direct_instruction
    direct_instruction -.->|"原因になり得る"| disguised_contracting
    notification_37 -->|"前提とする"| labor_management_independence
    notification_37 -->|"前提とする"| business_management_independence
    labor_management_independence -.->|"防止する"| disguised_contracting
    business_management_independence -.->|"防止する"| disguised_contracting
    management_responsible_person -.->|"軽減する"| disguised_contracting
    onsite_secondment -.->|"原因になり得る"| disguised_contracting
    per_head_pricing_contract -.->|"原因になり得る"| disguised_contracting
    disguised_contracting -.->|"原因になり得る"| deemed_labor_contract_offer
    ses -.->|"利用する"| quasi_mandate_contract
    agile_development -.->|"前提とする"| labor_management_independence
    quasi_mandate_contract -->|"用いるのは非推奨"| direct_instruction
    worker_dispatch -->|"推奨される対応"| direct_instruction
    labor_management_independence -->|"で構成できる"| management_responsible_person

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全17件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2．請負・準委任・派遣 ── 3つの契約を正しく区別する

2.1．請負 ── 仕事の完成に責任を負う

請負（民法632条）は、仕事の完成を約束し、その結果に対して報酬を受け取る契約です。システム開発なら「この要件のシステムを完成させて納品する」形が典型で、受託側は完成義務を負い、納品物が契約内容に適合しない場合は契約不適合責任を負います。

2.2．準委任 ── 業務の処理を善管注意義務で行う

準委任（民法656条）は、法律行為でない事務の処理を委託する契約です。システム開発の文脈では、要件定義支援、技術調査、設計レビュー、保守運用、開発支援など、「完成」よりも「専門家として業務を行うこと」自体を依頼する場面で使われます。受託側は完成義務ではなく、善良な管理者の注意をもって業務を処理する義務（善管注意義務、民法644条）を負います。

2020年4月施行の改正民法では、業務の遂行時間ではなく成果に対して報酬を支払う、いわゆる成果完成型の報酬の定め（民法648条の2）も明文化されており、準委任は「時間精算しかできない契約」ではなくなっています。

なお、IT業界でよく使われるSES（システムエンジニアリングサービス）は法律上の用語ではありません。エンジニアの技術力を役務として提供する取引の呼び名で、契約の形としては準委任が使われることが多い、という関係です。SESという名前を使っているかどうかも、適法性の判断には関係ありません。

2.3．労働者派遣 ── 指揮命令を「合法的に」渡す唯一の形

労働者派遣は、派遣元が雇用する労働者を、派遣先の指揮命令を受けて派遣先のために働かせるものです（労働者派遣法2条）。発注者側が業務の指示、労働時間の管理、タスクの割り振りを直接行いたいなら、この形しかありません。その代わり、派遣元には厚生労働大臣の許可が必要で、派遣先にも期間制限や派遣先責任者の選任など多くの義務がかかります。

この3つを並べると、偽装請負の構図がはっきりします。派遣の働かせ方（直接の指揮命令）を、派遣のコストと義務を負わずに、請負・準委任の契約書で手に入れようとするのが偽装請負です。

3．偽装請負の何が問題なのか ── 発注側・受託側双方のリスク

「現場がうまく回っているなら、細かいことを言わなくても」と思うかもしれません。しかし偽装請負が規制されるのには理由があります。指揮命令する者（発注者）と雇用責任を負う者（受託会社）が分離すると、労働時間の管理、安全衛生、労災の責任の所在が曖昧になり、労働者が保護の空白に置かれるからです。労働者派遣法は、この分離を許可制と派遣先・派遣元の義務のセットで管理しています。偽装請負はその管理の外で同じ分離を作る行為です。

具体的なリスクは次のとおりです。

行政指導・是正。偽装請負は労働者派遣法違反であり、労働局による指導・是正の対象です。厚生労働省は労働者派遣・請負を適正に行うためのガイドを公表し、区分基準の周知を進めています。

刑事罰の可能性。実態が労働者派遣なら、送り出す側は無許可の労働者派遣事業として労働者派遣法の罰則の対象になり得ます。また、構図によっては職業安定法44条が禁止する労働者供給事業に該当し、この場合は供給した側だけでなく供給を受けた側（発注者）も罰則（1年以下の拘禁刑又は100万円以下の罰金、同法64条）の対象になり得ます。

労働契約申込みみなし制度。発注側にとって最も直接的なリスクです。厚生労働省のリーフレットのとおり、労働者派遣法40条の6が定める制度で、要点を分解すると次のようになります。

• 対象：違法派遣の5類型（禁止業務への従事、無許可事業主からの受入れ、事業所単位の期間制限違反、個人単位の期間制限違反、そしていわゆる偽装請負等）
• 偽装請負等に固有の要件：労働者派遣法等の適用を免れる目的で契約を締結していたこと
• 効果：違法派遣が行われた時点で、受け入れていた側がその労働者に対し、現在と同じ労働条件で労働契約を申し込んだものとみなされる
• 成立まで：労働者が1年以内に承諾すれば、発注者との間に労働契約が成立する
• 例外：受け入れた側が違法派遣に該当することを知らず、かつ知らなかったことに過失がなかったとき（善意無過失）は適用されない

つまり、「協力会社のエンジニアだと思っていた人が、ある日自社の従業員になる」ことが法律上起こり得るわけです。しかも承諾までの猶予が1年あるため、現場の体制を是正した後に申込みを承諾される、という順序もあり得ます。

取引と信用への影響。是正の過程で契約の組み直しや体制変更が必要になり、プロジェクトは確実に混乱します。発注側・受託側のどちらにとっても、偽装請負は「バレなければ得」なものではなく、発覚した時点で双方が痛む構造になっています。

4．判断基準は37号告示 ── 2つの「独立性」をすべて満たす

では、適正な請負・準委任と労働者派遣は、具体的に何で区分されるのか。基準は「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）、いわゆる37号告示です。

37号告示は、受託側の事業主が次のすべてを満たす場合を除き、労働者派遣事業を行う事業主であると定めています。大きくは2つの独立性です。

1つ目は労務管理上の独立性 ── 自己の雇用する労働者の労働力を、自ら直接利用していること。

2つ目は事業経営上の独立性 ── 請け負った業務を、自己の業務として相手方から独立して処理していること。

ソフトウェア開発の場合、最後の項目は「自己の有する専門的な技術・経験に基づいて業務を処理すること」で満たすのが通常です。つまり、開発会社にとっての実務上の焦点は、もっぱら労務管理上の独立性、とりわけ「業務の指示」「労働時間」「配置」を誰が握っているかに集まります。

さらに37号告示3条は、形式上すべての要件を満たしていても、法違反を免れるため故意に偽装したもので、真の目的が労働者派遣であるときは労働者派遣事業に当たるとしています。書面を整えるだけの「対策」は通用しない建て付けです。

5．開発現場でありがちなOK・NGの境界線

37号告示だけでは現場の判断に迷うため、厚生労働省は疑義応答集（第1集〜第3集）でQ&Aを公表しています。そこから、システム開発の現場に当てはめた境界線を整理します。

（各行の根拠は疑義応答集第1集の問1・2・5・7・9・10・11、および第3集のQ4・Q7です。）

表を貫く原則は一つで、「会社対会社」のやり取りはよいが、「発注者対エンジニア個人」の指揮命令はだめ、ということです。

もう2点、開発の現場で特に効いてくる論点を挙げます。

指示は文書やツール経由でも指示。疑義応答集第1集の問7は、発注者が作業の内容・順序・方法を文書で詳細に示し、そのとおりに作業させる場合も偽装請負と判断されるとしています。口頭で言わずチケットやチャットに書けばよい、という話ではありません。誰が書いたかと、それが指揮命令として機能しているかが見られます。

「人数×単価」だけの契約は危ない。第1集の問8は、製品や作業の完成ではなく、投入した労働力（人数）で受発注し、労働力の単価で精算している場合は、単なる労働力の提供であり偽装請負と判断されるとしています。準委任で時間や工数に基づいて精算すること自体は否定されませんが、契約書に業務の内容がなく「エンジニア○名、単価○円」しか書いていないような契約は、労働力の提供と評価されやすい形です。何の業務を委託するのかを契約で特定できていることが前提になります。

5.1．線を越えていく現場 ── 説明のための架空シナリオ

以下は実在の事案ではなく、ここまでに挙げた基準を組み合わせて作った説明用のシナリオです。ただし、出てくる要素はどれも上の表のNG側や、この後の実務の項目に対応しています。

製造業のA社が、業務システムの改修をB社に準委任で委託しました。B社のエンジニア1名がA社に常駐しています。契約書には「業務システム改修支援 一式」とだけ書かれ、請求は「1名×月額単価」。B社の管理責任者は、その常駐エンジニア本人が兼ねています。ここまでは、多くの現場にありそうな出発点です。

• 4月：A社の担当者が、朝会でエンジニアに「今日はこの画面を先にやってください」と作業の順序を直接指示するようになります。急ぎの案件なので、B社に伝えて折り返してもらう時間が惜しいからです。
• 6月：月末の締めが近いという理由で、A社の担当者が「今週は残業でお願いします」と本人に直接伝えます。
• 9月：A社の別部署から「ついでにExcelのマクロも直してほしい」という依頼が本人に届きます。契約書に業務の内容が特定されていないため、現場には断る根拠がありません。
• 12月：エンジニアが体調を崩し、労働時間を管理していたのは誰だったのかが問題になります。

この時点で、4章の労務管理上の独立性のうち「業務遂行の管理」と「労働時間の管理」は成り立っていません。加えて、契約に業務の内容がなく人数×単価で精算していること（第1集の問8）、1人常駐で管理責任者を本人が兼ねていること（第1集の問4）が重なっています。是正の局面では、契約の巻き直し、体制の作り直し、常駐の一時引き揚げといった対応が必要になり、プロジェクトは止まります。

なお、労働契約申込みみなし制度まで進むかどうかは、これに加えて「労働者派遣法等の適用を免れる目的」があったかどうかの判断が入ります。ただし、その手前の行政指導や契約の組み直しは、目的の有無にかかわらず起こり得ます。

怖いのは、この4つのステップのどれも、当事者にとっては「ちょっとした融通」でしかないことです。誰かが悪意で偽装したのではなく、忙しい現場で最短経路を選び続けた結果として、契約の線と指示の線がずれていきます。だからこそ、次章で述べる「依頼のルートを最初に決めて全員に共有する」が、いちばん効く対策になります。

6．準委任で正しく働くための実務 ── 体制・窓口・報告

境界線が分かったところで、それを毎日の運用に落とし込むための実務を整理します。ポイントは、指揮命令の経路を契約と体制で固定することです。

flowchart TB
    subgraph OK["適正な準委任"]
        direction TB
        A1["発注者"] -->|"依頼・要求・成果物への注文"| B1["受託会社"]
        B1 --> C1["管理責任者"]
        C1 -->|"指揮命令"| D1["エンジニア"]
    end

    subgraph NG["偽装請負"]
        direction TB
        A2["発注者"] -->|"契約"| B2["受託会社"]
        A2 -->|"直接の指示<br/>タスクの割り付け<br/>作業手順の指示<br/>残業や休日出勤の指示"| D2["エンジニア"]
    end

「適正な準委任」のほうは、発注者からの依頼がいったん受託会社で受け止められ、管理責任者を経てエンジニアに届きます。矢印が一本の線でつながっているのがポイントです。「偽装請負」のほうは、契約の線は会社間にあるのに、実際の指示は発注者からエンジニアへ直接飛んでいます。契約の線と指示の線がずれていること、これが偽装請負の図です。

6.1．受託側が整えること

• 契約書・注文書で業務内容を特定する。「システム開発支援一式」ではなく、対象システム、業務の範囲、体制、期間、報告の方法まで書きます。成果完成型にするか履行割合型（時間・工数ベース）にするかもここで決めます。
• 管理責任者（現場責任者）を置き、権限を持たせる。発注者との窓口、エンジニアへの指示、進捗と品質の管理を受託側で担う人です。疑義応答集第1集の問4のとおり、管理責任者が作業を兼任すること自体は問題ありませんが、実態として管理ができていなければ意味がなく、常駐メンバーが1人でその人が管理責任者を兼ねる形は、発注者からの注文がそのまま個人への指揮命令になるため偽装請負と判断されます。1人常駐の案件では、社内のマネージャーが管理責任者として機能する設計（依頼の受け口を会社に置く、定期的な報告・レビューを社内で行う）が必要です。
• 勤怠は自社で管理する。始業・終業、休暇、残業の判断は雇用主である受託会社が行います。発注者のビルの入退室管理に従うことや、発注者が安全確認のため在席を把握することは「単なる把握」の範囲ですが、残業してほしい・明日は早く来てほしいという話は、必ず自社経由で受けます。
• 業務報告を残す。何を依頼され、何を行い、どう完了したかを、月次や週次の報告書・完了報告として残します。これは偽装請負対策であると同時に、善管注意義務を果たしたことの記録でもあります。

6.2．発注側が整えること

• 依頼は窓口（管理責任者）へ。新しい作業依頼、優先度の変更、やり直しの要求は、エンジニア個人ではなく受託会社の窓口に出します。成果物への注文・クレームを会社宛てに行うのは、疑義応答集第1集の問2のとおり正当な発注行為です。
• 個人を指名しない。「Aさんを入れてほしい」「Bさんは外してほしい」は、受託側の配置決定への介入であり、適正な請負・準委任とは認められません（第3集Q7）。技術力の確認は、個人を特定しないスキルシート等で行います。
• 会議の位置づけを決めておく。定例会議は、要件・仕様の伝達、進捗の共有、課題の協議の場と位置づけ、個人へのタスク割り付けの場にしないことです。会議やチャットに双方の全員が参加すること自体は問題ありません（第3集Q6）が、そこで発注者からエンジニアへの直接の指示が流れ始めると偽装請負になります。
• 「把握」と「管理」を区別する。進捗や品質を把握し、契約どおりでなければ会社宛てに是正を求めるのは発注者の当然の権利です。一方、その手段としてエンジニアの時間の使い方や作業手順に手を入れ始めたら、それは管理＝指揮命令です。

6.3．現場のメンバーに共有しておくこと

偽装請負は、契約担当者ではなく現場の善意から始まることが多いものです。発注者側の担当者が「ちょっとこれもお願い」と隣の席のエンジニアに頼み、エンジニアも悪気なく受ける ── こうした頼み事は、雑談の延長のように見えても「業務に関係のない日常的な会話」ではなく業務の依頼であり、本来は窓口を通すべきやり取りです。積み重なれば、発注者からの指揮命令の実態そのものになります。発注側・受託側双方の現場メンバーに、依頼のルート（誰に頼むか、誰から受けるか）を最初に共有しておくことが、結局いちばん効きます。

7．アジャイル開発と偽装請負 ── 「対等な協働」なら問題ない

「発注者と受託者が密に会話したら偽装請負になるなら、アジャイル開発は無理では？」という疑問には、厚生労働省が疑義応答集第3集（2021年公表）で正面から答えています。2026年5月にはQ8が追加され、この考え方がアジャイル型開発以外のシステム開発にも当てはまることが明示されました。

要点は次のとおりです。

• 密な連携・情報共有・技術的な助言・提案はOK。発注者側と受託側の開発関係者が一つのチームとして随時情報を共有し、対等な関係の下で協働し、受託側の開発担当者が自律的に判断して開発を進めていると認められるなら、偽装請負ではありません（Q2・Q5）。
• プロダクトオーナーによるバックログの説明もOK。発注者側の開発責任者が、受託側の開発担当者に直接、プロダクトバックログの内容を詳しく説明し、開発に必要な情報を提供すること自体は問題ありません（Q4）。
• 境界はやはり指揮命令。その説明や議論が、実態として業務の遂行方法や労働時間に関する指示になっているなら偽装請負です（Q4・Q5）。進捗遅れの際に仕事の割り付け・順序・緩急の調整を指示する必要が生じたら、それは受託側の管理責任者が行うべきことで、発注者側が直接行えば、管理責任者を選任していても偽装請負と判断されます（Q3）。
• 事前の設計が重要。双方の役割・権限、チーム内での業務の進め方をあらかじめ明確にして合意しておくこと、アジャイル開発は開発担当者が自律的に進めるものだという認識を関係者の研修等で共有しておくことが推奨されています（Q2）。

つまり、アジャイルだから偽装請負になりやすいのではなく、自律的なチームという建前で実際は発注者がメンバーを動かしているときに偽装請負になります。スクラムの「自己組織化されたチーム」を実態として運用できているなら、準委任のアジャイル開発は制度上も想定された働き方です。

8．請負・準委任・派遣、どれを選ぶべきか

最後に、そもそもどの契約を選ぶのが適切かを整理します。

大事なのは、「指揮命令したいのにコストや義務を避けたいから準委任にする」という選び方をしないことです。それは契約選択ではなく、偽装請負の入口です。発注者として直接コントロールしたい事情が本当にあるなら、派遣契約に切り替えるか、受託側の体制（管理責任者経由の運用）で満たせないかを検討するのが正しい順番です。

まとめ

• 偽装請負かどうかは契約書の名前ではなく、発注者が受託側の労働者に直接指揮命令しているかという実態で判断されます。準委任契約でも偽装請負になり得ます
• 請負・準委任は発注者とエンジニアの間に指揮命令関係を生じさせない契約であり、直接指揮命令できるのは労働者派遣だけです
• 判断基準は37号告示です。業務遂行・労働時間・配置の管理を受託側が自ら行うこと（労務管理上の独立性）と、資金・責任・専門技術による独立処理（事業経営上の独立性）のすべてを満たす必要があります
• 日常会話、仕様の説明、会社宛ての注文、対等な技術的議論は問題ありません。個人へのタスク割り付け、作業手順の直接指示、残業の直接指示、メンバーの指名・交代要求は偽装請負のサインです
• 常駐や混在それ自体は偽装請負ではありません。1人常駐＋管理責任者兼任のような、注文が個人への指揮命令に直結する体制が危険です
• アジャイル開発は、対等な協働と受託側メンバーの自律的な判断が実態として成り立っていれば偽装請負ではありません。この考え方はアジャイル以外の開発にも当てはまります
• 偽装請負のリスクは行政指導や刑事罰にとどまらず、労働契約申込みみなし制度により、発注者がエンジニアに労働契約を申し込んだとみなされる可能性があります
• 迷ったら、都道府県労働局に相談できます。労働契約申込みみなし制度への該当性については労働局が助言を行う仕組み（労働者派遣法40条の8）もあります

受託開発・技術支援の進め方をご検討の方へ

外部のエンジニアに開発を依頼したい、あるいは今の常駐・支援の形がこのままでよいのか気になる場合、最初に整理すべきは「何を依頼したいのか（完成物か、業務か、労働力か）」と「誰が指揮命令するのか」の2点です。ここが決まれば、請負・準委任・派遣のどれで組むべきか、体制と窓口をどう設計すべきかは自然に決まります。

合同会社小村ソフトは、Windowsアプリケーションを中心とした受託開発と技術支援を、請負・準委任いずれの形でもお受けしています。業務範囲と成果物を明確にした契約、窓口と報告を通じた進め方を基本としており、「どういう切り分けで依頼すればよいか分からない」段階からのご相談も可能です。

準委任は、正しく運用すれば、要件が固まりきらない開発や継続的な改善にとても適した契約形態です。契約の形と現場の働き方を一致させて、発注側・受託側の双方が安心して協働できる体制を作るところから始めてみてください。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

SESと準委任契約は同じものですか？

SES（システムエンジニアリングサービス）は法律上の用語ではなく、エンジニアの技術力を役務として提供する取引を指す業界の実務用語です。契約の形としては準委任契約が使われることが多いですが、SESと呼んでいるか準委任と呼んでいるかは適法性の判断に関係ありません。判断されるのは、発注者が受託側のエンジニアに直接指揮命令をしていないかという実態です。

準委任契約で発注者のオフィスに常駐して働くのは問題ですか？

常駐そのものは問題ではありません。厚生労働省の疑義応答集でも、発注者の労働者と受託側の労働者が同じ場所で混在して働いていることだけをもって偽装請負と判断されるものではないとされています。問題になるのは場所ではなく指揮命令です。常駐していても、業務の指示・労働時間の管理・配置の決定を受託側の会社が自ら行っていれば適正ですし、逆にリモートでも発注者が直接指揮命令すれば偽装請負になり得ます。

発注者が受託側のエンジニアに直接質問や依頼をしてもよいですか？

日常的な会話、仕様や要件の説明、情報提供、対等な立場での技術的な議論・助言・提案は、それだけで偽装請負になるものではありません。一方、作業のやり方や順序の指示、個人へのタスクの割り付け、残業・休日出勤の指示を発注者が受託側のエンジニアに直接行うと、指揮命令とみなされ偽装請負と判断されます。新しい依頼や作業指示は、受託側の管理責任者（窓口）を通す運用にするのが原則です。

偽装請負と判断されると、どうなりますか？

労働者派遣法違反として労働局の指導・是正の対象になり、無許可の労働者派遣や労働者供給に該当すれば刑事罰の対象にもなり得ます。さらに労働契約申込みみなし制度により、派遣法等の適用を免れる目的で偽装請負を行っていた場合、発注者がそのエンジニアに労働契約を申し込んだものとみなされ、エンジニアが1年以内に承諾すれば発注者との労働契約が成立します。発注側・受託側の双方にとって重大なリスクです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。