PMBOK第8版とは？第6版・第7版との違いと使い分け【2026年版】

---

計画を精密にしたのに、顧客が欲しいものとずれた。AIを取り入れて開発速度を上げても、意思決定や検証が追いつかない。いま多くのプロジェクトが直面する問題は、「ウォーターフォールかアジャイルか」という二択だけでは解けない。

2021年のPMBOK第7版は、第6版の詳細なプロセスから原則・価値・テーラリングへ大きく重心を移した。そしてPMIは2025年11月にPMBOK第8版を正式公開し、英語ペーパーバック版も2026年1月に刊行された。第8版では、原則と価値を保ちながら、実行を支えるプロセスガイダンスが再び一冊の中でつながった。

では、何を計画し、何を試しながら進めればよいのか。鍵になるのが「予見可能性」である。

予見できるなら計画する。予見できないなら早く試す。そして、どちらの場合もリスクと手戻りを最小化する。

PMBOK第8版とは？第6版・第7版から何が変わったのか

第8版最大の変化は、原則かプロセスかという二者択一を離れ、原則・実務領域・プロセスを再接続したことである。

まず、第6版・第7版・第8版を並べて全体像を確認してみましょう。

※第8版の構造・変更点はPMI公式情報を基に整理しています。一方、表中の「主役」「強い問い」は、各版の特徴を直感的に理解するための本記事独自の整理です。

PMBOK第6版・第7版・第8版の違い

観点	PMBOK第6版	PMBOK第7版	PMBOK第8版
主役	プロセス	原則・価値	原則＋ドメイン＋プロセス
強い問い	どう進めるか（How）	なぜ行うか・何の価値か（Why / Value）	なぜ・何を・どう進めるか（Why / What / How）
代表構造	5プロセス群・10知識エリア	12原則・8パフォーマンスドメイン	6原則・7パフォーマンスドメイン・5 Focus Areas
テーラリング	存在する	前面化	継承し、実務との接続を強化
プロセス	詳細なプロセス体系	大きく後景へ	進化した非規範的な形で再導入
特徴的な論点	体系的な計画・管理	価値・アウトカム・適応	AI・PMO・調達などを拡充
※出典：Project Management Institute（PMI）。第8版はPMI公式版および公式目次を基に整理しています。

第8版は、第7版で採用された原則とパフォーマンスドメインという基本構造を捨てていません。その上で、より簡潔で実行可能な構造へ整理しています。
6つのコア原則は、本記事では次のように理解すると分かりやすいでしょう。

①全体を見る｜②価値へ集中する｜③品質を組み込む｜④説明責任を持ってリードする｜⑤サステナビリティを統合する｜⑥権限を持つチーム文化を築く

7つのパフォーマンスドメインは、ガバナンス、スコープ、スケジュール、財務、ステークホルダー、リソース、リスクです。
ここで注目したいのは、スコープ、スケジュール、財務、リスクという言葉です。
第6版を知るプロジェクトマネージャーなら、どこかなじみを感じるのではないでしょうか。

第7版では思想や原則が大きく前面へ出ました。一方、第8版では、現場でPMが日々向き合う管理対象が再び分かりやすく見えるようになっています。

第8版で再導入された5つのFocus Areas

さらに重要なのが、Project Management Focus Areasです。

PMBOK第8版の5つのFocus Areas

Focus Area	日本語での理解	実務で問うこと
Initiating	立ち上げ	何のために始め、誰にどんな価値を届けるのか。
Planning	計画	何をどこまで事前に決め、何を未確定として残すのか。
Executing	実行	人・資源をどう動かし、価値ある成果へつなげるのか。
Monitoring and Controlling	監視・コントロール	差異・リスク・変化をどう捉え、どこで軌道修正するのか。
Closing	終結	何をもって完了とし、何を次へ引き継ぐのか。
※Focus Areasの名称はPMI公式目次に基づく。「実務で問うこと」は本記事の理解補助のための独自整理。

名前だけを見ると、第6版の5プロセス群がそのまま帰ってきたように見えるかもしれません。しかし、ここを「第6版へ戻った」と理解すると第8版の狙いを見誤ります。

実行を支えるプロセスガイダンスは再び一冊に統合されましたが、第6版の手順を一律に復活させたわけではありません。第8版では5つのFocus Areasとして整理し、テーラリングを前提にプロセスを実務へ接続しています。

