要件定義で危険な要件とは

要件定義で出してはいけない要件は、前回と同じ現行踏襲です。

このように考えるのも以前のシステム開発のプロジェクトでこのような要件をユーザから出されたことがありました。ただ、当然のことながら後々の工程でユーザとの間で意思疎通が図れずにかなり問題になったことがあります。

今回の記事ではなぜこの要件でユーザと意思疎通が図れなかったのか、そしてどうすれば良かったのかを記載していきます。

ユーザともめた原因

要件を決める際によくあることとして、前回と同じように対応してくれればよいです、といったことを言われることがあります。

パッと聞いた感じだと、「あっ、前回と同じでいいんだ。楽でよかった」と思うかもしれません。ただ、これはすごく危険なことです。

というのも、前回と同じ、という内容が関係者すべてのステークホルダーが同じ考えを持っていればよいのですがそんなことはありません。細かいことを詰めていくと必ず違うことを考えているものです。

また、前回行った対応が具体的に何か、ということを覚えていないものです。もしくは覚えている気になっているだけです。

私の以前のプロジェクトでこんなことがありました。

ユーザ:あれ、必要な帳票が出ないんだけど。

私:はい。それは前回の対応の時に帳票を廃止しているからです。要件定義の時にもお伝えしましたが。

ユーザ:えっ、でも部内でその帳票を使う前提で調整しているんだけど何とかならない?後、なんで帳票を廃止したんだっけ?

私:(マジか、ここにきて変更要求?勘弁してくれ)いったん、ご要望としては承りました。実施可否につきまして取り急ぎ調査の上報告いたします。

この後、なんで今更こんな状態になっているんだとか他には同じような漏れは無いのかなど散々に詰められました。

影響調査と並行して前回に行った対応と今回行う対応を全関係者を集めて再度、意識合わせをして問題がこれだけであるということが分かり少し安堵しました。

その後、影響調査の結果も出て簡単な改修(帳票出力のオンとオフの切り替え)で行えるとこが分かったので変更要求のプロセスにのっとり承認を受け各種設計書の変更からテストまで実施して事なきをえました。

これは、ユーザ目線の要件定義の不具合ですが、システム目線でも同じように失敗することがあります。それは、非機能要件、主に性能観点ではないか、と考えます。

システムは日々変化していきます。特にデータ量でしょうか。

以前の対応では性能問題は出なかったものの長年蓄積したデータによってバッチが止まったり画面が重くなって動かなくなったりしたら目も当てられません。

これはシステム側の目線から日々の経済状況などを鑑みて前回と同じ対応、と言われても何か非機能に関する対応をする必要性を考える必要があります。

要件は明確に

以前の記事でもお伝えしましたが、要件定義ではあいまいな表現はなくし明確に書かなくてはなりません。

関連記事

システム開発における要件定義は重要です。 そもそも、どのようなシステムを作るかが明確になっていないと何も作れませんよね。ちゃんとやっているつもりでも、意外と要件定義書の内容があいまいな表現になっていて後の工程で致命的な不具合になりかね[…]

今回のようなケースはユーザ側もシステム側も現行踏襲や以前と同じ対応、というあいまいな要件のまま突き進んでしまった結果でした。

システム側はそう思っていなくてもユーザ側が前回と同じだからいいや、と思ってしまってはダメです。意外と前回の内容をみんな覚えていない、または勘違いをしているケースが多々あります。

そうならないためにも、現行踏襲という要件をよりブレイクダウンし前回にやった内容、それを今回に適用したらどうなるか、本当にそれで良いのかの確認、を行うことが大切です。

そうしていくと、前回にこんなことやったかな、もっとよりよくできるのではないか、といったことになります。要は、意外と過去のことを覚えていないことを分からせること、そして、現在の経済・経営状況を鑑みたらもっと良い方法があるのでは、と気付かせることができます

企業やそれを取り巻く環境、そしてシステムなどは日々進化していくものです。そのため、普通は今までと同じという結論にはならないのではと考えます。

一歩でも前に、たとえ現行踏襲と言われてもしっかりと要件を検討・合意し時代に取り残されないようにしていきたいですね。

 

最新情報をチェックしよう!