【半蔵門ビジネストーク】20171018 説明義務・断る義務・協力義務
２００８年に開始されたITシステム開発訴訟。ユーザーであるスルガ銀行とベンダーであるIBMの間で、ベンダーのマネジメント責任とユーザーの協力義務を争点として争われ、２０１５年に、ベンダーの敗訴となった。この判決に、ITベンダー関係者は震え上がる。大きなプロジェクトで途中の仕様変更が発生し、最終的に完成しなかった場合に、どちらに責任があるのかと問われて、ベンダーに責任とされてしまう判例となってしまうからだ。
プロジェクトで途中の仕様変更 ー これらはスケジュールと合わせて考えると無理難題となることも多い。しかし、その仕様が満たされないとシステムが役目を果たさない、支払いはできないといわれれば、ベンダーとしてはなんとか開発をやり遂げるしかなくなる。
もちろん、こうした判決を受けて業界としては、ベンダーもユーザーもそうした不幸な結果にならないように、対策を取って来た。しかし、同じような争いが起こってしまう。
スルガーIBMの訴訟が始まった２００８年、旭川医大のシステム刷新を請け負ったNTT東日本との間で、同じようなシステムへの追加要望が発生し、両者は、仕様の変更受け入れとスケジュールの見直し、仕様を凍結して、稼働を目指したがその後も仕様変更が相次ぎ、それを受け入れて、最終的に稼働に間に合わなかった。
争点は、スルガーIBMと同じく、プロジェクトマネジメント義務とユーザーの協力義務。
一審で地方裁は、遅延などプロジェクトに支障が出ることが予測されるなら、拒絶するか変更を取り下げさせるなどの義務があり、PM管理義務とした。これは、スルガ判決と同じ。
しかし、控訴審で高裁は、「できないなら受け入れない」と言われれば拒絶するというのは現実的でなく、仕様凍結を合意しているのは拒絶したのと同意で、その後の追加要望にさらに拒絶できなかったのは、PM管理義務というには酷だとした。ユーザー義務違反はあったが、PM管理義務違反はなかったと結論づけた。
システム開発プロジェクトで、開発途中での仕様追加、変更は発生する。状況は変わるし、使えないシステムを納品しても意味がない。したがってそれらはユーザーとベンダー双方が協力し、機能や費用、スケジュールで折り合いをつけていくしかないのであろう。
折り合いをつけるために、
ITベンダーは、
「システム開発に伴う懸念やリスクをユーザー企業に包み隠さず説明すること」
の重要さを再認識し、
ユーザー企業は、
「ITベンダーから適切な説明や提言を受けたうえで、プロジェクトの方針を適宜見直す」
重要な責任を負う。
２つの訴訟の判決は、仕様凍結という合意の重要性と双方の義務の判断基準を示したのだ。
