プロジェクトマネジメントフレームワーク５

プロジェクトマネジメント・ビジネス文書

意味のあるプロジェクトかどうか、それを判断するための文章というものがあります。いわばプロジェクトの存在意義です。

プロジェクト・ビジネス・ケース
プロジェクト・ベネフィット・マネジメント計画書

プロジェクト・ビジネスケースは、通常プロジェクトのスポンサーが作成するもので、内容に関する責任もスポンサー側にあります。プロジェクトマネージャーは、それに合うように、プロジェクトマネジメント計画書、プロジェクト憲章、プロジェクト・ベネフィット・マネジメント計画書の整合性をとっていくことが必要になります。ここは、プロジェクトと、それを依頼する側（プロジェクトのメリットを受け取る側）との接点になる部分で、非常に重要なところになります。ベネフィットという言葉からわかるように、プロジェクト・ビジネスケース、プロジェクト・ベネフィット・マネジメント計画書は、プログラムマネジメント側で作成される場合もあります。

プロジェクト・ビジネス・ケース

この文書を作成することで、プロジェクトを実施するメリットと、それを受け取る側が本当に欲しいものの橋渡しをすることができます。プロジェクト・ビジネス・ケースをもとに、このプロジェクトを実施する意味があるかを判断します。ここからはビジネスの話ですので、評価尺度にお金が出てきます。メリット、それを行うのにかかるコスト、それらをお金に換算して比較検討するわけです。ここを検討することで、今やっていることが本当に意味があるかを判断することができるということで、この文書が地図のような役割を果たすとも言えます。プロジェクト・ビジネス・ケースには以下のような事柄が記載されます。

プロジェクトの目標(定量的な)評価基準
ニーズ評価の結果（組織の目標と課題、チャンスなどから検討）

具体的には以下のような事柄です。

今何が問題か/もしくは何が目標か
それゆえに何をするのか
それはなぜか（真の原因や今のチャンスは何か）
それをすることでどういう関係者に影響があるのか
どこまでの範囲で対応するのか
それをするのに必要な能力と、至らない部分
わかっている危険性
何をよしとするのか

それぞれに、必須、望ましい、任意　といったレベルを記載して状況を分析します。とるべき行動としては以下の選択肢が考えられます。

何もしない
最小限の対応をする
最小限以上の対応をする

当たり前のことを書いているようですが、こだわるべき部分をものすごくシンプルにしたもので、それゆえに何が重要かがわかりやすくなる選択肢です。通常やるか、やらないか。というのは選択肢として生じるのは当たり前ですが、ここに最小限の対応をするというのが入ることがミソで、これが一番おいしいところとも言えます。なんでもやればやるだけ良いのですが、どんどんうまみはなくなって、大変さが目立ってきます。最小限の力で最大限の対応をする、それが真ん中にある最小限の対応をするということです。

プロジェクト・ベネフィット・マネジメント計画書

プロジェクト・ビジネス・ケースで、このプロジェクトを行う意味を、目標や課題からやるべきこと、やる意味があることへと落とし込まれたら、こんどはそれが、どのタイミングでメリットとしてあらわれるのか、またどのようにそれを測るのかということを考えるのが、プロジェクト・ベネフィット・マネジメント計画書です。ここまでやれている会社があれば本当に見事だと思いますが、さらに手厚く、ベネフィットを確実にするため、もしくはベネフィットが得られなかった場合の原因をはっきりさせるため次のことも行うことができます。まずはこの利益（ベネフィット）を監視、記録し、結果どうだったかを報告するベネフィット・オーナーを決めます。重要な役目です。また、ベネフィットがどういうときに意味を成すか、逆にどういう状態になるとベネフィットが得られないかを明確にする、前提条件、ベネフィットを無効にしたりマイナスにしたりしかねない、リスクについても、プロジェクト・ベネフィット・マネジメント計画書では記載します。まとめると次の項目になります。

目標ベネフィット
戦略との整合性
ベネフィット・オーナー（ベネフィットを監視、記録、報告）
前提条件
リスク

プロジェクト憲章とプロジェクトマネジメント計画書

プロジェクト・ビジネス・ケース、およびベネフィット・マネジメント計画書により、やるべきことや範囲と、それがいつどのくらいの量で還元されるか、その計画を作成でき、このプロジェクトにやる価値というお墨付きがでれば、それをやらない理由はありません。必要な人に必要な権限を渡して成功裏に、思惑通りにベネフィットを受け取りたいものです。そこで、スポンサーがプロジェクトの存在を正式に認可し、組織の資源をプロジェクト活動のために使用する権限を、プロジェクトマネージャーに与える文書のことを、プロジェクト憲章といいます。任命されたプロジェクトマネージャーは、プロジェクトマネジメント計画書を作成して、プロジェクトを実行、監視、コントロールする方法をそこに記載します。

プロジェクトの成功とは何か

プロジェクトの中にこもってしまえば、最初に決めた要件をコントロールして成果物として作成作成できること、それらが予算内、予定期間であれば成功という言い方はできると思います。しかし、ポートフォリオマネジメントやプログラムマネジメントの視点にたつと、もしかすると今更それができても意味がないかもしれません。出来上がった品質は、実はそもそも思っていたものからゆがんで小さくなっているかもしれません。そういったところまで評価できて、プロジェクトは成功と呼ぶ、というのが本当にプロジェクトに求められている成功ということは、実務者として、少なくとも頭の片隅には残しておきたいものです。

現実世界とのすり合わせ（個人的に観測できる範囲の話）

ここからは、今までにできた、非常に体系的で、かっちりとした考え方に対して、現実に会社の中ではどのようにやっているのか、ありていに言えばつじつまを合わせているのか、自分の観測できる範囲での感想を書いてみようと思います。プロジェクト・ビジネス・ケースですが、これは会社の中でいうと稟議というものになると思います。ある課題を感じた人（担当者なり課長や部長、役員や社長）がこれを解決するにはどうしたらよいか検討して、こういうやり方でやればいくらで、どれくらいの期間で、どういう変革ができるかというのを考えて、各所と調整をとって、最終的に予算と期間、得られる成果を決めます。このときに自分の会社ではできないところは、他社に発注するので外にお金を払う必要があり、この支払の合意をとる作業を稟議を通すといいます。これが通ったうえで実行しているプロジェクトであれば、すでにプロジェクト・ビジネス・ケースはできている状態かと思います。ベネフィット・マネジメント・計画書ですが、これも稟議の、効果の部分に書かれることになると思いますが、ここに出てくるような、ベネフィットオーナーを決めて、定量的に観測まで行い、予算を使った結果の評価を正しく組織にフィードバックできているところは、非常に少ないと思います。多くの会社ではやって終わりなんではないでしょうか。もしそこをしっかりしている会社にいるとしたら、それはとても恵まれていることだと思います。プロジェクト憲章は、外部の会社にプロジェクトの実施を依頼する場合は契約書にかかれる内容になると思います。プロジェクトを実行するためにどういった権限が必要で、どれくらいの協力が必要か、といったところが契約書に書かれているケースはあると思います。社内プロジェクトの場合は、ここまでかっちりとやらずに、ケースバイケースで、上司が指示や横の連携を使って、プロジェクトが回るように調整をするのが一般的ではないでしょうか。最後にプロジェクト・マネジメント計画書については、これは基本的にはPMとなった人が頑張って作るものになってくると思います。