パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ：「訴えてやる！」の前に読む IT訴訟 徹底解説（65）（2/4 ページ）

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

「現状通り」とまとめられた要件は有効か？

東京高等裁判所　平成27年6月11日判決から

あるユーザー企業が自社の販売管理システム開発をベンダーに委託した。開発の内容はパッケージソフトウェアをカスタマイズして行う方式で、ベンダーは要件定義工程から設計、製造、テスト、運用準備、移行までを請け負った。

しかし、出来上がったシステムについてユーザーは複数の不具合を指摘し検収を拒んだ。ただし、不具合として指摘した事項の中には追加要件にあたるものも含まれていたため、両者は話し合い、結局、ユーザーが追加費用を支払って、開発を継続することで合意した。

ところが、追加作業後もユーザーは満足せず、検収と費用の支払いを拒んだ。理由としては主に「1. システムに多数の不具合が存在すること」「2. 既存のシステムにある機能を新しいシステムが網羅していないこと」だった。

ベンダーは「1」については、システム開発である以上多少の不具合混入は不可避であり、これは債務不履行ではなく瑕疵（かし）担保責任として対応すべきものであること、「2」については、既存システムの機能は満たしていると主張し裁判となった。

　少し補足すると、ユーザーの主張する「不具合」とは、「ロール発注というユーザー企業の業界独特の発注方式にパッケージソフトが対応しておらず、本来、カスタマイズ要件として定義すべきところだったが、定義されず、機能として実装されなかったこと」などである。

　カスタマイズ要件の定義はベンダーが行ったが、要件定義時点でユーザー企業も要件定義書に同意している。要件が抜け落ちた責任はどちらが負うべきなのだろうか。

　ユーザー企業の主張は、「業界内の取引を考慮すれば、ロール発注のような機能は、要件として定義されていなくても当然に具備すべき機能である」というものだ。

　要件定義書には多くの抜け漏れがあったが、「現システムの業務内容を継承」「現状の機能を網羅する」と書かれており、要件として抜け落ちたものは「現状通り」という言葉で補われている。いわば野球のバックネットのようなものだ。

　一方のベンダーの主張は、「現システムの業務内容を継承」「現状の機能を網羅する」程度の言葉で、ロール発注などユーザーの業界独特のものまで要件として定義したとは見なせない。そもそもパッケージソフトウェアとは、それに合わせてユーザーの業務自体を変えるのが本来の使用法であり、「定義されていない要件は、パッケージが持つ機能をそのまま使うのが当然である」というものだ。