★プロジェクト・チームは、全14回のスプリントの13回目を実施中です。バックログには最終リリースに入る予定の画期的なフィーチャーが含まれています。プロダクト・オーナーは、競合企業がこのフィーチャーと同様の機能を持つ新製品を発売するという情報を得て、このフィーチャーを直近のリリースに組み込むことを要求しました。PMはどうすべきでしょうか？「開発チームとのレビュー会議を設定して必要な作業量を把握する。」「この変更についてプロダクト・オーナーやステークホルダーと話し合って今後の計画を立てる。」「必要な評価を行った上で変更管理委員会（CCB）に変更要求を提起する。」

→この変更についてプロダクト・オーナーやステークホルダーと話し合って今後の計画を立てる。

プロダクト・オーナーはプロジェクト後期に、スコープ、スケジュール、資源に影響を及ぼす可能性のある大きな変更を要求しています。プロジェクト・マネジャーは、プロダクト・オーナーやステークホルダーと話し合って影響を分析した上で今後の計画を立てるべきです。プロジェクトの戦略的ゴールや優先順位に関わる意思決定には主要ステークホルダーの意見を聞く必要があります。こうした協働的なアプローチは、アジャイル方法論の要です。

その他の選択肢は誤りです。

開発チームとのレビューは、今すぐ行うことではありません。まずはプロジェクトの主要な意思決定者を巻き込んで、この変更の実現可能性と影響について話し合うべきです。

アジャイル・プロジェクトにはCCBは存在せず、意思決定はプロダクト・オーナーとチームとステークホルダーが協働で行います。

変更による影響を分析せずに否定するのは正しいアプローチとは言えません。アジャイルでは、プロジェクトの末期でも変更を受け入れて顧客価値を最大化します。最終リリースまで変更を先送りするかどうかは、変更の影響を分析した上で関係者全員で判断すべきです。

理由

このシナリオでは、アジャイル・プロジェクトのスプリント13／14という終盤に、
POからフィーチャーを前倒して実装したいという重要な変更要求が入っています。

アジャイルでは、変更は拒絶されるものではなく、
価値に基づいて優先順位を再検討する対話のきっかけとみなされます。

したがってPMがまず行うべきは、
POと主要ステークホルダーと協議し、

この変更が全体スケジュールやリリース計画にどのような影響を与えるか
ビジネス上の価値（競合対応）としてどの程度優先すべきか
を共に検討して次の行動方針を決めることです。

これはPMBOKでも「変更はプロジェクト・チームとステークホルダーの協働によって管理する」ことが推奨されています。
特にアジャイルでは、変更管理委員会（CCB）のような形式的なプロセスよりも、迅速な対話と意思決定が重視されます。

❌ 他の選択肢の誤りの理由

「開発チームとのレビュー会議を設定して必要な作業量を把握する。」

→ 時期尚早。
　この段階ではまだ「変更を実施するかどうか」が決まっていません。
　まずはPO・ステークホルダーと戦略的な方向性を決定し、
　実施が決まった後に開発チームと見積り・調整を行うのが正しい順序です。

「必要な評価を行った上で変更管理委員会（CCB）に変更要求を提起する。」

→ これは予測型（ウォーターフォール）プロジェクトのアプローチです。
　アジャイルではCCBを通すのではなく、
　プロダクト・オーナーがプロダクト・バックログの優先順位を再調整することで変更を取り込みます。
　形式的な変更承認プロセスは、アジャイルのスピード感と柔軟性に反します。

💡 ワンポイントアドバイス

PMP試験で「アジャイル中に重要な変更要求が入った」ときは、
以下の思考ステップで判断すると迷いません👇

まず話し合う（PO・ステークホルダーと協議）
　→ 変更の価値・優先度・影響範囲を共に理解する。
その後、必要に応じて開発チームに見積り依頼。
　→ 実装可否や影響を評価する。
最終的にPOがバックログを再優先化する。
　→ 価値に基づいた柔軟な対応がアジャイルの本質。

✅ まとめ

正答：この変更についてプロダクト・オーナーやステークホルダーと話し合って今後の計画を立てる。
理由：アジャイルでは形式的なCCBではなく、PO・ステークホルダーとの協働と柔軟な優先順位調整で変更を管理する。
誤答理由：
　- 開発チームとの会議は変更実施決定後の行動。
　- CCBへの提出はウォーターフォール的対応であり、アジャイルでは不適切。
ワンポイント：
　💡「アジャイルの変更管理＝会議よりも会話、手続きよりも価値判断」。

フルレングス試験2 (日本語) 68