ビジネス・マネジャーとプロダクト・オーナーは、リリース期間を短縮して競合他社に対抗するためにプロダクト・バックログへの変更をもっと柔軟に取り込んでほしいと言っています。PMはどうすべきでしょうか?「プロダクト・オーナーがビジネス・ゴールに沿ってバックログ項目の優先順位を変更できるようコーチングする。」 「前提条件ログとプロジェクトマネジメント計画書を見て変更の可能性を見つける。」 「包括的な変更管理プロセスを作成して変更管理委員会(CCB)を準備する。」

→プロダクト・オーナーがビジネス・ゴールに沿ってバックログ項目の優先順位を変更できるようコーチングする。

バックログ項目の優先順位付けはプロダクト・オーナーの役目です。競合他社が新製品を頻繁にリリースしている場合、プロダクト・オーナーが優先順位を見直してフィーチャーのリリース順を変更する場合があります。

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

変更可能性を見つけてもリリース期間の短縮には役に立ちません。

包括的な変更管理プロセスは、むしろ変更への柔軟性を損ないます。

ステークホルダー全員に優先順位の変更権限を与えてしまうと、プロジェクト目標やビジネス・ゴールに沿わない機能が先に実装される恐れがあります。

理由

このシナリオでは、

  • 競合対応のためにリリース期間を短縮したい
  • バックログへの変更を柔軟に取り込みたい
    という要望があります。

つまり、**アジャイルの変化対応力(Responding to Change)**を強化したい状況です。

このときPM(プロジェクト・マネジャー)は、
ウォーターフォールのように「変更管理プロセスを厳格にする」方向ではなく、
アジャイルの基本原則 —

「変化を受け入れ、顧客価値を最大化する」
に従って対応すべきです。

したがって、PMが取るべき行動は:

プロダクト・オーナー(PO)がビジネス目標に沿ってバックログを柔軟に再優先できるよう支援・コーチングすること。

アジャイルでは、

  • バックログの所有者はPO
  • 優先順位変更の判断基準はビジネス価値(Business Value)
  • PMはプロセスの健全性を支援・促進する立場(サーバントリーダーシップ)

よって、「変更の受け入れ体制を作る」=「POをコーチングして自己組織化を促す」ことが最適解です。


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

「前提条件ログとプロジェクトマネジメント計画書を見て変更の可能性を見つける。」

→ これは予測型(ウォーターフォール型)の考え方です。
 前提条件や計画書は“固定された計画”を前提にしており、
 アジャイルでは計画よりも適応を重視します。
 したがって、ビジネスの変化に柔軟に対応する手段にはなりません。


「包括的な変更管理プロセスを作成して変更管理委員会(CCB)を準備する。」

→ これも完全に予測型アプローチの発想です。
 アジャイルでは、変更要求はCCBではなくPOによって優先順位の変更で管理されます。
 CCBを設けることはアジャイルの「自己組織化」と「柔軟性」に逆行します。


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

PMP試験では、次の判断基準を使うとアジャイル系問題の選択がスムーズになります👇

状況取るべき行動
柔軟性・迅速性が求められる✅ POやチームをコーチングして自己調整力を高める
変更要求が発生する✅ バックログの再優先で対応する(CCBではない)
ビジネス環境が変化✅ POがビジネスゴールと整合させるよう支援する

✅ まとめ

  • 正答
     プロダクト・オーナーがビジネス・ゴールに沿ってバックログ項目の優先順位を変更できるようコーチングする。
  • 理由
     アジャイルでは、変化への適応を支援し、POが価値に基づいてバックログを調整できるようPMが支援することが重要。
  • 誤答理由
     他の選択肢は予測型の固定的な変更管理手法であり、アジャイルの原則(柔軟性・自己組織化)に反する。
  • ワンポイント
     💡「アジャイルでの変更管理=POによる優先順位調整」。
     PMは“コントローラー”ではなく“コーチ/ファシリテーター”として機能する。

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

コメント

タイトルとURLをコピーしました