PRINCE2の教え－－プロジェクトで大事なのはマネジメントかガバナンスか？

PRINCE2の教え－－プロジェクトで大事なのはマネジメントかガバナンスか？
（2014-07-21）

このサイトをご覧の読者の方なら、『鉄の三角形』という言葉をご存知と思う。プロジェクトを定める「スコープ」［コスト］［スケジュール」という三大制約条件を、三角形の形で模式的に示したものだ。

三角形の一片の長さは、他の辺に影響を与えずに変えることができない。同じように、プロジェクトの三つの制約条件は、独立でなく必ず他と関わり合っている。例えばプロジェクトのやるべき責任範囲である「スコープ」が増えたとしよう。すると「コスト」が増えるか、「スケジュール」が伸びるか、あるいはその両方が必ず起きる。そこでプロジェクトマネージャーは、これら3つのファクターの相互関係とバランスを、よく考えながらコントロールする必要がある。

ちなみに、製造業の三大ファクターと言えば「QCD」、すなわち、品質(Quality)・コスト(Cost)・納期(Delivery)である。プロジェクトの場合は、品質で三角形を書くこともあるが、ふつうはスコープを用いる点が大きな違いだ。では品質はどこに行ったのかというと、品質を確保し保証し検証するための活動(activity)として、スコープが含んでいると解釈される。品質要求のレベルに応じて、プロジェクトのスコープが増えたり軽くなったりする訳である。

ところで、現代プロジェクト・マネジメント理論（モダンPM論）の中心的な技法は、
・WBS (Work Breakdown Structure)
・EVMS (Earned Value Management System)
・CPM (Critical Path Method, PERT/CPMとも表記)
である。これらを知らずに、プロジェクト・マネジメントは語れまい。PMBOK Guide(R)などでも丁寧に記述している。

とくに計数管理が必要なプロジェクトでは、上記は必須の技法である。計数管理は、ほんの数人・数ヶ月程度のプロジェクトを一度やるだけなら、たいして要りはしない（リーダーシップやチームワークや「気合い」で乗り切れる）。だが、大規模な場合や、小規模でも複数プロジェクトを常時動かしている場合は、数字でのコントロールがやはり大事になってくる。

ところで、上記の三つのマネジメント技法は、それぞれがちょうど『鉄の三角形』の三辺に対応している。スコープをマネージしたければWBSを、コストをマネージするにはEVMSを、そしてスケジュールにはPERT/CPMという具合だ（図参照）。この対応関係は、偶然の産物ではあるまい。プロジェクトを運営して行くにあたって、最大の制約条件を何とかコントロール下におさえるべく、上記三つの技法がそれぞれ発達してきた、という事情なのである。

ちなみに、プロジェクトの難しさや失敗率について語るとき、米国Standish Groupの統計が引用される。これは3年に一度行われる大規模調査の統計である。そこでの成功・失敗の定義は次のようになっている（2003年度版による）。

(1) Successful: completed on time, on budget, with all
specified features.
(2) Challenged: completed and operational, but over-budget,
over time and with fewer features than specified.
(3) Failed: the project is cancelled before completion
or never implemented.

すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。かくて、WBS,
EVMS, CPMのマネジメント三技法は、プロジェクトの成功率を高めるために貢献する訳だ。

もちろん、WBSにせよEVMSにせよCPMにせよ、技法の中核的アイデアは単純だが、実際に適用となるとかなり奥が深い。わたしの所属するエンジニアリング業界では、コスト・エンジニア、スケジュール・エンジニアなどの専門職が形成されており、プロマネの参謀的なスタッフとして、マネジメントを補佐していく。プロジェクト・マネージャー自身も、この三つの技法について、ある程度は習熟し、議論でき、きちんと決断できるだけのハード・スキルが望まれる。『鉄の三角形』を御すのは、決してたやすい仕事ではない。

しかし。

プロジェクトには、もっと別の難しさもある－－そういう風に、わたしは最近つよく感じるようになった。それは、プロジェクトは予算内に完遂するが、成果物に価値が見いだせない、という形での失敗だ。仕様どおり作ったけれど使われなかったシステム、予算内に完成したけれど利用客のさっぱり来ない道路や空港、期日どおり出荷したが売れない新製品・・わたし達のまわりには、そうした失敗例が、実はあふれているのではないか。そして、このような失敗は、上記のStandish
Groupの統計の、どれに分類されるのだろうか？　明らかに、どれでもあるまい。

だとすると、プロジェクトは、スコープ・コスト・スケジュールの『鉄の三角形』を守るだけでは、不十分なのだ。こうした失敗はそもそも、プロジェクトのゴール、プロジェクトが生みだすべき成果物に、十分な利用価値が見いだせない状態なのに、最後まで進めてしまったことに原因がある。である以上、プロジェクトを途中でいったん止めて、ゴールや成果物を根底から見直すべきであるし、それが無理ならば、プロマネを交替させるか、いっそプロジェクトを中断撤退すべきだったのだ。

では、その判断を下すべきなのは、誰か？

明らかに、プロジェクト・マネージャーではない。プロマネは、自分で始めたプロジェクトを、途中で降りる権限はない。プロマネ自身を罷免する権限もない（自分で辞任することはできるが、「罷免」とは本人が望まないのに強制的に辞めさせることである）。

である以上、その決断を下すべき者は、プロマネより上位に位置する権限者である事が分かる。それは、プロジェクト・オーナーかもしれないし、ステアリング・コミッティーかもしれないし、場合によってはプログラム・マネージャーかもしれない。ともあれ、プロマネを任命した権限者が、プロジェクトの価値や行く末について、要所要所でジャッジするべきなのである。

