【PMBOK第8版】変更の評価と実装〜予測型・適応型の違いと「終わらないアジャイル」の罠

PMBOK第8版のガバナンス・パフォーマンス領域を読み解くシリーズ。今回は、8つ目のプロセスである「2.1.6.8 変更の評価と実装（Assess and Implement Changes）」について解説します^[1]出典：Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 … Continue reading。

いかなるプロジェクトであっても、開始から完了までの間に「変更」は避けて通れません。このプロセスは、プロジェクトを成功に導くために、変更要求をどのように評価し、実装（コントロール）していくかを定義しています。

PMBOK第8版の大きな特徴は、この変更管理のやり方を「予測型アプローチ（ウォーターフォール）」と「適応型アプローチ（アジャイル）」で明確に区別して解説している点にあります。

予測型（Predictive）アプローチにおける変更管理

予測型のプロジェクトでは、計画の「ベースライン（基準線）」が設定されるまでは柔軟な調整が可能ですが、一度ベースラインが確定した後は、すべての変更は「公式なプロセス」を経る必要があります。

適応型（Adaptive）アプローチにおける変更管理

一方、適応型のアプローチでは、CCBのような公式で厳格な変更要求プロセスは存在しません。変更は主に「バックログ・マネジメント（Backlog management）」を通じて、より柔軟に管理されます。

• 継続的な評価と優先順位付け：
  ステークホルダーから変更が提案されると、それは「プロダクト・バックログ」の新しいアイテムとして記録されます。そして、反復的（イテレーティブ）な開発サイクルの中で、常にその優先順位が評価され続けます。

適応型には公式な「承認・延期・却下」のプロセスはありませんが、バックログの扱いが実質的にそれに相当します。

• 承認に相当： 提案された変更がバックログに追加され、開発の優先順位が高く設定されること。
• 延期に相当： 提案された変更に、低い優先順位が割り当てられること。
• 却下に相当： 変更をバックログに追加しないと決定すること、または既存のアイテムをバックログから削除すること。

【SSAITSの視点】「エターナル（終わらない開発）」の罠に注意

今回の第8版の定義を見ると、適応型（アジャイル）の変更管理は、事実上「変更のための作業が、新たなバックログとして次々と追加されていく」というスタイルであることがわかります。

柔軟に対応できることはアジャイルの強みですが、実務においてはここに大きな罠が潜んでいます。

変更要求を言われるがままにバックログに追加し続けると、タスクが無限に増殖し、いつまで経っても開発が終了しない、俗にいう「エターナル（永遠）」な状態に陥ってしまうのです。
「アジャイルだから変更歓迎です！」と安請け合いし続けた結果、予算も時間も底を尽き、プロジェクトが炎上・破綻するケースは後を絶ちません。

もし、プロジェクトの進行中に「変更のための作業（新たなバックログ）」が目立って増えてきたと感じたら、それはプロジェクトの危険信号かもしれません。

そのような時は、プロマネとして一度立ち止まり、「そもそも、このプロジェクトや開発の根本的な方向性が間違っていないか？」「ユーザーの本当の課題を見失っていないか？」を、チームやステークホルダーと落ち着いて見つめ直す勇気を持つことが大切です。

まとめ

変更は、プロジェクトをより良いものにするための「機会」です。しかし、それをコントロールできなければプロジェクトを破壊する「脅威」にもなります。

予測型の「CCBによる厳格な判断」であれ、適応型の「バックログの優先順位付け」であれ、プロマネは常に「その変更は本当に価値を生むのか？」を見極め、プロジェクトを適切なゴールへと導く舵取りが求められます。