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

[ITプロセスコンサルタント 細川義洋，＠IT]

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

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

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

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

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

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

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

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

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

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

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

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