訴訟に至るようなITトラブルを防止するためには何を行うべきか。シリーズ企画の第3回は、合意すべき機能要件があいまいで、開発プロジェクトが遅延し訴訟になった事例をとりあげる。機能要件に関わる合意の重要性が浮かび上がるケースである。
今回、紹介するのは、顧客管理システムの開発・導入プロジェクトである。最初に発注したベンダーに問題があり、別のベンダーに切り替えたものの、上手く立て直せず、プロジェクトが頓挫。発注者が損害賠償請求の訴えを起こした。
なお、裁判は結審に至っておらず、内容を精査するための資料が乏しい。相当量、筆者の推測が入ることをお許し頂きたい。プロジェクトの経緯は以下の通りである。
発注者は大手放送会社。顧客サービスの拡大を目指して、契約内容や問い合わせの対応状況を管理する、顧客管理システムの刷新プロジェクトを立ち上げた。当初、選んだのは、ベンダーA社である。
A社は、要件定義、基本設計と作業を進めたが、開発フェーズに入る段階で降板した。発注者がB社に担当を切り替えたのである。A社による要件定義と基本設計に不備があったようだが、詳細な理由を、裁判資料から窺い知ることはできない。
この記事の続きをお読みいただくには、
会員登録(無料)が必要です
会員登録(無料)が必要です
【次ページ】
- 1
- 2
- 3
- 4
- 次へ >
バックナンバー
- 訴訟事例から学ぶパッケージソフト導入時の注意点(2014/09/19)
- 簡易なシステムのリスク回避(2014/07/07)
- システム開発会社のスキル不足にどう対処すべきか(2014/06/13)
- ベンダーによるオーバーコミット(過剰な提案)と 発注者の“相手任せの姿勢”が訴訟を招く(2014/01/15)
- データ移行の失敗で、業務システムが使い物にならない!(2013/11/21)