なお、PMIのCCRS掲載情報では、第8版について40のevolved processes（進化したプロセス）が示されています。これは5つのFocus Areasの配下に40プロセスが単純配置されているという意味ではなく、第8版でプロセスガイダンスが具体性を取り戻したことを示す補足情報として捉えるのが適切です。

PMI自身が、再導入されたプロセスガイダンスをevolved, non-prescriptive、つまり進化した非規範的なものと説明しています。

プロセスは戻った。しかし、プロセスを一律適用する思想が戻ったわけではない。

ここが第8版を理解する第一歩です。

PMBOK第6版――予見できるなら、計画する

第6版の強さは、見通せる仕事を構造化し、抜け漏れを抑え、プロジェクトの予見可能性を高めることにある。

PMBOK第6版を象徴するのが、5つのプロセス群と10の知識エリアです。

5つのプロセス群

PMBOK第6版で整理された5つのプロセス群

プロセス群	役割
立ち上げ	プロジェクトを正式に開始し、目的や大枠を定める。
計画	スコープ、スケジュール、コスト、品質、リスクなどの進め方を具体化する。
実行	計画に基づきチームと資源を動かし、成果物を生み出す。
監視・コントロール	計画と実績を比較し、差異や問題へ対応する。
終結	成果物を受け渡し、プロジェクトまたはフェーズを正式に完了する。

この5つは、単純な一方向の工程表ではありません。

計画と実行、監視・コントロールを往復しながら、プロジェクトを制御していくための大きな枠組みです。

10の知識エリア

PMBOK第6版の10知識エリア

知識エリア	主な役割
統合	個別の活動を束ね、プロジェクト全体を一貫して動かす。
スコープ	何をやり、何をやらないかを定義・管理する。
スケジュール	作業順序と期間を計画し、納期を管理する。
コスト	必要な費用を見積もり、予算内で管理する。
品質	成果物とプロセスに必要な品質を確保する。
資源	人員や設備など必要な資源を計画・活用する。
コミュニケーション	必要な情報を、必要な相手へ適切に届ける。
リスク	不確実性を特定・分析し、対応を準備する。
調達	外部から取得する製品・サービスや契約を管理する。
ステークホルダー	プロジェクトへ影響する関係者を特定し、期待や関与を調整する。

第6版を「古いウォーターフォール型のPMBOK」とだけ見ると、実務での価値を取り逃します。

重要なのは手法の名称ではなく、開始時点で何をどこまで予見できるかです。

例えば、過去に何度も経験しているシステム更改を考えてみましょう。対象機器、移行方式、必要な成果物、テスト方法、納期まで、開始時点でかなり先を見渡せるプロジェクトがあります。
こうした仕事で、すべてを短い試行錯誤に置き換える必要はありません。

WBSを作り、依存関係を確認し、要員を割り当て、スケジュールを引き、コストを見積もり、リスクを先に洗い出した方が合理的です。
予見できる仕事は、計画するほど効率が上がる。

これが、第6版的なプロセス思考が今でも強い理由です。

プロセス管理は「官僚主義」ではない

問題なのはプロセスを使うことではなく、プロジェクトの性質を見ずに必要以上の管理を持ち込むことである。

WBS、EVM、PERT、クリティカルパス。リスク登録簿、変更管理、責任分担計画――こうした言葉を聞いて「重たい」と感じる方もいるでしょう。
しかし、道具が悪いわけではありません。

必要のないプロジェクトへ、必要以上の管理を持ち込むことが問題なのです。

100万円規模の小さな開発に、数十億円規模の基幹システムと同じ管理体系を適用すれば、管理のための管理になります。逆に、数百人が関わる大規模移行をチャットとホワイトボードだけで管理するのも危険です。
つまり、問うべきなのは「プロセスを使うか、使わないか」ではなく、「どの程度使うか」です。

この感覚は、第7版・第8版で重要性を増したテーラリングへそのままつながります。

PMBOK第7版――予見できないなら、早く試す

第7版が前面へ出したのは、計画を守る能力だけでなく、変化の中でも価値を見失わずに適応する能力である。

第7版への変化は大きなものでした。第6版でプロセスを中心に学んできた人にとって、12の原則や8つのパフォーマンスドメインは、かなり抽象的に見えたはずです。
その変化を理解するには、次の問いが有効です。

