また、実際に運用する環境で、満足な性能を上げられるかどうかも気にしなくてはなりません。仕様書上は、例えば｢検索ボタンを押してから結果が表示されるまで3秒以内で、検索対象データは10万件｣とあっても、それが開発環境では実現できていたとしても、運用環境で実現できなければ意味がありません。

そして、もう一つ。本当に欲しいシステムというのは、納品されたソフトを動かした時に、初めてわかることもある、ということです。動かしてみて初めて、本当に欲しいのはこんな機能ではないとか、こういうことができないといけないはずなのに要求を出していなかったとか、理想を追い過ぎていて実業務がついていけないとかがあります。先に述べたように、ソフトハウスは仕様書に基づいて作っているだけなので、ユーザーが本当はどういう使い方をしたいのかを、正確に理解できているわけではありません。

ですから、コミュニケーションに問題があるのは当然のことと捉えて、しっかり実際の業務に合うのかどうかを検証しなければならないのです。そのためには、ソフトハウスやIS部門のテスト結果に左右されることなく、どういうテストを行うか、どういうことをしたらどういう結果が出るべきなのかを、ユーザー自身が考え検証しなければならないのです。これを怠ると、本運用が始まってからとり返しのつかない問題が発生して、会社のビジネスに悪影響を及ぼすことになります。

残念ながら、ソフトハウスにいた人間として言えるのは、どんなに相互の確認をしっかり取っていても、運用に入った時に、必ず問題が出ます。そして｢こういう場合は、こんな風にならないと困るんだよね｣といった、初耳の情報を発したりします。

また、データ移行についても考えるべきことはたくさんあります。これも、ユーザーが深く関わるべき問題です。現在のオープン系システムは、データさえあれば取り込むのは比較的簡単です。ですが、旧システムからのデータ移行については、旧システムをよく知っている人がいなければ無理というものです。コード体系を変えたため、データの変換作業が必要になったりもします。過去のデータは、きれいに整備されていないことも多いですから、では新システムではどうするのかといった問題が出ます。