PMBOKとは

PMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。読み方は「ピンボック」です。米国のプロジェクトマネジメント協会（PMI）が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。

本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。

【参考】PMI日本支部

2017年に発刊されたPMBOKの第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験（プロジェクトマネジメント・プロフェッショナル試験）の受験勉強をしていた人たちです。

PMP受験者は主にPMBOKガイドを使って学習します。そのため、第6版で（または第6版の解説書で）勉強してきた人にとって第7版での内容変更は、「今までの勉強が無駄になった」と感じたでしょう。PMI日本支部は「試験は第6版を参考にすれば問題ない」としていますが、受験者の不安は拭えません。

国際資格であるPMPは2020年時点で世界で1,118,998人、日本で39,850人の資格保有者がいます。受験者数は公表されていませんが、次の試験を目指して勉強中のプロジェクトマネジャー経験者やプロジェクトリーダー経験者は数多くいるでしょう。

「資格を取るつもりはないが、有名なPMBOKとはどんなものか勉強しよう」と解説書を読んだ人にとっても、第7版での大きな内容変更は受け入れにくいものです。

【参考】PMP(R)PMI-ACP(R)資格保有者・資格取得者は？｜2020.9更新 | PMP,プロジェクトマネジメント,CBAP,Prince2のE-PROJECT

第6版までのPMBOKの骨組みは「10の知識エリアと5つのプロセス」

PMBOKの第6版までは、プロジェクトマネジメントの骨組みを「10の知識エリアと5つのプロセス」として解説しています。プロジェクトの成功、つまりQCD（品質・費用・納期）の目標を達成するには、プロジェクトの5つのプロセスの各段階で10のエリアに区別されるマネジメントが必要であるとしています。ここでは、「10の知識エリアと5つのプロセス」について詳しく解説します。

PMBOKは、プロジェクトの進行を次の5つプロセスの遂行として捉えます。

1.立ち上げプロセス プロジェクトの目的・ゴール・予算・期限を定めて、プロジェクトオーナーがプロジェクトの立ち上げを認可します。

2.計画プロセス プロジェクトマネジャーによってゴールまでのハイレベルな（=おおよその）作業計画が立てられ、プロセスが進むにしたがって計画を詳細化します。

3.実行プロセス 立案した計画に基づいてチームがタスクをこなします。

4.監視・コントロールプロセス 次工程への受け渡しで、確実な検査や検証が行なわれているかを監視します。

5.終結プロセス QCD（品質・費用・納期）を検証・評価してプロジェクトを終結します。

プロジェクトの完成までの上記プロセスは、次に紹介する「10の知識エリア」に分けられて綿密に管理されます。

プロジェクトマネジメントの10の知識エリアとは、マネジメント（管理）の対象を業務の種類や性質によって10エリアに分けたものです。

1.統合管理 : 他の9つのエリアを統合する全体管理 2.スコープ管理 : 仕事の範囲と成果物がを明確にするマネジメント 3.スケジュール管理：高い生産性を保つスケジュール計画 4.コスト管理：予算内でプロジェクトを終えるための費用管理 5.品質管理：プロセス・成果物の品質を高く保つための品質管理 6.資源管理 : プロジェクトを完成するための人材や物資（ヒトとモノ）の管理 7.コミュニケーション管理：プロジェクトの情報共有管理 8.リスク管理 : プロジェクトの遂行プロセスで発生するリスクの予測・回避・対処 9.調達管理 : プロジェクトを進める上で必要なサービスやツールの調達管理 10.ステークホルダー管理 : クライアント・経営層・社内関係部署などのプロジェクトに関係するステークホルダー（利害関係者）との情報共有管理

10のエリアの2〜8までは立ち上げプロセスと終結プロセスには関係しませんが、他の3つのプロセス（計画プロセス・実行プロセス・監視プロセス）に密接に関わっています。

上記のような論理的で綿密な構成は、「きちんと計画し見通しを立ててやるべきことを積み上げて行けば、プロジェクトは成功する」という考え方です。第7版では、上記の楽観的で人間の理性へのシンプルな信頼に疑問符をつけています。

PMBOKの10の知識エリアと5つのプロセスについて徹底解説！

第7版の変更点

第7版では「5つのプロセス」も「10の知識エリア」も完全に姿を消し、新たに登場したのが「価値提供システム」「12の原則」「8のパフォーマンスドメイン（行動領域）」という新しい概念です。ここでは、第7版での変更点について説明します。

第6版までは、プロジェクトの最終目的をQCD（品質・費用・納期）を達成することとしていました。「予算と期限を守ってまっとうな成果物を提供することが重要である」としていたのを、第7版ではプロジェクトの目的を「価値の提供」としています。第6版までと第7版では全く違う概念に変更されました。