「予見できないものまで、無理に予見しようとしていないか？」

顧客自身が完成形をまだ持っていない。市場が変わる。新しい技術を採用する。実物を見せなければ要求が具体化しない。競合の動きで優先順位が変わる。
こうした状況では、プロジェクト開始時に作った詳細計画ほど早く陳腐化します。計画を精密化すればするほど、変更時の手戻りが大きくなる場合さえあります。

そこで必要になるのが、早く試すことです。

小さく作り、見てもらい、観察し、学び、修正して次へ進む。ただし、第7版は「アジャイルだけを推奨するPMBOK」ではありません。
Predictive（予測型）、Adaptive（適応型）、Hybrid（ハイブリッド型）を含む複数のアプローチを視野に入れ、プロジェクトの状況へ合わせて方法を選ぶテーラリングを重視しています。

予見できないなら、長期計画を無理に精密化するより、早く試し、早く学び、早く修正する。　これが、第7版を実務的に理解する一つの鍵です。

「何を作ったか」から「何が変わったか」へ

第7版を理解する鍵の一つは、成果物そのものではなく、その成果物が生み出すアウトカムへ視線を移したことである。

ここで、成果物（Deliverable）と結果・効果（Outcome）の違いを整理しておきましょう。

DeliverableとOutcomeの違い

観点	Deliverable	Outcome
意味	プロジェクトが作った成果物	成果物によって起きた変化・効果
例	営業支援システムを完成・リリースした	営業生産性が上がり、入力時間や受注率が改善した
問い	何を作ったか	それによって何が変わったか

例えば、新しい営業支援システムを期限通りリリースしたとします。予算内で完成し、仕様書も納品され、システムも問題なく動いている。

成果物の観点では成功です。しかし、誰も使っておらず、営業活動も変わらず、受注率も上がらず、顧客情報の入力負荷だけが増えたなら、本当に価値を生んだのか疑問が残ります。

Deliverableは「何を作ったか」。Outcomeは「それによって何が変わったか」。

この違いは、AI時代にはさらに重要になります。AIがコード、資料、画面などの作成を支援できる範囲が広がるほど、作った量そのものではなく、「それで何の価値が生まれたのか」が問われるからです。

第7版には、一つの戸惑いが残った

第7版は柔軟性を獲得した一方、「では具体的に何をすればよいのか」が見えにくいという実務上の難しさも残した。

第8版が登場する前、実務では「第6版の明確なフレームワークを使いながら、第7版の柔軟性を取り入れる」という読み方が合理的でした。
第6版には具体的なプロセスがある。第7版には、変化へ適応するための原則がある。

ならば、両方の強みを使えばよい。

そして2025年11月、PMIは第8版を正式公開しました。英語ペーパーバック版は2026年1月に刊行されています。

そこで見えてきたのは、第6版と第7版を対立させるのではなく、両者を再び同じ体系の中で接続する方向でした。

PMBOK第8版――「計画か適応か」という二択を終わらせた

第8版は第6版への逆戻りではなく、第7版の原則・価値・適応性を保ちながら実行のためのプロセスを再接続した版と捉えられる。

PMIによれば、第8版は第7版の原則とパフォーマンスドメインという基盤を維持しています。
その上で、構造を簡素化してより実行可能な形へ整理し、実務的なプロセスガイダンスも再導入しました。
この変化は、次のように整理すると分かりやすくなります。

第6版は「どう進めるか（How）」を強くした

どう計画するか、どう見積もるか、どう管理するか、どう監視するか、どう変更を扱うか。第6版は、プロジェクトの実行を構造化するための「どう進めるか」に非常に強い体系でした。

第7版は「なぜ行うか（Why）」を強くした

なぜそのプロジェクトを行うのか。どんな価値を生むのか。どの原則で判断するのか。変化したときにどう適応するのか。
第7版は、プロセスの先にある目的と価値へ視線を上げました。

第8版は「なぜ・何を・どう進めるか」をつなぎ直した

何のために行うのか。何を管理しなければならないのか。そのために、どのプロセスや技法を使うのか。

PMI自身、第8版の更新について、原則、パフォーマンスドメイン、プロセスガイダンスを通じて、プロジェクトマネジメントのwhy・what・howをつなぐものと説明しています。
つまり、第8版を「第6版と第7版のどちらが正しかったか」と読む必要はありません。
問うべきなのは、「このプロジェクトでは、どこまで計画し、どこから適応するべきか」です。

