コンセプチュアル・マネジメント

◆プロジェクトマネジャーの最重要の役割は「自分の役割を決めること」

プロジェクトマネジャーのもっとも重要な役割は、「自分の役割を決める」ことである。これ以外にはないと言ってもよい。

プロジェクトマネジメントのガバナンス、オーナーシップの議論はあるものの、プロジェクトマネジャーに期待されていることはプロジェクトを成功させることである。そこで、考えるべきことは、そのために自分がどのような役割を果たせばよいかということだ。

こういう発言をするとＰＭＯなど、プロジェクトマネジメントに対して指導的な立場の人から異論を戴くことがある。これも勘違いである。プロジェクトマネジメントのプロセスなり、標準なりを決めることはＰＭＯの役割である。そこで、上に述べたような進捗管理だとか、計画だとかのやるべき仕事が決まる。これはそのとおりだ。

この前提で役割を果たすとは何かということを考えてみると、

その仕事をなんのためにやるか

を決めることに他ならない。

もっともわかりやすいのは計画作業である。非常に「やばい」プロジェクトであれば、プロジェクトマネジャーは自分の役割をリスクの防波堤とするだろう。そうすると、リスクマネジメント計画は単にチェックリスト的な意味合いよりは、もっとつっこんで、防波堤となりうるように、リスク計画だけではなく、そのほかの計画をリスクという観点から体系的に見るために計画を作る。

◆役割を決めるための権限がない

ただ、プロジェクトマネジャーが自らの役割を決める状況はリスクのようにある意味で単純な話だけではない。もっとも重要なのは「戦略上」の役割である。このためには

自分がプロジェクトマネジャーとしてどのような役割を果たせば、このプロジェクトを組織の戦略実行に少しでも役立てることができるか

という視座を持つ必要がある。そして、果たすべき役割を明確にし、その役割を遂行する必要がある。

ところがプロジェクトマネジャーがそのような役割を果たそうとしたときに、十分な権限が与えられていないケースがある。これが次の問題だ。例えば、上でリスクの防波堤の役割を果たすという話をしたが、実はリスクマネジメントというのはプロジェクトだけでは成り立たないケースが少なくない。権限の問題により、コンティジェンシーが作れないのだ。

その典型が人の問題である。

ある商品開発のプロジェクトで、競合の動向によってはプロジェクト開始当初に想定していたスペックが変わる可能性があった。プロジェクトマネジャーはそのことに気がついており、部内の計画レビューでもその議論はしていた。そして、リスク計画にもいれ、その対応として、スペック変更に対応するために必要な技術者をプロジェクトに入れることが承認されていた。スペック変更要求は予期したとおりに起こったが、エンジニアの確保ができず、結果として対応できなかなった。

この問題をどう捉えればよいだろうか？研修ケースとしても使っているのだが、コンティジェンシー計画が問題だという意見が多い。教科書にあるとおり、コンティジェンシー計画の実現性をきちんと検証すべきだというわけだ。

◆権限委譲に対する誤解

著者の見解は少し違う。これは権限委譲の問題である。と回答すると、人事権をプロジェクトマネジャーに委譲するなどとんでもないという議論になる。当然である。人事権を委譲するには仕掛けが必要である。一つの方法はリソースプールの仕組みで、必要な人材をリソースプールに入れておき、プール内の人材は、リソースマネジャーと同等な権限を与えるだけで、権限委譲が進み、コンティジェンシーが実質的なものになってくる。

実は、権限委譲の問題は、プロジェクトマネジメントの中で恐ろしく軽んじられている。そもそも、権限委譲という概念として、上位職の持つ権限をそのまま委譲するようなイメージをしがちだが、こんなことは不可能である。上位職の権限を使って、プロジェクトマネジャーが動けるルールを作るのが権限委譲である。

どのような権限が必要かはプロジェクトマネジャー自身が決める必要があり、それをプロジェクトマネジャーを引き受けるときに交渉するのだ。

そのように考えたときに、プロジェクトマネジャーが自分自身の役割を決めることができるようにしようときに、どのような権限を持っておけばよいはは常に考えておく必要があるといえよう。