プロジェクトマネジメントは、スケジュールを守るだけの仕事ではありません。スコープを整理し、リスクを予測し、ステークホルダーとコミュニケーションを取り、変更要求の扱いを判断する。この一連の判断こそがプロジェクトマネジメントの中心です。
First Run は、こうした実務の判断を新しいメンバーがゲームのクエストとして体験できるように設計したオンボーディング RPG です。設計の土台には、PMP® 資格を持つプロジェクトマネージャーの実務経験があります。この記事では、PMP の学習で身につく PMBOK® ガイド的なものの見方を、どのように状況判断のクエストに変えているのかを紹介します。
なぜPMをクエストで学ぶのか
新しいメンバーは、文書を読むだけではプロジェクトの状況を立体的に理解しにくいものです。一方で、「クライアントが途中で追加の要望を出してきた」「QA の段階で重大な不具合が見つかった」「人手が足りず優先順位を決め直す必要がある」といった場面を、実際に選択肢として経験すると、仕事の流れがぐっとつかみやすくなります。
プロジェクトの判断には、正解がひとつに決まらないものが多くあります。どの行動も間違いではないが順番が違う、誰に先に伝えるかで結果が変わる、という種類の判断です。こうした判断は、文書の記述を読むよりも、場面の中で一度選んでみるほうが身につきます。
PMP学習と状況設問の相性
PMP の学習でよく出会うのが、状況を読み「プロジェクトマネージャーとして次に何をすべきか」を選ぶ形式の設問です。用語を暗記しているだけでは解けず、その場面で何を優先すべきかを判断する力が問われます。
オンボーディングのクエストも、同じ発想でつくることができます。「正しい用語を選ぶ問題」ではなく、「最初に確認すべきこと」「いま報告すべき相手」「リスクへの対応方法」を選ばせると、実務に近い判断の練習になります。
PMBOKの視点を場面に置き換える
PMBOK ガイドは版によって構成が変わってきました。第6版では、統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーという知識エリアで整理され、第7版では原理・原則とパフォーマンス領域を軸とした構成に改められました。版が変わっても、プロジェクトを複数の視点から見るという姿勢は変わりません。
First Run の PMO クエストでは、その中から新人がつまずきやすい5つの視点を選び、それぞれを判断の分かれ目がひとつだけある場面に置き換えています。
スコープ：変更要求の受け止め方
- 場面：締め切りの直前に、クライアントが大きな機能の追加を依頼してくる
- 問われる判断：その場で受ける・断るを決めるのではなく、スケジュール、コスト、リスクへの影響を評価してから合意につなげられるか
- ありがちな選択：無条件に受け入れて詰め込む、一律に断って関係を損なう、チームに黙って残業させる
スケジュール：遅延をいつ伝えるか
- 場面：主要機能の開発が3日遅れることが確実になった
- 問われる判断：原因、影響、対応案を整理し、ステークホルダーに早い段階で共有できるか
- ありがちな選択：週末に取り戻せることを期待して黙っておく、合意のないままスコープを削る
リスク：起きる前に登録する
- 場面：連携している外部 API の安定性に不安がある
- 問われる判断：まだ起きていない不確実性をリスクとして識別し、リスク登録簿に記録して、軽減策と対応計画を立てられるか
- ありがちな選択：問題が起きてから対応する、いきなり API を全面的に入れ替える
- 押さえたい区別：リスクは「起きるかもしれないこと」、課題は「すでに起きていること」です。この区別ができると、報告と対応の優先度を正しく付けられます
変更管理：承認後のベースライン
- 場面：承認された変更要求を、これから計画に反映する
- 問われる判断：スケジュールとスコープのベースラインを更新し、チームに共有するところまでを変更管理の一部として扱えるか
- ありがちな選択：承認されたのですぐに開発だけ始める、変更を口頭でしか伝えない
- 押さえたい点：変更は承認された時点では終わりません。基準となる計画を更新し、全員が同じ版を見ている状態になって初めて完了します
ステークホルダー：調整と報告
- 場面：デザインチームと開発チームが優先順位をめぐって対立している。あるいは、役員にプロジェクトの状況を報告する
- 問われる判断：共通の目標を基準に、データで優先順位を合意できるか。報告では、結論、リスク、必要な意思決定を先に示せるか
- ありがちな選択：声の大きい側に合わせる、判断を先送りする、何でも上にエスカレーションする。報告では、作業の記録を時系列で読み上げてしまう
このほかにも、リリース前夜に致命的ではない不具合が5件残っている場面での Go/No-Go 判定（深刻度と影響範囲を評価し、主要な利用経路が問題なく動くことを確かめてから判断する）や、何週間も残業が続いて疲れ切ったチームへの対応（優先順位を見直し、スコープとスケジュールを現実的なものにする）といった、品質と資源にかかわるクエストもあります。
ひとつのクエストの組み立て方
First Run のクエストは、状況の説明、4つの選択肢、ヒント、フィードバックで構成されています。たとえばスケジュールのクエストは、次のような問いから始まります。
状況：主要機能の開発が3日遅れることが確実になりました。 問い：最初にすべきことは何でしょうか。
PMP の状況設問と同じように、問われているのは「正しい行動」ではなく「最初の行動」です。設計では次の4点を意識しています。
- 状況の説明には、締め切りや確定済みの事項など、選択を絞り込む制約を入れる
- 誤答の選択肢は、明らかに悪い行動ではなく、現場でついやってしまいがちな行動にする
- 評価は Excellent（優秀）、Good（良好）、Risky（リスクあり）、Poor（不十分）の4段階にし、確認を飛ばした選択やリスクを誰かに先送りする選択は Risky 以下にする
- フィードバックでは正誤よりも「なぜその順番なのか」を説明し、学習ポイントをひとつ示す
ヒントは答えそのものではなく、見るべきポイントを示します。スケジュールのクエストなら遅延を隠さず早めに共有すること、スコープのクエストなら変更の影響（スケジュール、コスト、リスク）を先に評価すること、といった観点です。
選んだ結果が信頼として残る
プレイヤーは PMO タワーのメンター Leo が示す状況を読み、最も適切だと思う対応を選びます。結果に応じて EXP（経験値）、評判、メンターの信頼度、昇進ポイントが変わり、レベルアップやバッジの獲得につながります。
Risky や Poor を選んでも進行は止まりませんが、評判とメンターの信頼度が下がり、そのクエストは完了しないまま復習ボードに残ります。あとからやり直して Good 以上を取れば、Recovered（リカバー済み）として記録されます。実際のプロジェクトでも、判断の結果は周囲からの信頼という形で積み重なります。その感覚を、失敗しても実害のない場所で先に経験できるようにしています。
レベル3からは他職種のクエストにも挑戦でき、自分の専門を深めながらほかの役割も理解する T型の成長を体験できます。
社内のPM研修に組み込むには
新人 PMO やプロジェクトメンバーの研修に取り入れる場合は、次のような使い方が考えられます。
- 自社の変更管理手順やエスカレーション経路と、クエストのフィードバックを見比べ、違いがあればその理由をメンターと話し合う
- 間違えたクエストの類型をもとに、1on1 で自社の実例を補足する
- PMBOK の用語と、自社で実際に使う呼び方を対応させておく（たとえば「変更要求」を社内では「仕様変更依頼」と呼んでいる、など）
PMO の判断をクエストにする具体例は、新人PMOが直面する意思決定シナリオでも紹介しています。
PMPとPDUについての注意
PMP® は Project Management Institute, Inc.（PMI）の登録商標です。First Run は PMI とは提携しておらず、PMI の公認教材でもありません。プレイしても PDU（PMP 資格の維持に必要な継続学習の単位）は付与されません。First Run は資格試験の対策ツールではなく、PMP の学習で培われる考え方を、新人研修での状況判断の練習に応用したものです。
判断を先に経験させる研修
よいオンボーディングは、情報を渡したところで終わりません。新しいメンバーが実務の状況を前もって経験し、自分で判断してみる機会をつくることが大切です。PMP の学習で身につくスコープ、スケジュール、リスク、変更管理、ステークホルダーという視点は、そのまま「場面を読み、次の一手を選ぶ」練習の設計図になります。
First Run は、プロジェクトマネジメントと職種ごとの実務の場面をクエストに置き換え、入社直後から判断の経験を積めるオンボーディングを目指しています。操作方法は初心者マニュアルにまとめています。
実務シナリオをクエストで体験してみませんか
PMO をはじめとする職種別の状況判断クエストは、First Run のデモで実際にプレイできます。