本稼働1週間前ですが、要件を変更します！――プロジェクト管理義務の理想と限界：「訴えてやる！」の前に読む IT訴訟 徹底解説（50）（2/3 ページ）

本番稼働直前に要件を変更する、必要な情報は提供しない。こんなユーザーをベンダーはどうコントロールすればよかったのか？――システム開発にまつわる訴訟を教本に、トラブルの予防と対策法を解説する人気連載。今回のテーマは「プロジェクト管理義務の限界」だ。

[ITプロセスコンサルタント 細川義洋，＠IT]

要件変更はいつまで許されるのか？

平成19年2月16日 東京地方裁判所判決から（つづき）

ユーザー企業が「デザインシステム」について、種々変更指示をし、それによって、ある程度完成が遅れたことは否定できない。特にユーザー企業は、平成17年6月23日（当初、本稼働時期とされていたのと同じ月）にも最終的な変更指示をしているので、その指示に基づく「脇石の明細項目についての自動計算」機能（デザインシステムの一部機能）が完成していないことは、ベンダーの責めに帰すことはできないと認められる。

　裁判所は稼働直前の変更部分について、ベンダーの立場を理解した判断をしている。

　これまでの判例で、「ユーザーが要件を凍結しなければいけない時期」を裁判所が判断した例は、あまりないし、この判決でも明確な時期を指定しているわけではない。しかし、さすがに「本稼働予定まで1週間」という時期に要件を変更するのは非常識ということだ。

　判決文は、要件の変更が具体的にどの時期まで許されるのかまでは述べていないが、新しい要件や変更要望が、客観的に見て残りの期間、工数では対応できない時期に出されたのなら、ベンダーは、これを断ったり、スケージュールや見積もりの変更を申し出たりできると考えてもよさそうだ。

　ユーザーに「このままでは、このシステムは使えない」と言われても、ベンダーがこれを無条件で受け入れる必要まではない。

　ところが、実際の開発現場では、こうした非常識なことが日常茶飯事である。私も、プロジェクトの最終段階であるユーザー受入テストの段になって新機能の追加を要望され、泣く泣く対応した経験が何度かある。

　もちろん本当なら、追加された要件が新規のものであること、その対応が残された工数と期間では対応できないことを説明しなければならない。その意味でも、プロジェクト開始時点から要件とスケジュールと工数を管理し、状況をユーザーと共有することはベンダーが己を守る上でも大切だ。

　しかし残念なことに、本件のベンダーは少し甘さがあったようだ。判決の続きを見てみよう。

宝石の美しさはデザインで良くも悪くも変わる