俺、コンサルタント。準委任だから品質には責任持ちません：「訴えてやる！」の前に読む IT訴訟 徹底解説（61）（1/3 ページ）

コンサルティング会社が作った要件にヌケ漏れがあった。責任を取るのは、開発会社か、コンサルティング会社か、それともユーザー企業か？――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回のテーマは「コンサルティングの義務」だ。

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

連載目次

　謹んで新年のお祝いを申し上げます。

　いよいよ平成最後の年となるが、この30年間、オンプレの汎用機システムがクラウドやスマホアプリに変わり、ウオーターフォールがアジャイルになっても、IT紛争の類型に限っては相変わらず要件定義やプロジェクト管理の問題が取り上げられる。それでも、本連載などを参考に、毎年少しずつでもIT導入に関わるプロセスを改善させ、その成功率を少しでも高めていただきたい。そんなことを願う年始だ。

システム開発の目的とは

　本連載で何度もお話ししてきたように、システム開発、あるいはITの導入で、ベンダーが負わなければいけない債務は、「契約の目的に資するモノやサービスを提供すること」である。

　例えば、「ユーザーから提供された要件にモレがあり、それを基にして作ったシステムが業務の役に立たない」となった場合、「漏れた要件が契約の目的に照らして当然に必要と考えられるもの」であれば、専門家としてそれを指摘して要件を加えてモノを作ることがベンダーには求められる。もちろん、裁判でどのような結果が出るかは、その欠落した要件の内容によるが。

　例えば、既存のシステムに具備され、新しいシステムでも特に不要と判断されていない機能を、要件定義書に記されていないことを理由にベンダーが実装しなかったために、システムが完成したと認められなかった判例がある。

　裁判において、要件定義書は軽視される存在ではない。

　しかし、そこに全てが正しく書かれているわけではなく、そうした欠落を埋めながら開発や導入を進めなければならないことを裁判所も知っている。

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回も必要な機能が具備されなかったシステムを巡っての争いだ。ただし、これまでと少し様相を異にするのが、争った相手が、開発ベンダーではなく上流工程で要件定義書を作成したコンサルティング会社である点だ。

コンサルタントの田中です。私が決めた要件に従って開発してください（画像はイメージです）