【補助線】プロジェクトにおける例外管理
◆例外管理は基本中の基本
当たり前すぎて、今ではあまり語られることのなくなってきたマネジメントの原則に「例外管理（Manegement By Exception）」という原則がある。
金井 壽宏、岸良 裕司「過剰管理の処方箋 自然にみんながやる気!になる」、かんき出版（2009）
では、
=====
組織には、それまでの経験から、マニュアルや標準業務手順などの形で知識が蓄積されている。管理者はそれをうまく活用して人を動かす。マニュアルは曖昧さがないほど望ましいとされ、それを管理者は部下に渡しておく。「あとは任せた」でいければ、うまくいっている証拠で、管理者は介入しない。うまくいかないとき、つまり、マニュアルに書いていない例外的事象が起きたときだけは、管理者は「俺の指示を聞け」という。
=====
と説明されている。この本では、さらに、最近では例外が多すぎたり、また、例外に対して、経験が常に役立つとは限らない時代になってきたので、例外管理という考え方は現実的ではなくなり、経営学の教科書にすら、あまり出てこなくなった、でも、イロハのイとして、意識しておくべきことだと指摘されている。
◆例外とは何か
これについては指摘の通りだと思うが、ここで、考えたいのは、
プロジェクトにとって例外というのは何か？
という問題である。
まず、そもそもも、例外というのは何を意味しているのかを考えてみよう。金井・岸良の説明の中に出てくる、「マニュアル」や「標準業務手順」には、業務プロセスだけではなく、その業務を行うための権限や、判断能力が含まれている（明示的に、あるいは、前提として）。つまり、業務内容によって範囲のばらつきはあるが、例外とはマニュアルや業務手順で決められている、あるいは前提にされている権限や能力では部下に対応できないことを言っていると考えてよい。
このような観点から例外管理というのをマニュアルやルールにこだわらないで再定義してみると、
管理者が部下を管理するに当たって、部下の権限や判断で対応できることは部下に任せて介入しない。部下の権限や判断では処理できないようなこと、すなわち例外的なことが起こった場合だけ対処していく管理方法
ということになる。
プロセスの例外か、権限の例外かという話はプロジェクトの例外管理問題を考える上では極めて重要である。
プロジェクト業務では、通常マニュアル化されたプロセス（オペレーション）は存在しない。これが基本であり、だからプロジェクトとして業務を行う。
言葉を変えると、プロジェクトは非定型業務である。従って、マニュアルや標準的なオペレーションという概念そのものが存在しない。例外だけで構成されている業務だということもできるかもしれない。
◆プロジェクトの例外とは
この議論の落とし穴は、そもそも、オペレーションが固定的なものだという前提にある。プロジェクトのオペレーションは計画で規定されるものである。計画として規定され、それが組織により承認される。承認されていない作業や意志決定をしなくてはならない状況が発生すれば、それは例外が発生したということになる。
問題は、計画とは何かである。実際に想定されるいくつかのケースを考えてみよう。
仮に、計画をプロジェクト作業計画（実施計画）だと考え、その中には例えば、作業スケジュール計画とコスト計画が含まれているとする。すると、スケジュールが１日変わったら、例外発生ということになる。
仮に、プロジェクトマネジメント計画（基本計画）だと考え、例えば、マネジメントの方針と、ＷＢＳとマイルストーンか大工程、リスク計画、コミュニケーション計画が含まれているとする。すなわち、具体的な作業スケジュールなどは実施計画に含まれているという想定だ。この場合には、スケジュールに関しては、マイルストーンを変えざるを得ない状況が発生すれば例外発生であるが、実施計画のスケジュールの変動はプロジェクトマネジメント計画に影響がなければ例外発生とは言えない。
プロジェクトでどの計画を基準にして例外を考えるかは一律には決まらない。ここに権限委譲の問題が絡んでくる。例外の基準は組織がどの計画までを承認しているかによる。
本当の意味でプロジェクトに権限委譲するというのは、プロジェクト憲章で、目的、制約を与え、あとは全部任せることである。この場合は、プロジェクトマネジメント計画で決めていることを変えても例外発生とはならない。
プロジェクトマネジメント計画が承認の対象であれば、プロジェクト作業計画はプロジェクトマネジメント計画が変わらない限り、自由に動かすことができる。つまり、スケジュールなど作業計画の変動は例外とは言えない。
プロジェクト作業計画までが承認の対象であれば、スケジュールを変えると例外になる。
◆承認レベルをどのように決めるのか
このように考えていくと、どのようにして承認レベルが決まっているかという問題に行き着く。この問題は、その組織がプロジェクトマネジメントをどのような考えで行うか依存する。いわゆる「プロジェクトマネジメントポリシー」である。
ポイントになるのは目標と手段の関係である。上のように整理すると、承認されている計画が目標になり、それを承認されていない計画を手段として使って目標達成を目指す。
仮に、作業計画までを承認の範囲にすると、それを達成するための手段は個人の段取りしかないことになる。メンバーのパフォーマンスが低い場合には、一定の底上げの効果があるので適した方法である。一方で、例外発生は恐ろしく増えることが予想されるので、プロジェクトマネジャーや組織マネジャーは例外管理に追われることになる。
仮に、プロジェクトマネジメント計画までを承認の対象にすると、それを達成するための手段としては、作業計画と個人の段取りが使える。少なくとも、作業計画を承認する場合よりは自由度が大きく、個人としてもチームとしても高いパフォーマンスが実現できる可能性がある。
仮にプロジェクト憲章だけで運用すると、プロジェクトマネジャーの能力が高い場合にはパフォーマンスが極めて高くなるが、そうでないと目も当てられないような状況にならないとも限らない。
◆ダイナミックスケジューリングが一般的
このようなトレードオフの中で、どこに承認レベルを置くかが問題になる。結論からいえば、プロジェクトマネジメント計画までを承認範囲とし、作業計画と段取りを目標達成の手段とするという考え方がパフォーマンス上、最適だと考える人が多く、ダイナミックスケジューリングと呼ばれる手法として定着している。
これだと、プロジェクトマネジメント計画で定められるプロジェクトの目標や管理計画が変わる場合にのみ、例外と見なし、上位管理者が介入してくることになる。
◆リスク計画をどのように位置づけるか
ここにもう一つ考えるべきポイントがある。リスクである。プロジェクト目標が変わったらすぐに例外と見なし、介入の対象になるかというとそうではない。また、先に、プロジェクト作業を定型化して、マニュアル管理しようとするケースについて述べたが、この際も実際に定型性が崩れる場合に直ちに介入するかというとそうではない。
その変更がリスクとして計画されているかどうかによって話が変ってくる。リスクとして計画されていない場合には、例外である。しかし、リスクとして想定されているならば、それは例外とはいえず、計画内のことだとして、承認対象になっている計画を変更して進めることができる。
ここに多くの組織は変更管理を絡めて、承認を必要だとしているが、論理的には承認されたリスク対応策によって、計画（目標）を変更する場合には、事後でもいいので報告は必要だが、事前の変更承認を行う必要はない。任せるというのはそういうことだ。
ところが、ガバナンスのルールは、組織が「安心」を得たいために混乱しているケースが多い。これが「過剰管理」である。過剰管理に対しては、このように例外管理を適用することによって、プロジェクトは管理上の矛盾なく、整理できる。
ガバナンスに混乱があると自覚しているプロジェクトマネジャーは、プロジェクトスポンサーやプロジェクトマネジャーとこのような整理をしてみるといいだろう。
| | 
コメント