第5回： 【トレーサビリティとモニタリング】
続いてのドメイン「トレーサビリティとモニタリング」に対応するのはBABOK V2の知識エリア「要求のマネジメントとコミュニケーション」です。v3では「要求のライフサイクルマネジメント」が最も近い知識エリアになります。
BABOK V2： 「要求のマネジメントとコミュニケーション」
この知識エリアでは要求をマネジメントする次の3つのタスク、
- 4.1 ソリューションスコープと要求をマネジメントする。
- 4.2 要求のトレーサビリティをマネジメントする。
- 4.3 再利用に備えて要求を保守する
そして要求を伝達（コミュニケーション）する次の2つのタスク
- 4.4 要求パッケージを準備する。
- 4.5 要求を伝達する。
があります。
「4.2 要求のトレーサビリティをマネジメントする」タスク
要求のトレーサビリティは、ビジネス要求からステークホルダー要求、ソリューション要求、設計、チームが作成する成果物、そしてソリューションコンポーネントまでを双方向につないでいく作業です。さらに要求同士の関連も明確にします。ですからどんなにステークホルダーが強く主張してもビジネス要求につながらない要求は認められないことがあります。
「4.1ソリューションスコープと要求をマネジメントする」タスク
要求（およびソリューションスコープ）の変更を管理し、最終承認までを扱います。一旦承認された要求はベースライン化できます。その後の変更は変更管理プロセスで管理されます。
「4.3 再利用に備えて要求を保守する」タスク
作成された要求が他のプロジェクトや運用時にも参照できるように保守、管理します。
BABOKでは、上記3つのタスクは主に要求管理ツールを使用することが推奨されています。要求が複雑になると、トレーサビリティを効果的に管理するためにはツールが必要です。
「4.4 要求パッケージを準備する」タスク
RFPやBRDなど要求に関するドキュメントを作成します。「要求パッケージ」はビジネスアナリストが作成するさまざまな要求に関するドキュメントで、典型的なものは次の通りです。
- RFP
- BRD
- プロダクトロードマップ
- 要求仕様書
- ビジョン文書
多くの組織では要求文書用のテンプレートが事前に作成されていますが、これらを総称して「要求パッケージ」と呼びます。BABOKのタスクのうまいところで、例えば、上記異なる5種類のドキュメントを作成するとしても、抽象化したタスクとしては「要求パッケージを準備する」となります（ズルい！かもしれませんね）。
「4.5 要求を伝達する」タスク
これも伝達する要求（や要求パッケージ）の数だけ繰り返される継続的なタスクです。ある時はRFPを伝達し、ある時はBRDを伝達します。少なくとも作成されたパッケージの数だけ実行されます。
つづいてPMIのビジネスアナリシス実務ガイドを見ていきます。
PMI ビジネスアナリシス実務ガイド： 「トレーサビリティとモニタリング」
PMIの「ビジネスアナリシス実務ガイド」のドメイン「トレーサビリティとモニタリング」には次の7つのタスク（もどき）があります。
- 5.2 トレーサビリティ
- 5.3 関連性と依存関係
- 5.4 要求事項の承認
- 5.5 承認済み要求事項のベースライン化
- 5.6 トレーサビリティ・マトリクスを用いて要求事項をモニタリングする
- 5.7 要求事項ライフサイクル
- 5.8 要求事項の変更をマネジメントする
全て要求事項（とプロダクトスコープ）を管理（承認を含めて）することに関するタスクと言えます。
リストを見て気が付きましたが、BABOKの「要求を伝達する」タスクに該当するタスクがありません。この章の概説では「5.6 トレーサビリティ・マトリクスを用いて要求事項をモニタリングする」タスクを通じて要求事項が伝達されることになっているのですが、このタスクの中にはその具体的な記述がありません。作成した要求事項文書は伝達しないのでしょうか。知識体系ではありませんので全てのタスクを網羅する必要はありませんが、少し寂しく感じます。タスクの具体的な内容を見ていきます。
5.2 トレーサビリティ
次の要求事項属性を用いたトレーサビリティ・マトリックスが紹介されています。
- ID
- 要求事項記述
- ビジネスニーズ・好機、ゴール、目標
- プロジェクト目標
- WBS成果物
- プロダクト設計
- プロダクト開発
- テストケース
これはPMBOK第5版のP119に掲載されている図そのものです。要求→設計→開発→テスト と 下流工程にトレースすることに主眼が置かれているようです。PMBOK第5版と整合を取るためにはやむを得ないのかもしれませんが、もっと上流にフォーカスしてもらいたいような気がします。
5.7 要求事項ライフサイクル
要求事項のライフサイクルを次のように管理する例が紹介されています。
- 提案
- 承認済み
- 進行中
- 完了
一つの考え方として有効ですが、BABOKの要求のライフサイクルの考え方とは異なるようですので注意が必要です。BABOK v3の要求のライフサイクルは後述します。
5.8 要求事項の変更をマネジメントする：タスク
次の変更管理ツールが紹介されています。
- コンフィギュレーション・マネジメント・システム（CMS）
- バージョン管理システム（VCS）
BABOKで紹介されている要求管理ツールは要求そのものを管理しますが、PMIのBA実務ガイドが紹介しているものはどちらかというと設計・構築（実装）で役に立つドキュメントの構成や版を管理することに主眼が置かれています。ビジネスアナリシスというより、プロジェクトマネジメント（設計、構築、テストまで含む）の中での作業にフォーカスされています。PMIらしいというか、PMBOKとの整合性を考えているのかもしれませんね。ビジネスアナリシスへの考え方の違いが出ているようです。
PMIのBA実務ガイドの特徴である「協働ポイント」を紹介します。
[協働ポイント]
- 誰がスコープをマネジメントするかについて、プロジェクト・マネジャーとビジネスアナリストの間に、しばしば混乱が生じる。プロジェクト・マネジャーにプロジェクト・スコープをマネジメントする責任があるのに対し、ビジネスアナリストにはプロダクト・スコープをマネジメントする責任がある。要求事項を追跡するプロセスは、ビジネスアナリストがプロダクト・レベルでスコープ・マネジメントに関与する明確な例である。第4章で紹介したいくつかの要求事項の引出しと分析モデルも、ビジネスアナリストがモデリングを行っている間、どのようにプロダクト・スコープを分析するかを示す。
最後にBABOK v3をご覧ください。
BABOK v3： 「要求のライフサイクルマネジメント」
要求のライフサイクルの流れは次のとおりです。
- ビジネス・ニーズを要求として表現するところから始まり
- ソリューションの開発作業の間、ライフサイクルは続き
- ソリューションとそれを表現する要求が廃棄された時点で終了します
ソリューションが実装されたからといって、要求の管理が終わるわけではありません。
ソリューションが存続している間ずっと、要求は価値を提供し続けますから、要求を適切に管理する必要があるのです。今はやりのDevOpsと共通の考え方と理解してください。
これが、新しいビジネスアナリシスの要求のライフサイクルの考え方です。PMIのBA実務ガイドの考え方とは異なりますので注意しましょう。
この知識エリアの特徴は左図でわかるように、全てのタスクのインプットとアウトプットが要求管理ツール/リポジトリとのやり取りをすることです。BABOKではこの知識エリアでもツールの使用を重視しています。ツールの使用を前提とした知識エリアと言えます。
次の5つのタスクがあります。
- 5.1 要求をトレースする
- 5.2 要求を維持する
- 5.3 要求に優先順位を付ける
- 5.4 要求変更を評価する
- 5.5 要求を承認する
5.1 「要求をトレースする」 タスク
BABOK V2の「要求のトレーサビリティをマネジメントする」タスクと同じ内容です。左図で、右側のデザイン、コード、テストではなく「ビジネス・ニーズ」↔「ビジネス要求」↔「ステークホルダー要求」↔「ソリューション要求」を結びつけることに主眼を置いています。このBABOK v3の解説の図が PMIのBA実務ガイド と BABOK v3の トレーサビリティの考え方の違いをよく表しています。
「5.2 要求を維持する」タスク：
要求の属性を管理しますが、「ビジネスアナリシス情報マネジメントを計画する」タスクで、どの属性を使って管理するのかを決めて、それを要求管理ツールに登録しておけば、あとはツールが支援してくれるので属性の管理も大幅に手が省けます。
要求の再利用も同様ですが、要求管理ツールの仕様（機能）に大きく依存します。あるツールは特定プロジェクト内での要求を管理することだけを支援してくれます。別のツールはエンタープライズ全体で要求をシェアすることまでサポートするものもあります。そのようなツールを使用すれば、他のプロジェクトから当該プロジェクトで作成した要求を再利用することも容易に支援してくれます。また、開発フェーズを越えて、運用フェーズにおいても、開発フェーズで開発された要求をそのまま使用することも可能になります。ですからツールの仕様に大きく依存します。
「5.3 要求に優先順位を付ける」タスク：
要求に優先順位を付けます。優先順位の高いものから実装されますから、ビジネス価値をベースに決めることが多いです。
「5.4 要求変更を評価する」タスク：
要求やデザインに対して提案された変更を評価します。
このタスクは、新しいニーズが生じたり、可能性のあるソリューションが新たに明らかになったりしたときに実行します。
「5.5 要求を承認する」タスク：
ビジネスアナリシス作業を継続したり、ソリューションの構築を進めるために、要求とデザインについて合意と承認を得ることです。
予測型アプローチでは一般に、承認はフェーズの最後か、定期的に行われる変更管理会議の中で行います。適応型アプローチの場合は、要求を満たすソリューションの構築と実装を開始できるようになったときにのみ行います。