→正式な変更要求を提起する。
オープンソース製品の利用にはプロジェクト計画の変更が必要なので、正式な変更要求を提起します。変更による影響をステークホルダーに周知することで混乱を最小限に抑えることができます。
その他の選択肢は誤りです。
追加スキルが必要なのはユーザーでありチーム・メンバーではありません。
コスト・マネジメント計画書のレビューが必要かもしれませんが、変更が承認された後に行うことです。
プロダクト・マネジャーへの相談は、アジャイル・プロジェクトであれば必要でしょう。
理由（なぜこの選択肢が正しいのか）
このケースでは、ステークホルダーが「既成のオープンソース製品を採用したい」というスコープ変更提案を行っており、
さらに、その変更によって「チームに新しいスキル（＝トレーニングの必要）」というプロジェクトへの影響が発生しています。
このように、スコープ・スケジュール・コスト・リスク・品質などに影響を与える可能性のある提案が出た場合、
PMBOKの統合変更管理プロセスでは、
まず 正式な変更要求（Change Request）を提出する のが正しいステップです。
その後、影響分析を行い、変更管理委員会（CCB）やスポンサーの承認を得てから実施可否を決定します。
PMが自己判断でトレーニングや導入を進めるのは、プロセス逸脱にあたります。
その他の選択肢が誤りである理由
❌ 「プロジェクト・チームのトレーニングを要求する。」
まだ変更が正式に承認されていない段階で、トレーニングを依頼するのは時期尚早です。
新しい製品の採用はプロジェクトのコスト・スケジュールに直接影響するため、
まずは変更要求を提出して承認を得ることが先になります。
承認後に、必要なトレーニング計画を立てるのが正しい流れです。
❌ 「コスト・マネジメント計画書をレビューする。」
コスト影響の評価は、変更要求を提出した後の「影響分析フェーズ」で行うべき作業です。
現時点では、「オープンソース製品を採用する」という提案が承認されたわけではありません。
したがって、いきなりコスト・マネジメント計画書をレビューするのは手順の飛ばしです。
❌ 「プロダクト・マネジャーに相談する。」
アジャイル的な要素を含んでいる場合でも、今回のように製品そのものの採用可否やプロジェクト方針を変えるレベルの話は、
プロダクト・マネジャー単独で決定できる範囲を超えています。
ステークホルダー間の合意や公式承認を必要とするため、まずは正式な変更要求を通すことが適切です。
ワンポイントアドバイス
PMP試験では、「まず何をすべきか？」という設問で、“変更を承認なく進める行動”は常に誤りになります。
- 提案や要望を受ける
→ 正式な変更要求を提出
→ 影響を分析
→ 承認を得て実施
この流れを守ることが、**統合変更管理（Perform Integrated Change Control）**の基本です。
まとめ
- 状況：ステークホルダーからオープンソース製品採用の提案
- 影響：チームに新スキル習得（＝スコープ・スケジュール・コストへの影響あり）
- PMの行動：まず正式な変更要求を提起する
🟩 ワンポイント：
「提案を受けたらすぐ対応」ではなく、「まず公式な変更手続きを踏む」。
PMPでの鉄則：“Evaluate before Act.”（行動の前に影響評価）
ミニ試験11(日本語)6
コメント