連載
» 2018年02月19日 05時00分 公開

「訴えてやる!」の前に読む IT訴訟 徹底解説(52):ユーザーがワガママだから失敗したんです (2/3)

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

 このプロジェクトは当初、コンサルタント会社が基本設計を行い、ベンダーはそれを受けて詳細設計以降の作業を行っていた。しかしユーザー企業は、コンサルタント会社との基本設計契約をなぜか途中で解除してしまった。

 これを知ったベンダーは、「自分たちがもう一度基本設計からやり直す」という提案を行ったが、ユーザー企業は受け入れず、「その時点で作業を進めていた詳細設計の中に、基本設計の残存分を組み込む」という、特殊な作業を強いた。

 要するに、コンサルタント会社が作りかけた基本設計はそのままに、残りの部分はベンダーが考えて、詳細設計に組み込むというやり方だ。

 これは混乱する。そもそも作りかけの基本設計書では全体の網羅性も正確性も担保されていないし、ベンダーには、なぜそのような設計になっているのかの理由も分からない。それを正しいものと仮定して受け取り、想像も交えて残りの設計を行う。しかも、最終的に正しいモノを作ることを保証しろというのだから、かなりメチャクチャな話である。

 コンサルタント会社との契約を途中で解除したということは、その時点でプロジェクトがかなり混乱し、スケジュールもかなり計画を逸脱していたであろうことが想像される。そんな状態で、基本設計の補充という新しい作業も追加しながら、詳細設計以降の作業を行えば、納期を守れないことも、不具合が多数出ることも、ある意味当然の結果である。

 その上、裁判の資料を見ると、「受け入れテストで出た不具合の多くは、ユーザーが準備したテストデータや手順の不備が原因」であり、ベンダーには責任がなかった。それ以外のものも軽微で修正可能な不具合であり、債務不履行の対象とはならないものばかりだった。

 このような事情もあり、裁判所は以下のような判決を申し渡した。

大阪高等裁判所 平成27年1月28日判決から(つづき)

本件仕事が完成しているとはいえないと評価するためには、「本件仕様書の記載に明らかに反し、軽微で容易に改修できるものではないような、システム全体の見直しを行わなければならないほどの欠陥であると認められるようなプログラムミス」が存在しなければならないと解される。

 裁判所はさらに、

  • 受け入れテストのエラーはユーザーのテスト手順やデータに問題があった
  • ユーザー企業が掲げる瑕疵(かし)一覧表記載の指摘事項は、いずれも軽微で改修可能だった

と述べ、ユーザーの請求を全て棄却した。不具合はベンダーの責任ではないし、スケジュールの遅延もユーザーの主張は妥当ではないと退けた。当然と言えば当然の判決である。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。