IT導入におけるユーザの協力義務、ふたたび

ユーザの協力義務が問題になった裁判の例

　※ この裁判では、このプロジェクトの終了が契約終了通知によるものなのか、契約解除によるものなのかという点も争点になりました。実は、単なる契約終了と契約解除では費用の支払いを巡る考え方に大きな差があります。これはITユーザとして知っておくべき重要な事項ではありますが、話が複雑になるため、別の回で解説したいと思います。

ユーザが果たさなかった協力義務

　「納期通りにモノを納めてくれなかったんだから、金なんか払わない。」「いや、交渉にも応じない一方的な契約解除には応じられない。」―IT紛争では、非常によく聞く言葉の応酬です。もちろん、同様の応酬がなされる他の裁判でも、その判断はケースバイケースなのですが、その際に論点になるのは、”本当に合意なく納品が遅れた (なされなかった) のか ” という点と ”ベンダ側はプロとして行うべきプロジェクト管理を行なっていたのか (いわゆる、プロジェクト管理義務 ) ” 、それに “ユーザは、必要な協力を行なったのか (ユーザの協力義務 ) ” という点です。このプロジェクトではどうだったでしょうか。判決文の続きを見てみましょう。

　ご覧の通り、裁判の結果はほぼ全面的にユーザ側の敗訴でした。やはり、ユーザにはプロジェクトを成功させるためにやらなければならないことがいくつもあるようです。この判決には、ユーザの協力義務違反の見本とも言うべき事項が並んでいます。

1. 役割分担された作業を実施しない。
2. ユーザが判断すべき事項を必要な時期までにしない。
3. ベンダが作業する環境を必要な時期までに整えない。
4. 必要な時期までに情報を提供しない。
5. 契約範囲外の作業を依頼する。

　まさに、このままチェックリストにしても良いのではないかと思えるような協力義務違反のオンパレードです。これでは、プロジェクトはうまくいきません。このプロジェクトではユーザの協力が足りなかったようです。ただ、実際にプロジェクトを始めてみると、こうしたことは読者の皆さんにとっても他人事ではなく、分かっていてもできないことが多いのも事実です。例えば、1．の分担された作業や3．の環境整備について言えば、引き受けた後になってその難易度の高さに気づいたり、想定以上の時間がかかると分かったりということがしばしばあります。2． のユーザ判断や 4．の情報提供については、ユーザ内部で、システム担当者以外の人間が十分に協力してくれなかったために起きることですが、これも、そのときになってみないと皆が協力してくれるか予測できないものです。5． についてはプロジェクトのスコープについての問題ですが、これも、プロジェクトの概要すら知らないエンドユーザ部門が、後になって想定外の機能を要求してきたり、そもそもシステム担当者がスコープの切り方を十分に理解していなかったりということで起きることで、ユーザサイドにIT導入経験が十分でない場合致し方ない面もあります。こうして他人の失敗を後から見ていると、ついつい見下したような気になってしまいますが、こうしたモメ事は、私も含めて、どんなユーザにも起き得ることなのです。