役割分担表では「問い合わせ対応」のみですが、実際は全面協力してくださいね。ベンダーなんだから:「訴えてやる!」の前に読む IT訴訟 徹底解説(34)(1/3 ページ)
IT紛争解決の専門家 細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、ユーザーとベンダーの間で交わした「役割分担表」にまつわる訴訟を解説する。
システム開発で作られる「役割分担表」とは
“システム開発は、ユーザーとベンダーの協業である”
裁判所の判決でよく聞かれる言葉だし、私も本連載や著書の中でこうしたことをよく書いてきた。いったんシステム開発プロジェクトが始まれば、ユーザーとベンダーは、「お客さま」と「請負人」というよりも、皆がプロジェクトメンバーであり、おのおのの役割を果たすことが必要となるからだ。
確かに、システムを設計したりプログラムを作ったりするのはベンダーの役割だが、要件定義は、ユーザーの出した「要望」をベンダーが「要件」として文書化して一緒に検討するし、受入テストもお互いの協力が必要な場合が多い。そこではお互いの立場を捨てて議論にのめり込むこともあるし、そうした方が良いものができることも多い。
しかし、そうした混成チームで作業をするからには、お互いの「役割」や「責任」を明確にしておくことも必要だ。
システム要件について皆が自由な発言をしたとしても、最終的には誰かが決断をしなければならないし、テストの実施も、技術面、業務面から、結果が妥当であることに責任を持つ人間が必要だ。具体的に「誰が」までは決めなくても、ユーザーとベンダーの「どちらが」決断し、責任を持つかは明確にしておく必要がある。
そうしたこともあり、多くのシステム開発プロジェクトでは「役割分担表」を作って、個々の作業を「どちらが行う」のか、「誰が責任を持つ」のかを定義する。以下のような定義表だ。
作業 | ユーザー | ベンダー |
---|---|---|
エンドユーザーへの要望ヒアリング | 主担当 | 支援 |
要件定義書の取りまとめ | ― | 主担当 |
要件定義書レビュー | 主担当 | ― |
※(筆者注)説明の都合上、あえてあまり良くない表記法を例示した。理由は後述 |
こうしたものを読者の皆さんも見たり作ったりすることはあるだろう。
この役割分担表の「解釈」を巡ってユーザーとベンダーが対立し、裁判の重要な争点になるケースもある。役割分担表に書かれている主担当や支援の「意味合い」が不明確で、双方が都合よく判断してしまい、「テスト仕様書作成は、ベンダーの役割だったはずだ」「いや、そんな約束はしていない。やるなら追加費用を見積もる」……といった争いになってしまうケースだ。
IT訴訟事例を例にとりトラブルの予防策と対処法を解説する本連載、今回は、「役割分担業」の解釈をめぐって争われた裁判の例を見てみよう。その役割分担表のある場所に書いてあった文章が、裁判所の判断に大きく影響をした裁判だった。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回はパッケージソフトを使った開発のトラブルを解説する。契約にない「要件定義」をパッケージベンダーはするべきなのか? - 定形外業務も自主的に調べるのがベンダーの努めです
今回は、契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する - ベンダーはどこまでプロジェクト管理義務を負うべきか
プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか。ある裁判の判決を例に取り、IT専門調停委員が解説する - 検収後に発覚した不具合の補修責任はどこまであるのか
ユーザー検収後に発覚したシステム不具合を補修をめぐる争いで、裁判所が1724万円の支払いを命じたのは、ユーザー、ベンダーどちらだったのか? - 最低限の知識も理解もないユーザーと渡り合うには?
「出荷管理をシステムを発注したにもかかわらず、勘定科目を把握していない」「意見を社内でまとめず、五月雨式に投げてくる」「モックを本番と勘違い」――こんなユーザー、あなたならどうする?