ここから本文です

このシステム、使えないんでお金返してください!:あるあるIT訴訟解説

@IT 7月15日(金)6時10分配信

 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前々回、前回と、「多段階契約」プロジェクトにまつわる争いを紹介し、契約のポイントを解説した。

【その他の画像】このシステム使えないんで、お金返してください!(画像はイメージです)

 多段階契約は、個別契約の都度、プロジェクトの状況に応じて、成果物や納期、費用を調整しながら進められるので、ユーザーにとってもベンダーにとってもリスクテイクできる手段である。さらにベンダーにとっては、「プロジェクトが途中で終わっても、仕事をしたと認められる部分の支払いを受けられる」というメリットがある、

 しかし、前々回の「分割検収後に既払い金の返還をユーザーがベンダーに求めた裁判例」や、前回の「発注されなかった後期工程の支払いを求めたベンダーの裁判例」のように、原理原則から外れた事案で争われることもある。

 今回も多段階契約の意味合いを考えさせられる裁判例を取り上げる。そもそも多段階契約が認められるのはどのようなときか、ベンダーが多段階契約のメリットを享受するためにはどのようなことが必要なのか、を考える。

●プロジェクトが中断し、ユーザーが全額返還を求めた裁判例

○東京地裁 平成25年7月19日判決より抜粋して要約
 米国デラウェア州の法人(以下 ユーザー)が、システム開発業者(以下 ベンダーA)に対し、SNSサービスサイトの構築を委託した。契約は、第1段階から第3段階までに分けられ、段階が完了するごとに検収と支払いが行われることとされた。

 開発は順次行われ、着手金と第1段階分、第2段階分までの支払いが行われたが、第3段階の実施中にプロジェクトが計画通りに進まず、結局中止となった。

 ユーザーはベンダーAとの契約を解除して、別のベンダー(以下 ベンダーB)にシステム開発を依頼し、これを完成させた。ベンダーAに対しては、既払いの第1段階、第2段階分費用の全額返還を求めて提訴した。

※ユーザーは、ベンダーBに支払った費用を損害としてベンダーAに賠償を求めたが、本稿ではその点は割愛する。
---

 第1段階と第2段階の検収が終わり支払いまでしているにもかかわらず、ユーザーは契約全体を解除し、費用の全額返還を求めて提訴している。前回も書いたが、こうした訴訟が起こること自体「IT紛争では検収書が絶対のものではない」ことを物語っている。

 対立点は、「本契約は、そもそも分割して考えられるのか」だ。

 ユーザーは、「多段階契約であっても、結局は1つのシステムを開発する契約である。それが完成しなかった以上、ベンダーに費用を払ういわれはない」との主張だ。

 一方のベンダーは、「多段階契約は複数の契約である。全体が完成しなくても、検収した分は支払いを受けられる」との考えだ。多段階契約をする目的そのものと言ってもよいだろう。

 では、裁判所はどのように判断したのだろうか。次ページで判決文の続きを見ていこう。

●多段階契約は複数の契約である。ただし……

○東京地裁 平成25年7月19日判決より抜粋して要約(続き)
 ベンダーAは、第3段階の不履行を理由とする本件契約の全部解除は許されない旨主張するところ、仮に、契約が可分であり、かつ、分割された給付につき相手方が利益を得ていると認められる場合には、未履行部分についての一部解除しかすることができないと解するのが相当である。

 これを本件についてみるに、本件契約は、第1段階から第3段階までの段階ごとに進捗(しんちょく)管理がされ、分割金も各段階が「完了した後」に支払われるものとされていることからすると、本件契約は、上記段階ごとに可分なものと解する余地はあると解される。
