システム開発契約のトラブル事例②
前回記事の続きです。
３．システムに必要な機能が備わっていないとして、代金の支払いを拒否された事例
◆概要
ベンダは、ユーザとの間で、航空券の申込・決済システムの開発契約を締結し、ベンダは仕様書に従ってシステムを構築した。
しかし、ユーザは、「システムに当然あるべき遠隔操作機能が備わっていないため、システムは完成しておらず、代金は払わない」と主張した。
裁判所は、ユーザが業務を行う上で遠隔操作機能は不可欠であり、ベンダが作成した他の資料に同機能の記載があったとして、ユーザの主張を認めた。
◆ポイント
①システムの要求仕様を明確にする
たとえ仕様に明確な記載がなかったとしても、その機能が無ければユーザの業務に支障をきたすことが明らかである場合には、契約内容として認められるケースがあります。
ベンダとしては、要件定義の段階で「ユーザの業務に必要な機能が何か」を十分に分析し、その機能を実現する方法やメリット・デメリットを提示して、ユーザに決断してもらうことが重要です。
②検討の経緯を記録する
ユーザとの協議の中で、予算や納期の関係上、「ある機能を開発しない」という結論になることもあります。
その場合には、後でユーザから「機能が足りない」と主張されても反論できるよう、仕様決定のプロセスを議事録などに記録しておきましょう。
４．システムの導入効果をめぐって争いとなった事例
◆概要
ベンダは、ユーザとの間で、社内基幹システムの開発契約を締結し、ベンダは仕様書に従ってシステムを構築した。
しかし、ユーザは、「システム導入後に業務効率が向上せず、契約の目的が達成されなかったので、代金を払う必要は無い」と主張した。
裁判所は、業務効率の向上は契約内容に含まれないとして、ユーザの主張を退けた。
◆ポイント
①双方の責任範囲を明確する
ユーザの業務プロセスの変革を伴うシステムの場合、業務効率化などの効果は、ユーザが業務変革を行ってはじめて発生します。
しかし、ユーザがこの点を十分に理解していないと、「業務効率が向上しなかった」としてトラブルになる可能性があります。
そのため、ベンダとしては、システム導入の結果として期待される効果はユーザの業務変革によって生じるものであり、（コンサルティング契約などを締結している場合を除き）業務変革の実行はユーザの責任であることをユーザに対して事前に説明する必要があります。
②検討の経緯を記録する
事例３と同様、ユーザから「機能が足りない」と主張されることがないように、検討の経緯を書面に残しておきましょう。
参考文献
難波ほか『裁判例から考える システム開発紛争の法律実務』（商事法務, 2017）
飯田耕一郎＝田中浩之『企業訴訟実務問題シリーズ システム開発訴訟』（中央経済社, 2017）
情報システム・ソフトウェア取引高度化コンソーシアム編「情報システム・ソフトウェア取引トラブル事例集」（2010）
平野ほか「システム開発トラブルの回避策 ユーザ・ベンダ双方の視点から」BUSINESS LAW JOURNAL 2019年12月号