要件に勝るシステム「開発の目的」の重要性
この連載で以前にも取り上げましたが、システム開発や導入においては要件よりも、目的に資するモノを作ったのか？ のほうが大切という判断を裁判ではよく見られます。
たとえばユーザーが「営業力を強化して顧客に対する提案数を2倍とし、売上を30％上げること」を目的に、営業支援データベースの構築をベンダーに依頼したとします。ところがベンダーは、納期までに必要な機能を作り上げることができませんでした。
それでも、なんとか使うことはできるからとユーザーに費用を請求したが、機能不全を理由に、ユーザーが支払いを拒んだとします。その場合、実装できなかった機能がたとえばシステムの運用管理に関わる部分で、営業支援の機能自体は実装されているようなケース、あるいは営業支援のメイン画面がユーザーの想定とは異なり使いにくいと感じるが、それでも使うことはできるというようなケースは、どう判断されるのでしょうか。
裁判所は約束した機能が過不足なく実現できているかというよりも、ベンダーの作ったものがユーザーの目的である提案数2倍、売上30％増に役立ちそうなものであれば、システムの完成を認めて、ユーザーに支払いを命じる場合が多いように思えます。
この場合、もちろんまだできあがっていない機能については“追完”つまり、納品後に完成させる必要はありますが、とにかく債務不履行による契約解除となり、お金を一銭も貰えないということにはなりにくいと言ってよいでしょう（※）。
※少し補足すると、この場合、実際にユーザーの目的である提案数2倍、売上30％増が達成できたかが、問題なのではありません。そうするために必要な機能が実装されていれば、ベンダーの責任はそこまでです。
また、これとはまったく逆に、要件として定義されていない機能であっても契約の目的を考えれば、これは当然実装すべき機能であると裁判所が判断して、システムの完成が認められなかったという例もあります。
こうした事例を見ていると、IT開発プロジェクトにおいて要件定義は、必ずしも完全なものではなくどうしても抜け漏れや誤りが避けられないものであることを、裁判所はある程度理解しているとも思えるわけです。
