『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版』*1を読んだので書評を書いた*2。
動機 / 背景
当記事の筆者がPMBOKガイド第7版を読むに至った背景について。
- PMBOK自体は認知してて、201x年に新卒で入ったSIerで「いつかはこれを読んでプロジェクトマネジャー資格を取れ」的なことを聞いて第4か第5版あたりを流し読みしたけどほぼ何も覚えていない
- 2010年代半ばからはWebサービスを運営する企業に入り、いわゆるプロダクト開発をする中でプロジェクトマネジメントの基礎や知識が求められることがとても多いと思っていた
- 2021年に公開された記事「界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】」と同筆者のDevelopers Summit 2022の登壇スライドを見て、改めてPMBOKが気になっていた
- 古くはウォーターフォールに代表されるような予測型アプローチ（predictive approach）中心だったが、第7版では不確実性への対処のような適応型アプローチ（adaptive approach）、言い換えればアジャイルもカバーできる内容にシフトしたらしい
- プロジェクトマネジメントとプロダクトマネジメントは別物扱いされることが多いが実際は多くを共有している（わかる）
本の構成と各パートの感想
PMBOK（Project Management Body Of Knowledge）とはPMI（プロジェクトマネジメント協会）が世界中のプロジェクトマネジャーや実務家から意見を集めプロジェクトマネジメントについて知識体系化したガイドである。世界中のプロジェクト大小を問わず現場からのイテラティブなフィードバックによって1996年から編集・更新され続け版を重ねている。
ここからはPMBOK第7版の概要を示しつつ個別のパートについて感想を記す。なお、過去の版との違いはわかっていないので一切述べない。
本書はPMBOKと呼ばれるが「プロジェクトマネジメント標準」と「PMBOK（プロジェクトマネジメント知識体系）ガイド」を1冊にまとめたものである。この2つが何であるかを要約する。
ちなみにこの本自体がプロジェクトマネジメントに関するあらゆる事柄を煮詰めて簡素化した要約みたいなものなのでそれをさらに要約したら何も残らない点に注意されたい（＝読まないと意味がわからない可能性が高い）。
「プロジェクトマネジメント標準」
「プロジェクトマネジメント標準」は用語と概念の定義、プロジェクトに関わる人間が従う原理・原則について規定する文書。プロジェクトの性質や取り組む領域、そして予測型・適応型どんなアプローチを取るかにまったく依存しない前提の話である。
しかし実務経験がある人にとってはだいぶ退屈で、特に原理・原則のスチュワードシップ（責任感や倫理観）あたりは行動規範とかマナー的な話で「そりゃまぁ…そうだろ」としか思えないかもしれない。プロジェクトを破壊したい人間はここを読んで悔い改めるのかもしれない…というのは冗談だが、後続のパフォーマンス領域やテーラリングにおいて意思決定に迷うときの指針として機能することが期待されているようだ。このような規範は字面だけで理解してもあまり意味がなく、自らのチームや組織において咀嚼して内面化されなければ効果を発揮しないものだ。
そんなわけなのでPMBOKを読み進めていて不明な用語や概念があるときに立ち戻って読む程度で良い。ただしまったくプロジェクトマネジメントを知らない人や一般的な用語の理解が曖昧な場合はある程度は目を通した方が良い（そのような方が想定読者とされているようには思わないが）。
「PMBOKガイド」
「PMBOKガイド」のコンテンツは主に以下の3つで構成される。
- プロジェクトパフォーマンス領域 (130 pages)
- テーラリング (20 pages)
- モデル・方法・作成物 (50 pages)
1. プロジェクトパフォーマンス領域
PMBOKの基礎となる内容で最もボリュームが多い。プロジェクトの成果を効果的に提供するために不可欠な8つの領域について詳説している。
- ステークホルダー
- チーム
- 開発アプローチとライフサイクル
- 計画
- プロジェクト作業
- デリバリー
- 測定
- 不確かさ（不確実性と呼んだほうが通りが良いと思うのだが…どうか）
これらはどのようなプロジェクトにおいても存在するものであり、いずれも相互に繋がり、重なり、作用するものなので分離して扱うことは推奨されない。何を重視するか実施するかはプロジェクトのさまざまな変数によって異なるため、PMBOKにおける重みづけや順序は存在しない。
目次的にはだいぶ面白そうで、その通り、このあたりから（筆者視点では）ようやく日常的な開発に馴染みのあるトピックや問題領域への言及が始まる。具体的な内容とはたとえば、
「要求のあるべき姿は以下の基準を満たす。明確さ・簡潔さ・検証可能・一貫性・完全性…（以下で各項目の説明がなされる）」
とか
「プロジェクトチームは将来何が起こるかを予測する。定量的な予測には以下のものがある。残作業見積もり（ETC：estimate to complete）・完成時総コスト見積もり（EAC：estimate at completion）・回帰分析・スループット分析…（他にも続く）」
のようなものである。
この他にもプロジェクトの期間が長くなるほどに途中で要求や変更が起き終端が後ろにずれていくとか、欠陥やバグは発見されるフェーズが遅くなるほど変更コストが高くなるとか、メトリクスを計測すると誤用が始まることがあるとか、ソフトウェア開発で馴染みあるテーゼやアンチパターンも述べられる。
関心を持てる話題ではあるものの、各領域の多様なトピックに関する非常に端的で簡潔な説明が矢継ぎ早に繰り返されるため、全てを一度に脳内メモリに載せるのはおよそ不可能と思われる。そのためこのパートは読者が課題意識を持つ領域にフォーカスして読むか、後続のテーラリングパートを読んで検討や実践を試みる前に読まないとなかなか頭に入らない。課題意識なく読み進めても「いろいろあるのはわかったけど….うーん…それで？」と疑念を抱いて終わりそう。
ただ、冒頭で紹介した記事の方も書かれている通り「不確かさ」パフォーマンス領域はこのパートの白眉。不確実性、言い換えれば現状が不明であったり予測不可能な状態に関係するものとして、一般的な不確かさ（理解や認識の不足etc.）・曖昧さ・複雑さ・変動性・リスクを挙げ、これらを低減させる一般的な手段について述べられている。これらの概念や手法はリスクマネジメントと言い換えてもいい。
実験やプロトタイプにより因果関係の特定や関係を理解する、システムの構成要素を分割（decoupling）することで変数を減らす、フェイルセーフを取り入れリスクが現実になった場合の被害を減らす、等々システム開発において馴染みのあるアプローチが多い。納得度も高く、未知のアイデアに出会ったときも引き出しに入れておきたいと思えた。
2. テーラリング
テーラリングとはプロジェクトマネジメントの知識体系を目前のプロジェクトやタスクに合わせていい感じに調整して適応させること。これまでに紹介した内容は時には抽象的すぎたり、具体的なものも「いつ使えばいいのか」がわかりにくかった。それがこのパートで少し解消される。
このパートはとても重要だと思う。PMBOKが提示する知識体系をどのように活かすかは読者と読者の適応能力次第だということが示唆されていると解釈したからだ。1桁人数の数ヶ月プロジェクトだろうと数万人月の大規模プロジェクトだろうと知識体系が十分に適用できる範疇であり、何を選択して何を選択しないか、選択したものをどのように適応させるかはプロジェクトに関わる人間の経験とスキルに依拠するのだと。
実際に本書にも以下のようにある。
このような方法論の大半は、それを厳密に適用するのではなく、テーラリングのプロセスを実施して、プロジェクトのタイプ、規模、複雑さに基づき、どの要素が最も有用であるかを判断すべきであることを明確に示している。経験の浅い実務者の中には、プロジェクトの規模、複雑さ、期間、組織の状況に関係なく、方法論をそのまま適用しようとする人もいる。
PMBOK第7版 p.132
また、適応しているかをどうかを測るためにはおなじみのレトロスペクティブ（振り返り）も本書に記述がある。プロジェクト初期に選定したアプローチに固執するのではなく途中にて積極的に診断を行い、状況に適したアプローチを知識体系から取捨選択して適応することが推奨される。
3. モデル・方法・作成物
各単語がわかりにくいが、モデルとは「プロセス、フレームワーク、現象を説明するための思考戦略」、方法とは「成果物を得るための手段」、作成物とは「テンプレートや文書やアウトプットや成果物」を指している。
プロジェクトの様々な局面で役立つ思考様式やツールの網羅的な紹介と捉えて良いと思う。このパートは自分のような「命名された概念やフレームワークをコレクションしたいタイプ」や「攻略本や設定資料集にハマるタイプ」にとってはとても興味深い。例を挙げるならば、リーダーシップについてはOSCARモデルやDaniel Pinkの動機付け、欲求理論、マグレガーのX,Y,Z理論など、チームや組織の変革についてはチェンジマネジメントを軸にADKARモデル、チームの成長についてはタックマンモデルなど。いつかは使いたくなるものばかりだ（これはハンマーを持つと全てが釘に見えるアレな姿勢）。
特に不確実性や複雑さへの対処として僕のお気に入りのカネヴィン・フレームワークが挙げられていて良かった。本書に図はないが以下の広木さんのtweetがフレームワークの応用としてとてもわかりやすいので引用させていただく。
https://twitter.com/hiroki_daichi/status/1050671531288752130
この他にもデータ収集・分析にまつわる用語や手法、見積もり手法、会議とイベントの種類（デイリー・スタンドアップ、レトロスペクティブみたいなやつ）などノウハウも紹介されている。
このような図を見るとまだ手に入れていないツールやスキルがあったり、手持ちのスキルの知らなかった使い方が見えるようでワクワクする。
内容が具体的かつどのような問題領域に適用可能かが示されているので、最もわかりやすく知的興奮を得られるパートであった。
全体の感想
個々のパートについては先んじてだいぶ感想を書いてしまったので全体に関する感想を述べる。
PMBOKの読み方
上述の内容で理解されたと思うが、逐一逐語を読んでいくタイプの本ではない。たった200ページではあるがすべてを理解して内面化したり活用できるようなものではないし、PMIもそのような期待を読者にしていないと思う。
ではどう読むか。
読者が関心を持つ領域や目前の課題に関連する箇所にフォーカスして読む。すべての読書はそうあるべきとも言えるが、このような知識体系ガイドの場合はそれが特に顕著である。
またはプロジェクトマネジャーないしは類する職種の方が「自身にとって不足している知識やスキルが何かを発見する」ために読む。埒外の知識を自発的に学ぶのは難しいので知識マップを先に頭に入れておき、必要に応じてリファレンスとして参照することで穴を埋めていくアプローチは効率的だろう。
不確実性に対する考え方++
これも先述してしまったが、改めて不確実性に対する考え方がとても現代的、VUCA的で良いと思う。はっきり言ってPMBOKを読んでも具体的な不確実性との戦い方は見えてこない。「好きな方法論と思考モデルを組み合わせて君だけの戦い方を見つけよう！」ということだ。
具体的な方法論よりも変化への適応を重視
前段に関連した話題をもう少し書く。全体的に抽象度の高い話が多いが、具体的な方法論よりも変化への適応を重視する適応型のアプローチやプロジェクトをカバーするためにそうなったようす。
不確実性が高く適応型のアプローチが求められる環境では「前提Aならば方法Bを使う」のような正解はない（ちなみに予測型アプローチだからといってそのような正解があるわけでもない）。だからこそ個別の方法論よりも価値観や思考方法の柔軟性といった抽象的な話に比重が置かれる。
テーラリングの章では特にその点が強調されており、読者に対して適応すること・変化すること・選択することの重要性を理解してもらいたいという意思が感じられた。PMBOKを読んだあとに学んだ方法論を無理やり実践しようとしたり、自分たちの問題領域にとっては不要だとして退けてしまうのは、PMBOKの目指す方向の真逆にあるということだ。
プロダクトとプロジェクト
付属文書X4「プロダクト」について。本書の冒頭ではこの本の想定読者に明確に「プロダクトマネジメントに関わる人」が含まれており、この層へ向けたものだろうか。
ここ10年でプロジェクトの成功の定義は変わり、スケジュールと予算目標の達成ではなくプロジェクトの価値と成果を指標とするようになってきたという。おかげでプロジェクトマネジメントとプロダクトマネジメントの目的や方法論においてはより多くが共通項となり、一方の知識が両者にて活かせるようになった。
最も大きな違いについても述べられている。プロジェクトは一般に有期で終わるのに対し、プロダクトはプロダクトの開始から撤退までのライフサイクルを辿る長期的なものである。ゆえにチームは長期間継続するし、そのような永続的チームは短期的なチームよりも市場や顧客に対して敏感になり、品質向上・価値創出にも寄与するという。
細かい不満
読み進める上で気になったこと。
抽象というか概念的な話から具体的な話にシフトするのが非常にゆるやかなので前半部で音を上げそうになった。知識体系ガイドという役割や構成上やむを得ないとは理解した。
文章が読みにくい。原文を読んでいないので日本語訳のせいかどうかはわからないが、一文がやたら冗長でスッと頭に入ってこないことが多い。先に書いたように抽象的な話が続いたり互いに疎な要素の説明が連続したりすることも重なり、ページ数の割に読むのに時間がかかった。
プロジェクトマネジメント標準やプロジェクトパフォーマンス領域までは図が多かったが、テーラリング以降の図が少ない…。前者はPMBOKの骨子で後者は様々な文献からの寄せ集めなので仕方ないとは思う。
評価
★★★☆☆
万人にはおすすめしない。述べた通り関心や問題意識のある方だけが臨めば良い。
問題意識の範囲がソフトウェア開発プロジェクトに閉じないのは良い点である。プロジェクトマネジメントの知識体系の根幹には人間活動に対する深い洞察があるので、事業開発やマーケティングなどの企業活動や、さらには皆さんの人生で立ち向かう何らかの一大プロジェクトに応用できるポテンシャルはある。
会社に1冊あって良い本だと思う。