ここに、第8版を実務で読む大きな意味があります。

PMBOK第6・7・8版を「予見可能性」で読み直す

方法論を決めてからプロジェクトを見るのではなく、プロジェクトをどこまで予見できるかを見てから方法論を選ぶ考え方である。

ここからはPMIの公式分類ではなく、長年のプロジェクト実務を通じて重視してきた判断軸です。　それが、予見可能性です。

要求はどこまで固まっているか。顧客は完成形を想像できているか。使用する技術は既知か。工程は経験済みか。規模を見積もれるか。非機能要件は明らかか。外部依存は読めるか。完成条件を定義できるか。

つまり、「どこまで先が見えるのか」です。

国内案件だけでなく、インド、中国、オーストラリアなどを含むオフショア開発や、その後のプロジェクトマネージャー育成・支援を経験する中で、方法論そのものより先に「何が見えていて、何がまだ見えていないのか」を見極めることが重要だと感じてきました。

予見可能性が高いなら、計画する

要件が明確で、技術も既知、類似案件の経験もあり、工程や成果物もかなり読める。この状況では、第6版的なプロセス思考が強く効きます。計画を立て、WBSへ落とし、依存関係を確認し、要員を確保し、リスクを事前に潰す。

未来をある程度予見できるからこそ、詳細な計画が投資になります。

予見可能性が中程度なら、読める部分と読めない部分を使い分ける

実際のプロジェクトは、完全に読めるか、まったく読めないかの二択ではありません。
例えばインフラ部分は読めるが、新しいAI機能は読めない。法令対応部分は固定されているが、UXはユーザーへ見せなければ決められない。

こういう場合、すべてをウォーターフォールにする必要も、すべてをアジャイルにする必要もありません。

読める部分は計画し、読めない部分は反復する。

これがハイブリッド型の考え方です。
単なる手法の混合ではなく、不確実性を分解し、それぞれに合った管理方法を割り当てることに意味があります。

予見可能性が低いなら、早く試す

顧客自身も正解を持っていない。技術的に実現できるか分からない。性能が出るか分からない。使ってもらえるかも分からない。この段階で詳細なWBSを作り込むと、WBS自体が大きな手戻りになる可能性があります。

予見できないなら、早く試す。

プロトタイプやPoCを使い、短いサイクルで試し、観察し、間違っていれば軌道修正する。これは「計画しない」という意味ではありません。
分からないことを、できるだけ早く「分かる状態」へ変えることです。

プロジェクトマネジメントの極意は、方法論ではない

ウォーターフォールでもアジャイルでも目的は同じであり、リスクを下げ、無駄な手戻りを減らして価値ある成果へ近づくことである。

プロジェクトマネジメントを考える際、特に重視したいのは三つです。

予見可能性、リスク軽減、手戻り最小。

方法論は、この目的を実現するための手段です。

ウォーターフォールの詳細計画は、未来をある程度予見できる場合に、先回りしてリスクと手戻りを減らします。

アジャイルの短いフィードバックループは、未来を十分に予見できない場合に、現実から早く学ぶことでリスクと手戻りを減らします。

スパイラル型の試行は、技術的な正解自体が見えていない場合に、小さな実験によってリスクを早期に顕在化させます。

そう考えると、ウォーターフォールとアジャイルは真逆の思想ではありません。

「リスクと手戻りをどう減らすか」という同じ目的に対する、条件の異なる解法です。

ウォーターフォール・アジャイル・ハイブリッドはどう選ぶか

方法論から入るのではなく、予見可能性と不確実性の種類を先に見て、プロジェクトに合ったアプローチを選ぶべきである。

予見可能性から見るプロジェクトアプローチの選び方

プロジェクトの状態	基本アプローチ	主な狙い
要求・技術・工程がかなり読める	予測型 / Waterfall	計画による効率化と先回りしたリスク軽減
安定部分と不確実部分が混在する	Hybrid	読める部分は計画し、読めない部分だけ反復する
顧客ニーズや正解が変化する	適応型 / Agile	短いフィードバックループで学習する
技術的成立性そのものが分からない	Spiral / Prototype / PoC	未知を早期に顕在化させる
※本表はPMIによる公式分類ではなく、筆者の実務経験に基づく判断モデル。実際には、規模、契約、規制、品質要求、組織文化、技術リスク等を考慮してテーラリングを行います。

