IT・ベンチャーの企業法務

IT業界の派遣と請負の区別にかかわる法律と裁判の事例について

2019.11.08

2025.12.19

ITプロジェクトを推進する上で、外部の技術リソースを活用する際の「労働者派遣」と「請負」の法的違いを正しく理解することは、企業のコンプライアンスとリスク管理の観点から極めて重要です。この二つの契約形態は、プロジェクトにおける指揮命令権の帰属、責任の範囲、そして企業が負う法令上の義務が根本的に異なります。

特にIT業界では、契約書上の「請負」と実際の業務運営が乖離し、実態が派遣となってしまう「偽装請負（ぎそううけおい）」が深刻な問題となっています。この偽装請負は、労働者派遣法などに違反する行為であり、発注側・受注側双方に行政処分や罰則、さらには社会的な信用失墜といった重大なリスクをもたらします。

本記事では、実務上区別が曖昧になりがちな派遣と請負の区別を整理するとともに、そうした契約周りの問題が、プロジェクト全体の円滑な進行にどのような影響を及ぼしうるものであるかを解説します。

この記事の目次

派遣と請負の違いとは

ITプロジェクトの現場では、発注元企業からベンダー（受注企業）へ業務が委託され、そのベンダーが自己の責任でプロジェクトを遂行するために、現場へ技術者やチームを送り込む、という形態が一般的です。この際に結ばれるのが、民法上の請負契約です。

これは、発注元企業がベンダーに対し、仕事の完成（例：システム開発）という「結果」に対して報酬を支払うという契約です。したがって、ベンダーが現場に技術者を送り込む場合でも、その技術者への業務の指示や管理は、発注元ではなく、あくまで技術者を雇用しているベンダー自身が行う義務があります。

なお、このベンダーがさらに別の協力会社へ業務の一部を依頼（再委託）し、その協力会社の技術者が現場に入る場合でも、取引の根底にあるのは同様の請負契約の原則です。請負契約とは何か、その特徴や法的義務については、以下の記事で詳しく解説しています。

システム開発で、請負契約を結ぶ際の注意点とは

請負契約では、「仕事の完成」が債務の履行条件となります。請負契約に基づいて現場に人を常駐させる場合、それはあくまで企業間の商取引にとどまるため、技術者を受け入れる発注者／現場側には労働法を遵守する義務等は発生しません。

しかし、そのかわり当該技術者に対して直接的に指揮命令を及ぼすことも法律上認められません。このような点に配慮しない場合、たとえ実際は請負契約が締結されていたとしても、違法な労働者供給事業、すなわち「偽装請負」であるとの扱いを受ける危険性があります。

IT業界における偽装請負の判断基準と対処法とは

IT業界における偽装請負の摘発事例

以下に取り上げるのは、派遣と請負の区別が曖昧になったことに端を発するプロジェクトの炎上事案です。

派遣と請負では債務の履行要件が大きく変わる

派遣と請負は、開発現場に人員が送り込まれる点まではよく似ています。しかし先述の通り、請負であれば「仕事の完成」が認められない限りは原則債務の履行が認められません。

以下に引用する判決文の事案でも、最終的にプロジェクトが頓挫した事案につき、報酬の請求が認められるか否かが争点となりました。請負であれば「仕事の完成」が要件として課されるところ、派遣であれば実働時間等の実績のみで労働対価を正当化することが可能になります。

受注側／ベンダー（原告）は、派遣契約が事後で締結されており、あくまで派遣の形態で人員が送り込まれていた旨を主張し、「仕事の完成」までは義務として課されていない旨を主張しました。しかし裁判所はその主張を否定しました（下線部、太字は筆者が追記したものである。）。

