PMBOK®第8版におけるプロジェクト・ライフサイクルの考え方（概要）
プロジェクト・ライフサイクルとは何か
PMBOK®第8版において、プロジェクト・ライフサイクルは、
プロジェクトをどのような構造で捉えるかを説明するための概念として定義されています。
重要なのは、第8版のライフサイクルが、
・管理手順を示すもの
・必ず従うべき工程モデル
として説明されていない点です。
第8版におけるプロジェクト・ライフサイクルは、プロジェクトが開始され、価値を生み出し、完了に至るまでの全体像を、構造的に理解するための枠組みとして位置づけられています。
製品ライフサイクルとの違い
PMBOKでは明確に、
プロジェクト・ライフサイクルは製品ライフサイクルとは独立した概念であると説明されています。
プロジェクトは、
・製品を生み出すこともある
・成果物を通じてアウトカムを実現することもある
・組織戦略の実現を段階的に支えることもある
一方で、製品ライフサイクルそのものを管理対象とするわけではありません。
開発アプローチに依存しない概念としてのライフサイクル
第8版のプロジェクト・ライフサイクルは、特定の開発アプローチに依存しない概念として説明されています。
ウォーターフォール型、アジャイル型、ハイブリッド型といった違いは、ライフサイクルの外側で選択されるものであり、ライフサイクルそのものは、いずれのアプローチにも適用可能な上位概念です。
この整理によって、第8版では、
・ライフサイクル
・開発アプローチ
・管理手法
が意図的に分離されて説明されています。
これは「どのやり方を選ぶか」よりも前に、「プロジェクトをどう捉えるか」を明確にするための構造だと読み取れます。
「フェーズありき」ではなくなったという転換
第8版では、プロジェクト・ライフサイクルの中にフェーズが含まれることは否定されていません。
むしろPMBOKでは、フェーズについて次のように説明しています。
・フェーズはライフサイクルの中で記述されうる
・フェーズは属性によって表現される
・属性は測定可能であり、入口条件・出口条件を含みうる
つまり、フェーズは引き続き管理可能で、観測可能な対象です。
一方で、第6版までのように、フェーズ構造そのものがプロジェクト管理の前提や起点になるという位置づけは後退しています。
第8版においてフェーズは、判断の前提として固定的に置かれる枠組みではなく、原則に基づく判断の結果として現れるプロジェクトの状態を記述するための属性として扱われています。
この点を踏まえると、「フェーズが不要になった」のではなく、フェーズは引き続き有効な管理単位であるが、それ自体が唯一の設計起点ではなくなった。
Project life cycles are independent of product life cycles, which can be part of the outcomes produced by a project. Projects may also generate outputs, which in turn enable outcomes that progressively realize the organization’s strategy.
The phases in a life cycle can be described by a variety of attributes. Attributes may be measurable and unique to a sepcific pase. Attributes may include but are not limited to name, number, duration, resource requirements, entrance criteria for a project to move into that phase, and exit criteria for a project to complete a phase. A phase gate may occur after the end of a phase, before the beginning of the next phase.
（訳）プロジェクトライフサイクルは、プロジェクトによって生み出される成果の一部となり得る製品ライフサイクルとは独立しています。プロジェクトはアウトプットを生成することもあり、それによって組織の戦略を段階的に実現する成果がもたらされます。 ライフサイクルの各フェーズは、様々な属性で記述できます。属性は測定可能で、特定のフェーズに固有のものである場合があります。属性には、名前、番号、期間、リソース要件、プロジェクトがそのフェーズに移行するための開始基準、プロジェクトがフェーズを完了するための終了基準などが含まれますが、これらに限定されません。フェーズゲートは、あるフェーズの終了後、次のフェーズが始まる前に発生する場合があります。
PMBOK(R)第８版「4.1 Project Phases」より
第8版が示しているメッセージ
ここまで整理すると、第8版におけるプロジェクト・ライフサイクルの位置づけは明確です。
ライフサイクルは、どう管理するかを指示するものではなく、どの手法を使うかを決めるものでもなく、プロジェクトをどのような構造で捉え、その中で判断や行動をどう位置づけるかを理解するための枠組みと言えます。
第8版は、「管理方法の説明」よりも先に、「プロジェクトをどう捉えるか」という視点をPMに求めていると言えるでしょう。
承知しました。
ご指摘のとおり、第8版の用語構造（定義 → 構造 → 各アプローチ）を先に押さえるほうが、読者の理解負荷が大きく下がります。
以下は、その意図を反映した**第2章の再ドラフト（全面修正案）**です。第1章との接続も自然になるよう調整しています。
PMBOK®第8版が示す「プロジェクト開発アプローチ」とは何か
プロジェクト開発アプローチという概念
PMBOK®ガイド第8版では、プロジェクトの管理および実行の方法を定義する概念として
プロジェクト開発アプローチ（Project Development Approach）が説明されています。
この「プロジェクト開発アプローチ」は「プロジェクト開発フェーズ」とは異なります。
「プロジェクト開発アプローチ」は、プロジェクトをどのような前提で設計し、管理し、実行していくかという全体的な進め方の考え方を定義します。
つまり、フェーズは「構造を記述する要素」であり、開発アプローチは「その構造をどう使うかの考え方・定義」という関係になります。
プロジェクト開発アプローチは3つに整理されている
PMBOK®第8版では、代表的なプロジェクト開発アプローチとして、次の3つが示されています。
- Predictive（予測型アプローチ）
- Adaptive（適応型アプローチ）
- Hybrid（ハイブリッド型アプローチ）
ハイブリッド型は通常は予測型アプローチと適応型アプローチの組み合わせとして意図されています。
アプローチの選択
アプローチの選択は、プロジェクトマネージャがプロジェクトマネジメントチームと協議の上行います。プロジェクトマネジメントチームは、プロジェクトの性質に基づいて、チームとの連携の枠組みと方法を確立するために必要な評価を行います。
アプローチ選択に影響する主な要因
PMBOKでは、アプローチ選択に影響する要因として、次のような観点を挙げています。
・要求事項の明確さと安定性
・スコープ、スケジュール、予算の制約条件
・プロジェクトの目的とゴール
・組織文化や組織の成熟度
・ステークホルダーの関与レベル
・リスク特性、技術的要素、全体の複雑性
これらはチェックリスト的に評価するものではなく、総合的なプロジェクト文脈（Project Context）として捉えることが求められています。
予測的アプローチが選ばれる状況
要求事項が早期に明確で、かつ大きな変更が想定されにくい場合、予測的アプローチが合理的な選択になることがあります。
この場合、
・スコープ
・スケジュール
・コスト
を早い段階で整合させ、統合ベースラインとして管理することが可能になります。
ここで重要なのは、予測的アプローチは「計画を重視する」のではなく、計画が有効に機能する前提条件が整っている場合に選択されるという点です。
適応的アプローチが選ばれる状況
一方で、要求事項が初期段階では十分に明確でない場合や、不確実性・複雑性が高いプロジェクトでは、
適応的アプローチが有効になります。
適応的アプローチでは、
・一定期間（タイムボックス）で作業を区切る
・成果をレビューし、フィードバックを得る
・次の判断を更新する
というサイクルを繰り返します。
この場合、スコープは固定されるものではなく、時間や予算を制約条件として、その中で実現する価値を調整するという考え方になります。
制約構造では、異なる適応型アプローチが、異なるプロジェクトのベースラインをセットする可能性があり、他のプロジェクトによって固定された制約で動くために、一連の制約を変更する能力が必要になります。
ここで言われている「制約を変更する能力」とは、無秩序に変えることではなく、固定制約を守るために、どこを調整するかを意図的に選択し、変更する能力を指しています。
PMBOK(R)第8版により「適応型アプローチの制約構造」
Predictive（予測型アプローチ）
Predictive アプローチは、プロジェクトのスコープを早い段階で安定させることができる場合適しています。ウォーターフォール型、計画主導型、または従来型アプローチがこの予測型プローチに該当します。
・成果や要件が比較的明確
・変更コストが高い
・事前計画の価値が高い
という前提に適した考え方です。
計画段階で多くの判断を行い、実行段階では計画に基づいて進めることに重心が置かれます。
利害関係者はプロジェクト全体が完了する前に製品の一部を使用してメリットを得ることができ、構造化された計画と管理された変更管理の予測フレームを遵守しながらプロジェクトの価値提案を強化できるメリットがあります。
Adaptive（適応型アプローチ）
アダプティブ型アプローチは、変更主導型アプローチ、アジャイルアプローチが該当します。プロジェクトの要件と技術ソリューションが大きな不確実性と変動性にさらされており、プロジェクト全体を通して大幅に変更される可能性がある場合に有効なアプローチです。
このアプローチでは、プロジェクトと製品のビジョンの定義をもとに、
・仮説を立て
・実行し（インテグレーション）
・学習し（フィードバック・優先順位付け）
・調整する
というサイクルを通じて、価値を段階的に明らかにしていきます。判断は初期に固定されるのではなく、プロジェクトの進行とともに分散して行われます。
Hybrid（ハイブリッドアプローチ）
Hybrid アプローチは、
Predictive と Adaptive のいずれかを選ぶのではなく、
・予測できる部分
・適応が必要な部分
が混在する現実的なプロジェクトを前提とした考え方です。
すべてを計画で固めることも、すべてを柔軟に変えることも適さない場合に、どこを固定し、どこを柔軟にするかを意図的に設計します。
実際にはほとんどのプロジェクトは、適応型と予測型の手法を組み合わせたハイブリッド型アプローチから大きなメリットを得ることができます。予測可能な側面を制御しながら、変化する柔軟性を持っています。
そういった意味では、第8版では、Hybrid を例外的な折衷案ではなく、多くの現場で自然に選択されるアプローチとして位置づけています。
プロジェクト開発アプローチ選択の考慮要素（PMBOK®第8版 4.3 要約）
PMBOK(R)第8版の4.3の「Considaration Development Approach Section」で説明されている各要素とアプローチの関係を整理します。これは論理的に各プロジェクトの状況でどのアプローチが適しているのかを理解するうえで役に立つと思います。
Deliverables（成果物に関する要素）
| 変数 | 予測的アプローチが向く場合 | 適応的アプローチが向く場合 | 補足説明 |
|---|---|---|---|
| 技術・ビジネスの革新性 | 技術・ビジネスモデルが既知・成熟 | 新規性・複雑性が高い | 不確実性が高いほど探索が必要 |
| 要求の明確さ | 要求が明確・安定している | 初期段階で要求が不明確 | 要求の確実性が判断軸 |
| スコープ安定性 | スコープがほぼ固定 | スコープが変化しやすい | スコープ変動耐性が重要 |
| 変更のしやすさ | 変更コストが高い | 変更を前提に設計できる | 変更吸収力の差 |
| デリバリー形態 | 一括・完成形で提供 | 段階的・漸進的に提供 | インクリメンタル性 |
| リスク | リスクが比較的低い | 不確実性・リスクが高い | 適応はリスク学習向き |
| 安全要求 | 厳格な安全・品質要件 | 安全要件が比較的柔軟 | upfront計画の必要性 |
| フィードバック価値 | フィードバック頻度が低い | 頻繁なフィードバックが価値を生む | 顧客関与の重要性 |
| 規制 | 規制・文書要件が厳格 | 規制が比較的緩やか | 監査・証跡の重さ |
Project（プロジェクト特性）
| 変数 | 予測的アプローチが向く場合 | 適応的アプローチが向く場合 | 補足説明 |
|---|---|---|---|
| ステークホルダー関与 | 限定的関与 | 継続的・密な関与 | 意思決定頻度の違い |
| スケジュール制約 | 終了日が厳格 | 早期価値提供が重要 | 固定制約の位置 |
| 資金の不確実性 | 予算が確定 | 資金状況が流動的 | 投資判断の柔軟性 |
| 規模・複雑性 | 小規模・単純 | 大規模・複雑 | 変化耐性の必要性 |
| チーム経験・スキル | 統制型マネジメント向き | 自律・協働が可能 | チーム成熟度 |
| 依存関係 | 他プロジェクトとの依存が少ない | 相互依存が多い | 調整頻度の差 |
Organization（組織特性）
| 変数 | 予測的アプローチが向く場合 | 適応的アプローチが向く場合 | 補足説明 |
|---|---|---|---|
| 組織構造 | 階層型・機能別組織 | ネットワーク型 | 権限設計の違い |
| 組織文化 | 計画重視・統制志向 | 不確実性許容・自律重視 | 判断の前提 |
| 組織能力 | 標準化されたPMプロセス | 柔軟なWays of Working | 再現性 vs 適応性 |
| チーム規模・配置 | 大規模・分散 | 小規模・近接 | コミュニケーション密度 |
これらの整理から読み取れるポイント
- アプローチ選択は「方法論の好み」ではない
- 制約・不確実性・価値の置きどころによる構造的判断である
- 同一プロジェクト内で複数アプローチが併存し得る
- 「どれが正しいか」ではなく「何に最適化するか」が問われている
まとめ ― 第8版が示す「プロジェクトをどう捉えるか」という転換
これまで、PMBOK®第8版におけるプロジェクト・ライフサイクルの考え方を整理してきました。
第8版が明確に示しているのは、プロジェクト・ライフサイクルが「管理手順」や「工程モデル」ではなく、プロジェクトをどのような構造で理解するかを示すための概念であるという点です。
プロジェクト・ライフサイクルは、
- 製品ライフサイクルとは独立した概念であり
- 特定の開発アプローチに依存せず
- プロジェクト全体を俯瞰するための枠組み
として位置づけられています。
また、第8版では、フェーズそのものが否定されたわけではありません。フェーズは引き続き、測定可能で管理可能な属性として存在します。
しかし、その位置づけは大きく変わりました。
第6版までのように、
- フェーズ構造を前提に管理を設計する
- フェーズを起点にプロジェクトを理解する
という発想から、
- 原則に基づく判断の結果として、プロジェクトの状態を記述する要素
へと、フェーズの意味づけが再定義されています。
この整理によって、第8版では、
- ライフサイクル
- 開発アプローチ
- 管理手法・実践
が明確に分離され、それぞれが異なる役割を担う構造になりました。
参考書籍
※本稿はプロモーションを含みます。
コメント