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

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

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

連載目次

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回は、主要な要件が欠落していたために使いものにならなかったシステムをめぐる裁判事例を、新国立競技場の聖火台になぞらえて解説した。

　今回は、パッケージソフトをカスタマイズして開発するプロジェクト頓挫の裁判例を解説する。要件定義の責を負うべきは、ユーザーか、SIベンダーか、はたまたパッケージベンダーか？

増加するパッケージソフト導入失敗紛争

　昨今、ソフトウェアを一から作るスクラッチ開発は徐々に数を減らし、サードパーティが作ったパッケージソフトをカスタマイズしてユーザーに提供する開発が増加している。

　開発期間が短縮でき、他ユーザーにも多く導入されていて欠陥がある程度枯れているパッケージソフトの利用は、1日も早いリリースを望むユーザーにも、一定期間に多くのプロジェクトを成功させたいベンダーにも魅力的である。また、ERPの導入などでは、パッケージソフトの持つ機能が、ユーザーの業務改善のヒントにもなる。今や、パッケージソフト活用は、業務システム開発の主流といってもいいだろう。

　開発数が増えれば、失敗する数も増える。最近の紛争例を見ると、パッケージソフトに関わる裁判の割合が増えているように思う。従来の「ユーザー」「ベンダー」に加え、「パッケージソフトベンダー」という新たなプレーヤーが加わったトラブルは、責任分界点が分かりにくくトラブルになりやすい。

　特に「要件定義」は、原則の責任はユーザーにあるが、実質的にはSIベンダーが取りまとめを行わざるを得ない。さらに、ソフトのカスタマイズ要件はパッケージベンダーにしかできないことが多い。結局、「誰が作業主体」で「誰が責任を持つのか」不明確なまま、プロジェクトが進むことも多い。

　今回は、元請けのSIベンダーと下請けのパッケージベンダーの間で起きた紛争の例を紹介する。

実作業はキミに任せるよ。契約書には書かないけどね（画像はイメージです）