システム開発を発注したが、個別契約の一部が履行されなかった……それでも費用は「全額」支払うべき？

契約の前にリスクを想定しておこう

　こうしたトラブルを紛争にまで発展させないためには、発注者と受注者が契約前にプロジェクト頓挫を想定して、万が一発生した場合の対応について合意しておくことが大切です。

　その際、裁判所が言うような機能同士の“密接関連性”なるものを検討するのもよいですが、これは実際には難しい作業になるかと思います。それよりも、もっとシンプルに「一部機能が動かない場合に、業務として使えるか」、そして「不具合部分の改修計画が明確であるか」という判断基準で費用の支払いが可能かを定め、契約書別紙や覚書にしておくことが有効ではないかと思います。

　ここで言う「業務に使える」とは、多少の不便さはあってもとりあえず使えるレベルのことであり、画面上の表示の誤りであったり、手作業や旧システムなどで代替可能であったりする場合は、早期の改修を前提にとりあえず納品を認めるというような意味です。

　また、一つのシステム内に独立した二つの機能がある場合、たとえば「出張精算のシステムで、国内出張の機能は使えるが海外出張はできていない」という場合なら、国内用の機能の分だけは検収して費用を支払うという切り分けもできます。

　いずれにせよ、特に個別契約を結ぶ場合には、開発が上手くいかなかった場合を想像し、検討してあらかじめリスクテイクをしておきましょう。こうしたことができていない契約も世の中には多いように思えるのですが、皆さんの組織ではどうでしょうか。

とはいえ、すべては信頼のうえに……

　無論、こうした交渉はお互いの信頼があってこそです。

• あのベンダーは、いい加減なモノづくりでもお金だけはとりっぱぐれないように、こんな話し合いを持ちかけてきたんだ
• あのクライアントは、一部でもシステムが動かないことを理由に、全額の支払いを拒むかもしれない

　お互いにこんなことを考えていたら、契約時にプロジェクトが失敗した場合のことまで話し合うなんてできないかもしれません。

　ですから、ユーザー側は「システム開発に失敗はつきもの」という考えを、ベンダー側は「自分たちの仕事は、顧客の業務を動かすこと」というマインドを念頭に、様々な失敗のケースについて胸襟を開いて話し合うことが大切です。場合によっては、リスク抽出専用の打ち合わせを契約前に重ねてみるのもよいかもしれません。

　信頼とは、「相手が失敗しない」と信じることではなく、「失敗しても協力して対応できる」ことを確認できて成り立つものだと言えるでしょう。そのうえで失敗について話し合っていけば、個別契約の頓挫について揉めたり、裁判になったりなんてことは起こらないはずです。