界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】
Developers Summit 2022で登壇した時の資料です↓↓↓
・・・
・不確実性パフォーマンス・ドメインについて加筆しました
・テーラリングについて加筆しました
・適応課題について補足を追加しました。
はじめに
PMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。
いや、でした。。。以前の第6版までは（7版からはすごく薄い）。
2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。
一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験しました。大中小規模それぞれでプロジェクトマネージャとしての実務経験と実績もあると思います。またスタートアップや新規事業を主戦場としてからはもっぱらアジャイルなプロダクトマネジメントやプロジェクトマネジメントに従事したり、最近はエンジニアとして開発に専念しています。
なぜざわついたのか？
そもそも知識体系としてのあり方ごと大きく変化しています。PMBOKが大事にする考え方ごとアップデートされたといえます。
まずその変化の概要です。
・アウトプットのデリバリーから価値のデリバリー重視に
・プロセスを細かく規定するのではなく、プリンシプル（原則）ベースに
・そもそもページ数が大幅削減
大方針というか、存在目的ごと変わっているといえます。（ウォーターフォールのように）成果物をきっちり届けることを目的していた第6版までとは異なり（その観点も含んだ形で）、価値を届けることが目的の第七版に変更されています。価値はまさに探しながら創っていくという、まさにアジャイルな考え方にピボットした、とも捉えられます。
厳密にいえば、予測型アプローチ（predictive approach）から、適応型アプローチ（adaptive approach）に変わったということです。
適応型と聞いてピンと来た人もいるかもしれません。少し余談となりますが、ハーバード大学のロナルド・ハイフェッツ教授のいう「技術課題」と「適応課題」の話と同様だと思います。簡単に説明すると、技術課題（technical problems）とは、解き方がわかっている課題です。適応課題（adaptive challenges）とは、解き方はわかっておらず、自分たちが環境に合わせて変わらなければ解けない課題のことです。もっと細かく言えば、自分たちチームのメンタルモデルを変化させなければ問題も解決方法も見えてこないような課題と言えます。
極端に言ってしまえば、
ウォーターフォールに適したプロセスベースの思想から、アジャイルに適したプリンシプルベースに進化した
ということです。
こう表現すると、いかに大きな転換だったか、ざわつくかが分かるかもしれません。もっとも、ざわついた原因はさらにその先にあるかもしれせん。予測型アプローチが主戦場だったPMが、急に適応型アプローチに対応できるのか、ということが裏側にあるような気もします（実際難しいと思います。僕も最初は難しかったので...）。
もちろん、内容的には両方に対応して記載されていますので、ウォーターフォールを捨てたわけでも否定しているわけでもありません。
ただ、不確実性がますます高まっている（計画して作ったものが成果を上げるとは限らない）昨今の時代感に合わせた進化だと思います。環境に適応した変化なので「進化」と呼べるでしょう。
ちなみに、PMIはこの変化の背景を次のように説明しています（こちらの出所をベースに意訳）。
・テクノロジーの進化はプロジェクトマネジメントに変化をもたらした
・世界中のプロマネからフィードバックを受けた
・彼らは価値提供を求められており内容を大幅に見直さざるを得なかった
（補足）ちなみに、プロマネの知識体系はPMBOKの他にCMMI、PRINCE2がありますが、PMBOKの旧版のようにプロセスベースなので、ウォーターフォールっぽいなっていう印象を受けるかもしれません。PMBOKの動きや反響を受けて、どう動いてくるでしょうか。
何が変わったのか？
では、具体的に構成はどう変わったのでしょうか？
まずは構成の変化です。個人的に内容が大きく変化したと思う箇所をハイライトしてみました。
いかがでしょう。パッとみただけで、全部ハイライトされてるやん！（変わってる）と思ったかもしれません。（実際変わったなという印象...）
さて、個別のワードに目がいってしまいましたが、大きな違いは、「価値提供システム」「12のプリンシプル」と「8つのパフォーマンス・ドメイン」です。それぞれ概要を見ていきましょう。まずはこれらの新しい概念を見ていきましょう。
価値提供システムとは？ （Value Delivery System）
価値とは顧客、組織、社会などに何らかの重要だったり有用なものである。システムとは互いに影響し合う構成要素の集まりである。価値提供システムとは、価値を創出し提供する組織と組織の活動。
プロジェクト・マネジメント・プリンシプル（原則）とは？
プロジェクトに関わる人々の行動の指針となることを目的とし、戦略、意思決定、問題解決のための基礎的なガイドラインとなるもの。
パフォーマンス・ドメインとは？
プロジェクトの成果を効果的に実現するために不可欠な、関連する活動のグループのこと。パフォーマンスドメイン同士が相互に関係しあい、望ましい成果を達成するために一体となって機能する。
抽象的で分かりにくいと思いますが、自身の経験との照らし合わせで理解していくしかない気がします。この辺りが第7版の分かりにくさとも言えると思っています。
プロジェクトマネジメントとプロダクトマネジメントの違いなども整理されていて、システムの相互作用という点で取り上げているのだなと解釈しました。
さて以降では、今回大きく変わったプロジェクトマネジメント・プリンシプルとパフォーマンス・ドメインを見ていきましょう。
【前編】丸ごと生まれ変わったザ・スタンダート：プロジェクトマネジメント・プリンシプル（原則）
次の12項目がプリンシプルです。PMBOKの本文には、1つずつ解説が書かれていますが、細かい内容が大事というよりも、この12の言葉を組織に合わせて解釈して進めることがプリンシプルの使い方だと個人的には考えています（内容は全て読んでいますが、ここでは個別の説明は省略します）。
・スチュワードシップ
・協力的なプロジェクトチームの環境を作る
・ステークホルダーを効果的に連携する
・価値に集中する
・システムの相互作用を認識し、評価し、対応する
・リーダーシップを行動で示す
・文脈に基づいたテーラリング（カスタマイズ）
・品質をプロセスと成果物に組み込む
・複雑性に適応する
・リスクへの対応を最適化する
・適応力とレジリエンスを高める
・未来の状態を達成するために変化できる
スチュワードシッップが個人的には分かりにくかったです。なので少し補足します。
スチュワードシップとは、責任感を持って単にプロジェクトを遂行するだけでなく、倫理観を持って取り組むことを指します。また、事業だけでなく、社会的、環境的な持続可能性についてコミットすることを指します。誠実さ、配慮、信頼性、コンプライアンスなどを含み、全体的な視点で物事を捉える必要があります。
（参考）日本語で直訳すると受託責任ですが、ちょっと分かりにくい概念だと思います。金融ではスチュワードシップコード（コーポレートガバナンスコードに対して）のような概念もありますので、業界によっては既にお馴染みかもしれませんね。
【後編】不確実性まで飲み込んだPMBOKガイド：パフォーマンス・ドメイン
これまでのような立ち上げ〜終結というフェーズごとにプロセスを規定するというよりは、8つのパフォーマンス・ドメインごとに、プロジェクトのフェーズを通じた活動の内容や考え方のフレームワーク、そして望ましい成果例とチェックリストが説明されています。ただ、以前よりも概念的に記述されている印象です。前は、input-tool/technic-output でしたが、今回は違います。tool/technicは最後に列記される程度です。
・ステークホルダー
・チーム
・開発アプローチとライフサイクル
・計画
・プロジェクトワーク
・デリバリー
・測定
・不確実性
分かりやすい例として、「計画」を取り上げてみると、以下のような内容になっています。各パフォーマンスドメインで考えるべき観点と説明が概念的に記述されています（ボリュームはそんなに多くないです）。
＜計画パフォーマンスドメインの構成＞
・計画の変数
・開発アプローチ（予測型、適応型、ハイブリッド）
・プロジェクト成果物の定義
・組織的な要求
・市場の状況
・規制などの制約
・成果のデリバリーの方法
・見積もり（幅、精密性、正確性、信頼度）
・ etc...
個人的に注目しているのは、不確実性パフォーマンス・ドメインです。何それ？という感じですが、次のような内容となっています。これまでは変動性に対しては、6thでもカバーしている範囲だったかなと感じていますが、複雑性への対応は痺れるものがあるなと思いました。例えば、リフレーミングのところが一番のポイントだと考えており、今回のPMBOKの第7版もまさにリフレームしたなと思います。
＜不確実性パフォーマンス・ドメインの構成＞
・不確実性（情報取集、複数の成果に備える、セットベース（複数案）の設計、レジリエンスの組み込み）
・曖昧性（漸進的に解像度を上げる、実験、プロトタイプ）
・複雑性（システム思考、リフレーミング、プロセスベース）
・変動性（代替案の発見・評価、リザーブでの備え）
・リスクと機会（回避、エスカレーション、転嫁、軽減、受容）
また、パフォーマンスドメインの各項目では、成果のチェックリストがついていますので、自分のプロジェクトを振り返るときに活用できそうです。どういうことが期待されているか記載があります。
参考までに、「不確実性パフォーマンス・ドメイン」を一部抜粋すると、以下のような感じです。
＜不確実性パフォーマンスドメインの成果チェックリスト＞
▶︎成果1 プロジェクトを取り巻く環境（技術的、社会的、政治的、市場的、など）を認識できていること
▶︎チェックリスト 不確実性やリスクなどを考慮して環境を評価しているか
ーーー
▶︎成果2 能動的に不確実性を探索し、対応できているか
▶︎チェックリスト リスクへの対応は、予算・スケジュール・パフォーマンス等のプロジェクトの制約上の優先度と整合性が取れているか
※他にもありますが省略
使い手をかなり選ぶ内容になっていて、実際に実務で使うのは難しいと思いました。そもそも文字通り従うようなものでもないと思いますが。
いずれにせよ、パフォーマンスドメインも概念的な内容が多いので、不慣れな方は、「実際何やればいいの？」となるのは容易に想像がつきます...。経験しないと塩梅が分からないですしね。
テーラリング
今回から追加されている項目です。CMMIでは10年以上前からあった概念なのでお馴染みともいえます。
テーラリングとは、ちょっと分かりにくいかもしれませんが、例えばスーツをテーラーメイドする、というように、知識体系をプロジェクトの環境に合わせていい感じに調整して適用することです。
本文の中でも、"just enough"と書かれていますし、過剰にならないような注意だと受け取りました。
また、そもそもなぜテーラリングが必要になったか、というと、おそらく今回のプリンシプルベースへの変更に伴い、全体的に抽象的な内容になったことが影響していると思います。
つまり、以前のような規定的なプロセスベース（この場合は、このツール使って成果物を作る...）ではなく、プリンシプルベースなのでプロジェクトやチームに合わせた調整（というか実体化、プロセス化）がそもそも必須になったからだと考えています。
【最後に】 原則ベースにならざるを得なかった背景考察
今回のアップデートで、個人的に印象的だったのは
「チーム」「リーダーシップ」「価値」「複雑性」「不確実性」
の箇所です。
これが見出しにあるだけで、「あっ、これまでと違うんだ」って気になりました。前よりも、「人間味」が全面に出てるとも感じました。今っぽいな、と。
もっとマニアックにいうと、ウォーターフォール前提の場合は、人月の神話のように、人を機械のように扱っている感があり（つまり人間味がなく）、テイラーの科学的管理法的ないわゆるテイラリズムを感じていました、個人的な印象ですが。
これはアジャイルとは真逆ですよね。
時代の要請として、アジャイルを本気で取り込まざる得ない状況になり、アジャイルとウォーターフォールという言わば「混ぜるな危険」を包み込んでいるのです。
よって、プリンシプル（原則）のような抽象的な概念にならざるを得なかったのではと思います。
個人的には実務経験があるので読むだけで、自分の過去の経験と照らし合わせながら理解できますが、PM初心者向けにはかなり難しいものになったというのが所感です。何事もメリット・デメリットありますよね。
今回のアップデートは進化だと思っていますし、ポジティブに受け取っています。理解が誤っている箇所もあるかもしれません。その際はお手数ですが、twitterなどでDMいただけると嬉しいです。
なお、新規事業などで活用できるアジャイル型のプロジェクトマネジメントについてはこちらに解説していますので、何かのヒントになれば幸いです。
※Miz KushidaはAmazonのアソシエイトとして適格販売により収入を得るプログラムに参加しています。