最後の不具合が除去されるまで、働き続けてもらいます：「訴えてやる！」の前に読む IT訴訟 徹底解説（72）（1/3 ページ）

　それでも理想を目指して、昨日よりは今日が、今日よりは明日が少しでもマシになる、そんな希望を持ちながら、2020年も1年、この連載を通して考えていきたい。

後を絶たない「名ばかり請負契約」

　ソフトウェア開発を請負にするか派遣にするか曖昧なまま契約し、後で苦しむことになったITベンダーの例は、本連載でこれまでに何度も紹介してきたし、今でもその発生は後を絶たない。

　「成果物の納品」（請負）と「約束した工数」（派遣）の両方を使い分けて、ベンダーの作業員を都合よく使う、もしくはその両方でベンダーを縛り付け続けるという行為は、問題が多いと言わざるを得ない（たとえ「とにかくきちんと動くものを作ってくれるまでは面倒を見てほしい」という発注者の気持ちを相当に配慮したとしても）。

　そんな契約ならベンダーの方から断るべきとも思えるのだが、ベンダーはベンダーで、「お金をもらう身」の弱みがあり、多少、不都合な条件を突き付けられても、のんでしまう傾向はある。何事もなくソフトウェアが完成してしまえば、契約上の問題は表には出ない。そんなことよりも目の前の受注だし、既に確定している納期が大切。そんな気持ちも分からないではない。

　しかし、ソフトウェア開発というものは、失敗の確率が高く、だからこそ契約形態が費用支払いのときに問題になることが多い。IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載。今回は契約形態が鍵となった紛争を紹介する。

請負と派遣の内容が混在した契約書

　まずは概要を見ていこう。

　本連載の読者なら、契約書の条項を見て首を傾げることだろう。

　実行形式のプログラムを成果物としており、代金の支払いも発注者が販売したシステムの代金に応じて支払われる。つまり請負契約のはずである。しかし、「発注者と受注者協議の上、1人月相当と合意した作業を、発注者の指示に従って行う」という、いわゆる派遣契約の内容も混在している。

　この条項だと、受注者はモノが出来上がらなければ解放されないのはもちろんのこと、仮に出来上がって作業時間が余っていれば発注者の都合で追加の作業を要請されたり、あるいは代金の減額を求められたりすることにもなりかねない。実に発注者にとって都合の良い条項なのだ。

　このような契約を結ぶと、問題が発生したら即、受注者には不都合なことになる。それなのに、本紛争の受注者営業担当者は、目先の受注欲しさからか、契約書に対する認識の薄さのためか、この条件をのんでしまった――。