新人PMO・中途入社者のオンボーディング研修をゲームで設計する方法

新しくPMOに配属されたメンバーや、中途入社でプロジェクトの途中から参画するメンバーは、最初の数週間で覚えることが山のようにあります。報告の宛先、変更の受け付け方、リスクと課題の管理表、リリース判定の進め方。多くはどこかの資料に書かれていますが、資料を読んだだけで、最初の判断の場面で迷わずに動ける人はそう多くありません。

この記事では、新人PMOやプロジェクト参画者のオンボーディングを、状況判断のクエストとして設計する方法を紹介します。PMP®資格を持つプロジェクトマネージャーがFirst Runを設計する中で整理した考え方をもとに、最初に押さえるべき4つのテーマ、資料をクエストに変える手順、サンプルのクエストカード、設計チェックリストを順に取り上げます。

最初の数週間で押さえる4テーマ

経験の有無にかかわらず、新しくプロジェクトに加わった人がつまずきやすいのは、専門知識よりも「このプロジェクトでは、どう進めるのか」というローカルなルールです。特に次の4つは、最初の数週間のうちに判断を求められやすいテーマです。

報告ライン

誰に、何を、いつまでに、どの形式で報告するか。週次報告の締め切り、定例会議の位置づけ、クライアントとの窓口は誰か、判断に迷ったときの相談先はどこか。報告ラインがわからないと、新しいメンバーは「誰にも言わずに抱え込む」か「とりあえず全員に送る」のどちらかに振れがちです。

変更管理

変更要求をどこで受け付け、誰が影響分析を行い、誰が承認するのか。承認された変更を、スケジュールやスコープのベースラインにどう反映するのか。前職で口頭の依頼をそのまま受けていた人ほど、ここで戸惑います。

リスクと課題の区別

リスクはまだ起きていない不確実な事象、課題はすでに起きている問題です。言葉では単純ですが、現場では混同されがちです。リスクを課題として扱えば過剰な対応や不要な混乱を招き、課題をリスクとして扱えば対応が遅れます。リスク登録簿と課題管理表がそれぞれどこにあり、どう使い分けるのかも、初週に確認しておきたい点です。

Go/No-Go判定

リリースの可否を判断する基準は何か、判定には誰が参加するのか、残っている不具合はどう扱うのか。判定会議に初めて同席する前に判断の基準を知っているかどうかで、その会議から学べることの量が変わります。

資料だけでは定着しない理由

これら4つのテーマは、どの組織でもプロジェクト計画書や手順書に書かれているはずです。それでも資料だけでは定着しにくい理由があります。

資料は「何があるか」を説明しても、「どの場面で使うか」までは示さない
読んで理解することと、その場で判断することは別の行為である
中途入社者は、前職のやり方を無意識に当てはめて判断しやすい
経験者ほど「知っていて当然」と見られ、基本的な質問をしにくい
OJTは担当者や案件によって差が出やすく、必要な場面が来るまで学ぶ機会がない

特に中途入社者の場合、前職で身についた「当たり前」が、新しい組織のルールとぶつかることがあります。前職では開発者への直接依頼が普通だった人は、変更管理を通すという発想を持ちにくいかもしれません。こうしたズレは資料を読むだけでは表に出にくく、実際の場面で初めて問題になります。

資料をクエストに変える手順

そこで、資料の内容を「判断の場面」に置き換えます。First RunのPMOクエストと同じ形式でクエストを作るなら、流れは次のとおりです。

新しいメンバーが最初の数週間で必ず出会う判断の場面を洗い出す
場面ごとに、最初に取るべき行動とその理由を決める
実際に起きやすい誤りをもとに、もっともらしい誤答を3つ用意する
各選択肢に評価、フィードバック、学習ポイントを書く
迷ったときの手がかりとして、ヒントを1文添える
間違えた場面を後から解き直せるようにする
実施後、選ばれた回答の傾向を見て、クエストと資料を見直す

場面を洗い出すときは、過去のプロジェクトの振り返りや教訓の記録が役に立ちます。新しいメンバーがつまずいた場面は、そのままクエストの題材になります。

誤答づくりには特に時間をかけてください。明らかに間違った選択肢ばかりでは、考えなくても正解できてしまいます。実務で起きやすい誤りは、たいてい次のどれかに当てはまります。

隠す・先送りする：確定するまで黙っておく、判断を無期限に延ばす
独断で決める：合意なくスコープを削る、依頼をその場で受け入れる
丸投げする：自分で調整する前に、上位者へエスカレーションする
過剰に反応する：影響を評価する前に、大きな対応に踏み切る

評価は正解と不正解の2択ではなく、段階をつけるのがおすすめです。First Runでは、優秀（Excellent）・良好（Good）・リスクあり（Risky）・不十分（Poor）の4段階で評価します。たとえば外部APIの安定性に不安がある場面で「APIをすぐに全面的に置き換える」を選ぶと、評価は「リスクあり（Risky）」です。リスクに向き合ってはいるものの対応が大きすぎる、という判断を、段階の違いで伝えられます。

サンプルのクエストカード

以下は、この記事のために作成したサンプルです。First RunのPMOクエストと同じ形式で、「リスクと課題の区別」を扱っています。

