連載
» 2016年05月10日 05時00分 公開

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 パッケージを利用した開発経験のない方が見ると、SIベンダーが強引であると見えるだろう。「設計・開発には当然に要件定義も含まれる」や「支援は実質、主体である」との論は、言葉だけを見ると無理がある。

 しかし実際の開発現場では、契約書に書かれた役割分担とは違う体制で仕事をすることは珍しくない。特にパッケージ開発の場合、SIベンダーに十分なスキル・知識がないまま、プロジェクトがスタートし、現場ではパッケージベンダーが中心になることも多い。

 SAPのように、世界中のSIベンダーが一生懸命勉強し、SAP社の人間でなくても、一通りの作業が可能なソフトならいざ知らず、今回問題になった生産管理システムのように、十分なスキルがパッケージベンダーにしかないような場合には、要件定義からテストまで、技術力が必要な作業のかなりの部分をパッケージベンダーが負う場合が多いのは事実だ。今回のSIベンダーも、そうした対応をパッケージベンダーに期待していたのだろう。

 無論、「パッケージベンダーは契約以外の作業を行う義務はない」と考えるのが正論だ。仮に、「自分たちがやらなければプロジェクトは失敗する」と分かっていても、「契約は契約」と考えることもできる。

 裁判所は、どのように判断しただろうか。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。