プロジェクト・マネジメント再考
プロジェクト・マネジメントの理論は、だいぶ枯れて来ました。
これから必要なのは、それがなぜ活かせないか、どうすれば活かせるようになるか、なのではないでしょうか、というお話です。
PMBOKは、優れた知識体系。
建築系およびIT系の方にはお馴染みかと思いますが、PMBOK（Project Management Body Of Knowledge）は、プロジェクト・マネジメントの理論をプロセスと知識エリアによって整理し、プロジェクト・マネジメントの国際標準とされている「知識体系」です。
PMIという機関によって監修され、世界各国でガイドブックを発行、その体系に基づく知識とプロジェクト・マネジメントの実務経験からなる認定試験「PMP：Project Manegement Professional」も行われています。
私がPMP試験に合格した時は、まだPMBOKは第2版だったように思います。
(なお、それ以降一度も更新できてませんので失効済です。現在の更新要件はPMP® 試験・資格について｜一般社団法人 PMI日本支部を参照）
その後、2004年に第3版になるタイミングでかなり変更が加わって強化されました。
2013年に出た第5版が最新のようですが、正直なところ第4版、第5版の改訂ポイントは追いかけていません。
第3版リリースのときと比べてニュースにもならなかった感があるので、そんなに大きな変化はなかったのでしょうか。ご存知の方がいたら教えて下さい。
第2版の頃の日本でのPMBOKおよびPMPの知名度はまだまだで、試験の日本語化もようやくおいついた程度でした。
その日本語も危ういレベルだということは当時のPMIも認識していたようで、CBT（Computer Based Testing：コンピューター上で受ける試験）には「日本語英語切り替えボタン」があり、好きなタイミングで何度でも切り替えることができるようになっていました。*1
なんでそこまで丁寧な仕様になっていたか。
日本語訳が、英語と反対の意味に読み取れたりすることがあったからです。
当時TOEICで500点未満の私ですら、それが判るレベルで。
と、冒頭から話がそれてしまいました。
そんなわけで、私の知識は第2版ベースとなるわけですが、当時勉強していて思ったことは
「現場で起きている問題の大半は、PMBOKに書かれていることをうまく適用できていれば、防げたのではないか」
ということでした。
日本へ輸入、普及活動に入った段階で、理論としてはかなりの完成度だったと思われるのです。
PMBOK以前のプロジェクト管理理論と対称化して、このPMBOKに基づくプロジェクト・マネジメントを「モダン・プロジェクト・マネジメント」と呼ぶこともありますが、もう、充分に枯れていると思うわけです。
それでも尽きない炎上プロジェクト
第2版の頃は、まだ「知識としての、体系化されたプロジェクト・マネジメント理論としてのPMBOK」が知られていない、知る機会が少ないという状況でした。
当時の私も、上司に「このセミナー受けてこい。そしてこの試験受けてこい」と言われてPMBOKの存在を知ったレベルです。
ですので、「知っていれば防げたかも」という炎上案件も多数あったのではないかと思います。
今ではPMBOKおよびPMP自体もかなり普及しています。数あるプロジェクト・マネジメント指南書籍の大半がPMBOK準拠を謳うか、明記されてなくても中身はPMBOKに書いてある内容から外れていません。
ですので、プロジェクト・マネジメント理論を学ぶハードルは圧倒的に下がっており、だれでも手にすることができるようになっています。
しかしながら、炎上プロジェクトはなくなってはいません。
「知っていれば防げたかも」から、「知っていても防げなかった」に変わってきているかと思います。
炎上の理由はなにか
データが欲しかったのですが、ちょっと見つけられなかったので、体験および日常の情報収集ベースで、主な炎上原因を３つあげてみます。
- 当初から無理な受注。期間見積もりも工数見積も妥当なのに、その見積と乖離した条件で受注してしまう。
- 見積もり誤り。期間、工数、金額の各要素で、見積もりそのものに、漏れや過小算出があり、プロジェクト期間に入ってから明らかになる。
- 要件の肥大化。見積もりも妥当、契約条件も妥当だが、プロジェクトがスタートすると、あれもこれもと話が広がって収拾がつかなくなる。
今も昔も、この3つのいずれか、あるいはその組み合わせだ、と言ってハズレはないでしょう。
メンバーの病気や怪我、災害等などは、発生頻度からすれば取るに足らないレベルです。
プロジェクトの反省会を開いて、この３つが１つも出なかったら、相当うまくいったプロジェクトか、相当ダメな集団かでしょう。
で、上記のような問題に対して、PMBOKでも当然、対応する箇所があります。
PMBOKは、そのマネジメントの知識を10の知識エリア（カテゴリ・領域）に分類し、プロジェクトのプロセス5段階に応じて、それぞれの知識エリアで管理すべきことが対応付けられています。
10の知識エリア
- プロジェクト統合マネジメント
- プロジェクト・スコープ・マネジメント
- プロジェクト・タイム・マネジメント
- プロジェクト・コスト・マネジメント
- プロジェクト品質マネジメント
- プロジェクト人的資源マネジメント
- プロジェクト・コミュニケーション・マネジメント
- プロジェクト・リスクマネジメント
- プロジェクト調達マネジメント
- プロジェクト・ステークホルダー・マネジメント
5個のプロセス群
- プロジェクトの立上げプロセス群
- プロジェクトの計画プロセス群
- プロジェクトの実行プロセス群
- プロジェクトの監視・コントロール・プロセス群
- プロジェクトの終結プロセス群
炎上プロジェクトの件にかぎらず、一般的に、「問題があることが把握されていて、原因がほぼ見えていて、その防止策となる知識も整備されている」としたら、次の問題は「なぜそれができないか。どうしたらできるようになるのか」に移ります。
そうすると、もう行き着くところは結局この２つですね。
- 個人の問題
- 組織の問題
個人の問題
個人が原因となって、やるべきことがわかっていてできないのは、
- 適用、適応能力の不足
- コミュニケーションスキルの不足
- メンタルの強さの不足
といったところに帰結してしまうのでしょうか。
「適用、適応能力の不足」については、数学の公式は解ってるけど、出題内容に合わせてうまく正解を導きだせないようなものなので、経験と訓練でかなりカバーできそうです。
しかし、「コミュニケーションスキルの不足」「メンタルの強さの不足」あたりの問題は手強いです。「うわ、でたよ、コミュ力（）」って感じですよ、もう。
能力とはいうものの、個性にほど近い属性のものだったりしますし。
一応、これらも、セミナーやらトレーニングやらあるので、それなりに底上げする方法はあることにはありそうです。効果の方はよくわからないです。
組織の問題
人が集まれば組織になって、組織になればルールができる。明文化、非明文化にかかわらず。
組織が原因となって、やるべきことがわかっていてできないのは、
- 権限の移譲の不足
- 非協力的な体制、支援の手薄さ
など、仕組みの問題に置き換えられると思います。
「権限の移譲の不足」というのは、「この金額でこの期間でこのメンツで、この案件を責任をもってマネジメントして解決しろ」と押し付けられるようなアレですね。
金額、期間、人員に関して、まったく権限がないのに、責任だけ押し付けられてるというやつ。
そりゃ、問題がわかっていて、知識も経験も充分だったとしても、手も足もだせませんがな。
目の前に見えている落とし穴に向かって、手足縛られて転がされるようなものです。
こんなのマネジメントでもなんでもない。
「非協力的な体制、支援の手薄さ」というのも、ほぼ同じです。
契約手続きやら、人員手配やら、組織の枠の中で色々とやらなくてはいけないことがあるなか、そうした手続きを拒否したり怠惰な処理をされたりしたのではたまりません。
背面から撃たれるような体制で、ナニができるのかと。
そんな組織的な逆境を跳ね除けるような個人であれば、プロジェクトは炎上しないかもしれません。
プロジェクト・マネジメントって、超人じゃなきゃできないんだっけ？
そんなこと言ってたら、とてもじゃないけどプロジェクトマネージャーが足りないですね。
また、超人的プロジェクトマネージャーだって、最初は初心者なわけですし。
初PM案件から、1度の失敗もなく、どんな案件も成功させてる人なんてソレこそ奇跡的な確率でしょう。
なので、「超人じゃなくても炎上しないための仕掛け」が必要なのです。
これから整備されていくべきは、制約のある条件のなかで、不足部分を補い機能させるための方法論
PM一人ですべてできないし、できなくてもいい。
組織だって完璧じゃない。
そういう前提にたって、どこで、何が欠けている時、どう補うことで、その影響を最小限に食い止められるか。
そのノウハウ、理論、事例といったものは、まだまだ不足していると思います。
個別具体的な事例となれば、守秘義務に引っかかることをおそれて、なかなか世に出てこないことも少なくありません。
情報が世に出ていたとしても、それを集積、整理する動きはまだまだでしょう。
こうした動きがもっと広がることを期待しています。
ところで、「制約のある条件のなかで、課題を解決していく」って、プロジェクトの定義ほぼそのまま*2じゃないですか。
つまり、＜「プロジェクトマネジメントをにおける課題を解決するプロジェクト」をマネジメントするためのノウハウ＞が求められているんじゃないでしょうかね。
