契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから:「訴えてやる!」の前に読む IT訴訟 徹底解説(26)(2/3 ページ)
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回はパッケージソフトを使った開発のトラブルを解説する。契約にない「要件定義」をパッケージベンダーはするべきなのか?
パッケージソフト導入の要件定義は誰がするべきか
東京地裁 平成17年7月27日判決より抜粋して要約
あるITコンサルタント会社(以下、SIベンダー)は、鉄鋼工業者(以下、ユーザー)から、生産管理システムの開発を請け負った。開発はパッケージソフトをカスタマイズして行われることになり、その開発企業(以下、パッケージベンダー)もプロジェクトに参加し、カスタマイズ部分の設計・開発を請け負った。
ところが、プロジェクトはパッケージソフトのカスタマイズ要件を定められずに、スケジュールが遅れ、このままでは、要件定義の完了も、それを受けて作成するカスタマイズ仕様書も、全く完了する見込みがなかったことから、ユーザーは契約を解除した。
これについて、SIベンダーは要件定義が完了しなかったのは、パッケージベンダーの債務不履行であるとして、これに損害賠償を請求し、訴訟に至った。
「要件定義がまとまらずにプロジェクトが頓挫する」という、よくある失敗プロジェクトの例である。しかし今回の例は「誰が要件定義を行い」「誰が完成に責任を持つべき」なのか、いまひとつ判然としない。
パッケージベンダーはSIベンダーに対する提案で、「自分達はこのプロジェクトで『設計・開発』を行う」と述べている。委託契約では、「自分達の役割は『詳細設計以降のフェーズ』」としながらも、「要件定義の支援は行う」ともしていた。
元請けベンダーはこれを、「パッケージソフトを使った開発の『設計・開発』は、実質的には要件定義も含む。また要件定義「支援」とは、下請けであるからそう書いたもので、実際にはパッケージベンダーが中心になって要件定義を行う」と解釈した。
ところがパッケージベンダーは、「自分たちはあくまで要件定義「支援」を行うのであり、何かあれば質問への回答などは行うが、責任を持つのは詳細設計以降であった」と述べている。
実際には、パッケージベンダーの考えに近い形でプロジェクトが進められ、必ずしもスキルが十分とはいえないSIベンダーが中心となって要件定義を行い、結果として頓挫してしまった。
そこでSIベンダーは、「パッケージベンダーがきちんと仕事をしなかったから、トラブルが起きた」と考えたのだ。
現場では契約よりもスキル……
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- パッケージソフト導入の「お・と・し・あ・な」
パッケージソフトの導入には、ベンダーのスキル不足や業務との不適合といった危険が常につきまといます。そうした問題に直面したとき、ユーザーとベンダーはお互いの状況や立場を積極的に共有し、垣根を超えて話し合うことが重要です - 排他制御でアイタタタ!―― パッケージソフトの落とし穴
システム化対象業務の基本的な機能を備え、設定とアドオンを行えば使用できるパッケージソフトウェアは、コストと品質面でとても有用です。しかし、自社の業務にフィットしないソフトを導入したことによる紛争も、数多く発生しています - システムを持たぬ時代に、あえてフルスクラッチに特化する:前編
プログラムレス開発が全盛の中、フルスクラッチ開発こそ、顧客のためになり、SEにとっても強みとなると主張する企業がある。彼らはなぜあえて今、このような主張をするのだろうか?