ユーザーがワガママだから失敗したんです：「訴えてやる！」の前に読む IT訴訟 徹底解説（52）（2/3 ページ）

お客さまは神様です。どんなにムチャを言われても応えるのがベンダーの努めです――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回は「ベンダーの義務」を考える。

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

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

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

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

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

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

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

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