EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

ユーザが協力義務を果たすためには何をすれば良いのか?【IT紛争事例に学ぶ】

edited by DB Online   2020/10/26 09:00

 今回はトラブルや不具合が起こった際についてまわる「謝罪文」について解説します。 お客様との関係性を保つために「とりあえず謝る」のは鉄則ですが、果たしてIT紛争においてはどのように作用するのでしょうか。

ユーザが協力義務を果たすためには

 IT開発プロジェクトが序盤から遅れに遅れて、結局、完成しなかった。その原因は、ユーザがシステムの構想や要件をまとめきれなかったことにあるのですが、それはユーザの協力義務違反でしょうか。それとも、それをうまくリードできなかったベンダのプロジェクト管理責任でしょうか。

 今回はそのポイントを考えるとともに、そもそもユーザが協力義務を果たすためには、何をしておくのが良いのか。それについて私なりの考えも、お話したいと思います。まずは事件の概要から見ていくことにしましょう。

要件の取りまとめが遅れて破綻したプロジェクト

(東京高等裁判所 令和2年1月16日判決より)

 あるユーザが自社の新基幹システム(問題となったのは、顧客管理,請求・入金管理,決済管理,店舗管理等)の開発をITベンダに委託した。しかし、プロジェクトはユーザによるシステムの構想が途中で変わったこと、画面構想他要件のとりまとめが遅れたこと等よりベンダ側の作業が混乱し、かつベンダがユーザの一部作業を手伝うなどせざるを得なかったことから作業が遅延した。

 ベンダとユーザは何度も話し合いを重ね時にはベンダが謝罪文を出すなどもしながら対策の検討を行ったが、プロジェクトは回復する兆しを見せず、納期を経過しても完成する見込みがないと判断したユーザは履行遅滞を理由にベンダとの請負契約を解除し、既払い金約7,000万円の返還とともに期限までに完成しなかったために生じた損害約21.5億円の損害賠償を求めた。

 少し補足をしましょう。まず“システム構想が途中で変わった"という点についてですが、そもそもこのプロジェクトは、同じ企業グループに属する2つの会社のシステムを、同一のものにしようとする内容でした。

 元々別のシステムを使っていたのですが、同じ企業グループでもあり顧客管理や請求・入金管理、決済管理等については、業務プロセスやルールを統一したほうが効率的です。であればシステムも同じであったほうが、開発・運用コストも抑えられるだろうというのが目的でした。

 ところが、実際に要件の整理を始めてみると、やはり一部の画面とそれに紐付く機能はどうしても同じものにできないことがわかってきました。結局のところ新しいシステムはある部分は統一するが、ある部分は個別に開発するという構想に変わってしまったのです。まったく同じものにするということで受注したベンダも、途中でシステム構想が変わったことで大いに混乱したようです。

 また新要件について、ユーザがエンドユーザ部門の意見を取りまとめきれなかった部分が多数ありましたし、元々古い2つのシステム自体が改修に改修を繰り返して非常に複雑な形であったことも、開発を難しくしていました。そんなこともあって、プロジェクトは遅延し、とん挫したのです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。 おもな著書に、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』 日本実業出版社、『IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』。

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5