第二回のテーマは「ＰＭＢＯＫ」です。アメリカの非営利団体PMI(Project Management Institute)が策定した知識体系です。「A Guide to the Project Management Body of Knowledge」という書籍にまとめられており、世界では事実上の標準として広く受け入れられています。
敢えて「世界では」と言ったのは、日本ではまだまだ普及していないからです。PMIではＰＭＢＯＫに準拠した国際的な認定制度「PMP」(Project Management Professional)を展開しています。日本でもPMP取得者が年々増加しています。しかし、周りのＰＭと話をするとＱＣＤの話は出てきますが、ＰＭＢＯＫの９つのエリア（統合管理、スコープ管理、タイム管理、コスト管理、品質管理、人的資源管理、コミュニケーション管理、リスク管理、調達管理）の話はあまり聞きません。
PMBOKの知識エリアとプロセス群
PMBOKの重要性
プロジェクトマネージメントの重要性が求められる時代になり、ＰＭの資格を持つ人が増えています。会社も資格取得に力を入れているようですが、取得した資格のスキルを生かすところまで知識が定着していないことを感じます。
では、なぜ生かすことができないのでしょうか？
今までの経験をもとにＰＭＢＯＫを生かすためのポイントを４つにまとめました。
新しい文化（＝ツール）を受け入れる
プロジェクトの終わりが見え佳境に入り忙しくなるとＰＭはＱＣＤだけに注目します。「納品、納品」と納品の事ばかり考えはじめます。本来ならば最後に発生するリスクやプロジェクト完了後のメンバーのリリース（開放）を考えれば調達にも気を使う必要があります。ＰＭＢＯＫの９つのエリアをベースにプロジェクト管理していれば、見逃すことなくできます。
原因はＰＭＢＯＫに準拠したプロジェクト管理ツールを使っていないこと（使いこなせないこと）です。相変らず、スケジュール管理のツールや表計算ソフトをプロジェクト管理ツールとして使用しているＰＭが殆どです。ＰＭオフィス（ＰＭの補佐をする組織）を用意してそれらの作業を行っていればまだしも、ＰＭ本人がツールを使い、プロジェクト内で利用するツールのルールを決め、メンバー全員がそのルールに従って作業することはほとんど不可能です。
表計算ソフトのマクロは徐々に崩れていき、集計も信頼できないものになり、表そのものもどんどん増殖していき最終的に収拾がつかなくなります。
新しい文化を受け入れること。新しい文化を取り入れる第一歩として、ＰＭＢＯＫに準拠したツールの利用をお勧めします。
多くの組織と連携する
ＰＭＢＯＫのエリアで組織管理は人事部門、調達管理は一般的に購買部門が密接に関係します。
組織管理では、マトリックス型の組織で働くメンバーのマネジメント方針の策定を行います。簡単に言うと各要員の役割と果たすべき責任を定義します。当然ですが、個々の要員が持つ権限についても定義します。そして最後に評価を行います。
また、調達管理の例としては、購買部門が行う協力会社からの要員の調達です。ＰＭが必要としているスキルを持った要員をプロジェクトの期間に合わせて適切なコストで調達することが必要です。もちろん、ＰＭが調達した結果の承認を行うことも重要です。
こうなるとＰＭだけでは、管理することができません。明確に「組織管理（過去の経験、得意分野、評価など）」「調達管理（スキル、単価）」とエリアを意識して積極的に他部門との連携を取ることがＰＭに課せられた重要な仕事になります。
PMBOKはソリューションの源
リスクについて話をします。ＰＭＢＯＫの対応は、リスクに対して「回避」「引き受け」「緩和」「転嫁」の適用です。
具体的に言うと、「回避」は，リスクが予見される作業を実施せず代替作業によって目的を達成できないか，もしくはリスクの要因を潰すこと。 「引き受け」は，発生時のインパクトよりも対処コストの方が高くつく場合に，そのリスクをあえて引き受けた方が有利かどうかを考えること。 「緩和」は，リスクの発生確率を最小限にするにはどのような手を打てばよいのかを考えること。または発生時のインパクトを最小限にする，すなわち，リスクが起きてから後工程への影響を最小限に抑えるにはどうすればよいかを考えること。 「転嫁」は，自社以外の第三者，すなわち保険会社や顧客，提携先のベンダーなどにリスクを引き受けてもらえないかを考えることです。
ＰＭＢＯＫを理解している人ならばだれでも知っていることです。そこで、実際のプロジェクトで、「このリスクを転嫁しよう」というと、大抵の（日本）人は「そんな事はできない」と言います。ではなぜ、リスクの転嫁を否定するのでしょうか？ ＰＭＢＯＫには、リスクの対応として「転嫁」の適用が定義されています。
どうも日本人は他人に責任を負わせることが苦手なようです。自社にないスキル、例えば特殊なデータベースのチューニングをスキルの高い第三者にリスクを「転嫁」しても良いのではありませんか。当然、トレードオフで、それなりの請求書が来る事を覚悟して。
ＰＭＢＯＫをソリューションの源と考えることが重要です。技術者のプライドも重要ですが体系だった知識を生かすこと。ＰＭＢＯＫを駆使することがプロジェクトの問題の解決に役立ちます。
経験したプロジェクトの教研を再利用する
経験したプロジェクトは，組織にとって貴重な財産となります。プロジェクトの後に実施する反省は敢えて教訓と言います。失敗ばかり記憶に残りますが、実は成功していることも沢山ある。それがプロジェクトです。
プロジェクトの結果を再利用するにはどうすれば良いのでしょうか。
まずは、同じ体系で会話することが重要です。つまりＰＭＢＯＫの活用です。また、組織は自ら学習はしません。仕組み作りも重要です。データベース化してプロジェクトのノウハウを資産としてプロジェクト関係者に活用してもらうことは、最大の課題です。
では、どうすれば良いのでしょうか。はじめからＰＭＢＯＫに準拠したツールを導入すれば、かなりの部分が継承されます。ツールがＰＭＢＯＫに準拠しており、メンバー全員がＰＭＢＯＫを意識したマネージメントを行えば、データベースという形で今まで以上に過去のプロジェクトの教訓を蓄積し生かすことができます。