“ある程度の自立性（自律性）を持つ組織を、どう動かすべきか”の方策を、『ガバナンス』と呼ぶ。自律性を持つ組織に対し、何かの役割を委託した際に、委託した側の利益や期待に合致するように働いてもらう必要がある。そのためには、どうコントロールをきかせるべきかが、ガバナンスだ。株主が会社の運営を役員に委託する際に、株主利益から反しないようにはかることを企業ガバナンスと呼ぶのが、その典型である。

ガバナンスでとくに大事なことは、相手が勝手に変な方向に進んでいかないようにすることだ。何かをまかせる以上、資源をおかしなことにつかわれてはまずい。したがって、上に書いたように、プロジェクトの方向性を適時ウォッチし、成果物が期待した価値を生みだすように下す判断は、プロジェクト・ガバナンスの領域なのである。

旅客の来ない空港、使われない情報システムは、まさにプロジェクト・ガバナンスの不全を示している。プロジェクトの最大の失敗は、ガバナンスがきちんときかないことなのだ。

そこで、PRINCE2の登場である。先日、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」では、講師に落合和雄氏を招いて、英国のプロジェクト標準であるPRINCE2の勉強会を行った。その席上、落合氏が開口一番いわれたことが、

「PRINCE2は、プロジェクト・マネジメントよりもプロジェクト・ガバナンスの方法論です」

という言葉であった。PRINCEの原型は、1989年、イギリス政府の情報システムのプロジェクト・マネジメントの標準として中央電子計算機局
(CCTA) が開発した。やがてこれは、IT向けに政府機関以外でも使われるようになる。そして、より汎用的なマネジメント手法として
PRINCE2 が1996年に発表され、今や英国でのプロジェクトのデファクトスタンダードとなっている。

PRINCE2の中心にあるのは、段階的な漸進主義（Manage by
stages）と、プロジェクトのもたらす便益（Benefit）へのフォーカス、そしてマネジメントの階層性である。PRINCE2では、プロジェクト・マネジメント・チームならびにその機能には、3つの階層がある。

(1) Project Board – Directing （プロジェクト理事会　－　方針指導）
(2) Project Manager – Managing （プロジェクト・マネージャー　－　マネジメント）
(3) Team Member – Delivering （チーム員　－　実務）

という階層になる（なお、PRINCE2にはまだ日本語版の正式翻訳がない。上記の括弧内は、わたしの勝手な意訳である）。

そして、指示は上から下へ、報告は下から上に伝えられる。とくに、コスト、スケジュール、スコープ、品質、リスク、ベネフィットにおいて、何らかの予期せざる大きな変動があった場合、必ずそれは上位組織に対して報告され、判断を仰がなければならない（Manage by exception＝例外管理）。組織は、「許容できる変動の範囲（tolerances）」をあらかじめ定めておく。

こうして、プロジェクトが、上位組織の知らぬ間に変な風に進まないよう、たがをはめておくのである。まさにガバナンスである。ちなみに、Project
Boardよりもさらに上位の階層は、企業（Corporate）ないしプログラム・マネジメントだと規定されている。PMBOK
Guideは「プロマネがどうプロジェクトをマネージするか」を中心テーマに据えて、いわばプロジェクトという単位の中で考えている。これに対しPRINCE2は、プロジェクトを企業活動全体の文脈の中にはめこむことに、苦心している。

落合氏は、元大手SIerのSEという異色の経歴を持つ税理士だが、「PRINCE2のようなきちんとしたガバナンスの発想は、日本企業にはとても必要だが、もしかすると文化的に受け入れられないかもしれない」と言われた。「しかしPRINCE2を見ていると、世界中の植民地を支配した大英帝国の根っこにある考え方が、本当によく分かる」とも。

わたしの受けた感想は、また方角が少し違うものだった。PMBOK Guideが記述する10のマネジメント・エリアやそのプロセス群は、受注型プロジェクトによくフィットする。他方、RPINCE2の規定する概念や手順は、むしろ自社が自発的に行うタイプのプロジェクトに向いているのではないか、と感じたのである。

もともと、初期のPMBOK Guideは、米国の防衛宇宙産業とENG産業の人たちが中心になってまとめたものだった。だから、受注型ビジネスが主軸になるのは当然なのである。そして、受注型プロジェクトの最大の特徴とは、スコープ・コスト・スケジュールの三大制約が厳しいことにある。だからこそ、その三つを統括する立場にいるプロマネには、かなりの権限が与えられ、決断がなされるべき、という思想になる。

PRINCE2はむしろ、オープンエンドな自発型プロジェクト、たとえば自組織（官庁を含む）が発案し投資する情報システム開発などが典型例である。そこではむしろ、プロジェクトの方向性と、組織全体の方向性のアライメントが重要なのである。だから、ある意味では過剰に上から介入される（ように見えかねない）3階層モデルや例外管理が大事とされるのだ。

したがって、PRINCE2は、製造業におけるBOM再構築プロジェクトなどには最適ではないかと感じる。あるいは新製品開発や、業務改革プロジェクトなどにもいい。こうした種類の自発型プロジェクトは、“基本設計さえ決めれば、あとは力仕事”というスタイルでは進めにくい。むしろ、“考え考え、少しずつ進んでいく”スタイルがあっている。いいかえれば、「歩きながら考える」である。欧州の定番ジョークに、“フランス人は考えてから走り出す、イタリア人は走ってから考える、そしてイギリス人は歩きながら考える”というのがあるが、PRINCE2はまさに、歩きながら考える英国文化の産物なのだろう。