「価値提供システム」とはどのようなものなのでしょうか。簡潔に言うと、従来の「予定していた成果物を作る」という考えから、「やりながら考え、臨機応変に価値のある成果物を作る」という考え方に変わったということです。

PMBOK第7版では「5つのプロセス」という概念が消え、「12の原則」という概念が登場しました。「プロセス重視」から「原理・原則の重視」へ概念が変更され、より現実的な考え方になりました。

「12の原則」とは、以下のような考え方を指します。

・スチュワードシップ : 請け負ったことを責任を持って行う ・お互いを尊重し協力し合うチーム ・ステークホルダー（利害関係者）との連携 ・価値の創造に焦点を当てる ・包括的思考：システムの相互作用を認識して対応する ・リーダーシップ ・テーラリング：状況に応じた調整（仕立て直し）を図る ・品質をプロセスと結果に組み込む ・事態の複雑さに対処、適応する ・リスク（好機と脅威の不確実性）に対処する ・適応性と回復力を備える ・変化することであるべき未来を達成する

第6版の5つのプロセス（立ち上げ・計画・実行・監視・終結）と比べると、「12の原則」では「調整」「複雑さ」「適応」「回復」「変化」など、一筋縄ではいかないプロジェクトの現実をわきまえた原理・原則になっていると言えます。

第7版では「10の知識エリア」という概念がなくなり、「8のパフォーマンス・ドメイン」という概念が登場しました。

8つのパフォーマンス・ドメインとは、次のようなものです。

​・Stakeholders（利害関係者） ・Team（チーム） ・Development Approach and Life cycle（開発アプローチとライフサイクル） ・Planning（計画） ・Project work（プロジェクト作業） ・Delivery（提供・納品） ・Measurement（測定） ・Uncertainty（曖昧さ・複雑さ・変動性などの不確実性への対処）

ドメインの名前を見ただけでは内容は分りませんが、全体のくくりが「知識エリア」から「行動領域」に変わったことからも、アプローチの姿勢の違いがわかります。特に、あいまいさや複雑さからくる不確実性をドメインの1つに加えたことが注目されます。

なぜPMBOKは大改訂されたのか

PMBOKはなぜ大改訂されたのでしょうか。理由は、従来の開発手法の限界や弱点が明らかになり、見直しの機運が高まったことにあります。具体的には、PMBOKもウォーターフォール開発の理論的基礎付けだけではなく、アジャイル開発の思想や手法もマネジメント理論に取り入れざるを得なくなったことが大きな理由でしょう。以下で大改訂された理由について詳しく説明します。

2001年に17人のソフトウェア開発者のグループによって「アジャイル開発宣言」がなされてから20年を経た現在、スタートアップ企業に限らず大手ベンダー企業でもアジャイル開発の手法が取り入れられています。「アジャイル開発宣言」には、次のような有名な言葉があります。

「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。」

上記にある、対話・協調・変化への対応という価値観が第7版に反映されていることは明らかです。

契約と計画に縛られてとことん行き詰った挙句に「炎上する」という、ウォーターフォール開発の「硬直性」を打破するのがアジャイル開発の「柔軟性」です。この流れの中でPMBOKも、「論理的で理性的なだけではプロジェクトは上手くいかない」という現実を、マネジメント管理に取り入れようとしたと言えます。

第6版までは論理的思考が強く現実的ではなかったため、実務で活用しにくい点がありました。実際のプロジェクトではイレギュラーな事故・突発的に発生する問題がありますが、臨機応変に対応することについてあまり触れられていません。

また、大規模開発が前提とされている・複数のプロジェクトが同時進行することを考慮されていない・具体策が記載されていないなどの点もデメリットでした。

人間関係が及ぼすプロジェクトへの影響についても、第6版まででは書かれていません。プロジェクトはチームで遂行するため、論理的思考だけではスムーズに進まないこともあります。チームワークを円滑にする・ステークホルダーと友好な関係を構築するなどは、実際の業務で重要です。第7版では人間関係の重要性についても言及されており、より実務を想定した内容に変更されています。

IТデザイナーはPMBOK第7版とどう付き合うか

第6版までのPMBOKガイドやその解説書を読んだエンジニアには「かなり精緻な理論だが、その通りには使えない」「PMBOKには人間が出てこない」と感じた人も多いでしょう。そのため第7版は親しみやすく、リアリティがあるかもしれません。

しかし、それでもPMBOKが簡単になったとは言えません。理屈を理解するより人間を理解する方が簡単だとは言えないからです。とはいえ、第7版ではPMBOKのプロジェクト管理理論に人間性や「人間のやること」に対する洞察が加わり、深みが増したと言えます。アジャイル開発の手法を学びたいという人も、PMBOKは勉強する価値がありそうです。

プロジェクト達成に役立つ世界標準のPMBOKと資格取得について