最新のPMBOK（R）第5版を入手しましたので、プロジェクトマネジメントを実行する上でビジネスアナリシス/BABOKとの組み合わせ方法に関して、解説します。PMBOK第5版の中からビジネスアナリシスに関係する下記の3つの重要な知識エリアを取り上げます。
- プロジェクト・スコープ・マネジメント
- プロジェクト・タイム・マネジメント
- プロジェクト・コミュニケーション・マネジメント
まず、最初のプロジェクト・スコープ・マネジメントを見ます。
知識エリア： 5．プロジェクト・スコープ・マネジメント：
「5.1 スコープ・マネジメント・計画」（プロセス）は、プロジェクト・スコープを定義し、妥当性を確認し、コントロールする方法を文書化するのですが、そのアウトプットの一つに、「要求事項マネジメント計画書」があります。その構成要素として、下記5点があげられています。
- 要求事項に関する活動の計画、追跡、および報告の方法
- コンフィギュレーション・マネジメントの活動。
- 要求事項の優先順位づけプロセス
- プロダクトの評価基準およびそれを使用する理由
- トレーサビリティ構造。どの要求事項の属性がトレーサビリティ・マトリクスに取り組まれるかを反映する。
このアウトプット「要求事項マネジメント計画書」は第4版から登場したのですが、大変わかりにくいアウトプットです。しかも第4版ではなんと「5.1要求事項収集計画」プロセスのアウトプットとなっていましたのでなおさらです。おそらくPMP資格保持者で正しく理解されている方は少ないのではないでしょうか。 なぜそんなに難しいのでしょうか。理由は簡単です。計画の対象となる実行系のプロセスがPMBOKのスコープ外（PMBOKには何も記述されていません）だからです。
これは、PMBOKの歴史上共通認識ですが、プロジェクトのプロセスには通常次の2つのカテゴリーがあります（PMBOKの第3章を参照）。
- プロジェクト・マネジメント・プロセス
- プロダクト指向プロセス：プロジェクトのプロダクトの仕様を決め、具現化する
PMBOKは最初のプロジェクト・マネジメント・プロセスのみを扱っていて、残りのプロダクト指向プロセスは何も触れていません。そして「要求事項マネジメント計画書」の構成要素がプロダクト指向プロセスを対象としているからです。例えば、コンフィギュレーション・マネジメントの対象はプロダクトのコンフィギュレーション・マネジメントですし、「要求事項の優先順位づけプロセス」もプロダクトの要求事項の優先順位だからです。ですからPMBOKだけを見ていてもそのアウトプットの意味するところが分からないのは当然なのです。
つづいて、ビジネスアナリシスの知識体系BABOKで該当するタスクを見てみましょう。
BABOKの知識エリア「ビジネスアナリシスの計画とモニタリング」の「2.5要求マネジメントプロセスを計画する」タスクとそのアウトプット「要求マネジメント計画」です。
アウトプットの「要求マネジメント計画」の構成要素は下記の4点です。
- トレーサビリティの構造化アプローチ
- 要求属性の定義
- 要求の優先順位づけプロセス
- 要求変更プロセス
[図のクリックで拡大表示]
殆どPMBOKの「要求事項マネジメント計画」と同じですが、上記4つの構成要素が各々次の実行系タスクのインプットになります。
- 4.2要求のトレーサビリティをマネジメントする
- 3.2引き出しのアクティビティを主導する
- 6.1要求に優先順位を付ける
- 4.1ソリューションスコープと要求をマネジメントする
このように、計画するタスクに対して実行系のタスクが存在し対応しているので何を計画するのかがわかります。つまり、BABOKはプロダクト指向のプロセス（タスク）だから実行系タスクが存在します。プロジェクトマネジメントの場合は計画プロセスに対して実行系プロセスがプロダクト指向プロセスになるとPMBOKには何も記載されていませんから、訳が分からなくなってしまいます。
それに対して、ビジネスアナリシスのBABOKでは計画タスク（プロセス）に対して実行系タスクがしっかり対応しているので安心です。ところで、一つの計画タスクに対して4つの実行系タスクが対応しているのはそれだけでも複雑です。できることなら計画タスクと実行系タスクが1対1に対応しているともっとすっきりすると思いませんか。BABOKの中でもわかりにくいタスクの一つです。実は、これも意外な理由があります。それは最近のソフトウェア開発環境のツールとの密接な関係です。特に要求マネジメントツール（RMツール）との関係が重要です。
BABOKでは要求は各タスクを実行すると、その状態が変化するという考え方をします。例えば、「6.1要求に優先順位を付ける」タスクを実行したアウトプットは要求[優先順位付き]です。「6.5要求を検証する」タスクのアウトプットは要求[検証済み]です。約10種類の状態がBABOKでは定義されています。別の言い方をすると要求はその状態が変化する、すなわちライフサイクルがありそれを管理する必要があるといことです。ではどのように10種類にも及ぶ要求の状態を管理すればよいのでしょうか。もはやエクセルで管理できるレベルではありません。それを可能にするのが最近台頭しつつあるRM（要求管理）ツールです。特に北米ではRMツールの使用がすでにポピュラーになっています。
RMツールの例です。要求の状態が[表明された][確認された]などがあるのがわかると思います。また、上段には要求の属性として、「優先度」「リスク」「難易度」「安定度」などが表示されています。このように、要求の状態や、属性の捕捉状況を管理して表示してくれますから便利です。
[図のクリックで拡大表示]
同じRMツールで、トレーサビリティを表示している例です。左の列が「ステークホルダー要求」で、上のリストが「ソリューション要求」の例です。緑の矢印が2つの要求間のリンクを表しています。赤い表示はステークホルダー要求に対して対応するソリューション要求が何もリンクされていないことを示してくれて大変便利です。
[図のクリックで拡大表示]
「2.5要求マネジメントプロセスを計画する」タスクはこのRMツールと密接な関係があります。アウトプットの「要求マネジメント計画」はこのRMツールの設定にそのまま使えます。例えば、当該プロジェクトで管理する要求の属性を決めれば、このRMツールに入力します。要求の引き出し活動ではその属性を捕捉しながら、RMツールに属性情報を入力します。要求プロセスで要求の状態の変化（ライフサイクル）もRMツールが自動的に管理してくれます。また、トレーサビリティも決めたやり方でRMツールを設定すれば、自動的にトレースを管理してくれ、リンクされない（トレースされない）要求を一目瞭然に表示してくれます。そうです、このタスクはRMツールのためにあるタスクだといえます。そう思うと大変便利なタスクです。
BABOKもPMBOKもRMツールを表面には何も出していませんので、一見大変わかりにくいタスク（プロセス）ですが、最近のRMツールのためにあると思えばよいのです。