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

請負契約だけど、作業指示は出しますよ。あと「動作保証されている」と私が認めるまでは、支払いはしませんよ。だって、こちとら発注者様ですからね！

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

　皆さま、あけましておめでとうございます。

　いよいよ東京で2回目のオリンピックが開かれる年がやってきた。56年前の東京オリンピックでは、日本で初めて汎用機で構成されたオンライン情報システムが使用されたとのことだ。その後の技術の進歩には目覚ましいものがあるが、一方で、システム開発の品質やIT技術者の労働に関する問題は、あまり変わっていない印象だ。

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

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

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

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

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

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

※本連載では通常、ソフトウェア開発を依頼する側を「ユーザー」、依頼される側を「ベンダー」と表すことが多いが、本件は、発注側が必ずしもユーザーには当たらないため、おのおのを「発注者」「受注者」と記述する。

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

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

東京地方裁判所 平成27年6月25日判決から

あるPOSシステム販売業者（以下 発注者）がソフトウェア開発業者（以下 受注者）に美容サロン向けPOSシステムのソフトウェア改修作業を依頼した。両者の間では「請負業務に関する基本契約」が締結され、作業費用の支払いは発注者が本件システムを販売した実績に応じて払われることとなった。締結された契約書には、以下のような条項が含まれていた。

本件委託内容は、本件製品の改修作業に関し、両者協議の上、1人月相当と合意した作業を、発注者の指示に従って行うものとし、改修後の本件製品のソースコードを含む開発環境一式、改修箇所および改修方法を示すドキュメントおよび動作保障された実行形式プログラム一式を納品物とする。

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

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

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

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