この契約は、請負でも準委任でもありません：「訴えてやる！」の前に読む IT訴訟 徹底解説（110）（2/3 ページ）

発注者は請負だと思い、受注者は準委任だと思って進めていたシステム開発プロジェクト。だがトラブルが起きて契約書を見直してみると、請負、準委任、どちらの文字も書面になかった。トラブルの責任はどちらが負うべきなのだろうか。

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

契約の内容からは、どちらともいえない

　少し補足をすると、本件ソフトウェアは契約当初から、リリース後に利用しながら改良を重ねることが想定されていた。このため、契約はシステム完成までを見込んだものだったが、そこには納期の定めはなく、費用と共に個別の注文によって都度、定めていたようである。従って下請けベンダーの技術者Aは、当初予定のソフトウェアを作成後、費用の支払いを受けた後も改良作業を複数回続けており、その都度、請求書と注文書のやりとりがなされ、リリース後に費用が支払われていた（ただし、ソースコードは渡されていなかった）。

　開発は当初、順調に進んでいたが、追加注文については、品質上の問題から検収を受けられないことが続いていた。

　さらに、改良作業中にAが死亡したため、開発が止まってしまった。このソフトウェアは、元請け会社が顧客から請け負った計測システムの一部であり、全てが完了しなければ顧客に納品できない。従って元請け会社としては、これにより発生した損害の賠償と完成した部分、未完成の部分共にソースコードの引き渡しを求めたのだ。これは契約が請負であることを前提とした主張だ。

　一方で下請けベンダーは、これは準委任であるとの立場から、未完成による損害賠償義務もソースコード引き渡しの義務もないとしている。さて、この契約はどちらと評価すべきなのだろうか。

　契約書には請負や準委任という文字は見当たらないようだ。双方が勝手に、自分に都合の良い判断を主張している。残念ながら、判決文には契約書の文言までは書かれていないが、認定された事実からすると、以下のようなことが合意されていたようだ。

1. 当初契約、および追加の注文には、作成すべき機能と納期、金額が記されていた
2. Aからは実行形式ファイルが収められ、この品質によって費用支払いの延期が合意されたこともある
3. 注文には納品物は明記されていなかった
4. 本件契約は、Aによる作業を前提とされていた

　これらを見ると、「1」「2」は請負契約の考え方が反映されており、他は準委任契約に近いようにも思える。

　判決の続きを見てみよう。