Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

仕様凍結って意味あるの?

2017/06/15 06:00

 「仕様凍結」という言葉があります。システムを開発する際に、ユーザ側からの要望が出尽くしたところで、「もうこれ以上の仕様の追加や変更はしない」とユーザとベンダが合意して、後続の工程に入ることです。

仕様凍結とは言うけれど

 ただ、実際のシステム開発プロジェクトでは「仕様凍結」がなかなか出来ないというのが現状ではないでしょうか。仕様検討中には気づかなかったことに後から気づいたり、プロジェクトに参加したエンドユーザ部門の人間が、後になってこれでは使えないと仕様の変更を求めるということは、決して珍しいことではなく、むしろ、ほとんどのプロジェクトで、こうしたことが起きていると言っても良いくらいです。

 仕様がいつまでも決まらなかったり、凍結後に仕様が変えられてしまうと、当然に手戻りが発生してスケジュールやコストに悪い影響を及ぼします。しかし、そうは言っても現実には、どうしても必要な機能に後から気付いたり、実際に動くものを見たらイメージしていたものと違ったりということは、人間同士が話し合って進めるシステム開発プロジェクトでは不可避のことと言っても良いでしょう。実際、仕様凍結を厳格に守りすぎると役に立たないシステムを作ってしまう確率が高まるのも事実です。

凍結後の変更は、どこまで許されるのか

 ベンダーから見た場合、ITユーザとはお金を頂ける”お客様”です。そういう立場からして、一旦、凍結したはずの仕様をユーザサイドから変えて欲しいと無理難題を言われたら、なかなか断りきれないものです。しかし、ベンダが断らないのを良いことに「ベンダさんは、結局なんでもやってくれる」と、いつまでも要求をやめないと、やがてプロジェクトが頓挫してしまいます。今回は、そんな事例の紹介です。

 仕様凍結をした後の要件変更で頓挫してしまったプロジェクト。悪いのはユーザなのでしょうか。それともやはり人間によるシステム開発である以上、ある程度のことは許され、むしろシステムを完成させることの出来なかったベンダに責任があるのでしょうか。

  (旭川地方裁判所 平成28年3月29日判決 より)

 ある医療法人が、電子カルテシステムを中核とする病院情報管理システムの導入をベンダに依頼した。プロジェクトはパッケージソフトウェアをカスタマイズしてシステムを完成させる方針で進められたが、仕様確定後、ユーザから出された追加要望のため、プロジェクトは混乱し、結局システムを完成させることができなかった。

 医療法人は、この為、ベンダの債務不履行に基づく契約解除の意志を示し、約19億円の損害賠償を請求した。

 (ユーザが示した追加要求は、画面や帳票の変更、操作性など、複数あったが、いずれも軽微なものであったことが判決文から推測されます。)

 最初に申し上げておくと、この裁判は、結局、システムに不具合があり、完成したとまでは言えないことなどを理由にユーザである医療法人に有利な判決が出ました。

 しかし、今回、論点としているユーザ側の ”仕様凍結破り” については、裁判所も、少し違った判断をしています。続きを見てみましょう。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年...

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5