2010年7月26日

　「要求の妥当性確認」とは何でしょうか。これも耳慣れない読者が多いのではないでしょうか。ソリューションやシステム/ソフトウェアの「妥当性確認」は良く聞きますけれどね。

　BABOK(R)以外の知識体系では明確に定義していませんので、耳慣れないのも仕方ありありません。

定義を見てみましょう。

「要求を妥当性確認する」：

ステークホルダ要求、ソリューション要求、移行要求がビジネス要求（ビジネスケース）に整合することを確実にすること。

このタスクへのインプットを見るとお分かりになると思います。

インプット：　「ビジネスケース」

　　　　　　　　　「ステークホルダ要求[検証された]」

　　　　　　　　　「ソリューション要求[検証された]」

　　　　　　　　　「移行要求[検証された]」

BABOK(R)を特徴づける典型的なタスクの一つです。

全ての要求はビジネスケースに貢献しなければいけません。言い換えると、ビジネス要求に貢献しないものは、要求としての妥当性が認められないのです。インプットのビジネスケースを用いて、個別の要求がビジネス価値を提供するかどうかをアセスメントすることができます。

ユーザー要求（ステークホルダ要求）は得てして膨れあがる傾向にあります。それがスコープクリープにつながることは多くの読者も経験されていることと思います。

上の図をご覧ください。少し古いデータですが今でも本質は変わりません。システム機能の約45%は全く利用されていないというものです。どうしてこのようなことが起きるのでしょうか。スコープクリープの結果のように思われますが、いかがでしょうか。折角の投資の約半分が使われていません。大変もったいないことだと思います。

｢要求を妥当性確認する｣タスクを実行さえしていればこのような事態が防げるのではないでしょうか。この「要求を妥当性確認する」タスクはスコープクリープを防ぐ決定打となりえるのです。

これにより、ビジネスに直結するソリューションの実現に大きく貢献します。

BABOK(R)の極めて明快なメッセージと言えます。

BABOK(R)以外の知識体系では、この「要求を妥当性確認する」タスクが明確にありません。

以下の図をご覧ください。BABOK(R)以外の知識体系（SWEBOK、CMMI、共通フレーム2007）との比較です。

上記は筆者の現時点（2010年6月）での調査結果です。

なぜBABOK(R)だけ、この「要求を妥当性確認する」タスクが明確にあるのでしょうか。

理由は、ビジネスアナリスト自身が「ビジネスニーズを定義」し、「ビジネスケースを定義」しているからに他ありません。他の知識体系は残念ながら、ビジネス要求にまで踏み込んでいないので、BABOK(R)ほど明確な「要求の妥当性確認」は不可能です。例えば、CMMIは要求が「ステークホルダ要求」に整合していることで、「要求の妥当正確認」を定義しています。ですから「ステークホルダ要求」の妥当性確認は不可能です。

SWEBOK（ソフトウェアエンジニアリング知識体系）では、ビジネス要求そのものが存在しません。考えてみれば「ソフトウェア工学」的なアプローチです。ビジネスとはあまり縁がないということでしょうか。

要求定義フェーズ（ウォーターフォールモデル）におけるBABOK(R)の各タスクの実施タイミングの例です。必ずしもこの図が正解と言うわけではありません。各組織の開発プロセスによってはもっと各タスクを頻繁に実施する方がよいかもしれません。知識エリア「引き出し」の各タスクはまとめて省略してあります。ステークホルダ毎にもっときめ細かく決めるべきものですが、概念的にご理解いただければ幸いです。

アジャイル開発では大幅に異なる実施タイミングになります。