クエスト名：リスクか、課題か状況：参画して2週目。定例会議で、外部ベンダーから「来週の納品が遅れるかもしれない」と連絡があったことが共有されました。遅延はまだ確定していません。質問：PMOとして、最初に何をしますか？ A. リスク登録簿に記録し、発生の可能性と影響、対応策と担当者を決める B. 課題管理表に登録し、すぐにクライアントへ遅延を報告する C. 遅延が確定するまで様子を見る D. 別のベンダーへの切り替えをすぐに検討し始めるヒント：まだ起きていないことは、どちらの管理表で扱うでしょうか。

各選択肢の評価とフィードバックは、次のように設計します。

A 優秀（Excellent）：まだ確定していない事象はリスクとして扱い、発生の可能性と影響、対応策を決めておきます。学習ポイントは「リスクは起きる前に管理する」
B リスクあり（Risky）：確定していない段階で課題として扱い、クライアントに報告すると、不要な混乱を招くおそれがあります。学習ポイントは「リスクと課題を区別する」
C 不十分（Poor）：確定してから動くと、取れる対応の選択肢が減ります。学習ポイントは「不確実なうちに備える」
D リスクあり（Risky）：影響を評価する前の過剰な対応です。学習ポイントは「対応は影響の大きさに見合った形で」

このクエストの続編として「納品の遅延が確定した」場面を用意すると、リスクが課題に変わる瞬間を体験できます。その場合の正解は、課題として登録し、原因・影響・代替案を整理して関係者に共有することです。

ゲームの仕組みを研修に活かす

クエストの形式にするだけでも効果はありますが、ゲームの仕組みを組み合わせると、学びが続きやすくなります。First Runでは、次のような仕組みを取り入れています。

ヒント：開いても減点されないため、わからないまま当てずっぽうで選ぶことを減らせます
復習ボード：「リスクあり」「不十分」だったクエストが自動で集まり、解き直して正解すると「Recovered（リカバー済み）」になります
メンターとの対話：PMOの場合、PMOタワーのメンターLeoをはじめ、同僚との会話からクエストが始まるため、場面の文脈をつかみやすくなります
ストーリー：プロローグからエピローグまでの7つのチャプターで、プロジェクトの局面が進みます。近道を選びがちなライバルPMのKevinは、章を追うごとに変化し、QAを省いた判断の結果と向き合います
T型成長クエスト：Lv.3からほかの職種のメンターのクエストにも挑戦でき、PMOとして開発者やデザイナーの判断の背景を知ることができます
プレイレポート：正答率や強み、伸ばしたい点を確認でき、メンターとの1on1の材料になります

実績も、クリアした数ではなく、同僚と話す、間違えたクエストを復習で取り戻すといった、新しいメンバーに期待したい行動に対して与えるように設計しています。

なお、First Runのクエストは特定の企業のルールではなく、プロジェクトの現場で一般的に起きる場面を題材にしています。自社固有の報告ラインや承認者については、この記事の手順で自社用のシナリオに落とし込み、定例やメンタリングで補うことをおすすめします。

最初の4週間の設計例

テーマを一度に詰め込まず、週ごとに1テーマずつ扱うと、実際の業務で出会うタイミングと学ぶタイミングを近づけられます。

1週目：報告ライン。報告と共有の場面のクエストに取り組み、実際の週次報告の宛先と形式を確認する
2週目：変更管理。変更要求の受け付けと承認の場面を扱い、実際の変更管理の記録を見せてもらう
3週目：リスクと課題。リスク登録簿と課題管理表の実物を確認し、区別を問うクエストに取り組む
4週目：Go/No-Go判定。判定基準を問うクエストに取り組んだうえで、実際の判定会議に同席する

各週の終わりには、メンターと短い振り返りの時間を取ります。どのクエストで迷ったか、実際の業務で似た場面があったかを話すことで、ゲームの中の判断が現場の判断につながります。

オンボーディング設計チェックリスト

新しいメンバーが最初の数週間で出会う判断の場面を洗い出したか
報告ライン（誰に、何を、いつまでに、どの形式で）を場面として示しているか
変更要求の受け付け経路と承認者が、正解の根拠として明記されているか
リスクと課題を区別する場面が含まれているか
Go/No-Go判定の基準と参加者を、判定会議の前に学べるか
誤答が、隠す・独断・丸投げ・過剰反応といった実際に起きやすい誤りになっているか
各選択肢に、評価の理由と学習ポイントがあるか
間違えた場面を、後から解き直せるか
中途入社者の前職での「当たり前」と、自社のルールの違いを扱っているか
結果をメンターとの1on1や振り返りにつなげているか
回答の傾向をもとに、資料とクエストを見直す仕組みがあるか

まとめ

新人PMOや中途入社のプロジェクト参画者にとって、最初の数週間に必要なのは、知識の量よりも「このプロジェクトではどう判断するか」の感覚です。報告ライン、変更管理、リスクと課題の区別、Go/No-Go判定を、資料ではなく判断の場面として体験してもらうことで、ルールが場面と結びついて残ります。

判断の考え方そのものはPMP試験の状況判断問題の解き方で、経験者が合格後に直面する課題はPMP合格後にぶつかる「実務の壁」で扱っています。PMPの学習経験をクエストに変えた背景はPMPの学習経験をオンボーディングのクエストに変える方法で、遊び方は初心者向けマニュアルで紹介しています。

※ PMP®およびPMBOK®は、Project Management Institute, Inc.の登録商標です。First RunはPMIと提携しておらず、PMIによる承認や推奨を受けたものではありません。

実務シナリオをクエストで体験してみませんか

PMOを含む5つの職種の実務シナリオを、ブラウザからFirst Runでプレイできます。