これは、私が時々、取り上げる例ですが、私の知るある企業で、生産管理のパッケージソフトを導入しようとしたとき、その機能が、ある意味便利すぎて問題になったことがあります。そのパッケージソフトは、製品の開発に遅延が生じたとき、スケジュールを遵守するために、開発に参加しているメンバーへの仕事の配分を勝手に調整してくれます。Aさんの作業が３日遅れているなら、作業が進んでいるBさんにAさんを手伝わせて、全体のスケジュールを守るように人員計画を作ってくれるのです。
ところがその会社では、常日頃から自社の生産性を計測して業務改善に役立てようとしていましたので、遅れたものは遅れたものとして管理し数値化しなければなりませんし、事実、それまで使っていたシステムでは、勝手に要員を入れ替えてスケジュールを守る計画を立てさせるようなことをしていませんでした。新しいパッケージソフトでは、そうした悪い数字を取り込めないので、業務改善に必要なデータを得ることができないのです。
この会社ではシステムの開発中に、このことに気づき、パッケージソフトを自分達の昔の姿に近いように改造することで対応ができました。しかし、世の中を見てみると、このようにパッケージの機能と自分達の今までのやり方が違い、しかもそのことを要件定義時に気づかずにモノづくりをしてしまった結果、こんなはずではなかったとエンドユーザからクレームの絶えないシステムになってしまうという例が、かなり多くあります。今回は、そんな例について、お話ししましょう。
カスタマイズ要件に記されなかった要件への対応を巡る争い
(東京高等裁判所 平成27年6月11日判決より)
あるユーザ企業が、自社の販売管理システムの刷新をベンダに依頼し、ベンダは、あるパッケージソフトウェアをカスタマイズして構築することを提案して、ユーザもこれに同意し、開発が開始された。システムは、パッケージソフトウェアの改造点をとりまとめた「カスタマイズ機能一覧」を要件として開発をしたが、それは全ての要件を網羅したものではなかった。一方で、契約前にベンダが示した提案書には、新システムにおいても「現状の機能を網羅すること」という記述があった。
販売管理システムというのは、顧客からの注文を受け付けてその商品の在庫を調べるとともに代金を請求する。顧客から入金があったら、その情報を管理するとともに出荷を指示するというものです。これを機能として羅列すると、「注文受付」「在庫管理」「請求」「入金管理」「出荷管理」といった具合でしょうか。このくらいの粒度であれば、新しいパッケージソフトもユーザが元々使っていたシステムにも同じようなものがあったでしょうから、ベンダが提案書で言っていた「現行機能の網羅」というのも実現できることになります。
しかし、ITの導入における要件定義というのは、これらをもっと細かくブレークダウンして行われます。注文受付にはどんな画面を作るのか、在庫管理の単位は個々の商品毎の他にそれを組み合わせたセット商品があるかないか、請求に分割払いはあるか、支払い方法は現金・クレジットカードの他に何があるのか。そういう細かいところになると、新しいパッケージソフトウェアと既存のシステムの間には、多々の違いがあり、パッケージソフトウェアの方を改造する必要が出てくるわけです。その改造点を取りまとめたものが「カスタマイズ機能一覧」と言うことになり、開発(改造)は、これを元に行われます。
とはいえ実際に開発を進めていくと、当初作ったカスタマイズ機能一覧にはない部分で、ベンダがどう作れば良いのか迷う部分もたくさん出てきます。「入金管理」と言うけれども、銀行やクレジットカード会社には、どのようなタイミングでお金が支払われていることを確認するのか、出荷管理には戻入(一度、出荷したが、なんらかの事情で帰ってきてしまった商品)の管理が必要かなど、当初は気づかなかった問題が出てきます。これは、システム開発を人間が行っている以上、どうしても避けられないことです。
このシステムでも、どうやらそうしたことが沢山あったらしく、事件の概要は以下のように続きます。
(東京高等裁判所 平成27年6月11日判決より)
ベンダは，本件システムを構築した後、ユーザに対して、システムの説明会を行ったが，ユーザからは機能の不足等が複数指摘され、ベンダはこれに対応する為、追加カスタマイズ契約を結んで、これに対応したが、ユーザはそれにも納得せず検収を行わなかった。
ベンダは、ユーザに支払いを求めて訴訟を提起したが、ユーザ側は、ベンダが約束した機能を実現しなかった(債務不履行)として、損害賠償請求の反訴を提起した。
