★★プロジェクト・チームは、製品に必要な要素をプロジェクトマネジメント計画書に入れ忘れていました。チームは迂回策を考えましたが、プロジェクトマネジメント・オフィス（PMO）は、品質レビューでその対応が無効だと判断しました。PMはどうすべきでしょうか？「この問題に対する改訂版迂回策のプロトタイプを考える。」「要求トレーサビリティ・マトリックスで抜け漏れた要素のビジネス価値を確認する。」「正式な統合変更管理プロセスに従って変更管理委員会（CCB）に変更要求を提出する。」「別の迂回策を考える影響を評価するためにリスクの定性的分析を行う。」

→正式な統合変更管理プロセスに従って変更管理委員会（CCB）に変更要求を提出する。

要素の抜け漏れと迂回策の失敗に対処するために変更が必要です。変更管理プロセスでは、変更の定義、分析、評価を行い、変更によるスコープ、スケジュール、予算他への影響を特定します。承認された変更は、プロジェクトの計画文に反映し、ステークホルダーに周知します。

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

プロトタイプは成果物の評価に使われるもので、迂回策のプロトタイプというのは意味不明です。

要件が抜け漏れているので、要求トレーサビリティ・マトリックスを確認しても当該要素は含まれていません。

リスク分析は必要ですが、単独で行うのではなく変更管理プロセスの一環として包括的に行うべきです。

このケースでは、プロジェクト計画に必要な要素（＝スコープ内の重要な要件）が抜け落ちていたという明確な不備があり、チームが独自に考えた迂回策はPMOによって「無効」と判断されています。
つまり、既存のプロジェクト・マネジメント計画では対応できない事態が発生しています。

PMとして適切な次の行動は、統合変更管理プロセス（Integrated Change Control）を開始することです。
これは、PMBOK第6版・第7版のどちらでも共通して「プロジェクト計画・成果物への変更が必要な場合の正式な手順」とされています。

具体的には、PMはまず変更要求（Change Request）を作成し、CCB（Change Control Board）に提出して承認を得る必要があります。
承認を経て初めて、抜け落ちた要素を正式に計画書に反映させることができます。

「この問題に対する改訂版迂回策のプロトタイプを考える」：
チーム独自の対処はすでにPMOによって「無効」と判断されています。
公式な変更手続きなしに再び代替策を試みるのは、**非公式な変更（無秩序な変更）**にあたり、プロジェクト統制を失う行為です。
「要求トレーサビリティ・マトリックスで抜け漏れた要素のビジネス価値を確認する」：
確認自体は有用な活動ですが、それは「なぜ抜けたか」「どの要件に関連するか」を分析する段階の話です。
現時点ではすでに問題が顕在化しており、まず正式な変更プロセスを開始するのが優先されます。
「別の迂回策を考える影響を評価するためにリスクの定性的分析を行う」：
リスク分析は、対応策の候補が承認された後に行うものです。
まだ正式な変更手続きも踏んでいない段階でリスク分析を始めても、前提条件が不明確なままの分析となり、順序が逆です。

PMP試験では、「問題が発生したときにまず何をすべきか？」という問いが頻出します。
このタイプの問題では、次の原則を意識しましょう。

✅ まとめ：

チームの迂回策が否定された時点で、非公式対応ではなく「正式な変更要求」を提出する。
これがプロジェクト・マネジメントの基本原則であり、PMBOKにおける「統合変更管理プロセス」の模範的対応です。

ミニ試験15(日本語)4