PMBOKとは？基本的な考え方やプロジェクトマネジメントへの活用についてわかりやすく解説！
PMBOKは、プロジェクトマネジメントに関する知識や考え方を体系化したもので、プロジェクトに関わる人にとって非常に有用なものです。初めてプロジェクトへ参画する方やマネジメントをされる方は、何をすればプロジェクトを成功させられるのかわからず悩まれるのではないでしょうか。そんな時のガイドラインとしてPMBOKを知っておくことは重要です。本記事では、PMBOKの意義や活用法、基本的な考え方について解説しています。
※この解説で使用する用語「PMBOK」「PMP」「Project Management Professional」は全てPMI(Project Management Institute)の登録商標です。
目次
1．PMBOKとは
PMBOKは、高品質で効果的なプロジェクトマネジメントを行うために必要とされる知識を集約し、体系化したガイドラインで、プロジェクトマネジメントについてのベストプラクティスを提供しています。
PMBOKはthe Project Management Body of Knowledge(プロジェクトマネジメント知識体系)の頭文字を取ったもので、「ピンボック」「ピームボック」と発音されます。
PMBOKはPMIによって「PMBOKガイド」という名称で書籍化されており、PMI日本支部が日本語翻訳版を出版しています。PMBOKと言った場合、実際にはPMBOKガイドをさすと考えても差し支えありません。
PMBOKガイドは2021年に第7版が出版されましたが、1996年の初版以降、ほぼ4年ごとに改訂が行われています。それは、社会環境の変化や技術の変化に対応するためで、次回の改定では「AIへの対応」がガイドラインとして加わるとアナウンスされています。
現在、PMBOKは情報システム分野におけるプロジェクトマネジメントのデファクトスタンダードの位置付けとして定着していますが、それだけではなく、電子機器業界、化学業界や研究分野でもPMBOKの考え方は参考にされています。また、2023年にPMI日本支部に建設コミュニティが立ち上がり、「PMBOKガイド 建設拡張版」も出版されています。そして、2024年には行政コミュニティが立ち上がりました。このことから、PMBOKが情報システム分野だけではなく、多方面において有用性を発揮していると言うことができます。 なお、PMBOKをベースにしたプロジェクトマネジメントの資格として「PMP*」があり、2024年現在、日本における資格保持者数は45,000名を超えています。
*PMP : Project Management Professional
1-1.PMBOKの活用法
PMBOKはプロジェクトの品質を高めることを本来の目的としていますが、それはプロジェクトマネジメントの品質を高めること、プロジェクトマネージャーの品質を高めること、プロジェクトチームの品質を高めること、プロジェクトの成果物の品質を高めること、プロジェクトの成果を実現することにも通じます。
かつて、プロジェクトをKKD(勘、経験、度胸)で運営していた時代がありました。しかし、プロジェクトを取り巻く環境が複雑化し、プロジェクトの成否が組織の成否と直結するようになってきたことで、KKDから脱却し、PMBOKのようなガイドラインが必要とされるようになったのです。
このPMBOKの本来的な活用法とは別に、次のような活用法も見逃せません。
- プロジェクトに関する辞書代わりに使う
プロジェクトを運営していく中では、プロジェクトマネジメントについての課題、問題、疑問が発生します。その際、PMBOKの中にアドバイスを見つけることができ、そこから解決策につなげることが可能です。 - プロジェクトに関して社内の共通用語とする
プロジェクトの運営に関して、チームメンバー間やプロジェクトチームとステークホルダーとの間で行われるコミュニケーションの共通用語として利用し、相互理解を促進することができます。特に、プロジェクトチームとステークホルダーではプロジェクトへの期待が違うことがあり、それをすり合わせるためのコミュニケーションは重要なポイントとなります。 - 協力会社との共通用語とする
情報システムを開発、運用していく際には外部の協力会社とのコミュニケーションも不可欠です。その際にもPMBOKを発注側企業と受注側企業との間でのコミュニケーションの共通用語とすることができます。ただし、発注側企業と受注側企業では表現が同じでも意図が違う用語がありますので、すり合わせは欠かせません。
2．PMBOK第7版のコンセプトと第6版との違い
2024年現在のPMBOK最新版は第7版です。第6版から第7版に改訂される際に大きな変化がありました。
第6版まではプロジェクトの開始から終結までの流れを開始時点で予測する前提で「5つのプロセス(立上げ、計画、実行、監視とコントロール、終結)」と「10の知識エリア(統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー)」を縦軸/横軸にした解説と、そこで利用される管理ツールの説明で構成されており、内容としては、プロジェクトのそれぞれのプロセスに対する「インプット(ドキュメント、計画等)」「(そのプロセスで使用する)ツールと技法」「アウトプット（ドキュメント、成果物等）」が解説されていました。
この構成の考え方が、第7版では「プロジェクトマネジメントにおける12の原理・原則」と「8つのプロジェクトパフォーマンス領域」に変更されました。前者はPMBOKの中で「プロジェクトマネジメント標準」編、後者は「プロジェクトマネジメント知識体系ガイド」編として分けて説明されています。
PMBOKの編構成を変更した理由は明記されていませんが、「プロジェクトに関わる人のふるまい等プロジェクトの独自性に関わらず変化しないもの(プロジェクトマネジメント標準編)」と「プロジェクトの複雑化、開発手法の多様化、社会の状況等の影響を受け適応させていくもの(プロジェクトマネジメント知識体系ガイド編)」とに分けたと考えられます。
3.PMBOK第7版の基本的な考え方
では、ここから、「プロジェクトマネジメント標準」編、「プロジェクトマネジメント知識体系ガイド」編にの内容について、簡単に解説していきます。
3-1.プロジェクトマネジメントの12の原則
プロジェクトマネジメント標準編は、12の原理・原則について解説していますが、その前に、基準点となる「価値実現システム」の説明を行っています。
価値実現システムとは組織を構築、維持、発展させることを目的とした戦略的な事業活動の集合のことであり、「プロジェクトの目的は個別のプロジェクトで最終成果物を作り上げるだけではなく、そのプロジェクトが生み出す戦略的価値に目を向けなければいけない」ということを示しています。
従来、プロジェクトの目標はプロジェクトを立ち上げた時に決めた「最終成果物」を完成させることと定義されていました。しかし、プロジェクトを取り巻く環境が不透明になり、社会の変化が激しくなっていることと、アジャイル方式のように最終成果物を固定しないような開発方式も多くなっていることにより、それに対応する定義が必要になってきたのです。
また、組織の中においても、プロジェクトを取り巻くものにはポートフォリオ(組織の戦略目標達成のためにグループとして管理されるプログラム、プロジェクト、業務)や、それに基づいて行われるプログラム(相互に関連を持つプロジェクトの集合体)、プロダクト(事業の源泉となる製品、サービス、情報等)、定常業務というような組織の価値を実現するためのアクティビティが多数存在しています。その中で、個別のプロジェクトがそれ自身の目標の達成のみを追いかけるだけでは、組織全体のパフォーマンスは向上しません。他のアクティビティとの相互関係を理解し、組織の戦略としてのガバナンスシステムと連動して初めて価値を実現することができるのです。
この考え方から、プロジェクトマネージャーやメンバーにはプロジェクトマネジメントの技術力だけではなく、経営的な要素も求められることになりますし、価値判断をするステークホルダーとのコミュニケーションは欠かすことのできないものとなります。
「価値実現システム」の解説の後に続くのが以下のプロジェクトマネジメントの12の原則です。12の原理・原則はプロジェクトを管理運営する上での戦略立案や意思決定、問題解決の基本的ガイドラインで、プロジェクトにおいての関係者のふるまいの指針となるものです。
- 勤勉で、敬意を払い、面倒見の良いスチュワードであること
プロジェクトのメンバー全員が責任を持って自分の役割を遂行し、チーム内やステークホルダーからの信頼を得るように行動し、かつ、コンプライアンスを遵守する - 協働的なプロジェクト・チーム環境を構築すること
チームワークの確立と効果的なチーム運営を行う - ステークホルダーと効果的に関わること
ステークホルダーの効果的な関与とサポートがプロジェクトの成功に繋がる - 価値に焦点を当てること
成果物を作るだけではなく、そこから生まれる価値を提供する - システムの相互作用を認識し、評価し、対応すること
実行しているプロジェクトだけではなく、組織内外の変化による相互の影響を認識・評価した上でプロジェクト運営を行う - リーダーシップを示すこと
プロジェクトマネージャーだけではなくメンバー全員がリーダーシップを発揮する - 状況に基づいてテーラリングすること
プロジェクトの独自性に合わせて、継続的にプロセス、方法、作成物等を適応させる - プロセスと成果物に品質を組み込むこと
プロジェクトのプロセスとプロジェクトが目指す成果物に対して、品質の定義を行い、常に、その乖離状況のチェックを行い、対応する - 複雑さに対処すること
プロジェクトの内部的な複雑性、ステークホルダーを含む外部からの影響によって発生する複雑性に対応する - リスク対応を最適化すること
好機と脅威両方のリスクを継続的に正しく評価し、事業に則した対応方針を決め、実行する - 適応力と回復力を持つこと
プロジェクト期間中に発生する変化や問題に対して的確に対応する - 想定した将来の状況を達成するために変革できるようにすること
プロジェクトは組織に対して、常に変革をもたらすが、その変革と事業のコンセプトの合致を確かにし、また、変革への抵抗を解消する
3-2. 8つのパフォーマンス領域
PMBOK第6版では「10の知識エリア」が定義されていましたが、第7版では「8つのパフォーマンス領域」(プロジェクトが成果を提供するために必要な活動群)に分けられています。これは、「10の知識エリア」と相反するものではなく構成を変えたもので、以下の8つです。
- ステークホルダー
プロジェクトに関係する人の洗い出し、対応方法の検討・実施等、価値を提供する相手としてのステークホルダーの分析と対応活動
・プロジェクト内外の影響力があるステークホルダーに焦点をあてる重要性は、「12の原則」にも重複してその項目があることでもわかります。プロジェクトの受益者がステークホルダーであり、そのステークホルダーとの緊密な連携が必要であることが背景となっています。 - チーム
チームの構成、チーム運営の方針やリーダーシップのコンセプト等、チームが成果を挙げるための活動
・チームの運営方針としては、プロジェクトマネージャーがリーダーシップを発揮する集権型マネジメントだけではなく、メンバーもチームの運営に関わる分散型マネジメントについても定義されており、それに対応してリーダーシップタイプも指示命令型、サーバント型について解説されています。 - 開発アプローチとライフサイクル
開発アプローチは「予測型」「適応型」とそのハイブリッドに類型化される。どのアプローチを選択し、プロジェクトのライフサイクルをどうするかについての意思決定を行うための活動 - 計画
プロジェクトの全体計画をはじめとして、コミュニケーション計画、予算計画、要員計画等、プロジェクトに必要な計画活動 - プロジェクト作業
プロセスの確立、プロジェクトが成果物と成果を提供できるようにする作業に関する活動 - デリバリー
プロジェクトの成果物と成果を事業目標や戦略と一致させるための品質管理に関わる活動 - 測定
プロジェクトのパフォーマンスに関係する様々なメトリクスの測定とそのフィードバックに関する活動 - 不確かさ
プロジェクトが直面する曖昧さ、複雑さやそこにあるリスクへの対応活動
また、これらの8つのパフォーマンス領域とは別に「テーラリング」と「モデル、方法、作成物」が独立した章として記述されています。
「テーラリング」は、それぞれのプロジェクトの独自性に合わせてプロジェクトマネジメントの方法を変えることを意味しますが、独立した章として取り上げているのは、「プロジェクトの独自性、社会環境の変化、事業環境の変化、開発アプローチの多様性等の諸条件により、それらに適合させるためにテーラリングは必須である」という考え方によります。
この章では「なぜ、テーラリングが必要か」「何をテーラリングするのか」「どういうプロセスでテーラリングするか」「どのパフォーマンス領域をテーラリングし、どのようにチェックするか」について詳細な解説があり、これまでよりもテーラリングを重視していることがよくわかります。
もうひとつの章「モデル、方法、作成物」で、プロジェクトのメンバーが利用できる思考戦略、手段/ツール、プロジェクトで作成される成果物（ドキュメント等）を紹介しています。これは、以前の「インプットーツール/技法ーアウトプット」の考え方に代わるものですが、「このツールを使うべき」という意図ではなく、テーラリングの方向に合わせて、「モデル、方法、作成物」を選択するという記述になっています。
そして、この2つの章と8つのパフォーマンス領域は「PMBOKの考え方をいつ、どのプロジェクトに適用するか」という疑問に対して「全てのプロジェクトの全ての段階において」という回答を示しています。また、「誰が利用するか」という疑問に対しても「プロジェクトの価値実現に向けて、プロジェクトマネージャーだけではなく、プロジェクトチームのメンバー全員、およびプロジェクトに関係する役割を持つ全員が利用すべき」だと示唆しています。
なお、プロジェクト運営のためのツールや技術については、プロジェクトタイプ、開発アプローチ、業界分野ごとにどう使用すべきかが別途デジタルコンテンツPMIstandards+ ™で示されています。これは、PMBOKの抽象性を補う役割を持っています。
4.まとめ
プロジェクトマネジメントを事業収入の中核としない企業や公共の組織では、プロジェクト期間外にプロジェクトマネージャー職を常設することはなく、プロジェクトが始まる際に、従業員や職員の中からプロジェクトマネージャーを任命するのが一般的です。プロジェクトメンバーについても同様です。
情報システム関連のプロジェクトであれば情報システム部門の担当者の中からプロジェクトマネージャーとメンバーが選ばれ、対象の業務部門からもメンバーが選ばれることになります。
その際、経験のない人がプロジェクトマネージャーやプロジェクトメンバーに任命されると、何から手をつければいいのか、どのように進めていけばいいのかがわからず手探りになってしまいます。
そのような場合、PMBOKはガイドラインとして威力を発揮します。PMBOKはボリュームが大きく、初めて読む人にとってはわかりにくい箇所も多く理解に時間がかかるため、適切に活用するためには普段から読みこなしておく必要がありますが、本記事に記載の基本的な考え方を知っているだけでも、そのふるまいや活動のイメージを持つことができるようになるのではないでしょうか。
また、PMIが示唆しているように、プロジェクトに関する知識はプロジェクトマネージャーだけが持っていればいいというものではありません。プロジェクトメンバーになる人やその他のプロジェクト関係者が全員PMBOKに触れておくことは、プロジェクトをスムーズに、効果的に進める上でとても重要なポイントです。
とはいえ、定常業務を抱えるユーザー組織メンバーだけでプロジェクトを円滑に進めることは簡単なことではありません。GPTechでは、プロジェクトマネジメントの専門知識を活用し、IT調達支援サービスを行っています。お困りの際には、是非お気軽にお問い合わせください。
あわせてこの記事をチェック
この記事の編集者
下里 朋子
自治体で情報政策分野を9年間担当した後、IT調達ナビの運営会社である（株）グローバル・パートナーズ・テクノロジーに中途入社。ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するメディア運営業務にも携わる。