特に技術的成立性そのものが分からないケースでは、プロジェクト開始時点で完成形を精密に定義しようとしても意味がありません。

新しいAI、新しいロボット、未知の性能、前例のないシステム連携など、試してみなければ分からないものがあります。

こうしたプロジェクトでは、試行 → 観察 → 軌道修正を繰り返します。

予見できないことを前提に設計したプロジェクトなら、方針転換は失敗ではありません。方針転換そのものが設計の一部です。

逆に、予見できる部分まで毎回ゼロから試行錯誤する必要もありません。

プロジェクトマネージャーに必要なのは「どの方法論が好きか」ではなく、「何が分かっていて、何がまだ分からないのか」を見抜く力です。

PMBOKは「使えない」のか――使えないのは一律適用である

PMBOKを全項目実行するチェックリストと考えれば重いが、必要な考え方と道具を選ぶ部品箱と考えれば非常に強い。

「PMBOKは現場では使えない」という言葉を聞くことがあります。

確かに、PMBOKに出てくる考え方や技法を片端から適用し、大量の文書を作り、何でも会議で承認する運用にすれば現場は疲弊します。

しかし、それはPMBOKそのものより、テーラリングしていないことに問題があります。

100万円の小規模案件と数十億円規模の基幹システム再構築、新規Webサービスと社会インフラ、社内向け生成AI PoCと規制産業の本番システムで、同じ管理密度が必要なはずはありません。

PMBOKは、「全部やるためのチェックリスト」ではなく、「必要なものを選ぶための知識体系」として使う方が実務的です。

料理でいえば、PMBOKは完成レシピというより、調理道具のそろった厨房に近い。包丁も鍋もオーブンもありますが、サラダを作るのにオーブンは要りません。

プロジェクトマネージャーの仕事は道具を全部使うことではなく、目の前のプロジェクトに必要な道具を選ぶことです。

AIプロジェクトで起きやすい技術・組織・経済面の失敗については、AIプロジェクトの失敗要因と実務ガイドでも詳しく整理しています。

AI駆動開発でPMBOK第8版をどう読むか

PMBOK第8版はAI駆動開発専用ではないが、AI利用が広がるほど価値・ガバナンス・リスク・責任分界の設計が重要になる。

ここまでの議論をAI開発の文脈で読む際、一つだけ明確にしておきたいことがあります。

PMBOKはシステム開発専用の標準ではありません。

建設、製造、新製品開発、組織変革、研究開発など、幅広いプロジェクトが対象です。
PMIも第8版で、予測型、適応型、ハイブリッド型を含む多様な開発アプローチを扱っています。
それでも本記事でシステム開発を多く例に使うのは、システム開発がこの20〜30年間に起きたプロジェクトマネジメントの変化を非常に鮮明に映す分野だからです。

ウォーターフォールからアジャイル、DevOps、クラウド、生成AI、AIコーディングエージェントへと、「どう作るか」の変化が非常に速い。

ただし、PMBOK第8版がAI駆動開発を前提に作られたとまでは言えません。

公式に確認できるのは、第8版でAIの扱いが拡充されたことです。
さらにPMIは2026年6月、The Standard for Artificial Intelligence in Portfolio, Program and Project Managementを公開しました。

このAI標準は、AIをプロジェクト業務で利用するケースと、AIを中核成果物とする取り組みの双方を対象としています。
内容には、8つの指針原則、5つのパフォーマンスドメイン、Human-in-the-Loop（人間による確認・判断・承認の介在）、倫理・法務上のガードレール、ライフサイクル、テーラリングが含まれます。

Human-in-the-Loopでは、AI出力を人間がレビューし、エスカレーションが必要かを判断し、AIの提案を受け入れるか上書きするかまで含め、人間の判断をプロセスへ組み込む考え方が示されています。

企業がAIを導入するときの業務分解と責任設計については、AI導入の業務分解と組織設計も参考になります。

AIが「How」を支援すると、PMには何が残るのか

AI時代に重要なのは作業を無条件に委任することではなく、AIと人間の責任分界、検証、承認をあらかじめ設計することである。

AIが設計案、コード、テスト、文書作成を支援できる場面は増えています。ただし、どこまでAIへ委ねられるかは、品質要求、規制、セキュリティ、システムの重要度、説明責任によって変わります。

