曖昧な要件定義は裁判沙汰の定番
曖昧な要件がシステム開発のトラブルを生むという事例は、もはや裁判の定番と言ってよいくらい数多く見られます。ユーザー企業側で、システム開発の企画と開発ベンダーへの発注を担当する部門は、要件定義か、あるいはそれよりも前の提案依頼書（RFP）の段階からエンドユーザー部門によくヒアリングして、本当に業務に役立つシステムを作っていく必要があります。
しかし実際にはそれをやりきれず、中途半端な要件定義がエンドユーザーやシステム部門、それに開発ベンダーの理解不足を招き、トラブルを引き起こすことが現実に数多く起きています。
今回取り上げるのは、まさにそうした事件です。曖昧な要件を提示したユーザー企業と、それを勝手に理解したつもりの開発ベンダー。この争いの顛末を通して、システムのユーザー、特にシステムを発注する部門の責任について考えてみたいと思います。まずは事件の概要から見てみましょう。
（東京高等裁判所 令和 2年 1月16日判決より）
あるインターネット・サービス・プロバイダ事業者（ISP）が、自社の基幹システムの開発に関する提案依頼書（RFP）をソフトウェア開発ベンダー（開発ベンダー）に交付し、開発ベンダーは、これに対する提案書を提示して両者の間にシステム開発請負契約が成立した。開発ベンダーが請負ったのは、新システムの要件定義から設計、製造、テスト工程までのすべての工程だった。
作業はRFPと提案書の内容を確認しながら開発ベンダーが要件定義書をまとめることから始まり、その後、基本設計、詳細設計と進んだが、その後、双方の要件の理解に齟齬があることが発覚して、プロジェクトは混乱し、結局、システムが完成しないまま請負契約は解された。
要件定義上の問題点は数多くあったが、その中にはエンドユーザー部門であるカスタマー部門で使用する「統計・カスタマーツール」機能に関する認識齟齬もあった。
