PMBOK 第7版(原則ベースのプロジェクトマネジメント)
1. 概要
A. 定義
PMBOK 第7版(A Guide to the Project Management Body of Knowledge, 7th Edition, 2021)は、PMI(Project Management Institute)が発行したプロジェクトマネジメント標準であり、従来の「プロセス・知識エリア中心(what to do)」の記述から脱却し、12個の原則(Principles)と8個のパフォーマンスドメイン(Performance Domains)を軸とする「原則・成果中心(how to think)」の体系へ転換した指針書である。成果物ではなく価値(Value)の提供を最上位の目標に置き、予測型・適応型・ハイブリッド型など、いかなる開発方式にも適用できるように設計されている点が特徴である。
PMBOK 第7版の本質は「標準がすなわち方法論ではない」という再定義にある。第6版までは5個のプロセス群 × 10個の知識エリアのマトリクスの中に49個のプロセスを配置し、各プロセスの入力・ツール・技法(ITTO)を詳細に規定する方式であった。この構造は「何を、どの順序で産出するか」を明確に示す利点があったが、アジャイル・リーン・ハイブリッドのように逐次的なプロセスの流れを前提としない方式が普及するにつれ、現実との乖離が大きくなった。第7版はこの問題に正面から取り組むため、特定のプロセスを強制する代わりに、「いかなる状況でも守るべき思考の原則」と「必ず成果を出すべきドメイン」だけを規定し、具体的な実行方法は組織が自ら仕立てる(Tailoring)ことに委ねた。
すなわち第6版が「レシピ(Recipe)」であったとすれば、第7版は「料理の原理(Principle)」に近い。何を作るにせよ守るべき衛生・うま味・味付けの原則を提示しつつ、韓国料理であれ西洋料理であれ具体的な調理手順は料理人(プロジェクトチーム)が状況に応じて決めよ、というアプローチである。
B. 登場背景と必要性
この転換の背景には、ソフトウェア・デジタル産業を中心とした適応型(アジャイル)開発の主流化がある。第6版(2017)もアジャイルを付録・別冊ガイド(Agile Practice Guide)で扱ってはいたが、本文の骨格は依然として予測型(ウォーターフォール)プロセスに合わせられていた。その結果、スクラム・カンバンで働くチームは標準と実際の業務との間の違和感を甘受しなければならなかった。市場は「開発方式に中立な(delivery-approach-agnostic)標準」を求め、PMIはプロセス中心の骨格を捨てる抜本的な改編で応えた。
もう一つの原動力は価値(Value)中心への重心移動である。従来の管理は「スコープ・スケジュール・コスト(三重制約)を守ったか」で成功を判定したが、定められたスコープを定められた予算で提供しながらも、肝心の組織に価値を与えられないプロジェクトは珍しくなかった。第7版は成功の基準を「計画遵守」から「期待した成果(Outcome)と価値の実現」へ移し、そのためにプロジェクトを組織全体の価値提供システム(Value Delivery System)の一構成要素として再配置した。不確実性が高く複雑な今日のプロジェクト環境において、規定された手順の遵守よりも状況適応力と価値判断力がより重要になったという認識が反映されている。
2. 全体構造 — 標準書と手引きの二元構造
PMBOK 第7版は大きく二つの部分で構成される。第一はプロジェクトマネジメント標準書(The Standard for Project Management)で、12個の原則を収めた規範的(normative)な部分であり、第二はPMBOK手引き(PMBOK Guide)で、8個のパフォーマンスドメイン・テーラリング・モデル/方法/成果物を収めた説明的な部分である。以下の構造図は、価値提供システムの中で原則とパフォーマンスドメインがどのように噛み合うかを示す。
flowchart TD
VDS["価値提供システム(Value Delivery System)"]
STD["標準書: 12 原則(Principles)"]
GUIDE["手引き: 8 パフォーマンスドメイン(Performance Domains)"]
TAILOR["テーラリング(Tailoring)"]
MMA["モデル・方法・成果物(Models/Methods/Artifacts)"]
VALUE["価値(Value)の実現"]
VDS --> STD
VDS --> GUIDE
STD -->|"行動指針を提供"| GUIDE
GUIDE --> TAILOR
TAILOR --> MMA
MMA --> VALUE
GUIDE --> VALUE
ここでの核心的な関係は、原則が「なぜ・どう考えるか」を、パフォーマンスドメインが「何において成果を出すか」を規定し、テーラリングがこれを特定のプロジェクト文脈に合わせて調整し、モデル・方法・成果物が実際の実行ツールを提供するという流れである。原則は羅針盤、パフォーマンスドメインは点検すべき管制塔の計器盤、テーラリングは航路調整、モデル・方法・成果物は航海装備に例えることができる。
この二元構造が持つ実務的な意味は、標準書(原則)はめったに変わらない安定した規範として置き、急速に進化する実行知識(モデル・方法)はデジタルプラットフォームで継続的に更新することにより、標準の安定性と実務の迅速性を分離して確保するという点である。過去のように新しい技法が登場するたびに標準書全体を改訂する必要はなく、原則は維持しながら実行ライブラリだけを更新すればよい。これは技術変化の速度が速いITプロジェクトマネジメントにおいて特に有効な設計である。
3. 12個の原則(Principles)
原則はプロジェクト関係者の行動を導く根本規範であり、特定の方法論に従属しない。各原則は「必ずこうせよ」という手順ではなく、「この方向で判断せよ」という羅針盤である。12個の原則は互いに独立してはおらず相互強化の関係にあり、たとえば「スチュワードシップ」と「リーダーシップ」は共に働いてこそ信頼を生む。
| 原則 | 核心的な意味 |
|---|---|
| スチュワードシップ(Stewardship) | 誠実・尊重・配慮をもって責任ある管理 |
| チーム(Team) | 協働的なプロジェクトチーム環境の醸成 |
| ステークホルダー(Stakeholders) | ステークホルダーと効果的に関与 |
| 価値(Value) | 価値に焦点 |
| システム思考(Systems Thinking) | システム相互作用の認識・評価・対応 |
| リーダーシップ(Leadership) | リーダーシップ行動の発揮 |
| テーラリング(Tailoring) | 文脈に合わせて調整 |
| 品質(Quality) | プロセス・成果物に品質を内在化 |
| 複雑性(Complexity) | 複雑性の航行 |
| リスク(Risk) | リスク対応の最適化 |
| 適応・回復力(Adaptability & Resiliency) | 適応性・回復力の受容 |
| 変化(Change) | 未来の状態を達成するための変化の支援 |
このうち価値の原則は第7版の哲学の頂点である。従来は「要求仕様どおりに提供したか」が成功尺度であったが、第7版は成果物が実際に組織・顧客に便益を与えるときにのみ価値が実現されると見る。たとえば電子政府の民願システムを予算とスケジュールに合わせて開始したとしても、市民の実際の利用率と処理時間の短縮という成果がなければ価値を実現したとは見なさない。したがってチームは開発の途中であっても「この機能は本当に価値を与えるか」を持続的に問い直さなければならない。
テーラリングの原則は第7版が方法論を強制しないという宣言の根拠である。規制が厳格な金融の次世代システムは文書・承認手続きを強化した予測型に近く、スタートアップの新規アプリは短い反復(スプリント)中心の適応型に近く仕立てる。同じ組織の中でもプロジェクトの規模・リスク・規制の強さに応じて異なる方式を採択でき、この判断そのものがプロジェクトマネージャーの核心的力量となる。
複雑性・リスクの原則は不確実性が定数となった環境を反映する。大規模SI事業で多数のステークホルダー・レガシー連携・規制変化が絡むと因果関係が非線形に絡み合う(創発性)が、このときは定められた計画を押し通すよりも小さな実験で状況を探索し学習するアプローチが有効である。
スチュワードシップ・リーダーシップ・チームの原則は「人」を管理の中心に置く。スチュワードシップは組織内外の資源を信託されたかのように誠実・透明に扱う責任を、リーダーシップは職位の権限ではなくビジョン提示・動機づけ・葛藤調整といった行動を強調する。特に自律性の高まったアジャイルチームでは「指示するマネージャー」よりも「障害を除去するサーバントリーダー」が成果を出すという点がこの原則に反映されている。三つの原則が共に働くとき、チームは心理的安全感の上で自己組織化し、それはすなわち提供速度と品質につながる。
4. 8個のパフォーマンスドメイン(Performance Domains)
パフォーマンスドメインはプロジェクトが価値を提供するために必ず成果を出さなければならない相互に関連した活動の束である。プロセスのように逐次的に遂行されるのではなく、プロジェクト全期間にわたって同時に・持続的に作動する。以下の図は8個のパフォーマンスドメインが互いに影響を及ぼし合いながら価値へ収束する相互作用の構造を示す。
flowchart LR
subgraph PD["8個のパフォーマンスドメイン"]
SH["ステークホルダー"]
TM["チーム"]
DA["開発方式・ライフサイクル"]
PL["計画(Planning)"]
PW["プロジェクト作業"]
DL["提供(Delivery)"]
MS["測定(Measurement)"]
UN["不確実性"]
end
SH --> DL
TM --> PW
DA --> PL
PL --> PW
PW --> DL
MS -->|"フィードバック"| PL
MS -->|"フィードバック"| PW
UN -->|"リスク調整"| PL
DL --> VAL["価値(Value)"]
MS --> VAL
各ドメインを個別に理解するよりも、これらが一つのシステムとして相互作用するという点を把握することが重要である。たとえば測定(Measurement)ドメインで得た成果データ(例: バーンダウンチャート、EVM指標)は計画とプロジェクト作業へフィードバックされて計画を調整させ、不確実性ドメインのリスク分析結果は計画のバッファ(Buffer)と対応戦略を変える。
開発方式・ライフサイクル(Development Approach and Life Cycle)ドメインは第7版で特に重要になった部分である。このドメインでプロジェクトは予測型(Predictive)・適応型(Adaptive)・ハイブリッド型(Hybrid)のうち何を選ぶかを決定し、提供ケイデンス(一度に提供するか、複数回に分けて提供するか)を設計する。たとえばインフラ構築は予測型で、ユーザー体験が重要なフロントエンドは適応型で進めるハイブリッド型が大規模プロジェクトでよく採択される。
提供(Delivery)ドメインはスコープ・品質要求を満たす成果物と成果を実際に提供する活動であり、要求管理・スコープ定義・品質確保を含む。このドメインが第6版の複数の知識エリア(スコープ・品質の一部)を成果の観点で統合した。
残りのドメインも第6版の知識エリアを成果の観点で再編したものである。ステークホルダー(Stakeholders)ドメインは関係者を識別・分析し持続的に関与させて彼らの要求と期待を管理する活動であり、プロジェクト成功の半分がここで決まると見なせるほど重要である。チーム(Team)ドメインはリーダーシップ・協働・動機づけを通じて高成果チームを作る活動を、計画(Planning)ドメインはスコープ・スケジュール・予算・資源の計画を状況に合わせて反復的に立てる活動を扱う。プロジェクト作業(Project Work)ドメインはチームが実際に仕事を遂行できるようプロセス・物理資源・調達・意思疎通を管理する運営的活動であり、測定(Measurement)ドメインは成果指標(KPI・EVM・バーンダウン)を通じて進捗と価値を定量化し調整信号を提供する。不確実性(Uncertainty)ドメインはリスク・曖昧さ・変動性・複雑性に対応する活動であり、第7版が「不確実性を管理対象として明示した」という点そのものが現代のプロジェクト環境の特性を反映している。8個のドメインはいずれか一つが不振であれば他のドメインの成果まで蝕む相互依存の関係にあるため、マネージャーは特定のドメインにのみ集中せず全体の均衡を持続的に点検しなければならない。
5. 第6版と第7版の比較 — なぜ変わったのか
両版の違いは単なる目次の改編ではなく、プロジェクトマネジメントを見るパラダイムの転換である。第6版が「定義されたプロセスを正確に遂行すれば成功する」という前提(定義的・規定的)に立っていたとすれば、第7版は「状況は毎回異なるため原則に従って判断し適応しなければならない」という前提(経験的・適応的)に立つ。
| 区分 | 第6版(2017) | 第7版(2021) |
|---|---|---|
| 中心軸 | 5プロセス群 × 10知識エリア、49プロセス | 12原則 + 8パフォーマンスドメイン |
| アプローチ | プロセスベース(What/How to do) | 原則ベース(How to think) |
| 成功基準 | スコープ・スケジュール・コストの遵守 | 価値(Value)・成果(Outcome)の実現 |
| 開発方式 | 予測型中心(アジャイルは付録) | 方式中立(予測・適応・ハイブリッド) |
| 実行ツール | ITTO(入力・ツール・技法)の詳細規定 | モデル・方法・成果物 + テーラリング |
この違いが生じる根本的な理由は環境の変動性(Volatility)である。要求が安定し反復可能なプロジェクトではプロセス標準化が効率的だが、要求が頻繁に変わり技術が急速に進化するデジタルプロジェクトでは硬直したプロセスがかえって対応を遅らせる。ただし第7版が第6版を廃棄したのではなく、第6版のプロセス知識はPMIstandards+というオンラインのデジタルプラットフォームへ移管され、「実行方法ライブラリ」として依然として参照される。すなわち原則(標準書)と実行知識(デジタルプラットフォーム)を分離したことが第7版の構造の実体である。
実際の試験・実務で留意すべき点は、第7版がEVM・WBS・クリティカルパスのような伝統的技法を「捨てたのではなく」テーラリングを通じて必要なときに取り出して使うツールとして再配置したという点である。たとえば政府の大型SI事業は依然としてWBS・EVMを要求し、第7版の体系においてもこれらは「測定」パフォーマンスドメインの有効な方法・成果物として活用される。
もう一つ指摘すべき点は資格試験(PMP)との関係である。PMP試験は第7版発行以前の2021年初めから既に「予測型・アジャイル・ハイブリッド」を均等に扱う試験概要(ECO, Examination Content Outline)へ改編され、人(People)・プロセス(Process)・ビジネス環境(Business Environment)の三領域を評価する。したがって第7版の原則・パフォーマンスドメインの体系はこの試験改編の方向と一貫しており、標準書・手引き・試験がすべて「方式中立・価値中心」という一つの方向に整列したと理解すればよい。
6. 深化 — テーラリング(Tailoring)と実務適用戦略
第7版を実務に適用する際に最も核心となる活動はテーラリング(Tailoring)である。テーラリングはプロジェクトの文脈(規模・複雑性・規制・組織文化・チーム習熟度)を診断し、それに合わせて開発方式・プロセス強度・成果物の種類・ガバナンス水準を調整する意思決定プロセスである。テーラリングはプロジェクト着手時に一度行って終わるものではなく、振り返り(Retrospective)と測定データに基づいて持続的にやり直す反復活動である。
テーラリングは通常三段階で進む。第一に初期の開発方式を選択し(予測・適応・ハイブリッド)、第二に組織・プロジェクトの特性に合わせてプロセスと成果物を加減し、第三に実行中に振り返りと測定データを根拠に持続的に微調整する。この過程で組織のプロジェクトマネジメントオフィス(PMO)はテーラリングのガードレール(許容範囲と最小の統制基準)を提供し、個々のチームの自律的なテーラリングが組織全体の一貫性・監査可能性を損なわないよう調整する役割を担う。
テーラリングの実務的な含意は「より多くの管理が常により良いわけではない」という点にある。小規模プロジェクトに大企業の標準文書セットを強要すれば管理オーバーヘッドが価値を蝕む(過剰テーラリング)。逆に規制産業の大型プロジェクトに軽量プロセスのみを適用すれば統制の空白がリスクを大きくする(過少テーラリング)。したがってテーラリングの目標は「価値を最大化する最小限の十分な(minimum viable)管理体系」を設計することである。
国内の公共・金融圏の適用を見ると、依然として契約・監理・成果物の規定が予測型を前提とする場合が多く、完全な適応型への転換は難しい。このため要求が明確なバックエンド・インフラは予測型で、ユーザー接点は反復改善するハイブリッド型(Hybrid)のテーラリングが現実的な折衷案として定着しつつある。近年は組織レベルでプロジェクトを越えてプロダクト(Product)中心の運営へ移行し、第7版の「価値提供システム」概念と結合して常設のチームが持続的に価値を提供するモデルが広がっている。たとえばある金融持株会社は次世代システムを予測型の骨格の上にアジャイルスクワッドを乗せるハイブリッド型に仕立て、規制対応(文書・監査)と市場対応速度を同時に確保した事例が報告されている。
7. 考慮事項および示唆点
- 適用戦略(移行管理): 第6版に慣れた組織が第7版へ移行するときは「プロセスの廃棄」ではなく「原則に基づくプロセスの再解釈」としてアプローチしなければならない。既存のWBS・EVM・リスク登録簿を捨てず、それぞれがどの原則・パフォーマンスドメインに寄与するかを再マッピングしてテーラリング基準を立てることが失敗を減らす道である。
- トレードオフ(柔軟性 vs 統制): 原則ベースの柔軟性は習熟したチームでは強力な自律性として作動するが、未熟な組織では「何をすべきか分からない」混乱を生みかねない。組織成熟度(CMMI水準、アジャイル経験)を診断してテーラリングの自由度を段階的に付与するガバナンス設計が必要である。
- ガバナンス・監理の整合性: 国内の公共事業の監理基準・契約成果物の規定が依然としてプロセス・文書中心であるため、第7版の成果・価値中心の管理と制度との間の隔たりを埋める「文書マッピング」が実務リスクである。最小限の規定成果物を成果ドメインの活動と結びつけて証憑とする設計が求められる。
- 測定歪みの防止: 価値中心の管理は測定指標に大きく依存するが、指標が目標になった瞬間に歪む(グッドハートの法則)。たとえばベロシティ(Velocity)を成果目標にすればチームがストーリーポイントを膨らませる逆効果が生じる。したがって測定は「統制」ではなく「学習と調整」のためのものだという観点を維持し、成果物指標よりも成果(Outcome)・価値指標を共に見る均衡が必要である。
- 連携技術・展望: 第7版はアジャイル(スクラム・カンバン・SAFe)・リーン・デザイン思考・DevOpsと自然に結合し、今後はAIベースのプロジェクト予測(スケジュール・リスク分析)とプロダクト中心の運営が「価値提供システム」概念をさらに強化すると展望される。技術士の観点では、特定の方法論の知識よりも「文脈に合ったテーラリング能力」と「価値判断力量」が核心的競争力となる。
参考資料
- Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management", 2021. https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
- PMI, "PMIstandards+ (Digital Content Platform)". https://standardsplus.pmi.org/
一言まとめ: PMBOK 第7版は、49個のプロセス中心から12個の原則・8個のパフォーマンスドメイン中心へ転換し、開発方式に中立で価値(Value)の実現を目標とし、文脈に合ったテーラリング(Tailoring)をプロジェクトマネジメントの核心的力量とした原則ベースの標準である。