人間のPMに問われるのは、すべての作業手順を決めることではなく、何をAIへ委ね、どこで人間が検証・承認し、誰が結果に責任を持つかを設計することです。

AI時代にPMが握るべき4つの問い

問い	日本語での意味	PMが決めること
Why	なぜ作るのか	顧客・事業にどんな価値を生むのか。
What	何を作るのか	何を対象とし、何をプロジェクト対象外とするのか。
Done	何をもって完成とするのか	誰が、何を確認し、どの条件で受け入れるのか。
Risk	何を任せてよいのか	AIへ委ねる範囲、人間が検証・承認する境界、責任者を定める。

AIが複数の設計案や修正案を提示したなら比較し、必要なら方針を変え、最後に成果を実業務で検証して受け入れます。

PMIのAI StandardがHuman-in-the-Loopを重視するのも、AIが意思決定を支援できても、最終的な説明責任まで自動的に引き受けるわけではないからです。

AIが強力になるほど、「作業を管理する人」から「委任境界を設計し、完成を定義し、選択し、責任を持つ人」へPMの重心は移っていきます。

AI時代のPMP試験と、AIを使った開発実務については、PMP試験2026年改定とAI時代のプロジェクトマネージャーで詳しく扱っています。

PMP記事は資格・試験・求められる能力、本記事はプロジェクトをどう捉え、どう進めるか。役割はここで明確に分かれます。

第8版で「予見可能性」はさらに重要になる

テーラリングとは単に手法を選ぶことではなく、どこまで先を読めるかを判断し、それに応じて管理密度を変えることである。

第8版では、チーム、組織、環境に合わせてプラクティス、ツール、技法を調整するテーラリングが重視されています。その判断では、規模、業界、法規制、組織文化、技術の成熟度、チームの経験、契約条件などを総合して見る必要があります。

しかし、それらを実務で一つの問いへ落とすなら、

「このプロジェクトは、どこまで予見できるのか」

が強い判断軸になります。
予見できるなら前倒しで考え、未来の問題を先に見つけ、計画の中で潰します。
予見できないなら、未来を無理に予測するのではなく、早く試し、現実から情報を得て、その時点で最善の判断をします。

計画とは未来を先取りしてリスクを減らす方法であり、反復とは未来を小さく早く経験してリスクを減らす方法です。

ここまで整理すると、ウォーターフォールとアジャイルは単純な対立概念ではなくなります。
どちらも、「未来の不確実性をどう扱うか」という同じ問題を解いているからです。
AI導入をツール導入ではなく、全社の業務・組織・意思決定の再設計として考える場合は、Agentic AI時代の全社OS化と組織設計も合わせてご覧ください。

一次情報からどこまで言えるか

PMBOK第8版の公式変更点と、本記事で提示する「予見可能性モデル」は分けて理解する必要がある。

PMI公式から確認できること

PMI公式のPMBOKページでは、第8版のPublication Dateは2025年11月、全408ページとされています。

一方、PMI公式書籍流通ページでは、ISBN 9781628258295の英語ペーパーバック版のPublication Dateは2026年1月です。

つまり、2025年11月のPMIによる正式公開と、2026年1月の英語紙版刊行は区別して理解する必要があります。

第8版は、第7版の原則・パフォーマンスドメインという基盤を継承しながら、6つのコア原則と7つのパフォーマンスドメインへ整理されました。

公式目次にはReintroducing Process Groups as Focus Areasと明記され、立ち上げ、計画、実行、監視・コントロール、終結の5つのFocus Areasが置かれています。

AI、PMO、調達の扱いも拡充され、5つのFocus Areasが再導入されました。さらに、PMIのCCRS掲載情報では40のevolved processes（進化したプロセス）が示されており、プロセスガイダンスは進化した非規範的な形で整理されています。

またPMIは2026年6月、AIをプロジェクト業務で利用する場合とAI-driven initiativeを管理する場合の双方を対象にしたAI専用標準を公開しました。

本記事の独自解釈

一方、
第6版＝計画する力
第7版＝適応する力
第8版＝状況に応じて両者を使い分けるための接続点
という整理は、本記事独自の理解モデルです。