---

 裁判所は、このプロジェクトは3つの段階に明確に分けて管理されており、費用も各段階の完了後に支払われていることから、契約は分けて考える余地があるとしている。つまり、原則としては、多段階契約なのだから、システムが完成していないことを理由に既払い金の返還は求められないとしている。

 ただし、これはあくまで原則の話であり、多段階契約さえ結んでおけば安心という意味ではない。

 引用した判決文の2行目を見ていただきたい。「分割された給付につき相手方が利益を得ていると認められる場合には~」とある。つまり、「途中までの費用をもらうには、そこまでに作ったものが、ユーザーに利益をもたらしているかがポイント」ということだ。

 例えば、ウオーターフォール型の開発を「要件定義」「設計」「実装」「テスト」と区切って契約し、「実装」途中でプロジェクトが頓挫した場合なら、「それまでに作った要件定義書や設計書が、他人でも理解できるものであり、仮に別のベンダーが作業を引き継いだ場合でも役立つものであれば、費用はもらえる」との考え方だ。

 アジャイル開発であれば、「先行してリリースした機能が問題なく動作し、後続の作業はそれ以外の機能だけを補えばよい、という状態であれば、リリースした部分を包含する契約に基づいて費用はもらえる」ということだ。

 では、ベンダーAが作ったものは、ユーザーに利益をもたらすものであったのだろうか。

●引き継いだ別ベンダーは、納品物を利用できたのか?

○東京地裁 平成25年7月19日判決より抜粋して要約(続き)
 しかし、本件においては、ベンダーAが履行していないことを自認する第3段階のみならず、第2段階の作業が完了したといえない(中略)上、(中略)第1段階についても、これを構成する全24項目のうち、必要な作業が完成していないとみられる項目が、バックエンドで3項目、フロントエンドで17項目に上っていることが認められ、このような作業状況に照らすと、本件契約が段階ごとに可分なものであるとしても、当該可分な段階に対応する独立した給付が完了したということはできない。

 加えて、(中略)ユーザーは、本件サイトの構築を他の業者に依頼せざるを得なくなり、(中略)その際、ベンダーAから納品を受けた成果物を利用できなかったことが認められ、これによれば、ユーザーがベンダーAから受けた給付により利益を受けたということもできない。以上によれば、本件契約は全部解除が認められるというべき(後略)
---

 裁判所は、第1段階、第2段階の成果物は未完成であり、「この状態での納品はユーザーに利益をもたらしていない」と判断した。「成果物が未完成である以上、分割して検収を受けても、納品とは認められない」との考えだ。

 後半部分では、ベンダーAの成果物が役に立たないものであった、つまりユーザーに利益をもたらさないものであったことを証明するために、ユーザーがベンダーBに開発を依頼し直した際、ベンダーAが作りかけたものを利用できなかったと説明している。

 検収を受けようと、支払いを受けようと、ユーザーが利益を得ていると認められなければ、既払い金は返還しなければならない、と裁判所は判断したのだ。

●多段階契約のポイントは「他人に渡せるものを作ったか」

 分割検収を行う際に大切なのは、納品物が「単体でもユーザーに利益をもたらすものであるか」だ。

 では、ベンダーはどうすればよいのだろうか。

 要件定義書や設計書ならば、他人が引き継いでも利用でき、最小限の手戻りで済むように作っておくべきだ。自分たちだけが分かればいいと記述をはしょったり、内部でしか通じない言葉を使ったりせず、品質良く仕上げねばならない。分割した契約ごとに順次機能の実装を行う場合は、誰もが分かる仕様の説明書を作成せねばならない。

 こうした作業は自分たちの身を守ることになるし、作業や成果物の品質向上にもつながるので、多少面倒でも心掛けたいものだ。

 請負契約でベンダーがユーザーからお金をもらう根拠は、作業を行ったかどうかでも、システムが完成したかどうかでもない。目的を達成して、ユーザーが利益を享受できる状態を作ったかどうかである。

●細川義洋 東京地方裁判所 民事調停委員(IT事件担当) 兼 IT専門委員 東京高等裁判所 IT専門委員。NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

最終更新:7月15日(金)6時10分

@IT