検索
連載

契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから「訴えてやる!」の前に読む IT訴訟 徹底解説(26)(2/3 ページ)

東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回はパッケージソフトを使った開発のトラブルを解説する。契約にない「要件定義」をパッケージベンダーはするべきなのか?

Share
Tweet
LINE
Hatena

パッケージソフト導入の要件定義は誰がするべきか

東京地裁 平成17年7月27日判決より抜粋して要約

あるITコンサルタント会社(以下、SIベンダー)は、鉄鋼工業者(以下、ユーザー)から、生産管理システムの開発を請け負った。開発はパッケージソフトをカスタマイズして行われることになり、その開発企業(以下、パッケージベンダー)もプロジェクトに参加し、カスタマイズ部分の設計・開発を請け負った。

ところが、プロジェクトはパッケージソフトのカスタマイズ要件を定められずに、スケジュールが遅れ、このままでは、要件定義の完了も、それを受けて作成するカスタマイズ仕様書も、全く完了する見込みがなかったことから、ユーザーは契約を解除した。

これについて、SIベンダーは要件定義が完了しなかったのは、パッケージベンダーの債務不履行であるとして、これに損害賠償を請求し、訴訟に至った。

 「要件定義がまとまらずにプロジェクトが頓挫する」という、よくある失敗プロジェクトの例である。しかし今回の例は「誰が要件定義を行い」「誰が完成に責任を持つべき」なのか、いまひとつ判然としない。

 パッケージベンダーはSIベンダーに対する提案で、「自分達はこのプロジェクトで『設計・開発』を行う」と述べている。委託契約では、「自分達の役割は『詳細設計以降のフェーズ』」としながらも、「要件定義の支援は行う」ともしていた。

 元請けベンダーはこれを、「パッケージソフトを使った開発の『設計・開発』は、実質的には要件定義も含む。また要件定義「支援」とは、下請けであるからそう書いたもので、実際にはパッケージベンダーが中心になって要件定義を行う」と解釈した。

 ところがパッケージベンダーは、「自分たちはあくまで要件定義「支援」を行うのであり、何かあれば質問への回答などは行うが、責任を持つのは詳細設計以降であった」と述べている。

 実際には、パッケージベンダーの考えに近い形でプロジェクトが進められ、必ずしもスキルが十分とはいえないSIベンダーが中心となって要件定義を行い、結果として頓挫してしまった。

 そこでSIベンダーは、「パッケージベンダーがきちんと仕事をしなかったから、トラブルが起きた」と考えたのだ。

現場では契約よりもスキル……

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る