プロジェクトマネジメント義務と協力義務とは？
本件においては「Corebank」という、新しいパッケージ製品を日本IBMが担いで提案したという流れがあった。
その時点では、スルガ銀行にも日本IBMにもよくわからないが、きっとうまくいくだろうという空気があったはずである。
この空気、それ自体が悪ではない。100%うまくいくことが見えているプロジェクトなど存在しないし、ある種の楽観性がなければ、プロジェクトをキックオフすることすら難しい。
だが、もちろんそれだけではダメだ。同時にダメだったらこうしようという慎重さをバランスよくハンドリングする必要がある。
司法の場においては、プロジェクトマネジメント義務と協力義務という2点によって、ユーザーとベンダーのどちらにどれだけの責任があるかを判断するのが通例だ。
交通事故と同じで、過失や責任がA：Bというふうに考えるのである。
プロジェクトマネジメント義務とは、ベンダーは、ものづくりのプロフェッショナルとして、プロジェクト自体を阻害する行動を取らないように、積極的に相手をリードしよう、ということだ。
開発する仕様が確定したのに、「やっぱりこうしてほしい」という変更要望が後から発生したら、いつまでたっても開発は終わらない。
しかし、ユーザーは開発のプロではないので、いつまでだったらそれが言えるのか、いつ以降は言えないのか、これがなかなかわからない。
ここを仕切るのはベンダー側なのだ、ということだ。実際に、他の判例を見ても、ここを仕切る行為が適切になされていたかというのが大きなポイントになる。
「旭川医大対NTT東日本事件」では珍しいことに、この点をもって「10:0」の判決がなされたのは有名な話だ。
一方の「協力義務」とは、開発に必要な資料をベンダに対して提供する協力義務のことである。当たり前だが、ユーザー企業からすると、「何をどこまで用意してあげたらいいか」というのは簡単にはわからないものだ。
また、「これとこれをどうするか、いつまでに判断してください」なんて設計書を渡されても、ちんぷんかんぷん、ということも多い。技術的な内容や、その判断のプロジェクトにおける位置づけ、影響範囲については、ベンダーからしっかりと説明を受ける必要があるのである。
