Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)テクノロジーでビジネスを加速するための実践Webメディア

テーマ別に探す

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

2017/01/16 06:00

 主としてITユーザの方へ向け、裁判事例をもとにIT導入時の注意点を考えてみようというこの連載も、開始して3年半近くが経ちました。これだけの期間続けてこれたのも、読者の皆様のお陰とあらためて感謝の意を深めております。この連載を通じて、私が最も強くお伝えしたいことは”IT導入におけるユーザの協力義務” です。ITの導入は、ITベンダとユーザの協業であって、ユーザが様々な情報提供やプロジェクト中に発生する数々の問題解決への協力、判断を積極的且つタイムリーに行わないと失敗してしまいます。これは数々のIT紛争の例を見てきた私の実感です。しかし残念なことに、近年の紛争事例を見ていても、やはりユーザの協力不足によるプロジェクト失敗は後を絶たたず、私自身も、こうした事例紹介の必要性、重要性を再認識させられているところです。そこで今回は、久しぶりに、この ”ユーザの協力義務” が判断の主眼となった裁判の例をご紹介して、IT導入の為にユーザが何をすべきなのかを考えてみたいと思います。

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

  (東京地方裁判所 平27年3月24日 判決 より抜粋して要約)

 ある通信販売業者 (以下 ユーザ) が基幹システム刷新のための開発をITベンダ(以下 ベンダ) に発注した。

 発注は、以下の通りに分割され、各々について個別契約が締結された。

  1. 個別契約1 : 要件定義(1億4550万円)
  2. 個別契約2: 外部設計書作成業務 (約2億3000万)
  3. 個別契約3: ソフトウェア開発業務,ソフトウェア運用準備,移行支援業務 (8億5500万円)

 このうち、個別契約1及び2については成果物が納品され支払いも完了したが、個別契約3については、スケジュールが遅延し、期限通りに成果物が収められなかった為、ソフトウェア開発業務の途中で、ユーザはベンダに契約の終了を通知し、更に2ヶ月後、履行遅滞に基づく解除通知を送付した。(※)

 なお、個別契約3については、委託料のうち、4億5000万円が前渡し金として支払われていた。

 これについてベンダは、この契約解除は、ユーザが一方的に行ったものであるとして、委託料の残額とその他の費用の計で約4億8200万円を請求して、訴訟を提起しが、一方のユーザは、契約の解除は、ベンダが期限までに成果物を納品しなかったからだと反論し、残額の支払いを拒否すると共に、損害賠償等4億5000万円の支払いを逆に求める反訴を提起した。

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

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

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

  (東京地方裁判所 平27年3月24日 判決 より抜粋して要約 <続き>)

 (確かにベンダの納品物の中には期限通りに納められなかったものがあるが、)

  •  「インターフェース一覧」については、ユーザの分担であるインターフェース仕様整理がされていないために納品されなかった。
  •  「システム/データ移行設計書」については,ベンダが移行作業方針及び移行処理方式の確認を求めたのに対し,ユーザの回答がないために作成できなかった
  •  「検証環境」については,検証環境構築がユーザの都合で延伸された

 上記前提事実によれば,ベンダには帰責事由はないと言わざるを得ない。また,各フェーズにおいて,納期に遅れて納品された成果物があることがうかがわれるが,各フェーズにおける個別の成果物の納品の遅滞は,主にユーザによる情報提供等の遅れやベンダの受注範囲外のシステムの仕様確定の遅れ等に起因する。

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

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

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

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年...

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

この記事もオススメ

All contents copyright © 2006-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5