要件定義書に書いていない要件でも、ベンダーは気付くべきだ：「訴えてやる！」の前に読む IT訴訟 徹底解説（129）（1/3 ページ）

ベンダーが作ったシステムは処理速度が遅く、タイムアウトによってシステムダウンを起こして使い物にならない。発注者は、「ITの素人が処理速度や処理時間を定義しなければならないなんて知ってるわけないだろう」とお怒りの様子だが、仕様漏れの責任は全てベンダーが負うべきなのだろうか――。

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

連載目次

　IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防策と対処法を解説する本連載。今回は、連載128回「取りあえず謝っただけなのに、プロジェクト失敗の責任を取らされるんですか」と同じ裁判を取り上げる。

　前回は「ベンダーの謝罪が、システム開発失敗の責任を認めている論拠になり得るか」という話をした。今回は「システム化要件の不備」について解説していく。このテーマは本連載で何度も取り上げてきたものだが、裁判に限らず私の周囲の開発プロジェクトでもいまだに問題が起き続けている。さらに本裁判では、今まで紹介してきた判例と少し異なる責任分担の考えが出ている。

　前回と少し重複するが、まずは裁判の概要から紹介していこう。

東京高等裁判所 令和6年1月31日判決より

求人情報事業などを行う発注者は、求人の募集要項の自動組版システムをベンダーの持つパッケージソフトをカスタマイズして開発する契約をこのベンダーと結び、開発をスタートさせたが、要件定義開始から2年以上たっても、要件定義のやり直しなどが行われるなどプロジェクトは混乱し、納期を超えて納められたシステムにも多数のバグが生じたことから発注者は契約を解除し、支払い済み代金の返還を求めて訴訟を提起した。

この訴訟において発注者は、当該システムは処理速度が遅く、タイムアウトによってシステムダウンを起こすなどの不具合があるなどとしてベンダーが債務を履行していない旨を主張した。

出典：判例タイムス1533号 90ページ

要件の提示漏れは、発注者の責任か？

　発注者の主張する不具合は、他にも「利用者に通知メールが届かない」「特定文字列の入力があると不具合が発生する」「画面やメッセージの表示に関する不具合」などがあったが、本稿は「処理速度の遅さによるシステムダウン」に絞って話をする。

　システムの処理速度は基本的に技術的な問題であり、不具合はベンダーの責任において解決しなければならない。発注者とベンダーの専門性を比較すれば当然だ。問題は「処理速度に関することが要件定義書には記されていなかった」ことだ。

　ある処理を何分以内で終わらせる必要があるか、応答時間は何秒以内であるべきかといった速度の問題は、それによって実現される業務の状態による。データベースの更新に3時間かけてもいいのか、数分で終わらなければならないかは利用者の業務プロセスやスケジュールによるからだ。

　これをベンダーに対して要件として示していなければ、ベンダーはシステム構成やデータベースのチューニング、ネットワーク帯域について特別な考慮をすることなくシステムを構築してしまうかもしれない。さらに、後で処理時間が遅過ぎると判明しても、（その場では謝るかもしれないが）「責任は要件として示さなかった発注者にある」と考えるかもしれない。