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

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

コンサルティング会社が既存機能を要件として定義しなかった事例

　まずは、事件の概要から見ていただこう。

東京地方裁判所 平成22年9月21日判決から

学習塾を営むユーザー企業が、教室管理システムの要件定義をコンサルティング会社に依頼した。コンサルティング会社は要望ヒアリングや現行システムの調査などを行って要件定義書をまとめ、ユーザー企業は、それを基にシステム開発を別の開発ベンダーに発注した。

ところが出来上がったシステムには、現行システムに存在した機能が欠落していた。原因はコンサルティング会社の作成した要件定義において、業務フローレベルから、当該機能が抜けていたことにあり、ユーザー企業は、債務不履行を理由にコンサルティング契約を解除した。

コンサルティング会社は、システムは完成している（※）として、費用の支払いを求める訴訟を起こしたが、ユーザー企業側も既払金の返還と損害賠償を求めて反訴を提起した。

※本訴訟は、コンサルティングに関してだけでなく、コンサルティング会社が行った基幹業務システム開発についても合わせて争われたが、話を分かりやすくするために本記事では割愛した。ただし、そういう理由で、コンサルティング契約の検収行為は全てのシステムが完成した後に行われる予定であったことをご理解いただきたい。

　昨今のIT導入では、最上流にコンサルティング会社を入れて要件定義を行う例が少なくない。筆者もそうした仕事をした経験がある。コンサルティング企業は、現状の業務を調査してその改善点を見いだし、それをどのように改善するのか、そのためにITをどのように使うのかを提言する。

　その段階で、既存システムの機能をどうするかをユーザー企業と確認して、それらを踏襲するかどうかを決める必要がある。しかし本件では、どうやらそれが不足していたようである。

　とはいえ、コンサルティングで既存機能の扱いの全てを書き切ることが絶対必須であるのかは微妙なところではある。コンサルタントの提言書や要件定義書は現行からの主な改善点のみを示して、詳細は開発フェーズでシステム要件の確認、詳細化で行うという例はいくらでもある。

　もう一つ考えるべきは、本件のコンサルティング契約が「準委任」だったことである。

　準委任契約は作業者の「工数」に応じて費用が決定されるので、請負と違って、検収を受ける際に出来上がったモノの「品質」は原則考慮されない。明らかに質や量が劣るのであれば、常識的な判断として作業品質が問われるかもしれないが、一部既存機能の欠落があった程度で「準委任契約に基づく債務を履行していない」とまでいえるかは難しい。

　では、裁判所はどう判断したのだろうか。判決の続きを見てみよう。