同様に、
予見できるなら計画する。予見できないなら早く試す。どちらの場合も、リスクと手戻りを最小化する。
という考え方もPMIの公式定義ではありません。PMBOKの変化を、長年のプロジェクト実務と結び付けて理解するための実務判断モデルです。
公式事実と実務解釈を混同しないことも、本記事で大切にしている点です。

まとめ――「計画する力」と「適応する力」は対立しない

PMBOK第8版が示すのは新しい手法への乗り換えではなく、状況を見極め、その場に合った方法を選び続ける力の重要性である。

PMBOK第6版は、計画する力を体系化しました。
計画し、分解し、見積もり、管理し、未来の問題をできるだけ早く見つける。
第7版は、計画だけでは届かない世界で、適応する力を前面へ出しました。

価値を見て、顧客から学び、変化を受け入れ、テーラリングし、アウトカムへ目を向ける。
そして第8版は、その二つを対立させる必要がないことを、より実務的な形で示しています。プロジェクトには、予見できる部分があります。同時に、どうしても予見できない部分があります。
だから先に問うべきなのは、「ウォーターフォールとアジャイルのどちらが正しいか」ではありません。

「このプロジェクトは、どこまで予見できるのか」

です。

記事冒頭では、次の原則を掲げました。
予見できるなら計画する。予見できないなら早く試す。どちらの場合も、リスクと手戻りを最小化する。
最後は、その意味をもう一段実務へ進めておきましょう。

AIが設計や実装を支援するようになっても、この原則は変わりません。
むしろ作業が高速化するほど、間違った方向へ進む速度も上がります。
だからこそ、何を作るのか。何をもって完成とするのか。何をAIへ委ねるのか。どこにリスクがあり、いつ計画し、いつ試し、いつ軌道修正するのか。

その判断が以前にも増して重要になります。

PMBOK第8版の価値は、正しい手法を一つ選ぶことではない。状況が変わっても、何を計画し、何を試し、どこで責任を持つかを選び続けられることにある。

プロジェクトを前へ進めるのは、版番号ではありません。見えているものと、まだ見えていないものを見分ける判断です。

専門用語まとめ

Predictive（予測型）

要求や工程を事前にある程度予測し、計画を基準にプロジェクトを進めるアプローチ。本記事ではWaterfallを代表的な例として扱う。

Adaptive（適応型）

変化や不確実性を前提とし、短いサイクルとフィードバックによって計画や成果を適応させるアプローチ。

Hybrid（ハイブリッド）

PredictiveとAdaptiveなど複数のアプローチを、プロジェクトの特性に応じて組み合わせる考え方。

Tailoring（テーラリング）

プロジェクトの規模、複雑性、環境、リスク、組織特性などに応じて、プロセス・技法・管理密度を調整すること。

Focus Area（フォーカスエリア）

PMBOK第8版で整理されたプロジェクトマネジメントの実務領域。Initiating、Planning、Executing、Monitoring and Controlling、Closingの5つで構成される。

参考文献 / 出典

次に読むならこの3本

補足Q&A

Q1.
PMBOK第8版が出たので、第6版・第7版はもう不要ですか？

A1. 不要ではありません。

現在の標準として中心になるのは第8版ですが、第6版のプロセス体系と第7版の原則・価値・テーラリングを理解すると、第8版がなぜ現在の構造になったのかを理解しやすくなります。

実務では旧版を丸暗記するのではなく、第6版の「計画する力」と第7版の「適応する力」を、第8版のテーラリングの中でどう使うかと捉えると分かりやすいでしょう。

Q2.
PMBOK第8版はウォーターフォールへ戻ったのですか？

A2. ウォーターフォールへ戻ったわけではありません。

プロセスガイダンスと5つのFocus Areasは再導入されましたが、PMIはそのプロセスガイダンスを非規範的な形と説明しています。

第7版が強調した価値、原則、適応性を捨てたのではなく、原則・ドメイン・Focus Areas・プロセスを再接続したと理解する方が適切です。

Q3.
PMBOK第8版はAI駆動開発を前提にしていますか？

A3. AI駆動開発専用の標準ではありません。

PMBOK第8版は業界や開発方式をまたぐプロジェクトマネジメント標準です。ただしAIの扱いは拡充されています。

さらにPMIは2026年6月、AIをプロジェクト業務で利用する場合とAI-driven initiativeを管理する場合の双方を対象にした専用AI標準を公開しています。

更新履歴