「プロジェクトをしっかり計画したのに、なぜうまくいかないのか」—— PMBOKはプロセス重視から原則重視へと大きく進化しました。2025年リリースの第8版で示された6つの原則を、建設・IT・マーケティングなどの事例を交えながら解説。不確実性が高まる現代のプロジェクト現場で、何を軸に判断するかを考えます。
～ ～ ～ ～ ～
はじめに
以前より、プロジェクトが計画通りに進まなくなった —— そう感じることはありませんか？
私は今現在、本業ではアメリカで不動産開発プロジェクトに事業主側のプロジェクトマネージャーとして携わっています。
アメリカではコロナ禍の低金利時代から一転、現在は金利の高止まりが続いており、融資を活用して投資リターンを最大化しようとしても、金利負担が収益を圧迫する状況が続いています。資材や人件費の高騰、行政の手続きの複雑化と長期化、そしてトランプ政権による関税政策などがもたらす不確実性も重なり、特に都市部の高層ビル開発において収益計画を立てることは、とても難しくなっています（2026年3月執筆時）。
住宅不足は深刻であるにもかかわらず、一般の買い手や借り手に手の届く住宅を提供することは、コスト面からとても困難な状況です。オフィス市場も低迷が続いています。コロナ後にリモートワークが定着し、一部企業でオフィス回帰の動きも見られるものの、コロナ前のような状況に戻ることは考えにくく、空室率の高い状態が続くでしょう。
プロジェクトの進め方そのものも変わりました。
業務は細分化され、チームがオンラインでミーティングすることが当たり前になった一方で、メンバー同士が一度も直接顔を合わせたことがないまま仕事を進めるケースも珍しくなくなりました。互いの状況が見えにくい中では、思わぬ連携ミスが起きやすくなります。また、離れた場所で働くチームのエンゲージメントや一体感を保つためには、意識的な工夫が必要です。物理的な距離は、コミュニケーションだけでなく、チームのパフォーマンスや文化にも影響を与えます。一方で、皆複数の業務を抱えていて、より多くの仕事をより少ない時間で進めなければなりません。
このように、わずか数年の間でも、プロジェクトを取り巻く環境は大きく、そして複雑に変化しています。
かつては「正しいプロセスを正しく実行すれば、プロジェクトは成功する」という考え方が主流でした。私がPMP（Project Management Professional）の資格を取得した2005年当時のPMBOK®も、まさにその考え方に基づいており、綿密な計画、徹底した管理、徹底した文書化を重視した体系でした。その明確で強力な枠組みは、多くのプロジェクトを成功に導いてきました。
しかし今、その前提そのものが揺らいでいます。
テクノロジーの急速な進化、グローバル化、複雑化するステークホルダー関係、そして経済・政治環境の急激な変化、さらには私たちが大切にする価値観の変化。「予測できることを正確に実行する」アプローチだけでは、現代のプロジェクト現場には対応しきれなくなっています。
そのような時代の変化を受けて、プロジェクトマネジメントの国際標準であるPMBOK®ガイドも大きく進化してきました。第7版では「プロセスを正しく実行すること」に加えて、「原則に基づき、状況に応じて判断し、価値を届けること」という視点が加わりました。そして2025年にリリースされた第8版では、その原則がさらに洗練され、6つに統合されています。
この記事では、PMBOKがたどってきた変遷を振り返りながら、第8版で示されている6つの原則（Principles）とは何か、そして実際のプロジェクト現場でどのような意味を持つのかを、具体的な事例を交えながら解説していきます。「手順を守ること」と「価値を届けること」は、本来、対立するものではありません。しかしその両立が難しい場面もあるからこそ、原則という考え方が重要になります。
～ ～ ～ ～ ～
PMBOKの変遷：プロセス重視からバリュー重視へ
2025年11月に、プロジェクトマネジメントの国際標準である『PMBOK®ガイド（プロジェクトマネジメント知識体系ガイド）』の最新版である第8版（英語版）がリリースされました（なお、本記事投稿時点では日本語版はまだ出版されていません）。
私が米国のPMIが認定するプロジェクトマネジメントに関する国際資格であるPMP（Project Management Professional）の資格を取得したのは2005年1月で、当時は第3版が最新版でした。
当時のPMBOKは、プロジェクトにかかる事象はある程度予測可能であり、綿密に計画してその通りに実行すれば成果にたどり着くことができるという前提に立ち、プロジェクトに必要なプロセスとステップを明確にし、確実に行うことを重視した構成になっていて、計画と文書化と管理に重きが置かれていました。
具体的には「統合、スコープ、スケジュール、コスト、品質、人的資源、コミュニケーション、リスク、調達」という9つの管理領域（2013年の第5版からステークホルダーが追加され10に拡大）を、「立上げ、計画、実行、監視・コントロール、終結」という5つのプロセスの流れの中で体系的にマネジメントする枠組みでした。
しかし、その後、プロジェクトは多様化していきます。
テクノロジーの進化やグローバル化、複雑化、求められる成果へのスピード感の変化によって、部門横断的かつ急速な変化が起きました。手順を確実に実行する従来の予測可能型（ウォーターフォール型）のアプローチでは、多くのプロジェクトが通用しなくなってきました。
2017年のPMBOKガイド第6版は、不確実性に対応する『アジャイル実践ガイド（Agile Practice Guide）』と同時にリリースされ、変化への適応性を組み込みました。この第6版が、その後のPMBOKの変化のターニングポイントになっています。
続く2021年の第7版では、『プロジェクトマネジメント標準（The Standard for Project Management）』がPMBOKと組み合わされてリリースされ、その中で「原則（Project Management Principles）に基づくアプローチ」が導入されました。
「原則」とは「手順」ではなく、あらゆる種類のプロジェクトに適用される高レベルの「行動指針」です。
「原則に基づくアプローチ」は、期待される成果や価値に重点を置き、手順やプロセスを明確に決められない場合でも、専門的判断と倫理的な行動を通して意思決定を導くものです。
つまり「プロジェクトを成功させるためのプロセス」に「プロジェクトを成功させるための原則」を加えたのです。これによって、従来型の予測型プロジェクトだけでなく、より不確実性の高いアジャイル型やハイブリッド型のアプローチへのサポートも可能になりました。
さらに第7版には「チェンジマネジメント」のコンセプトも導入されています。それ以前の版では、スコープ・スケジュール・コストのベースラインからの変更対応、つまり「変更管理」は含まれていましたが、それは「技術的な変化」に限られていました。
しかし第7版では、ステークホルダーのエンゲージメント、チームのパフォーマンス、リーダーシップなど組織変化の要素が加わり、技術面での変更に加えて「人的・心理的側面の変化」が取り入れられました。なぜなら、プロジェクトの成功には、技術的な要因だけでなく、意義や目的感、やる気、主体性、変化への適応性といった、関係者の人的側面、心理的要因が大きく左右するからです。
プロジェクトマネジメントの原則に関しては、第8版にも引き継がれていますが、第7版の12原則から6つの原則に統合・整理されています。それぞれの原則間の重複や細分化が解消し、より本質的な行動指針として再定義されると共に、実務に落とし込みやすくなりました。
つまり、PMBOKは次のように発展してきました。
「プロジェクトマネジメントとは一連のプロセスである」
⬇
「プロジェクトマネジメントとは価値を提供するためのシステムである」
⬇
「プロジェクトマネジメントは、専門的、倫理的な判断に基づく原則によって導かれる」
～ ～ ～ ～ ～
原則（Principles）に基づくアプローチ
先ほど紹介したように、第7版でPMBOKは大転換しました。それまでの「プロセスを正しく実行すること」に「原則に基づき、状況に応じて判断し、価値を届けること」が加わったからです。
第7版に対して、原則を実践するための実用的なガイダンスが明確でないという批判もありますが、それは原則がマニュアル化できるものではないからです。原則は手順やプロセスではなく、プロフェッショナルとしてのあり方や、プロジェクトに向き合う姿勢そのものだからです。
原則は方法論ではありません。原則は行動の核となるものであり、予測型かアジャイルかというプロジェクトの形態に関わらず、「何を大切にし何を守るのか」という信念であり行動原理です。それは、パフォーマンス領域、プロセス、手法以上のもので、変化に適応し価値を創出する「成長マインドセット」とも呼ばれる心の持ち方です。
プロジェクトマネジメントのマインドセットは、①プロアクティブ（積極性）、②オーナーシップ（主体性）、そして③価値主導という3つの次元で構成されています。この統合されたマインドセットは、多様な顧客ニーズのバランスを取り、持続可能性の重要性が高まる今日の複雑で急速に変化するビジネス環境において、不可欠なものとなっています。
それでは次に、第8版で示されている6つの原則について順番に解説していきましょう。
～ ～ ～ ～ ～
１．全体的な視点を取り入れる（Adopt a Holistic View）
「全体的な視点を取り入れる」ことは、システム思考と関連しています。「システム思考」とは、物事の仕組みやつながりを理解することです。プロジェクトを個別のタスク、フェーズ、または一部門としてではなく、相互に関連し合う大きなシステムとして見ることです。
複雑なプロジェクトでは、一部を改善しようとして、システム全体の問題を引き起こすことがあります。そして、その影響には短期的なものと長期的なものがあります。
問うべき問いを「このタスクをどのように最適化するか？」から「この意思決定は全体の仕組みにどのような影響を与えるか？」へ、また「この問題はどう解決できるか？」から「この問題の背景にある本質は何か？」へと広げることで、プロジェクト内外のさまざまな要素間の関連性や相互作用を理解できるようになります。
「木を見て森を見ず」という言葉がありますが、部分だけを見るのではなく、視野を高く上げて鳥の目線から全体を見渡すのです。そうすると、問題だけを見つめていては気づかなかった他の要素との関連性や課題が見えてきます。
【例１】新しいERPシステムの導入
✖ 狭く限られた視点
・技術的な導入のみに注力し、システム稼働開始と共にプロジェクトが終了
〇 全体的な視点
・従業員の準備状況をモニタリングし、サポートデスクを設置する
・従業員の抵抗感の背景を理解し、プロセスを段階的に変更しながら進める
・システム移行中の生産性低下や顧客への影響にも対処しながら進める
【例２】建設工事での、より安価な資材への変更
✖ 狭く限られた視点
・「200万円の材料費削減になるので、この材料で進める」と判断する
〇 全体的な視点
・スケジュールや作業性への影響、耐久性やライフサイクルコストへの影響
・法令・契約上の要件や保証上の制約を確認する
・隠れたリスクや二次的・長期的な影響がないかを検証する
～ ～ ～ ～ ～
２．価値にフォーカスする（Focus on Value）
いくら予算内で時間通りにシステムを導入できたとしても、顧客やユーザーが価値を感じなければ意味はありません。「スコープ、スケジュール、コスト」を管理するだけでは不十分です。
価値（value）は、プロジェクトの成功指標であり、プロジェクトを推進する力です。金銭的成果、社会的貢献など、さまざまな形で表現されます。
価値に焦点を置くことで、プロジェクトチームは特定の成果物を完成させるだけでなく、その成果物を通じてプロジェクトや組織のビジョン・目的を実現できるようになります。プロジェクトの成果物が望ましい価値を実現できなけば、時間とリソースの無駄遣いとなり、有益というよりむしろ有害になる可能性さえあります。
【例１】グローバルなマーケティングキャンペーンの立ち上げ
✖ 成果物重視
・すべての広告を当初計画通りに配信する
〇 価値重視
・コンバージョン率と顧客獲得コストを測定する
・データに基づき、キャンペーン期間中にメッセージを調整する
・パフォーマンスの低いチャンネルは停止する
【例２】ある病院へのシステム導入中に、別の系列病院からも参加の申し出があった
✖ 成果物重視
・決められた工期と予算で、最初に定められたスコープのみを完了する
〇 価値重視
・両病院を別々のサーバーで開始すると、サイロ化するリスクを認識
・スコープを再定義し、複数の病院で共有できる大容量サーバーを導入することを提案
・IT費用増加とスケジュール延長は伴ったが、将来的によりさらに多くの病院の参加が可能になった
～ ～ ～ ～ ～
３．品質を組み込む（Embed Quality）
「品質を組み込む」とは、仕事のプロセスそのものに品質を埋め込むことであり、製造の最終段階で品質を検査することではありません。極端を言えば、品質を埋め込むことができれば、最終検査がなくても高い品質を維持できます（最終検査が不要と言っているわけでは決してありません）。
【例１】商業オフィスビルの建設プロジェクト
✖ 誤った考え方
・構造検査は最終検査時のみ行えばよい
〇 品質を組み込む
・作業に入る前に、品質プロセスと使用するチェックリストを明確にする
・プロセスに従って、納入前に材料認証を確認する
・次の施工ステップに進むためには、チェックリストの全項目が合格になっている必要がある
・小さな不具合が生じた際は、すぐに根本原因を分析する
【例２】病院における新しい医療情報システムの導入
✖ 誤った考え方
・システムを稼働してから、スタッフの苦情やワークフローの問題に対応する
〇 品質を組み込む
・要件定義のワークショップに看護師と医師を参加させる
・システム稼働までのガイドラインと承認ワークフローを作成する
・実際のユーザーを対象にユーザビリティテストを実施する
・完全導入前に1つの部門でパイロット運用を行う
・稼働前にユーザートレーニングを実施し、フィードバックを収集する
～ ～ ～
「品質管理（QC）ではなく品質保証（QA）に重点を置くということですね？」と感じる方も多いでしょう。
基本的にはその通りですが、「品質の組み込み」はそれよりも広い意味合いを持ちます。品質が単なるプロセス領域ではなく、原則として扱われているからです。つまり、品質はシステムやテストだけでなく、思想や文化でもあります。
検査よりも予防を重視するシステムが導入されているだけでなく、姿勢・計画・実行・ガバナンスが文化に根ざしていること——「品質が、プロジェクトで行うすべてのことに意図的に組み込まれている」ということです。
品質の第一人者であるデミングは「仕事はシステムである」という考えを強く信じていました。デミングが提唱したPDCA（Plan-Do-Check-Act）サイクルも、継続的な改善のマインドセットに基づく「品質を組み込む」実践の一例です。
「品質の組み込み」とは、具体的には次のようなことです。
- 欠陥を検出するのではなく予防すること
- 関係者を早期に巻き込むこと
- 品質基準を事前に定義すること
- 継続的なフィードバックループを活用すること
- アウトプットだけでなくプロセスを改善すること
- 品質を全員の責任として扱うこと
～ ～ ～ ～ ～
４．責任あるリーダーになる（Be an Accountable Leader）
プロジェクトは、リーダーシップのニーズを生み出します。
役割が確立されたルーチンワークとは異なり、プロジェクトにはリーダーが必要です。
リーダーとは「権限」や「権威」や「地位」ではありません。
主体性、倫理観、そして意思決定における責任感 —— それがリーダーの本質です。
この違いはとても重要です。権限は委譲できますが、主体性や倫理観や責任感は偽造できません。正式な権限（肩書き、役職、階級）を持っていても、主体性や責任感がなければ、ただ「そのポジションにいるだけの人」になります。逆に、正式な権限がなくてもリーダーシップを持ち、発揮する人もいます。
責任あるリーダーには、次のような特徴があります。
- 誠実で、正直で、公平で、倫理的かつ透明性のある行動をとり、約束を果たす
- 自らの動機・価値観・強みを理解し、感情と思考を成果につなげることができる
- 心理的安全性のある環境を育み、対話を生み出しチームをサポートする
- フィードバックを謙虚さと敬意を持って受け止め、状況や相手に応じて柔軟に行動スタイルを調整する
- 他者に影響を与え、鼓舞し、動機づけ、自身の行動に責任を負い、模範を示す
【例１】複雑性の過小評価により製品リリースが遅延
✖ 責任を負わないリーダー
・見積もりの不備を開発者のせいにする
・スポンサーから遅延を隠す
・「チームメンバーが失敗した」と言う
〇 責任あるリーダー
・スポンサーに事実を早期に報告する
・見積もりの監督責任を自ら負う
・チームと協力して再予測を行い、スコープや工程を共同で調整する
・政治的な影響からチームを守る
・プロジェクトの意思決定を組織戦略と整合させる
【例２】プロジェクトの予算超過
✖ 責任を負わないリーダー
・報告書を改ざんしたり、目立たないよう書き方を指示する
・最新の収益情報の報告を遅らせる
〇 責任あるリーダー
・根本原因を直ちに分析する。差異をスポンサーに伝え、改善策を提示する
・監督上の責任を自ら負う
【例３】チームメンバーのパフォーマンスが徐々に低迷
✖ 責任を負わないリーダー
・問題の根本原因に向き合わない
・自分の責任とせず、人事部など他部署に苦情を言う
〇 責任あるリーダー
・率直で敬意のあるフィードバックのやり取りを行う
・メンバーへの期待を明確に設定する
・積極的にコミュニケーションを取って障害を取り除き、コーチングによって主体的な行動を引き出す
～ ～ ～ ～ ～
５．持続可能性の統合（Integrate Sustainability Within All Project Areas）
「すべてのプロジェクト領域に持続可能性を統合する」という原則は、第8版の改訂で新たに導入されたものです。
持続可能性とは「将来の世代のニーズを満たす能力を損なうことなく、現在のニーズを満たすこと」です。
プロジェクトのライフサイクル全体を通して、環境・社会・経済への影響を考慮します。「このプロジェクトを成功させることができるか？」から「社会的責任を持って、持続的に遂行できるか？」へと考え方を転換することが求められます。
【例】調達における持続可能性の統合
✖ コストのみを重視
・一番安いグローバルサプライヤーを選択する
・サプライヤーの労働条件や環境コンプライアンスリスクを無視する
・地域社会への影響を見落とす
〇 持続可能な統合
・調達基準に持続可能性を組み込み、サプライヤーの環境および労働慣行を評価する
・契約にサステナビリティ条項を含める
・サプライヤーの監査を実施する
・地域社会のステークホルダーを巻き込む
～ ～ ～ ～ ～
６．エンパワーメント文化の構築（Build an Empowered Culture）
最後に「エンパワーメント文化の構築」とは、「チームをコントロールする」から「チームの成功を支援する」へと意識を変えることです。
ステークホルダーとチームメンバーは、さまざまな側面からプロジェクトの成功に貢献できます。信頼され、権限を与えられることで、力を発揮することができます。そのような環境をつくり出すことが、リーダーの役割です。
組織構造を理解したうえで、オープンなコミュニケーションと相互理解に基づく協力的なチームを構築し、マイクロマネジメントではなく、信頼関係と相互尊重によって積極性や自律性を醸成します。
【例１】アジャイルプロダクトチームが新機能を開発
✖ エンパワーメントがない
・プロジェクトマネージャーがすべてのタスクを割り当て、すべての決定にPMの承認が必要
・チームは異議を申し立てることを恐れている
〇 エンパワーメントがある
・チームが自ら作業を計画し、振り返りを行い、改善を実施する
・ユーザーを組み入れたフィードバックループがある
・プロジェクトマネージャーは作業を指示するだけでなく、障害を取り除く役割を担う
【例２】建設プロジェクトの現場施工チーム
✖ エンパワーメントがない
・作業員は些細な業務上の決定にも監督者の承認が必要
・威圧的な監督者との対立を避けるため、安全上の懸念を述べることができない
〇 エンパワーメントがある
・作業員には、危険な作業を直ちに中止する権限がある
・作業員からのリスク報告が歓迎され、その機会も設けられている
・職長は定められた範囲内で作業手順を調整できる
・得られた教訓は共有され、毎週の議論を経てその後の作業に反映される
【例３】グローバルなマーケティングキャンペーンの立ち上げ
✖ エンパワーメントがない
・デザインチームは細かな変更にも承認が必要
・サブチームは、地域市場に合わせたメッセージの調整ができない
〇 エンパワーメントがある
・明確なブランドガイドラインが定義されている
・地域チームはブランドのガイドラインに沿ってコンテンツをローカライズする権限を与えられている
・クリエイティブチームは新しいアイデアを試すことを奨励されている
・迅速なフィードバックサイクルが実施されている
～ ～ ～ ～ ～
さいごに
以上、PMBOKがたどってきた変遷を振り返りながら、第8版で示されている6つの原則（Principles）について説明しました。
PMBOKは、「正しい手順を踏むこと」から「価値を届けること」へ、そして「原則に基づいて判断すること」へと進化してきました。その変遷は、単なる版の更新ではなく、プロジェクトマネジメントという実践そのものに対する問いの深まりでもあります。
第8版で示された6つの原則 —— 全体的な視点、価値へのフォーカス、品質の組み込み、責任あるリーダーシップ、持続可能性の統合、エンパワーメント文化の構築 —— は、どれもシンプルに表現されていますが、その実践は、決して簡単ではありません。
なぜなら、原則はマニュアルではないからです。状況を読み、判断し、チームや組織と向き合いながら、繰り返し問い直していくものです。正解が一つではない環境の中で、何を大切にして動くのかを自分の中に持っておくこと —— それがプロジェクトマネジメントにおける「原則を持つ」ということです。
私自身、さまざまなプロジェクトやその他の業務に向き合いながら、「何を軸に判断するか」を問われる場面が増えていると感じています。その意味で、最近のPMBOKの方向性は、個人的な実感とも重なるものがあります。
プロジェクトマネジメントを実践されている方や、これから学ぼうとしている方、あるいはプロジェクトとは関係のない業務に携わっている方も、日々の仕事をいったん振り返ってみてはいかがでしょうか？
