PMstyleプロデュース

◆組織を設計するというイメージ

プロジェクト組織を設計するというと何をイメージするでしょうか。たいていの場合、「権限」を決めることです。例えば、プロジェクト体制として以下のようなプロジェクト組織を設計したとします。

Ａ（事業部長）　──　Ｂ（ＰＳ）　──　Ｃ（ＰＭ）　──　Ｄ
　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　 　　─ Ｅ

このときに、ＡやＢとＣには上下関係があると考え、ＡはＢ、Ｃ、Ｄより権限を持つと考えられます。具体的には、Ａ、ＢはＣ以下の行使する予算を承認したり、Ｃ以下に指示できるわけです。

◆まず、設計すべきは「責任」

このように「権限」から考えるのは、プロジェクトには事業部長の持つ権限の一部しか、与えないことが前提になっています。例えば、プロジェクトとして外部の企業とのパートナーシップを組むといった事業部長がもっていない権限をプロジェクトに与えることができないわけです。そして、このことがプロジェクトで取り得るアプローチを限定しています。これが例えばイノベーションプロジェクトの成功が生まれにくい一因になっていると考えられます。

すべきことは体制を決めることではありません。まず、すべきことは責任の設計です。つまり、投資の判断、品質の判断、販売の判断など、プロジェクトで想定されるいくつかの代表的な状況における意思決定の責任を明確にする必要があります。

その上で、責任を果たすための権限を決める必要があります。

しかし上に述べたように、多くの場合、プロジェクト体制から決め、権限を先に決めています。そうすると権限がやたらと増え、政治的な活動の必要性が多くなってきます。極論すれば、すべての意思決定をＡやＢの了解を取らなくてはならなくなります。

プロジェクトの生産性が低い最大の理由はこの点にあるように思えます。

◆プロジェクトの責任はプロジェクトによって異なる

特にプロジェクト組織の場合はこの原則は重要です。一般的な組織であればある程度、業務が決まっており、権限と責任が同期しているので、権限を決めれば責任がついてくるという見方もできます。

ところがプロジェクトの場合、定型業務ではないので責任はさまざまです。プロジェクトごとにしか想定できません。したがって一般的な組織の感覚でプロジェクトをやると先に述べたように、プロジェクトは交渉や根回しなど政治活動の連続になります。

そのため、権限から決めると責任が誰にあるのかわからないケースが出てくることがよくあります。こういう場合、結局、プロジェクトマネジャーが最終責任を取るということで、済ませてしまうわけです。つまり、いわゆる権限のない責任というのが出てくることになります。

最悪なのは、ここで権限委譲をしてしまうことです。つまり、意思決定が出てきた場面に遭遇したときにはじめて権限委譲をするわけです。このように進めると、すべての意思決定が政治的な活動になり、権限を持つ人の顔色を伺わざるを得なくなります。

◆ＯＢＳとＲＡＭを使ったプロジェクト組織の設計をしよう！

最近、プロジェクトマネジメントの中でもステークホルダーマネジメントが注目されるようになってきました。その中で、よく聞く問題の一つにいわゆるプロジェクトスポンサーが責任を明確に認識していないという話があります。ところが観察していると、そのような場合でも権限は行使していることが多いようです。

要するに、プロジェクト組織を設計するときに、権限は組織の権限をそのまま持ち込み、責任はプロジェクトマネジャーにあると考えているケースが多いのが現実です。

プロジェクト組織の設計に関しては、ＯＢＳ（Organization Breakdown Structure ）という素晴らしい組織設計のツールがあり、また、責任の設計のツールとしてＲＡＭ（Responsibility assignment matrix）というツールがあります。これらを駆使して、まず、責任を設計し、責任を果たすための権限の設計をするようにしたいものです。