仕様凍結とは言うけれど
ただ、実際のシステム開発プロジェクトでは「仕様凍結」がなかなか出来ないというのが現状ではないでしょうか。仕様検討中には気づかなかったことに後から気づいたり、プロジェクトに参加したエンドユーザ部門の人間が、後になってこれでは使えないと仕様の変更を求めるということは、決して珍しいことではなく、むしろ、ほとんどのプロジェクトで、こうしたことが起きていると言っても良いくらいです。
仕様がいつまでも決まらなかったり、凍結後に仕様が変えられてしまうと、当然に手戻りが発生してスケジュールやコストに悪い影響を及ぼします。しかし、そうは言っても現実には、どうしても必要な機能に後から気付いたり、実際に動くものを見たらイメージしていたものと違ったりということは、人間同士が話し合って進めるシステム開発プロジェクトでは不可避のことと言っても良いでしょう。実際、仕様凍結を厳格に守りすぎると役に立たないシステムを作ってしまう確率が高まるのも事実です。
凍結後の変更は、どこまで許されるのか
ベンダーから見た場合、ITユーザとはお金を頂ける”お客様”です。そういう立場からして、一旦、凍結したはずの仕様をユーザサイドから変えて欲しいと無理難題を言われたら、なかなか断りきれないものです。しかし、ベンダが断らないのを良いことに「ベンダさんは、結局なんでもやってくれる」と、いつまでも要求をやめないと、やがてプロジェクトが頓挫してしまいます。今回は、そんな事例の紹介です。
仕様凍結をした後の要件変更で頓挫してしまったプロジェクト。悪いのはユーザなのでしょうか。それともやはり人間によるシステム開発である以上、ある程度のことは許され、むしろシステムを完成させることの出来なかったベンダに責任があるのでしょうか。
(旭川地方裁判所 平成28年3月29日判決 より)
ある医療法人が、電子カルテシステムを中核とする病院情報管理システムの導入をベンダに依頼した。プロジェクトはパッケージソフトウェアをカスタマイズしてシステムを完成させる方針で進められたが、仕様確定後、ユーザから出された追加要望のため、プロジェクトは混乱し、結局システムを完成させることができなかった。
医療法人は、この為、ベンダの債務不履行に基づく契約解除の意志を示し、約19億円の損害賠償を請求した。
(ユーザが示した追加要求は、画面や帳票の変更、操作性など、複数あったが、いずれも軽微なものであったことが判決文から推測されます。)
最初に申し上げておくと、この裁判は、結局、システムに不具合があり、完成したとまでは言えないことなどを理由にユーザである医療法人に有利な判決が出ました。
しかし、今回、論点としているユーザ側の ”仕様凍結破り” については、裁判所も、少し違った判断をしています。続きを見てみましょう。
