→ステークホルダーとパフォーマンス指標を見直し、システムでそれを達成できるようにする。
これによりステークホルダーの懸念を理解し、新システムがニーズを満たしているかどうかを確認できます。
その他の選択肢は最善策とは言えません。
新たなユーザー・ストーリーの特定は、パフォーマンス指標の見直しと合意後に行うべきです。
ステアリング・コミィティ・ミーティングの前に、まずはステークホルダーと話をして懸念を明らかにすべきです。
プロジェクト・ベネフィット・マネジメント計画書は、プロジェクト開始前に作成すべき文書です。
理由（なぜこれが正しいのか）
この選択肢は、すでにプロジェクトが実行または設計段階に入っていることを前提とした行動を表しています。
つまり、今必要なのは「計画の作成」ではなく、「既存のパフォーマンス指標（KPI）や成果基準を現実に合わせて再調整し、それを実装に反映すること」です。
PMP的な文脈で解釈すると
- 「パフォーマンス指標」＝プロジェクト成功を測る具体的な数値目標（例：稼働率、処理時間、ROIなど）
ステークホルダーの期待と実際の成果指標がずれている場合、PMは再定義や調整をリードする必要があります。 - **「見直してシステムで達成できるようにする」**という部分が重要。
これは単なるレビューではなく、実際のプロジェクト成果（システム要件や機能）に反映させるアクションを意味します。
つまり、ステークホルダーの期待 → パフォーマンス指標 → システム成果物
という三段階の整合を図る行為です。 - PMBOK第7版でも、成果（Outcomes）を実現するために「価値デリバリーを指標で管理し、実際のプロダクトに反映する」ことが重視されています。
この考え方は、単なる計画書作成よりも実践的・アジャイル寄りのマインドセットです。
🚫 他の選択肢が誤りである理由
「プロジェクト・ベネフィット・マネジメント計画書を作成してステークホルダーとレビューする。」
→ これは立ち上げフェーズや初期段階で有効な行動です。
しかし問題文は「すでにシステムをどう設計・実行するか」の文脈を示しており、
いま必要なのは計画書の作成ではなく、実際のパフォーマンス指標を調整・実現することです。
したがって、やや“前段階の対応”になります。
「プロダクト・マネジャーと相談して、この懸念に対処するためのユーザー・ストーリーを特定する。」
→ これは実装レベル（戦術）の対応であり、
「システム全体の成果をどう測るか」という戦略レベルの問題を解決するには範囲が狭すぎます。
「プロジェクトの成功要因を明らかにするためにステアリング・コミッティ・ミーティングを招集する。」
→ 成功要因の議論を行うこと自体は良いですが、
この選択肢は**“議論する”にとどまり、実際のパフォーマンス指標の見直し・反映という行動がない**ため不十分です。
💡 ワンポイントアドバイス
PMP試験では「どのフェーズにいるか」を見極めるのがカギです。
| フェーズ | 正しい行動 |
|---|---|
| 立ち上げ | ベネフィット・マネジメント計画書の作成 |
| 計画中 | 成功要因や指標の設定・合意 |
| 実行中 | パフォーマンス指標の見直し・調整・成果反映 |
今回のように**「システムでそれを達成できるようにする」**という表現がある場合、
それは「実行フェーズ」でのアクションを問うシグナルです。
✅ まとめ
- 状況：パフォーマンスやベネフィットの基準があいまいなまま実行中
- PMの目的：成果をステークホルダー期待と一致させる
- 最適な行動：ステークホルダーとパフォーマンス指標を見直し、それをシステム設計・実装に反映すること
👉 よって正解は：
「ステークホルダーとパフォーマンス指標を見直し、システムでそれを達成できるようにする。」
🟩 一言で覚えるなら：
「立ち上げでは定義する、実行では見直して実現する。」
ミニ試験8(日本語)5
コメント