皆さん、こんにちは。

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

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

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

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

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

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

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

という判決で、

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

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

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

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

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

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

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

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

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

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

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

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

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

ご参考までに。

要求事項などをヒアリングし、実装すべき機能を明確化していく作業のことを言いますが、

要件定義書はその内容を書面に書き起こしたもののことを言います。

皆さん、こんにちは。

業務コンサルタントの高橋です。

以前、開発ドキュメントを残す重要性という記事を書いたのですが、今回は少し内容を

掘り下げ、開発工程の一番先頭にある要件定義に絞ってお話ししてみたいと思います。

どのようなシステム開発においても、まずはクライアントがどのようなことを行いたいと

思っているのか？を、ヒアリングをしながらまとめていきます。

そして、それをシステム化するにあたって絵とテキスト文字にて表現し、設計段階に

入る前にクライアントと一緒にレビューというものを行います。

これは、クライアントと開発業者の間において、クライアント側としては要望している

ことが満たされているかを点検し、開発業者においてはヒアリングした内容に対する

認識が間違っていないかの点検を行う。

つまり、双方にとって間違いのないものであるかどうかを点検する作業になります。

従って、非常に重要な作業となり、タイトルで書いたとおり開発作業の要とも言えます。

では、これを行わないとどうなるのか？

言った言わないの世界に突入し、なかなか終息しない炎上プロジェクトに陥ります。

これはアジャイル開発でも同じことが言えます。

アジャイル開発は実際のシステムを作りながら確認作業を行っていきますが、

それにおいても双方においてコミットされたものは、後からまとまった段階で

ドキュメントとして残しておくのが一般的です。

この要件定義書を基に設計・製造の工程へ入っていくわけですが、それがしっかり

コミットされたものではない場合、間違った認識の基に設計・製造工程が進んで

しまうことになるため、結果的にトラブルに発展してしまうことになってしまいます。

そういったことにならないよう、この工程はしっかり押さえておくことが肝心です。