その仕様凍結、守られてますか？

拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」のご紹介がてら、システム開発を成功させるためのポイントをご紹介する本連載、第四回も要件定義の続きです。

要件の追加・変更がひどすぎると裁判に・・・

前回、要件定義について少しお話をしました。
私は以前に10年間ほど前まで裁判所でITに関するトラブルの調停や裁判の支援などを行なっていましたが、やはり裁判になるような大トラブルでも、その原因の多くは要件定義工程の不備にあるなあというのが率直な思いで、やはり何を作って欲しいのかを発注者が正しく伝え、受注者もこれを正しく理解するというのは本当に大切なことだと、つくづく思うところです。

拙著においても主人公の勤める不動産会社が会計システムのリニューアルを頼んだはいいけど、「管理会計」という機能がマルっと抜けていてさあ大変・・・というお話を書いていますが、このように要件に抜けもれがあったり、それを後で追加してくれ、変更してくれとベンダーさんに無理強いをしたがためにプロジェクトが破綻してしまったという話は、本当によく聞きます。では、そうして失敗したプロジェクトの責任というのはユーザーとベンダーのどちらにあるのでしょうか？そりゃワガママ言いたい放題のユーザーでしょ、いやいや、そういうのも織り込んでプロジェクトを管理するのがベンダーでしょ、と意見は分かれるかもしれませんね。まあ、私の感触では前者の考えを持つ人が多いような気はしていますが。
でも、実際のところ、要件の追加変更はプロジェクトに与える影響が非常に大きく被害金額も膨大になるので、裁判になるものも相当数あります。

有名な東京地裁 平成16年3月10日判決

では裁判ではどんな判決が出ているでしょうか？少し古いですが、平成16年に東京地裁が以下のような判決を出しています。
事件は国民健康保険組合で起きました。こちらの支部では機関システムのリニューアルを大手ITベンダーさんに依頼したのですが、一旦、凍結したはずのシステム化要件についてユーザー(保険組合)の担当者が、いや違うと言い出し、しかし別の担当者は、いやいや今のままで、と言って要件が固まらないということが発生しました。凍結したはずの要件をユーザーが後になって変えてくれという話はよくありますが、それをユーザー自身がまたひっくり返して結局決まらず、というのですからもっと性質が悪いですね。判決文を読むと、例えば紙やFAXで送られてきた保険の加入申込書を事務集中センターのようなところで一括でシステムに入力するか、申し込みを受け付けた支部で入力するか、その判断をいつまでもしてくれないというようなことがあったようです。
この事件についての解説はこちらのページにもう少し詳しく書いていますが、さて、判決はどうだったでしょうか？多くの人にとって意外なことに裁判所は、この部分についてベンダーに非があると判断しました。(実際には他にも多くの論点のある裁判だったので、この一点だけでベンダーの敗訴とまでは言えないのですが。)

ITベンダーのプロジェクト管理義務

ワガママを言い放題のユーザーじゃなくてベンダーが悪いって本当？そんな風にお考えの方も多いかもしれませんね。なぜ、こんな判断になるのでしょうか。実はITベンダーには専門家責任というものがあり、例えばユーザーがわがままを言ってプロジェクトの進行を妨げるなら、そうしたリスクをユーザーに言って決定を急がせたり、スケジュール変更や費用の追加を申し出る義務がある、簡単に言えば、ユーザーはITの素人なんだから、無邪気に色々なわがままを言ってく。それに対して言いにくいこともでしっかり言ってプロジェクトを成功に導く義務がベンダーにあり、それを怠ると、「プロジェクト管理義務違反」という不法行為になってしまうということのようです。

もっとスケジュール伸ばしてください、お金をもっとくださいというのが“権利”ではなくて”義務”だと言うんです。ちょっと意外ですよね。この判決は、そうした意味でさまざまな話題を呼びました。
ですが、これが一つの基本となって、例えばIBMとスルガ銀行の裁判や旭川医科大学の裁判などでもこの考え方が取り入れられました。

その場、その場でお客さんの顔色を伺うだけでなく、ダメなものはダメ、やるならお金と時間をください、そうじゃなきゃプロジェクトは破綻するときちんと警告をすることも、専門家としてベンダーには求められると言うことなんですね。

「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」