はじめに
前回の「PMBOK 第6版までと第7版からのまとめ」では、量が多くてまとめきれてなかったので、今回は「PMBOK第7版」をピックアップして、ラフに理解してみようと思います。
一言で、PMBOK第7版とは？
「原則（Principle）」と「成果に結びつく領域（Performance Domain）」をベースにした、より柔軟なプロジェクトマネジメント・ガイドラインです。
従来の「49のプロセス」中心の構成から、価値・原則・適応性重視のフレームワークへと大きく進化しました。
PMBOK第7版の構成要素（メイン4本柱）
| 項目 | 概要 |
|---|---|
| 1. プロジェクト・マネジメントの原則（12原則） | 成功に導くための“考え方”の指針 |
| 2. パフォーマンス領域（8領域） | プロジェクトを構成する“活動領域” |
| 3. モデル、方法、成果物 | 実務で使えるテンプレ・ツール集 |
| 4. テーラリング | プロジェクトに合わせた最適な進め方の工夫 |
プロジェクト・マネジメントの12原則（Principles）
PMBOK第7版の核となる「価値観的なガイドライン」です。
| No. | 原則 | 内容（ざっくり要約） |
|---|---|---|
| 1 | チームを尊重し関係を築く | 信頼関係が成果を生む |
| 2 | 顧客価値にフォーカスする | 「何を作るか」より「なぜ作るか」 |
| 3 | リーダーシップを発揮する | 指示だけでなく導く |
| 4 | チームの適応性と柔軟性を育てる | 状況に応じた変化対応力 |
| 5 | システム思考を活用する | プロジェクトを全体で考える |
| 6 | リスクを積極的に扱う | 不確実性をチャンスに変える |
| 7 | 情報に基づく意思決定 | 感情よりデータを重視 |
| 8 | 関係者と連携し続ける | ステークホルダーは味方に |
| 9 | 価値を継続的に提供する | 小さく届けてフィードバックを得る |
| 10 | 品質に責任を持つ | 「とりあえず納品」はNG |
| 11 | 組織に適応したアプローチを取る | 型にこだわらず柔軟に |
| 12 | 継続的に改善する | 昨日より今日、今日より明日よくする |
パフォーマンス領域（Performance Domains）
成果を出すための「実践領域」です。これまでの「プロセス群」とは違い、状況に応じた“領域ベース”の視点です。
| No. | パフォーマンス領域 | 内容 |
|---|---|---|
| 1 | ステークホルダー | 関係者との連携と期待調整 |
| 2 | チーム | チームの形成・育成・運営 |
| 3 | 開発アプローチとライフサイクル | アジャイル or ウォーターフォールの選択 |
| 4 | 計画 | 計画そのものより「適応性ある計画の仕組み」 |
| 5 | プロジェクト作業 | 実行・監視・成果物作成 |
| 6 | デリバリー（成果物提供） | 顧客に価値を届けるしくみ |
| 7 | 測定 | 成果やパフォーマンスの評価 |
| 8 | 不確実性 | リスク、変化、機会への対応力 |
モデル、方法、成果物（Models, Methods & Artifacts）
具体的なツール集・用語集・テンプレートを示すパートです。
例：
| 種別 | 例 |
|---|---|
| モデル（考え方） | PDCA、ステークホルダー分析モデル |
| 方法（やり方） | WBS作成、リスク対応、ベロシティ計測 |
| 成果物（ドキュメント等） | プロジェクト憲章、バックログ、バーンダウンチャート |
Models：思考モデル（枠組み）
プロジェクトの見方や判断に使う“考え方のテンプレ”
| モデル名 | 用途・説明 |
|---|---|
| PDCAサイクル | 継続的な改善の枠組み（Plan→Do→Check→Act） |
| ステークホルダー分析モデル | 関係者の影響力と関心度をマトリクスで整理 |
| Tuckmanモデル | チーム形成の5段階（形成→混乱→統一→機能→散会） |
| OODAループ | 観察→状況把握→意思決定→行動（変化に強い判断モデル） |
| 価値ストリームマップ（VSM） | 価値が流れる工程を可視化し、無駄を発見 |
| ジョハリの窓 | 自己理解と他者理解の4象限モデル |
| マズローの欲求段階 | チームモチベーションの理解に活用 |
| フィードバックループ | 改善や学習に必要な“反応と調整”の仕組み |
| PMOモデル | プロジェクト支援組織の役割と構成パターン |
Methods：方法・技法
実務で使うやり方・手法・計画策定の具体例
| 方法名 | 用途・説明 |
|---|---|
| WBS（Work Breakdown Structure） | 作業の分解・構造化 |
| KPT（Keep, Problem, Try） | 振り返りの定番フレーム |
| ユーザーストーリーマッピング | ユーザー視点で機能整理するアジャイル手法 |
| モンテカルロ・シミュレーション | リスク・スケジュール予測の統計的手法 |
| アーンドバリューマネジメント（EVM） | コストと進捗を同時に評価する |
| クリティカルパス法（CPM） | スケジュール上で遅延できない経路を分析 |
| フィッシュボーンダイアグラム（特性要因図） | 問題の原因分析に使う「骨型」の図 |
| インパクト・プロバビリティマトリクス | リスクの影響度と発生確率をマッピング |
| MoSCoW法 | 要件の優先順位付け（Must/Should/Could/Won’t） |
| タイムボックス | 時間制限で作業を区切るアジャイルテクニック |
Artifacts：成果物（ドキュメント類）
プロジェクトの進行や管理に使う具体的なアウトプット・資料
| 成果物名 | 用途・説明 |
|---|---|
| プロジェクト憲章（Project Charter） | プロジェクトの正式な立ち上げ文書 |
| プロジェクトマネジメント計画書 | プロジェクト全体の管理計画 |
| リスク登録簿（リスクログ） | 予測されるリスクと対応計画を記録 |
| ステークホルダー一覧表 | 関係者の詳細と影響度 |
| プロダクトバックログ | アジャイルにおける機能要求の一覧 |
| 課題ログ（Issue Log） | 発生した課題とその対応記録 |
| バーンダウンチャート | 残作業量と進捗をグラフで可視化 |
| 品質メトリクス表 | 品質基準と評価基準のまとめ |
| 教訓記録（Lessons Learned） | プロジェクトの学び・反省点の記録 |
| 成果物受領書 | 成果物を顧客やステークホルダーに正式に引き渡した記録 |
テーラリング（Tailoring）
「PMBOKのやり方をそのままやる」ではなく、プロジェクトに合わせてカスタマイズすることが重要だよ、という考え方です。
例：
「ウォーターフォールか？アジャイルか？どこを組み合わせるか？」
プロジェクトごとに柔軟に最適化する力が大事という時代の流れを反映しています。
プロジェクトの現場では、必要に応じてこれらをテーラリング（カスタマイズ）して使うのが第7版の大きな特徴です。
12原則の語呂合わせ
「チコリ チシリ ジスカ ヒクケ」（ちこり、ちしり、じすか、ひくけ）
AIが提案してくれました（笑）
| 語呂 | 原則 | イメージ・補足 |
|---|---|---|
| チ | チームを尊重し関係を築く | まずはチームが土台 |
| コ | 顧客価値にフォーカスする | 顧客のことを忘れずに |
| リ | リーダーシップを発揮する | プロジェクトの推進役 |
| チ | チームの適応性を育てる | 柔軟に変化に対応 |
| シ | システム思考を活用する | 全体を俯瞰する視点 |
| リ | リスクに積極的に対応する | 予測して備える |
| ジ | 情報に基づいて意思決定する | 感情ではなくデータで |
| ス | ステークホルダーと関わる | 協力を得る力 |
| カ | 価値を継続的に提供する | 小さく、早く届ける |
| ヒ | 品質に責任を持つ | “とりあえず”はNG |
| ク | 組織に適応したアプローチを取る | 型にとらわれず柔軟に |
| ケ | 継続的に改善する | 毎日1%でも進化しよう |
おわりに
AIがまとめてくれて、「12原則の語呂合わせ」も提案してくれました。（AI素晴らしい
"思考モデル"などでは、知らない言葉も出ているので、また時間を取って Qiita にまとめたいと思います。
そして、「12原則の語呂合わせ」を元にプロジェクトでも、"テーラリング"してフィットする形の作り方を少しずつ見つけて行きましょう！
参考（感謝）
- AIに全部聞きました