原告は、原告による本件システムのプログラムの開発不能が確定した後、昭和六一年四月一日原、被告間において、開発費用については、二期分及び合宿実施手当合計七一〇万六〇〇〇円を五五〇万円に減額して被告が原告に速やかに支払うこと、同年四月一日以降原告の業務を被告が引き継ぐこと及び文字情報システムの被告による開発につては、原告から労務派遣の形式で人員を出向させて実施し、派遣人員は三人として、単価はうち二人分五五万円、うち一人分三〇万円とすることを合意したと主張し、原告代表者尋問の結果は、これに副う。
　しかしながら、被告は、そのような合意がなされたことを否定し、原告は、もともと被告から本件システムのプログラム作成を請け負い、これを完成させる義務を負っていたものであって、そのような立場にある者がその完成をせず、プログラムを引き渡すこともできなかったのに、注文者である被告が、原告に以後その作成義務を免除したり、その間に原告が要した費用まで支払ってやるような不合理なことをする筈はないと主張する。確かに、原告が、プログラムを完成する義務を負っていたのであれば、被告の主張するところももっともであるといえる。
　そこで、まず、本件システムのプログラム開発に関する契約において、原告が、その完成義務を負っていなかったのかどうかについて、検討する。
　（中略）証拠をみると、原告が、右契約において、本件プログラムの完成義務を負っていないことを認めることのできる証拠を見出すことはできないのである。（中略）そして、原告代表者もその尋問の結果においては、右契約は、一括受注であって、原告社内でプログラムを開発するものであるとし、原告が、右プログラムの完成義務を負ったことを前提として供述しており、その義務を負っていたことを否定したことは一度もないことが明らかである。書証を見ても、成立に争いのない（中略）工程表は、原告が、右プログラムを完成する義務を負っていることを前提として、その完成までのスケジュールを記載した趣旨のものであることが認められるのであるから、これによれば、逆に、原告が契約上プログラムの完成義務を負っていたと認めることができるのである。（中略）
　その他に、原告が、右プログラムの完成義務を負っていたとの認定に反する証拠はないのである。
　そうであるとすれば、被告が主張するように、完成義務を負ったプログラムの作成をしなかった者は、債務不履行の責任を負うことはあっても、請負代金の支払を要求することのできないのは当然であり、特段の事情がない限り、そのような立場の者に注文者が、その契約上の義務を無条件で免除し、更に、それまでに要した費用を支払ってやるなどという合意をする筈はない。原告代表者は、その尋問の結果において、プログラムが完成していなくとも、発注者の指示に従って作業をしていれば、期限内に一応指示された範囲内の作業は約束を守って行ったのであるから、作業をした分についてコンピュータソフトウェア代金を請求できると考える旨供述するが、請負契約に関する一般の常識に反する発言であり、ソフトウェアの開発を行う原告や被告の業界においては、一般の常識と異なり、請負契約であり、仕事の完成がなくとも、報酬を支払う慣行があるような事実は証人の証言に照らしてもおよそ認めることができないから、右原告代表者の尋問の結果はその独自の見解という他はなく、採用することができないのである。
東京地判平成23年 2月22日

上記裁判例から読み取れることとは

上記の裁判例において特に注目に値すべきは、

表面的・形式的な派遣契約の締結を根拠にベンダーの「仕事の完成」義務を免責するのではなく、「仕事の完成」という両当事者の具体的な約束の内容に基づき、実質的にも公平な紛争解決を見込んだ点
「仕事の完成」を債務の履行要件として課している点から、当該契約は請負契約であると判断され、その他の論点においても請負契約に関する業界内の商習慣に基づいて判断を行うべきとされた点

といった点であると考えられます。

これら2点について簡単に総括すると、表面的な契約書の表題など以上に、両当事者の実質的な意思の合致が裁判では重視されるということを端的に示すものだと考えられます。また、契約の実質がひとたび請負契約と判断された後は、その他の論点についても請負契約にまつわる業界内での商習慣を踏まえた解決をはかったものとみられます。

