PMBOKとは【プロジェクトマネジメント基礎 第2章】

 2015.06.04  株式会社システムインテグレータ

第二回のテーマは「PMBOK」です。アメリカの非営利団体PMI(Project Management Institute)が策定した知識体系です。「A Guide to the Project Management Body of Knowledge」という書籍にまとめられており、世界では事実上の標準として広く受け入れられています。

敢えて「世界では」と言ったのは、日本ではまだまだ普及していないからです。PMIではPMBOKに準拠した国際的な認定制度「PMP」(Project Management Professional)を展開しています。日本でもPMP取得者が年々増加しています。しかし、周りのPMと話をするとQCDの話は出てきますが、PMBOKの9つのエリア(統合管理、スコープ管理、タイム管理、コスト管理、品質管理、人的資源管理、コミュニケーション管理、リスク管理、調達管理)の話はあまり聞きません。

PMBOKの知識エリアとプロセス群

第2回【PMBOK】:プロジェクトマネージメント連載シリーズ 1

PMBOKの重要性

プロジェクトマネージメントの重要性が求められる時代になり、PMの資格を持つ人が増えています。会社も資格取得に力を入れているようですが、取得した資格のスキルを生かすところまで知識が定着していないことを感じます。
では、なぜ生かすことができないのでしょうか?
今までの経験をもとにPMBOKを生かすためのポイントを4つにまとめました。

新しい文化(=ツール)を受け入れる

プロジェクトの終わりが見え佳境に入り忙しくなるとPMはQCDだけに注目します。「納品、納品」と納品の事ばかり考えはじめます。本来ならば最後に発生するリスクやプロジェクト完了後のメンバーのリリース(開放)を考えれば調達にも気を使う必要があります。PMBOKの9つのエリアをベースにプロジェクト管理していれば、見逃すことなくできます。

原因はPMBOKに準拠したプロジェクト管理ツールを使っていないこと(使いこなせないこと)です。相変らず、スケジュール管理のツールや表計算ソフトをプロジェクト管理ツールとして使用しているPMが殆どです。PMオフィス(PMの補佐をする組織)を用意してそれらの作業を行っていればまだしも、PM本人がツールを使い、プロジェクト内で利用するツールのルールを決め、メンバー全員がそのルールに従って作業することはほとんど不可能です。

表計算ソフトのマクロは徐々に崩れていき、集計も信頼できないものになり、表そのものもどんどん増殖していき最終的に収拾がつかなくなります。

新しい文化を受け入れること。新しい文化を取り入れる第一歩として、PMBOKに準拠したツールの利用をお勧めします。

多くの組織と連携する

PMBOKのエリアで組織管理は人事部門、調達管理は一般的に購買部門が密接に関係します。
組織管理では、マトリックス型の組織で働くメンバーのマネジメント方針の策定を行います。簡単に言うと各要員の役割と果たすべき責任を定義します。当然ですが、個々の要員が持つ権限についても定義します。そして最後に評価を行います。

また、調達管理の例としては、購買部門が行う協力会社からの要員の調達です。PMが必要としているスキルを持った要員をプロジェクトの期間に合わせて適切なコストで調達することが必要です。もちろん、PMが調達した結果の承認を行うことも重要です。

こうなるとPMだけでは、管理することができません。明確に「組織管理(過去の経験、得意分野、評価など)」「調達管理(スキル、単価)」とエリアを意識して積極的に他部門との連携を取ることがPMに課せられた重要な仕事になります。

PMBOKはソリューションの源

リスクについて話をします。PMBOKの対応は、リスクに対して「回避」「引き受け」「緩和」「転嫁」の適用です。

具体的に言うと、「回避」は,リスクが予見される作業を実施せず代替作業によって目的を達成できないか,もしくはリスクの要因を潰すこと。 「引き受け」は,発生時のインパクトよりも対処コストの方が高くつく場合に,そのリスクをあえて引き受けた方が有利かどうかを考えること。 「緩和」は,リスクの発生確率を最小限にするにはどのような手を打てばよいのかを考えること。または発生時のインパクトを最小限にする,すなわち,リスクが起きてから後工程への影響を最小限に抑えるにはどうすればよいかを考えること。 「転嫁」は,自社以外の第三者,すなわち保険会社や顧客,提携先のベンダーなどにリスクを引き受けてもらえないかを考えることです。

PMBOKを理解している人ならばだれでも知っていることです。そこで、実際のプロジェクトで、「このリスクを転嫁しよう」というと、大抵の(日本)人は「そんな事はできない」と言います。ではなぜ、リスクの転嫁を否定するのでしょうか? PMBOKには、リスクの対応として「転嫁」の適用が定義されています。

どうも日本人は他人に責任を負わせることが苦手なようです。自社にないスキル、例えば特殊なデータベースのチューニングをスキルの高い第三者にリスクを「転嫁」しても良いのではありませんか。当然、トレードオフで、それなりの請求書が来る事を覚悟して。

PMBOKをソリューションの源と考えることが重要です。技術者のプライドも重要ですが体系だった知識を生かすこと。PMBOKを駆使することがプロジェクトの問題の解決に役立ちます。

経験したプロジェクトの教研を再利用する

経験したプロジェクトは,組織にとって貴重な財産となります。プロジェクトの後に実施する反省は敢えて教訓と言います。失敗ばかり記憶に残りますが、実は成功していることも沢山ある。それがプロジェクトです。

プロジェクトの結果を再利用するにはどうすれば良いのでしょうか。

まずは、同じ体系で会話することが重要です。つまりPMBOKの活用です。また、組織は自ら学習はしません。仕組み作りも重要です。データベース化してプロジェクトのノウハウを資産としてプロジェクト関係者に活用してもらうことは、最大の課題です。

では、どうすれば良いのでしょうか。はじめからPMBOKに準拠したツールを導入すれば、かなりの部分が継承されます。ツールがPMBOKに準拠しており、メンバー全員がPMBOKを意識したマネージメントを行えば、データベースという形で今まで以上に過去のプロジェクトの教訓を蓄積し生かすことができます。


RELATED POST関連記事


RECENT POST「PMBOK」の最新記事


PMBOK

表計算ソフトの限界【プロジェクトマネジメント基礎 第4章】

PMBOK

プロジェクトの可視化【プロジェクトマネジメント基礎 第3章】

PMBOK

経営者の視点から見たプロジェクト管理【プロジェクトマネジメント基礎 第7章】

PMBOK

リスク管理とは【プロジェクトマネジメント基礎 第15章】

PMBOKとは【プロジェクトマネジメント基礎 第2章】

OBPM Neo TOPへ