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

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

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

連載目次

それって本当に準委任契約？

　先日、ITベンダーに勤める知人から相談を受けた。

　「準委任契約なのに、成果物の品質が悪くて検収できないとお客さまから言われた。こちらもプロだからいいかげんな仕事でお金をもらおうとは思わないが、請負でもないのに品質が悪いからお金を払わないというのはおかしくはないか」

　知人に「契約書に準委任契約と明記しているのか？」と尋ねると、答えは「No」だった。契約書には「システム開発委託契約」とは書いているが、その中身が請負か準委任かはどこにも明記していないという。私は知人に、まずは契約書の中身を読んで、双方の責任を整理した方がいいとアドバイスをした。

　システム開発契約は、請負や準委任がよく用いられる。請負契約は「成果物の納品さえすれば、誰がどのような作業をするかは受注者の自由」というのが基本的な考え方であり、準委任契約は「発注者であるユーザーの指揮、命令に基づいて作業を行い（指揮、命令は会社対会社の間のことであり、ユーザー企業の担当者はベンダーの担当者に直接指示を出せない）、きちんと働きさえすれば、成果物が出来上がらなくても費用は払ってもらえる」。知人は、自身の契約がこの後者に当たるとの認識だったようだ。

　ただし、お客さまであるユーザー企業から成果物の品質を理由に検収できないといわれているということは、ユーザー企業は契約を純粋な準委任とは考えていない可能性がある。作業の時間や質を縛った上に成果物の責任も負うという、ユーザー企業には都合の良い契約と理解していた可能性もあるのだ。

参考記事：システム開発プロジェクトに存在する複数種類の契約形態

発注者は請負だと思い込み、受注者は準委任だと信じた開発契約

　こうした問題は他にも数多く発生しており、ベンダーが深刻な状況に陥る場合も多い。今回紹介する判決は以前にも一度取り上げたものだが、上述の知人から相談を受けたとき、そのヒントになるものとして改めて想起し、再検討を試みたものである。

　事件の概要からご覧いただきたい。

東京地方裁判所 令和4年3月15日判決より

ある電子機器メーカー（以下、元請け会社）が、顧客から注文された計測システムのうち、一部のソフトウェア部品の開発をソフトウェアベンダー（以下 、下請けベンダー）に依頼した。下請けベンダー選定の理由としては、ベンダーの技術者Aが、高い能力と経験を有していたためであり、開発はこのAが単独で行っていた。

本件ソフトウェアは、リリース後、利用しながら改良を重ねる必要があることが想定されていたため、元請け会社と下請けベンダーの間では、当初開発の契約を結んだ後も完成に向けて追加作業が発生することが想定され、当初開発の終了後も追加注文に基づいてAによる作業が続けられており、都度、Aから実行形式ファイルが元請け会社に渡されていた（ソースコードは渡されていなかった）。

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

そうした中、1人で作業を行っていたAが死亡するという事態が発生し開発は頓挫した。元請け会社は下請けベンダーが請負契約上の義務を果たさなかったとして、既払い金の返還を含む損害賠償とソースコードの引き渡しを求めたが、下請けベンダーは本件は準委任契約であり、下請けベンダーにシステムの完成義務はないことから賠償すべき損害はなく、ソースコードも引き渡さなかったため訴訟となった。

出典：Westlaw Japan 文献番号 2022WLJPCA03158015