それでも、要件というものは変わってしまうことがあります。ユーザ部門の意向の変化、技術的な要因、ユーザの社内事情や社会情勢等の理由で当初の要件は変わって行くことが多く、ある程度の規模のITであれば、要件変更は日常茶飯事と言っても良いくらいです。
仮にそうしたことが一切なくとも、各部門やメンバーの意識共有不足・齟齬、伝達誤りのような、いわばミスによっても要件は変わります。正確な統計は知りませんが、２０数年に渡って、この業界に身をおく私の経験の感覚からすると、当初の要件が全く変わることなくITの導入や開発を終えるプロジェクトは、むしろ少数派でしょう。
ベンダの追加・変更作業をユーザが放置した結果起きた紛争の例
要件の追加や変更がIT紛争を起こしやすいものであること、それらをうまく管理してプロジェクトを成功させる責任はベンダにあるが、ユーザも真摯に協力しなければならない、ということについては、この連載の第一回、第二回あたりでお話ししました。
そこでお話しした”ユーザの協力義務”には、追加や変更に係る判断をタイムリーに行うということも含まれます。エンドユーザ部門から、”この画面を変えてほしいんだけど・・・” と要望があり、ベンダに相談したところ、その費用は意外と高く、納期も延ばさないといけないことが分かった。システム導入の責任を持つユーザのシステム部門は、エンドユーザとコスト・納期の板挟みになって、頭を抱える・・・。こんなこと、よくありませんか？私は、こんなユーザを沢山見てきました。
悩むのは仕方ないとしても、その期間があまり長すぎると問題が起きます。こうしたとき、ベンダはユーザの判断を待たずに作業を継続したがるのです。ベンダは契約上、納期を守ることが債務とされています。また、せっかくアサインしたメンバーの仕事を止めて待機させておくことにも限界があります。ですから、あまり長い間、決定をせずに、ぐずぐずしていると、ベンダは見切りで作業を再開してしまい、あとからベンダの合意していない費用請求をすることがあります。
「そんな、勝手に作業されたって知らないよ。」、「多分こうなるって言ったじゃないですか。ウチはそれを信じたんです。そもそも、決定が遅すぎるからこうなるんです。」といった会話が会議室から漏れてくるような事態になってしまうのです。
今回、ご紹介するのもまさに、そうした紛争の例です。裁判所は、こうした紛争について、どのような判断をするのでしょうか。まずは、事件の概要からご覧ください。
【仕様の変更・改善に伴う追加費用に関する裁判の例】
(東京地方裁判所 平成15年5月8日判決より抜粋・要約)
あるITベンダが通信販売業者から販売管理システム等の開発を受託し、開発を開始したが、途中で開発範囲(要求機能)に相違があることが判明した。通信販売業者はITベンダに多項目の修正・改善要求を出したが、ITベンダは追加費用を請求する見積書を提出した。
これについて通信業者は、開発範囲の修正は要件の追加・変更ではないし、見積もりにも合意していないとして費用の支払いを拒んだが、その間、ITベンダは見切り発車の形で作業を継続しており、費用が掛っていた為いた為、通信ベンダに追加費用を請求する訴訟を提起した。
ユーザとベンダが各々、相手の判断を甘く予測した結果の紛争というべきでしょうか。ベンダは追加費用について、要件変更だからユーザは払ってくれるだろうと考え、支払い拒否の正式決定まで作業を続けました。一方、ユーザは、追加要件はベンダの認識不足によるもので、見積もりを出してきたとしても、断れば無償で作業をするだろうと考えていたようです。(双方とも、ちょっと甘すぎでしょうか。)
