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

IT系のプロジェクトでは、多数の会社の人材がひとつのプロジェクトに駆り出され、参画する場合が多くみられます。そうした場合、プロジェクトに参画する技術者の職場は、当該技術者が所属する企業の所在地とは分離する場合も多くなります。いわゆる客先常駐・SESなどがそれにあたります。現場で働く技術者の雇用形態・契約形態が曖昧になっていくことは、後に労働者の権利をめぐる紛争に発展するリスクがある点はもちろんのこと、プロジェクトそのものの炎上リスクとなる場合があります。本記事では、実務上区別が曖昧になりがちな派遣と請負の区別を整理するとともに、そうした契約周りの問題が、プロジェクト全体の円滑な進行にどのような影響を及ぼしうるものであるかを解説します。

派遣と請負の違いとは

仕事を受注するベンダー（や、その再委託先となる業者）と、業務を発注する委託元の企業が異なる場合、そこでは請負契約に基づいて人材が現場に送られるということがよく行われます。つまり、受注側／ベンダーが間に入り、現場に技術者を送り込むということです。なお、請負契約というものがどのようなものであるかに関しては、以下の記事にて詳細に解説を行なっています。

上の記事では、「仕事の完成」といった点が債務の履行条件となること点が請負契約の本質的な特徴である点を解説しています。また、検収の合格条件を契約締結時に明確にしておくことがトラブルの発生を防止するために重要であることを説明しています。なお、請負契約に基づいて現場に人を常駐させる場合、それはあくまで企業ー企業の間の商取引にとどまるため、技術者を受け入れる発注者／現場側には労働法を遵守する義務等は発生しません。しかし、そのかわり当該技術者に対して直接的に指揮命令を及ぼすことも法律上認められません。こうした点に配慮しない場合、たとえ表面上は請負契約が締結されていたのだとしても、違法な労働者供給事業、すなわち「偽装請負」であるとの扱いを受ける危険性があります。

派遣と請負の違いが曖昧になったことから紛争に発展した事案

「請負契約」、「偽装請負」といった点についての一般論については、上記の内容に譲ることとして、以下に取り上げるのは、派遣と請負の区別が曖昧になったことに端を発するプロジェクトの炎上事案です。こうした区別が曖昧になることは、個人の労働者の権利侵害、労使間の紛争といったものに発展しうるだけでなく、プロジェクト全体の炎上リスクともなりうることは、以下を確認するとよくわかるのではないでしょうか。

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

派遣と請負は、企業が間に入って開発現場に人員が送り込まれる点まではよく似ています。しかし先述の通り、請負であれば「仕事の完成」が認められない限りは原則債務の履行が認められません。以下に引用する判決文の事案でも、最終的にプロジェクトが頓挫した事案につき、報酬の請求が認められるか否かが争点となりました。請負であれば「仕事の完成」が要件として課されるところ、派遣であれば実働時間等の実績のみで労働対価を正当化することが可能になります。

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

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

東京地判平成23年 2月22日

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

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

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

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

これら二点について簡単に総括すると、表面的な契約書の表題など以上に、両当事者の実質的な意思の合致が裁判では重視されるということを端的に示すものだと考えられます。また、契約の実質がひとたび請負契約と判断された後は、その他の論点についても請負契約にまつわる業界内での商習慣を踏まえた解決をはかったものとみられます。受注側／ベンダーの主張を退ける際に、「請負契約に関する一般の常識に反する発言」、「独自の見解」といった言い回しが登場する点は、端的にこうしたことを示すものともみられ、非常に特徴的です。社会常識・社会通念といったものが法解釈にも反映され、法律実務に影響を与えうるという点とともに、あわせて注目すべきポイントでしょう。ちなみに、当該判決においてこれほどにも重視されることとなった「仕事の完成」という概念については、システム開発の文脈を踏まえて以下の記事で詳細に解説しています。

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

プロジェクトマネジメント義務についての理解も前提として問われる

なお、本判決は、システム開発の専門家たるベンダー側が負う「プロジェクトマネジメント義務」の話も深く関連してきます。こうした義務についての一般的な解説は以下の記事にて行なっています。

上の記事の内容を踏まえると、システム開発プロジェクトの専門家という立場で仕事を受けるベンダーの責任も、決して軽いものではないことがわかります。たしかに、プロジェクトの円滑な進行のためにユーザー側の協力が必要となる場面が少なからずある点はいうまでもありません。しかし、必要な協力をユーザーに適宜呼びかけるなどの努力を行うこともなく、その義務が免責されることは通常考えにくいものです。プロジェクトが頓挫した責任をユーザー側に帰着させることは、こうした観点からもきわめてハードルが高いことがわかります。上記の判決の妥当性は、こうしたプロジェクトマネジメントについての理解が前提にあると、より実感しやすくなるのではないでしょうか。むしろ、こうした観点から導き出される妥当な結論と一致をはかるべく、取引の実態を派遣ではなく請負とする理論構成が採用されやすかったという面も少なからずあったのかもしれません。

まとめ

以上、派遣と請負の区別が曖昧な場合に起こりうるプロジェクトの紛争事案について解説しました。事案のなかでは、契約書の形式的な表題以上に相互に交わされてきた具体的な約束事項や、業界内の商習慣などの実質が重視されていることがわかります。また加えて、個別に締結された契約の類型が派遣か請負かといった細部にわたる法律の議論のみならず、それらに通底する基礎として「プロジェクトマネジメント義務」というものについての見識も重要であるように思われます。IT系のプロジェクトでは、派遣や請負に限らず、たとえば出向や準委任といった手法での人材活用も多くみられます。これらも踏まえた全般的な区別と違いについては、以下の記事で詳細に解説を行なっています。

派遣と請負の違いに限らず、契約類型の曖昧さに端を発する紛争のバリエーションには様々なものが想定されます。しかし、たとえ対処する事案が未知のものであったとしても、そこで大切にすべきものはやはり、「プロジェクトマネジメント義務」をはじめとする基礎的な事柄への見識なのではないでしょうか。