PMBOK®第7版の「価値」とビジネスアナリシス（2）
前回のコラムでお伝えしたのですが、PMBOK第7版ではプロジェクトマネジャーが価値にまで責任を持つべきと書いてありますが、価値の多くはプロジェクト終結後に発生するので、その価値にプロジェクトマネジャーが責任を持つのはなかなか難しいことではないでしょうか。
さらに終結後の価値を評価する方法（もしくはプロセス）には何も触れられていませんね。PMBOKですからプロジェクト終結後のことが記述されないことは仕方ないですね。さらにこれではプロジェクトマネジャーが価値に責任をもつことは到底無理と言わざるを得ないのではないでしょうか。
一方、ビジネスアナリシス知識体系（BABOK）では、プロジェクト終結後の実現価値を明確にし、不測（価値の実現がされていない）場合の対処方法までしっかりと記述されているので紹介したいと思います。
BABOKガイドの「ソリューション評価」という知識エリアがそれに該当します。
こと知識エリアには次の5つのタスクがあります。
- ソリューションパフォーマンスを測定する
- パフォーマンス測定結果を分析する
- ソリューションによる限界を評価する
- エンタープライズによる限界を評価する
- ソリューションの価値を向上するためのアクションを推奨する
5つのタスクを順番に解説します。
1. タスク「ソリューションのパフォーマンスを測定する」
まず、測定項目を決める必要があります。
ビジネス・ゴール、目標、ビジネス・プロセスなどから測定項目を作成します。
意外と日本でなじみが薄いのがビジネス・プロセスのパフォーマンス目標です。BPMなどを利用してビジネスプロセスの改善が叫ばれていますが、ワークフローの順番などの改善が主でプロセスを計測しているのをあまり聞いたことがありません。ビジネスプロセスを改善するのにプロセスのパフォーマンス（実行時間やTATなど）を測定することが必須なのです。
有名な格言に「測定できないと改善できない（If you can’t measure it, you can’t improve it）」がありますが、日本の多くの企業ではDX（デジタルトランスフォーメーション）はまだまだ先の話のようです。
サンプルサイズ、頻度、鮮度などを考慮しながら測定結果を収集します。（詳細は省略）
アウトプットの測定結果は次の「パフォーマンス測定結果を分析する」タスクに渡されるのみならず「現状を分析する」タスク（知識エリア：戦略アナリシス）にも渡されることがあります。
これは、現行のソリューションの欠陥改修などのスモールプロジェクトの最初のインプットとして使われる場合、また作成したソリューションのパフォーマンスが期待を満たしていないためさらなる追加作業が必要な場合にも使われます。
2. タスク「パフォーマンス測定結果を分析する」
パフォーマンス測定結果がそのままソリューションの価値に関する決定につながることはめったにありませんので、測定結果の意味するところを解釈（データ分析）することが重要です。
ソリューションのパフォーマンスの良し悪しと価値の大小は直接関係しないものです。
この時、測定結果を知識エリア「戦略アナリシス」で作成された「潜在価値」をレファレンスとしてと比較します。
潜在価値に見合うパフォーマンスが出ていれば良いのですが、そうでなければ．．．、次のふたつのタスクでそれを評価します。少しお待ちください。
そのために得られた測定結果（データ）をもとに潜在価値と比較します。単純な場合はQ C７つ道具のヒストグラム、管理図、散布図程度でも結構です。複雑になれば、必要に応じて傾向分析、回帰分析（最小二乗回帰）などのデータ分析も行ないます。そのためには測定結果が正確で信頼できるものでなければいけません（当たり前ですが）。
アウトプットの分析結果をソリューションの立場とソリューション以外（主にエンタープライズ側）の2つの視点で評価します。それが次の２つのタスクです。
3. タスク「ソリューションによる限界を評価する」
手短に言えば（ITシステムの場合）欠陥のアセスメントそのものです。欠陥数（1000ライン当たりまたはファンクションポイントあたり）、欠陥の深刻度、再発可能性等です。そしてビジネスへの影響も評価します。修正が必要か、ワークアラウンドで回避できるのか、許容範囲なのかを判断します。
この結果（タスクのアウトプット）は「ソリューションのパフォーマンスを測定する」タスクのアウトプット同様に「現状を分析する」タスク（知識エリア：戦略アナリシス）にも渡されることがあります。
このタスクはプロジェクト（出荷前）に行うテスト担当者の作業ではなく、主に運用時にビジネスアナリストが行います。運用時の場合、プロジェクトマネジャー同様にテスト担当者（プロジェクトメンバー）も解散していません。
4. タスク「エンタープライズによる限界を評価する」
このタスクでは、ソリューション以外の問題をアセスメントします。
インプットに「現状の記述」があることが重要です。そしてこの現状は「戦略アナリシス」で宣言しているように「チェンジの開発および実装が行われている間、エンタープライズの現状が変わらずにいることはほとんどない」つまりプロジェクト開始時点ではなく、運用時での「現状」なのです。この変化の激しい状況では数カ月前に記述した「（旧い）現状」はほとんど意味がありません。ソリューションを評価する時点での「現状」がインプットとなります。
この知識エリアで最も重要なことはプロジェクト開始時点で定めたビジネス価値を単純に実現しているのかを求めるのではなく、外部・内部環境が変化してしまっている状況においてもビジネス価値を確保するための仕組みになっているということです。
的（マト）に狙いを定めて砲弾をうち、単純にどれだけ的の中心に当たるのかを競うのではなく、的そのものが動いているのです。その動く標的を追尾しながら標的に当てることです。
すなわち、単純な大砲ではなく、最新鋭の（追尾機能を備えた）ミサイルのようなものです。
ですからこのタスクのアウトプットも「現状を分析する」タスクにも使われます。
このタスクは次の様なことを行います。
- 組織文化のアセスメント：人がエンゲージされているのか、組織文化がチェンジを受け入れられる状態なのか
- 組織構造（公式、非公式）がチェンジに適切なのかのアセスメント
- 運用のアセスメント： 人事管理、スキルとトレーニング、ツールとテクノロジーは適切に配備されているのか
アウトプットの多くは「現状を分析する」タスクへのインプットとなります。
5. タスク「ソリューションの価値を向上させるアクションを推奨する」
このタスクでは推奨案を作成します。
「何もしない」という推奨案もあります。十分に価値が実現されている場合や、チェンジをする労力・コストに比べてチェンジの価値が見合わない場合です。ソリューションに関係するチェンジへの態度、認識、関与をマネジメントするために組織的変革を推奨することもあります。
ソリューションが陳腐化すれば、ソリューションの廃止・リプレースを推奨します。
価値を実現するためには事前に正しくビジネス価値を定義することのみならず、外部・内部環境（現状）が変化する状況においても価値を確保する仕組みになっていることが極めて大切です。
新しいプロジェクトマネジメント知識体系第7版には価値実現が最も重要と謳っていますが、残念ながらプロジェクトは価値を所与の条件として受け入れることでしかなく、それを実現する仕組みがまだ完全ではないようです。価値実現を確実にするためにはビジネスアナリシスの知識体系が補完することになるのではないでしょうか。