業務改善コンサルティング情報ブログ

要件定義にまつわる訴訟の顛末

一昨年の記事で、『要件定義書は開発作業の要です』という記事を覚えていますか?

要件定義書

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ある方の記事で、要件定義にまつわる訴訟事例を拝見しました。

そこにあったのは、ベンダーには厳しいと思われる判決内容でした。

要件不備の責任を問われたベンダー

システム開発業者Aは、旅行会社Bの航空チケット発券システムを受託し、開発したが、システムの機能不足で稼働できず、訴訟になってしまったという話しで、その記事に書かれている機能不足とは、『遠隔地からデータベースを操作できる機能が不足していた』というもののようです。

この訴訟の結論を先に言うと、

要件の不備の責任の一端はベンダーにもある。

という判決で、

ベンダーは、ユーザーの業務をよく学び、実際のオペレーションを理解した上で、ユーザーが作成する要件定義書の過不足をチェックしなければならない。

という判断であったと、その方の記事には書かれています。

では、何故このような事態になってしまったのでしょうか?

要件定義の手順ミスの可能性

この訴訟、少々推察にはなってしまうものの、要件定義における手順にミスがあったと思えます。

まず、業務分析の段階において、システム開発の対象となるすべての部分を明示してもらうように促していない可能性があります。

次に、ユーザーが作成した要件定義書であれ、双方においてすべての要件に対して読み合わせと合意を行っていない可能性もあります。

これ、私であれば要件定義書に書かれている内容がすべてであることを明記し、読み合わせ後、合意した旨を責任者・担当者などに押印してもらいます。

(これを行っても解釈の疑義が生じることはあり得ます。)

要は、要件定義書に書かれている以上も以下もないということと、それに対してすべての関係者が合意したという証を残すということです。

もう1つ、ユーザーもベンダーが当然知っているだろうという勝手な思い込みは危険です。

要件定義書から漏れていることがあるならば、それはしっかり指摘をすべきではないでしょうか。

そういった漏れなどを無くすためにも要件定義を行っているわけですから。

ご参考までに。

Exit mobile version