プロジェクト・マネジャーは、更改プロジェクトの計画段階で、同じ技術を利用した他のプロジェクトをベンチマークとして参照したところ、保守作業による長時間のサービス停止が頻繁に発生していました。PMは次のステップとして何をすべきでしょうか?「他の技術を利用したプロジェクトをベンチマークして、より客観的なベースラインを設定する。」 「リスク登録簿に項目を追加して、ベンチマークに基づくしきい値を設定する。」 「スポンサーとダウンタイムの推定値について話し合い、サービス停止の事前承認を得る。」

→リスク登録簿に項目を追加して、ベンチマークに基づくしきい値を設定する。

リスク登録簿にリスク項目を登録して、予防あるいは発生時の対策について議論します。

理由(なぜこれが正しいのか)

この問題の本質は、過去のベンチマーク結果から将来的なリスクを予見した場合に、PMがどのように対応すべきか です。
PMが他プロジェクトのデータから「長時間のサービス停止が頻繁に発生していた」と気づいた時点で、それは明確な**リスクの兆候(リスクトリガー)**です。

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

そのリスクを正式にリスク登録簿に記録し、許容できるしきい値(トリガー条件)を設定すること。

です。


✅ PMP/PMBOK的な考え方

PMBOK第6版・第7版の「リスク・マネジメント計画」および「リスクの特定」プロセスでは、以下が基本ステップです:

  1. **ベンチマーク分析(Benchmarking)**により、過去の類似プロジェクトからリスク要因を抽出する。
  2. **リスク登録簿(Risk Register)**にリスクとして記載する。
    • 例:「保守作業中のシステムダウンが長時間化する可能性」
  3. **しきい値(Threshold)**を設定して、どの程度の停止時間なら許容できるかを定義する。
  4. 必要に応じて**リスク対応策(mitigation plan)**を立案する。

つまり、ここでPMが行うべき「次のステップ」は、分析を終えた上で**文書化・定量化(登録+しきい値設定)**を行う段階なのです。


❌ 他の選択肢が不適切な理由

「他の技術を利用したプロジェクトをベンチマークして、より客観的なベースラインを設定する。」

  • すでに有用なベンチマーク情報(同技術の過去事例)が得られています。
  • 「別の技術」での比較は分析の焦点をぼやかす行為であり、今必要なのは新たな情報収集ではなくリスク対応です。

「スポンサーとダウンタイムの推定値について話し合い、サービス停止の事前承認を得る。」

  • これはリスク対応策の実施段階で行うべきこと。
  • 現時点では、まだリスクを正式に記録・定義していないため、スポンサーとの交渉は早すぎます。
  • 「まず文書化→影響分析→対応計画→承認」が正しい順序です。

💡 ワンポイントアドバイス(試験対策)

PMP試験では、「次に何をすべきか(first/next)」の設問で、次のように整理すると正解率が上がります:

状況正しい対応
問題やパターンに気づいたリスクを特定し、登録簿に記載
既知のリスクが発生・顕在化影響分析を実施
承認やリソースが必要スポンサー・CCBと協議

この問題は1番目(リスクの特定)に該当します。


✅ まとめ

他のプロジェクトで同じ技術に関するダウンタイム問題が多発していることに気づいたら、
それをリスクとして正式に登録簿に追加し、発生を検知するしきい値を設定する。

これは、ベンチマーク分析の結果をリスクマネジメントに反映させる、
最も体系的かつプロアクティブな対応です。

フルレングス試験1 (日本語) 118

コメント

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