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

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

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

連載目次

プロジェクト管理義務に明確な線引きはない

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回まで3回にわたって旭川医大を舞台にしたシステム開発失敗の例を解説し、大変な反響をいただいた。

　ユーザーが要望を次々に追加変更することによってプロジェクトが頓挫する例は相変わらず頻発しており、その責任が野放図に要件変更を繰り返すユーザーにあるのか、それともそれをコントロールできなかったベンダーにあるのかという問題は読者の大きな関心事項なのだろう。

　実際のところ、「ベンダーはどこまでプロジェクト管理義務を負うべきか」で取り上げた平成16年3月10日の東京地裁判決以降、システム開発を巡る紛争でよく取り上げられるようになった「ベンダーのプロジェクト管理義務」は、その「限界」についての明確な線引きはまだないように思う。

　ユーザーはどの時点まで要件変更が許されるのか、あるいは変更できる要件とはどういうものなのか、明確なルール付けを行った判決は、私が知る限りまだない。裁判所は、何かの基準に基づいて機械的に判断をするようなことはせず、個別のプロジェクトの状況をできる限り具体的に把握した上で、個々に判断を行っていると見るのが妥当だろう。

　システム開発に携わる人々は、こうした例をできるだけ多く知り、具体的な内容からプロジェクトにおける「やって良いこと／悪いこと」を判断していくしかない。

　今回取り上げる事例も、ユーザーの要望変更によって失敗したプロジェクトに関するものだ。現場がどのようなことで迷い、失敗したのか、そのさまを想像しながら読んでいただき、判例から得られる知見を自分たちのプロジェクトに生かしてほしい。

想定外の追加、変更指示、必要なデータの未提出。でも、納期までに作れ！

　まず、判決文を見ていただこう。

平成19年2月16日 東京地方裁判所判決から

平成16年11月ごろ、ある宝石貴金属加工販売業（以下ユーザー企業）がインターネット通販の見積もり、販売システムの開発を発注した（本稼働予定は平成17年7月1日）が、ユーザー企業からの追加の指示などによりスケジュールが遅れ、結局、システムは完成しなかったため、ユーザー企業からベンダーに対して解除の意思表示がなされた。

これに対してベンダーは、開発の遅れはサブシステムである「デザインシステム」について、ユーザー企業から想定外の追加、変更指示が出されたこと、及び「リフォームシステム」についてユーザー企業から提示されるべき画面デザインのデータが全く提示されなかったことによるとして、そこまでの出来高相当分700万円の支払いを求めたが、これをユーザー企業が拒絶し裁判となった。

　典型的なプロジェクト管理義務を巡る紛争である。

　ユーザーがプロジェクトの進行を阻害するような要件の追加や変更を繰り返したり、必要な情報を提供しなかったりした場合、ベンダーには専門家として、そうした行為がプロジェクトに悪影響を与えることを説明し、要件の凍結や取り下げ、あるいはスケジュールの見直しや追加見積を行う「義務」がある。前述した平成16年3月10日の判例をはじめとして多くの裁判では、こうした考えの下、ベンダーに責任を求める判決が出ていている。

　冒頭に述べた旭川医大の事件では、札幌高等裁判所が、ベンダーの義務にも限界があり、責任の多くはいつまでも要件変更を繰り返したユーザーにこそあるとする判断をしている。

　今回はどうだったのか、判決の続きを順に見ていこう。