BABOK®ガイド　V3（パブリックレビュー版）　第5章　要求ライフサイクルマネジメント

2014/06/06

知識エリア【要求ライフサイクルマネジメント】

まずこの知識エリアの概説を引用します。

知識エリア「要求ライフサイクルマネジメント」はビジネスアナリストが、要求とデザインの最初から廃棄までの情報をマネジメントし保守するために行なうタスクについて記述する。これらのタスクは、関連する要求とデザインの意味のある関係を確立し、変更が提案される際に、要求とデザインの変更を評価し、変更についての分析とコンセンサスを得ることを記述する。
知識エリア「要求ライフサイクルマネジメント」の目的は、要求がステークホルダーのニーズに関して適切に、有効に、正確に、共通の理解を表わすことを確実にすることである。要求マネジメントは、要求と、要求が実装されてデリバリーされる実際のソリューションにどのように移行するかに関する管理基準を含む。要求マネジメントはビジネスアナリシス情報が、将来の使用に利用可能であることを確実にすることも支援する。
知識エリア「要求ライフサイクルマネジメント」の至る所で、要求という用語は広い意味で使用され、要求とデザインの両方をカバーするように意図されている。
要求ライフサイクルは:
・要求としてビジネスニーズの表現から始まり、
・ソリューションの開発期間を通じて継続し
・ソリューションおよびそれを表わす要求が廃棄されるときに終了する
一旦ソリューションが実行されても、要求のマネジメントは終了しない。ソリューションのライフサイクル全体にわたって要求は価値を提供し続け、適切に管理される。
知識エリア「要求ライフサイクルマネジメント」内では、ライフサイクルの概念は、ビジネスアナリシス作業を管理するために使用されるメソドロジーもしくはプロセスから分離している。
ライフサイクルは変革の任意の一部として通過する要求の存在と、さまざまなフェーズまたは状態を示す。要求は一度に多数の状態があるかもしれない。状態は、活動を行なう順序を規定するのが目的でもない。

要求には状態があり、発生から消滅までライフサイクル全体にわたって管理する必要があるという、考え方（思想）を理解する必要があります。日本では開発は開発。運用は運用という考えがまだ強く残っているようです。最近やっと、DevOpsという考え方で、開発から運用を一体として管理する必要があることに気が付いたところではないでしょうか。BABOK®では開発の前の要求、そのまた前のニーズの発生から管理するべき、という思想です。

バージョン2でも要求には状態があり、タスクを実行すると、その状態が徐々に変化するという考え方でした。例えば、

要求[確認された]
要求[優先順位の付いた]
要求[検証された]
．．．

すなわち、要求にはライフサイクルがあり、それをマネジメントするという事を暗黙的に示唆していましたが、残念ながら日本でそのことを正しく理解できていた人はあまり多くなかったと思います。ツールもエクセルが中心で、専用の要求管理ツールの普及には程遠いものでした。BABOK®ガイドバージョン3では、要求のみならず、デザイン、ニーズの発生時点から、開発、運用を経てソリューションが廃棄されるまで、適切に管理することをうたっています。そのためには専用の要求管理ツールの活用が不可欠です。

それでは、この知識エリアにおけるバージョン2とバージョン3の関係です。

タスクの変更点です。

「要求に優先順位をつける」タスクがバージョン2の知識エリア「要求アナリシス」から移動してきました。

バージョン2にあった、以下2つのタスクは知識エリア「引き出しとコラボレーション」に移動しました。

・要求パッケージを準備する

・要求を伝達する

[図のクリックで拡大表示]

つづいて、各々のタスクの概要を引用します。

【要求をトレースする】

成果物への変更の影響をマネジメントするために、異なるレベルの詳細さと構成で、要求とデザインの関係を理解する。

【要求を保守する】

エンタープライズのニーズおよびそれらの成果物の実際のインプリメンテーションを反映して、要求とデザインが最新状態にあることを確実にする。必要に応じて、異なる変革イニシアチブを横断し、要求の共有および再使用を支援する。

【要求に優先順序を付ける】

分析および(または)デリバリー作業が、いつも最も重要なものに集中することを確実にするために、関連する要求とデザインの価値、緊急性、リスクをアセスメントする。

【要求変更をアセスメントする】

変革イニシアチブの範囲内で、それらに作用する必要があるかどうか判断するために、新たに変わるステークホルダーのニーズを評価する。

【コンセンサスを得る】

要求とデザインのセットについて承認、合意に達するために、ガバナンスプロセスに関与するステークホルダーと仕事をする。

上記タスクの概説だけでは少しわかりにくいのですが、この知識エリアのコアは「リポジトリ」です。ライフサイクル全体を通して、すべての要求はリポジトリに格納され、その状態が管理されます。左のデータフロー図をご覧ください。

[図のクリックで拡大表示]

このデータフロー図でわかることは、この知識エリアはタスク間の情報のやり取りは全て、下のピンク色の「リポジトリ」を通して行われることです。どのタスクのアウトプットも知識エリア内の他のタスクの直接のインプットにはなっていないことが分かります。また、実行の順序も関係ありません。すなわち、要求のライフサイクルマネジメントを行う中心はリポジトリすなわち要求管理ツールです。

緑色の吹き出しは「ガイドラインとツール」です。ガイドラインはバージョン2ではインプットとして扱われていました。新しいバージョンではインプットはアウトプットに変換されるものだけに絞られて、参照されるだけで変換されないものはガイドラインという位置づけになりました。

「ガイドラインとツール」をよく見ると、「要求管理ツール/リポジトリ」が多く目につきます。前述したように、バージョン2でもそうだったのですが、BABOK®では要求（正確にはビジネスアナリシス情報）のライフサイクルを管理すること、そのための要求管理ツール（または構成管理システムとも言います）の活用を大きく意識しています。この新しいバージョン3ではそれが完全に前面に出てきたという印象です。その象徴が知識エリアのタイトル「要求のライフサイクルマネジメント」です。日本でもツールの活用を促進しなければいけません。

知識エリア【要求のライフサイクルマネジメント】におけるBAコアコンセプトモデル

コア・コンセプト	「要求のライフサイクルマネジメント」においてビジネスアナリストは；
変革（Change）：組織的に制御された変革（トランスフォーメーション）	意図したビジネスニーズに変革が最適に対処することを確実にするために、実装期間に変革に関係する要求とデザインを調整する。
ニーズ：ステークホルダーにとって潜在的価値のある問題、機会、または制約	ニーズが実装される変革によって満たされるように、既存の要求とデザインを現在のビジネス・ニーズと比較する。
ソリューション：コンテキストにおいてニーズを満たす具体的な方法	根本的なニーズについて明瞭に理解し、そしてニーズを満たすために理想的なソリューションの構想を描くことができるように、ステークホルダーを管理する。
価値：コンテキストにおいてステークホルダーにとって重要なもの	ステークホルダーがニーズとそれを解決するソリューションを理解し合意できるようにし、組織が価値を実現するのを支援する。
ステークホルダー：変革又はソリューションと関係を持つグループまたは個人	実装されるすべての要求とデザインについて理解、合意および承認を維持するために、重要なステークホルダーと一緒に仕事をする。
コンテキスト：環境のなかで変革を包含する部分	実装された要求とデザインが、ビジネス・ステークホルダーの目標としたニーズに整合するように、コンテキストを理解する。