受注側／ベンダーの主張を退ける際に、「請負契約に関する一般の常識に反する発言」、「独自の見解」といった言い回しが登場する点は、端的にこうしたことを示すものともみられ、非常に特徴的です。

社会常識・社会通念といったものが法解釈にも反映され、法律実務に影響を与えうるという点とともに、あわせて注目すべきポイントでしょう。ちなみに、当該判決においてこれほどにも重視されることとなった「仕事の完成」という概念については、システム開発の文脈を踏まえて以下の記事で詳細に解説しています。

システム開発における請負契約の仕事の完成とは

システム開発プロジェクトの実務で請負契約がよく用いられるところ、その本質的な要素が「仕事の完成」にある点を踏まえると、これについては深く理解しておくべきでしょう。

偽装請負になりやすい4つのパターン

偽装請負は、契約書上は「請負」「準委任」「SES」といった形式を取っていても、実態として発注者が受注者の労働者を直接管理している場合に成立します。IT業界では複数企業の人材が混在するプロジェクトが多く、偽装請負が構造的に起こりやすくなっています。厚生労働省の基準を踏まえると、偽装請負に該当しやすいパターンは大きく4種類に整理できます。

まず典型的なのが、発注者が受注者の労働者に直接指示を出す「代表型」です。作業内容・手順・優先順位・残業命令・勤怠管理などを発注者が行うと、その時点で請負の枠を超え、労働者派遣と同視される可能性が極めて高いです。

次に、受注者が現場責任者を置いているにもかかわらず、実際にはその責任者が発注者の指示をそのまま横流しするだけの「形式だけ責任者型」があります。外形上は請負の体裁を保っていても、実質的には発注者が管理している状態であり、偽装請負と判断されやすいパターンです。

3つ目に、複数企業のメンバーが入り混じるITプロジェクトで発生しやすいのが、誰が誰に指揮命令しているのか曖昧になる「使用者不明型」です。多重下請けが絡むプロジェクトでは特に境界がぼやけやすく、裁判でも「実態として発注者が管理していた」と判断されるリスクがあります。

最後に、個人事業主との業務委託にもかかわらず、実態として従業員と同様に扱ってしまう「一人請負型」です。始業・終業時刻や作業場所の指定、社内ルールの遵守強制、発注者からの備品貸与など、裁量のない働き方をさせると「偽装一人親方」と認定される可能性が高まります。

偽装請負の罰則

契約上は請負という形をとっていたとしても、その実態が偽装請負であると判断されると、関係する事業者は労働者派遣法・職業安定法・労働基準法に基づく罰則を受ける可能性があります。形式上は請負や準委任の形であっても、実態として発注者が受注者の労働者を直接管理していたと認定されれば、企業は重大な法的リスクを負います。

偽装請負が無許可の労働者派遣に該当する場合、労働者派遣法違反となり、派遣元の事業者には1年以下の拘禁刑または100万円以下の罰金が科される可能性があります。法人の代表者や担当者が行為者であれば、法人自体にも同様に100万円以下の罰金が科されます。

また、偽装請負が「労働者供給」に該当するケースでは、職業安定法違反となり、供給元・供給先の双方に対して1年以下の拘禁刑または100万円以下の罰金が科される可能性があります。こちらも、担当者が行為者であれば法人への罰金が併科されます。

労働基準法が禁じる「中間搾取」に該当する場合は、供給元の事業主に対して1年以下の拘禁刑または50万円以下の罰金が科される可能性があります。行為者が従業者であっても、使用者側が必要な防止措置を講じていなければ使用者にも罰金が及ぶ点には注意が必要です。

これらの罰則とは別に、行政指導や改善命令の対象になるリスクもあります。厚生労働省や労働局による指導・助言を受けた場合、その対応には相応の工数がかかりますし、悪質と判断されれば企業名の公表に至る可能性もあります。企業名の公表は、社会的信用の失墜を招くだけでなく、取引停止など事業継続に深刻な影響を及ぼす恐れがあります。