（１）パッケージ導入に現場部門が反発または現場の追加開発の要望を抑え切れなくなる
特定のパッケージソフトをユーザーに推薦したＩＴベンダー側の責任を問われるケースが多い
プロジェクトマネジメント義務違反と認定されるケース
ベンダーの技術者にパッケージの機能や業務の知識が不足していた
適切な要件定義の支援や情報提供ができなかった
ユーザー企業が協力義務違反を問われるけーす
「パッケージに合わせて業務を変える」ことを前提にパッケージ導入を決定したのに、
業務を変えることへの現場の反発を抑えられなかったケース
失敗の原因
旭川医大・ＮＴＴ東裁判 開発失敗（ユーザー企業側の「協力義務」に違反）
現場部門の要望を過剰に聞き入れての仕様が膨らみ過ぎ
トクヤマ・ＴＩＳ裁判 ＥＲＰ導入失敗（現場部門が新システム導入への協力を拒否）
原場部門の要望を聞かなければ導入直前に不満が爆発する
原因と対策
パッケージの選定や要件定義の際に現場部門のキーパーソンがほとんど関与していなかった
パッケージを選定した後に現場部門の要望を聞くという順序で進めると
後々のトラブルにつながりやすい
現場部門を交え、１～２年をかけて個々のパッケージソフトの特性を理解したうえでの選定が
コストや時間はかかるものの、後々のトラブルを未然に防ぎやすくなる
（２）理由のない検収の拒否
ＩＴベンダーがシステムを納品しようとした際、
ユーザー企業側が検収や受領、受け入れテストへの協力を拒否するケース
実際にプログラム品質が劣悪だったとしても、
それをユーザー企業が定量的・客観的に実証しない限り、
ユーザー側は裁判の場では正当性を主張できない
失敗の原因
旭川医大・ＮＴＴ東裁判
契約解除までに「システムはほぼ完成していた」と判断し、
「システムは未完成」と主張して受領を拒否した旭川医大に賠償を命じている
読売新聞・アクセンチュア裁判
読売新聞はバグが収束せず、システムの半分を廃棄すると決定
アクセンチュアはパッケージにはバグはなく、手計算にバグがある
原因と対策
バグの数、重要度、バグの収束度合いがどの程度なら
プロジェクトの中止もやむなしとみなせるか、
契約書に検収の条件となる基準の記載を求める
（３）データ移行やマスタデータ作成
データ移行についての検討は後回しにされがち
データの抽出からクレンジングまで想定外の工数が発生しやすい
データの移行について「ＩＴベンダーが全部やってくれる」と思いがち
ベンダーの交代を伴うプロジェクトでは、
旧ベンダーに作業を依頼せざるを得ない場合があり
旧ベンダーと契約関係にあったユーザー企業の責任はより重くなる
マスターデータを移行・整備する場合には、
業務をよく知る現場部門の協力が不可欠であり、これを怠れば協力義務違反となる
失敗の原因
旭川医大・ＮＴＴ東裁判
旭川医大の現場部門がマスタデータの作成に協力的でなかった点について
協力義務違反を認定している
コメントを残す