PMBOKをいくら学んでもそのまま実務には使えない！PMBOKを現場に活かす2つのポイント
はじめにお断りしておきますが、僕はPMBOKを学ぶ必要がないとはまったく思っていません。
タイトルにも書いた通り「そのまま」では使えないというだけで、応用すればとても有用ですし、弊社ではPMPの取得も推奨しています。
今日は、PMBOKがなぜそのままでは使えないのか。
どのようにすれば使えるようになるのかをお伝えしたいと思っています。
そもそもPMBOKとは
ご存じの方も多いとは思いますが、PMBOK（Project Management Body of Knowledge）はプロジェクトマネジメントの実務ノウハウを体系化してまとめた世界標準です。
建設業、製造業、IT業など、業種業態にとらわれないベストプラクティスであるとされています。
PMI（Project Management Institute）というアメリカに本部を置く団体が発行しており、2016年2月現在、第5版が最新版です。
全体の構成としては「10の知識エリア」と「5のプロセス群」のマトリックスから成り立っており、その中に「47のプロセス」が存在しています。
たくさんありすぎるので個別の解説はしませんが、項目だけを列挙すると以下です。
詳しく知りたい方はこちらをどうぞ。
（高くて分厚くて重いですけど・・・ｗ）
10個の知識エリア
- プロジェクト統合マネジメント
- プロジェクトスコープマネジメント
- プロジェクトタイムマネジメント
- プロジェクトコストマネジメント
- プロジェクト品質マネジメント
- プロジェクト人的資源マネジメント
- プロジェクトコミュニケーションマネジメント
- プロジェクトリスクマネジメント
- プロジェクト調達マネジメント
- プロジェクトステークホルダーマネジメント
5のプロセス群
- 立ち上げプロセス
- 計画プロセス
- 実行プロセス
- 監視・コントロールプロセス
- 終結プロセス
47のプロセス
- プロジェクト憲章作成
- ステークホルダー特定
- プロジェクトマネジメント計画書作成
- スコープマネジメント計画
- 要求事項収集
- スコープ定義
- WBS作成
- スケジュールマネジメント計画
- アクティビティ定義
- アクティビティ順序設定
- アクティビティ資源見積もり
- アクティビティ所要時間見積もり
- スケジュール作成
- コストマネジメント計画
- コスト見積もり
- 予算設定
- 品質マネジメント計画
- 人的資源マネジメント計画
- コミュニケーションマネジメント計画
- リスクマネジメント計画
- リスク特定
- 定性的リスク分析
- 定量的リスク分析
- リスク対応計画
- 調達マネジメント計画
- ステークホルダーマネジメント計画
- プロジェクト作業の指揮・マネジメント
- 品質保証
- プロジェクトチーム編成
- プロジェクトチーム育成
- プロジェクトチームマネジメント
- コミュニケーションマネジメント
- 調達実行
- ステークホルダーエンゲージメントマネジメント
- プロジェクト作業の監視・コントロール
- 統合変更管理
- スコープ妥当性確認
- スコープコントロール
- スケジュールコントロール
- コストコントロール
- 品質コントロール
- コミュニケーションコントロール
- リスクコントロール
- 調達コントロール
- ステークホルダーエンゲージメントコントロール
- プロジェクトやフェーズの終結
- 調達終結
ものすごい数ですよね？
しかもこれらは、すべて文書化することが要求されています。
もしプロジェクトのたびにこれらの項目を網羅するのが義務化されたら、日本中のプロジェクトマネージャーが死滅するんじゃないでしょうか。
もちろん、私だって死にます。
PMBOKが想定している「プロジェクト」
さて、「PMBOKなんて意味ないよね」と言われる最大の理由であり、意外と知られていないのが、PMBOKがどのようなプロジェクトを想定しているのかということです。
実はPMBOKが想定しているプロジェクトはかなり大規模です。
メンバー200～300人で3～5年かけて行う規模感を想定されていると言われています。
皆さんが普段実務で「プロジェクト」と呼んでいるもので、そんな大規模なものはあるでしょうか？
この規模感の違いを念頭におかずにそのままPMBOKを適用しようとしても、できるわけがないんです。
PMBOKは、経営学のようなもの
ここまでになると、実務感覚からすると「プロジェクト」というよりは「ひとつの事業」とも言える規模感です。
ですからPMBOKは、一種の経営学と言っても過言ではありません。
経営学を学んだからといってみんなが経営者として成功できるかというと、決してそんなことはありません。
しかし、経営学の知識がなければ、事業成功の確率が大きく下がることも事実です。
PMBOKもそれと同じで、それを学んだからといってプロジェクトが必ず成功するという性質のものではありません。
しかし、そこにある多くのヒントを活用することで、プロジェクト成功の確率を高めることができるというのも事実なのです。
PMBOKを実務に活用するための2つのポイント
では、どうすればPMBOKを実務に活用できるのでしょうか？
僕は以下の2つのポイントさえ押さえれば、かなり現場で活かせるのではないかと考えています。
１．PMBOKは「テーラリング」が前提
テーラリングとは、標準的な体系を個々のプロジェクトに合わせてカスタマイズして最適化することです。
前述の通りPMBOKはかなり大規模なプロジェクトのマネジメントが前提となっているので、小規模なプロジェクトにそのまま適用しようとすると管理コストばかりが膨らんでしまいます。
小規模なプロジェクトに応用するためには、プロセスも小規模にしなければ現実的ではありません。
ですから、47のプロセスのうち、個々のプロジェクトの課題解決になりそうな数個のプロセスだけに重点的に適用して残りのプロセスは無視すればいいのです。
それくらいの、ある種のいい加減さでPMBOKを応用して、はじめて現実世界に適用できるマネジメント手法になるのです。
２． 「実務TIPS」ではなく「考え方」として常に頭の片隅に置く
PMBOKの記述は非常に抽象的な概念で、実務TIPSではありません。
そのまま使える実務TIPSを手に入れようとするのではなく、あくまで考え方のヒントや心構えを手に入れるつもりで学びましょう。
そこには本当にたくさんのヒントが隠されています。
僕がPMBOKの中から得たヒントの一例を挙げてみます。
- プロジェクトチームは、スポンサーに対して「やる」と言ったことを実行するのではない。「やらない」と言わなかったことをすべて実行するのだ。
- プロジェクトマネージャーの仕事はコンフリクトの解消である。衝突や対立を起こさないようにすることも大事だが、そんなものは起きるに決まっている。コンフリクトに嘆くのはプロマネとしてのただの怠慢で、コンフリクトの解消こそがプロマネの仕事なのだ。
- プロマネの仕事の大部分はコミュニケーションなのだ。あらゆる関係者と徹底してコミュニケーションをとらないといけないのだ。
- つい実行フェーズの最適化に走りがちだが、プロジェクトマネジメントの最重要は計画なのだ。とにかく計画時点で手を抜かないこと。
- 目的を見失うな。プロジェクトのそもそもの目的は何なのか。くれぐれも手段と目的が逆転しないように常に注意しなければならぬ。
などなどなどなど、プロマネとして仕事をする上で本当に重要な考え方が詰まっています。
おわりに
PMBOKなんて実務では活用できないのではと思っていたそこのあなた！
いかがでしょうか、多少はPMBOKに対する印象が変わりましたか？
PMBOKをバイブルとして現場で活用できるプロジェクトマネージャーが1人でも増えることを願っています。
