ユーザが協力義務を果たすためには
IT開発プロジェクトが序盤から遅れに遅れて、結局、完成しなかった。その原因は、ユーザがシステムの構想や要件をまとめきれなかったことにあるのですが、それはユーザの協力義務違反でしょうか。それとも、それをうまくリードできなかったベンダのプロジェクト管理責任でしょうか。
今回はそのポイントを考えるとともに、そもそもユーザが協力義務を果たすためには、何をしておくのが良いのか。それについて私なりの考えも、お話したいと思います。まずは事件の概要から見ていくことにしましょう。
要件の取りまとめが遅れて破綻したプロジェクト
（東京高等裁判所 令和2年1月16日判決より）
あるユーザが自社の新基幹システム（問題となったのは、顧客管理，請求・入金管理，決済管理，店舗管理等）の開発をITベンダに委託した。しかし、プロジェクトはユーザによるシステムの構想が途中で変わったこと、画面構想他要件のとりまとめが遅れたこと等よりベンダ側の作業が混乱し、かつベンダがユーザの一部作業を手伝うなどせざるを得なかったことから作業が遅延した。
ベンダとユーザは何度も話し合いを重ね時にはベンダが謝罪文を出すなどもしながら対策の検討を行ったが、プロジェクトは回復する兆しを見せず、納期を経過しても完成する見込みがないと判断したユーザは履行遅滞を理由にベンダとの請負契約を解除し、既払い金約7,000万円の返還とともに期限までに完成しなかったために生じた損害約21.5億円の損害賠償を求めた。
少し補足をしましょう。まず“システム構想が途中で変わった"という点についてですが、そもそもこのプロジェクトは、同じ企業グループに属する2つの会社のシステムを、同一のものにしようとする内容でした。
元々別のシステムを使っていたのですが、同じ企業グループでもあり顧客管理や請求・入金管理、決済管理等については、業務プロセスやルールを統一したほうが効率的です。であればシステムも同じであったほうが、開発・運用コストも抑えられるだろうというのが目的でした。
ところが、実際に要件の整理を始めてみると、やはり一部の画面とそれに紐付く機能はどうしても同じものにできないことがわかってきました。結局のところ新しいシステムはある部分は統一するが、ある部分は個別に開発するという構想に変わってしまったのです。まったく同じものにするということで受注したベンダも、途中でシステム構想が変わったことで大いに混乱したようです。
また新要件について、ユーザがエンドユーザ部門の意見を取りまとめきれなかった部分が多数ありましたし、元々古い2つのシステム自体が改修に改修を繰り返して非常に複雑な形であったことも、開発を難しくしていました。そんなこともあって、プロジェクトは遅延し、とん挫したのです。
