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つのパフォーマンス・ドメイン」です。それぞれ概要を見ていきましょう。まずはこれらの新しい概念を見ていきましょう。

抽象的で分かりにくいと思いますが、自身の経験との照らし合わせで理解していくしかない気がします。この辺りが第7版の分かりにくさとも言えると思っています。

プロジェクトマネジメントとプロダクトマネジメントの違いなども整理されていて、システムの相互作用という点で取り上げているのだなと解釈しました。

さて以降では、今回大きく変わったプロジェクトマネジメント・プリンシプルとパフォーマンス・ドメインを見ていきましょう。

【前編】丸ごと生まれ変わったザ・スタンダート：プロジェクトマネジメント・プリンシプル（原則）

次の12項目がプリンシプルです。PMBOKの本文には、1つずつ解説が書かれていますが、細かい内容が大事というよりも、この12の言葉を組織に合わせて解釈して進めることがプリンシプルの使い方だと個人的には考えています（内容は全て読んでいますが、ここでは個別の説明は省略します）。

スチュワードシッップが個人的には分かりにくかったです。なので少し補足します。

スチュワードシップとは、責任感を持って単にプロジェクトを遂行するだけでなく、倫理観を持って取り組むことを指します。また、事業だけでなく、社会的、環境的な持続可能性についてコミットすることを指します。誠実さ、配慮、信頼性、コンプライアンスなどを含み、全体的な視点で物事を捉える必要があります。

（参考）日本語で直訳すると受託責任ですが、ちょっと分かりにくい概念だと思います。金融ではスチュワードシップコード（コーポレートガバナンスコードに対して）のような概念もありますので、業界によっては既にお馴染みかもしれませんね。

【後編】不確実性まで飲み込んだPMBOKガイド：パフォーマンス・ドメイン

これまでのような立ち上げ〜終結というフェーズごとにプロセスを規定するというよりは、8つのパフォーマンス・ドメインごとに、プロジェクトのフェーズを通じた活動の内容や考え方のフレームワーク、そして望ましい成果例とチェックリストが説明されています。ただ、以前よりも概念的に記述されている印象です。前は、input-tool/technic-output でしたが、今回は違います。tool/technicは最後に列記される程度です。

分かりやすい例として、「計画」を取り上げてみると、以下のような内容になっています。各パフォーマンスドメインで考えるべき観点と説明が概念的に記述されています（ボリュームはそんなに多くないです）。

個人的に注目しているのは、不確実性パフォーマンス・ドメインです。何それ？という感じですが、次のような内容となっています。これまでは変動性に対しては、6thでもカバーしている範囲だったかなと感じていますが、複雑性への対応は痺れるものがあるなと思いました。例えば、リフレーミングのところが一番のポイントだと考えており、今回のPMBOKの第7版もまさにリフレームしたなと思います。

また、パフォーマンスドメインの各項目では、成果のチェックリストがついていますので、自分のプロジェクトを振り返るときに活用できそうです。どういうことが期待されているか記載があります。

参考までに、「不確実性パフォーマンス・ドメイン」を一部抜粋すると、以下のような感じです。

使い手をかなり選ぶ内容になっていて、実際に実務で使うのは難しいと思いました。そもそも文字通り従うようなものでもないと思いますが。

いずれにせよ、パフォーマンスドメインも概念的な内容が多いので、不慣れな方は、「実際何やればいいの？」となるのは容易に想像がつきます...。経験しないと塩梅が分からないですしね。

テーラリング

今回から追加されている項目です。CMMIでは10年以上前からあった概念なのでお馴染みともいえます。

テーラリングとは、ちょっと分かりにくいかもしれませんが、例えばスーツをテーラーメイドする、というように、知識体系をプロジェクトの環境に合わせていい感じに調整して適用することです。

本文の中でも、"just enough"と書かれていますし、過剰にならないような注意だと受け取りました。

また、そもそもなぜテーラリングが必要になったか、というと、おそらく今回のプリンシプルベースへの変更に伴い、全体的に抽象的な内容になったことが影響していると思います。

つまり、以前のような規定的なプロセスベース（この場合は、このツール使って成果物を作る...）ではなく、プリンシプルベースなのでプロジェクトやチームに合わせた調整（というか実体化、プロセス化）がそもそも必須になったからだと考えています。

【最後に】 原則ベースにならざるを得なかった背景考察

今回のアップデートで、個人的に印象的だったのは
「チーム」「リーダーシップ」「価値」「複雑性」「不確実性」
の箇所です。

これが見出しにあるだけで、「あっ、これまでと違うんだ」って気になりました。前よりも、「人間味」が全面に出てるとも感じました。今っぽいな、と。

もっとマニアックにいうと、ウォーターフォール前提の場合は、人月の神話のように、人を機械のように扱っている感があり（つまり人間味がなく）、テイラーの科学的管理法的ないわゆるテイラリズムを感じていました、個人的な印象ですが。

これはアジャイルとは真逆ですよね。

時代の要請として、アジャイルを本気で取り込まざる得ない状況になり、アジャイルとウォーターフォールという言わば「混ぜるな危険」を包み込んでいるのです。

よって、プリンシプル（原則）のような抽象的な概念にならざるを得なかったのではと思います。

個人的には実務経験があるので読むだけで、自分の過去の経験と照らし合わせながら理解できますが、PM初心者向けにはかなり難しいものになったというのが所感です。何事もメリット・デメリットありますよね。

今回のアップデートは進化だと思っていますし、ポジティブに受け取っています。理解が誤っている箇所もあるかもしれません。その際はお手数ですが、twitterなどでDMいただけると嬉しいです。

なお、新規事業などで活用できるアジャイル型のプロジェクトマネジメントについてはこちらに解説していますので、何かのヒントになれば幸いです。

※Miz KushidaはAmazonのアソシエイトとして適格販売により収入を得るプログラムに参加しています。