PMP®に合格したあと、最初のプロジェクトで戸惑った経験はないでしょうか。変更管理もリスクマネジメントもステークホルダー・エンゲージメントも、知識としては理解している。それなのに、目の前の状況で「いま何をすべきか」がすぐに決められない。多くのプロジェクトマネージャーが一度は経験する、知識と実務のあいだの壁です。
この記事では、その壁がどこから生まれるのかを整理したうえで、現場でよく出会う3つの場面を例に、知識を判断に変える方法を考えます。後半では、シナリオ演習、振り返り、チームのオンボーディング設計という3つの取り組みと、資格維持に必要なPDUとの付き合い方にも触れます。
知識と判断のあいだの壁
試験の状況判断問題では、状況はすでに文章として整理されています。登場人物も、起きた出来事も、選択肢も揃っています。現場では、そのどれもが最初から揃っていることはほとんどありません。
- 情報が断片的：状況文を書いてくれる人はいません。チャットや会議での発言、担当者の様子から、自分で状況を組み立てる必要があります
- 時間が限られる：会議と会議のあいだの数分で、返事を求められることがあります
- 人と関係が絡む：相手の立場、これまでの経緯、組織の慣習が、正しい手順をそのまま実行しにくくします
- やり直しがきかない：一度口にした返事や、送ってしまった報告は取り消せません
PMBOK®ガイド第7版（2021年）は、原則とパフォーマンス領域を軸に構成され、予測型・アジャイル型・ハイブリッド型のいずれにも当てはめられるよう書かれています。裏を返せば、目の前のプロジェクトにどう当てはめるかは、実践する側の判断に委ねられています。この「当てはめる力」こそ、合格後に鍛えていくべきものです。
現場で出会う3つの場面
ここからは、プロジェクトに加わって最初の数週間で出会いやすい場面を3つ取り上げます。それぞれ、知識として知っていること、実際に難しいところ、判断の組み立て方を分けて考えます。
リリース直前の変更要求
リリースを翌週に控えた段階で、クライアントの担当者から連絡が来ます。「画面に項目をひとつ追加してほしい。小さな変更なので、今回のリリースに入れてもらえませんか」。
知識としては明快です。変更要求として受け付け、影響分析を行い、変更管理のプロセスで判断する。難しいのは、それを実際の会話の中で行うことです。相手は大切なクライアントで、本人は「小さな変更」だと思っています。営業担当は受けたがり、開発リーダーは無理だと言う。その場で答えを求められることもあります。
判断の組み立て方はこうです。まず、その場では受諾も拒否もせず、「影響を確認して、いつまでに回答します」と受け止めます。次に、開発・テスト・リリース判定への影響を確認し、選択肢を用意します。今回のリリースに入れて日程を動かす、今回は見送って次のリリースで対応する、今回に入れる代わりに別の項目を外す、といった具合です。そのうえで、承認の権限を持つ人に判断してもらいます。承認された後は、ベースラインを更新してチームに共有するところまでが一連の対応です。
成果物が遅れている
設計書の提出期限が明日に迫っています。担当者に確認すると「もう少しで終わります」という答え。ただ、進捗表はここ数日「ほぼ完了」のまま動いていません。
知識としては、進捗を監視し、差異があれば原因を分析し、早めに報告する、ということになります。実際に難しいのは、人の気持ちが絡むところです。担当者を信じたい。報告すれば担当者の評価に響くかもしれない。自分自身も、悪い知らせを上げるのは気が重い。
ここでは、「ほぼ完了」を事実に分解することから始めます。残っている作業は何か、あと何時間かかるか、手が止まっている理由は何か。そのうえで遅延が確実なら、原因・影響・代替案を整理して関係者に早く共有します。大切なのは、個人を責めるのではなく問題に焦点を当てることです。First RunのPMOクエストでも、遅延の場面で「開発者だけを責める」を選ぶと「不十分（Poor）」と評価され、「問題そのものに集中」という学習ポイントが示されます。
プロセスを飛ばすステークホルダー
事業部の責任者が、変更管理を通さずに開発者へ直接、仕様の変更を依頼しました。開発者は「責任者に言われたので」と、すでに作業を始めています。
知識としては、変更は変更管理のプロセスを通すべきであり、ステークホルダーには適切な形で関与してもらう必要があります。難しいのは、相手が上位者であり、多くの場合は善意で急いでいることです。手続きを守るよう求めると、関係がぎくしゃくしそうに感じます。
判断の順序はこう考えます。まず開発者を責めず、何を依頼され、どこまで作業が進んでいるかを把握します。次に責任者には、「手続きを守ってください」というルールの話ではなく、「影響を確認して確実に反映するため」という目的で説明し、変更要求として記録して影響分析に回します。同じことが繰り返されるようであれば、依頼の経路をプロジェクトの合意事項として明文化し、コミュニケーションの計画に反映します。さらに上の役職者へのエスカレーションは、自分で調整を試みた後の手段です。
知識を判断に変える3つの習慣
3つの場面に共通するのは、正しい手順を知っているだけでは足りず、「どの順番で、誰に、どう伝えるか」を組み立てる力が求められることです。この力は、次の3つの取り組みで少しずつ育てることができます。
シナリオ演習で場数を補う
実際のプロジェクトで判断の場数を踏むには時間がかかります。そこで、短いシナリオで判断を繰り返し、フィードバックを受ける練習が役に立ちます。大切なのは正解を覚えることではなく、なぜその選択肢が優れているのか、ほかの選択肢はどこで順序を誤っているのかを言葉にすることです。
First Runでは、PMOのクエストとして、締め切り直前の機能追加、外部APIのリスク、経営陣への報告、リリース前日のGo/No-Go判定、ステークホルダー間の対立といった場面を用意しています。回答は4段階で評価され、フィードバックと学習ポイントが表示されます。間違えたクエストは復習ボードで解き直せます。状況判断の考え方そのものは、PMP試験の状況判断問題の解き方で4つのステップに整理しています。
振り返りで判断を教訓に変える
判断の力は、判断した後の振り返りで伸びます。プロジェクト終了時に教訓をまとめるだけでなく、日々の判断を短く記録しておくと、自分の判断の癖が見えてきます。記録する項目は、たとえば次の5つです。
- 状況：何が起きていて、何がわかっていなかったか
- 判断：何を、どの順番で行ったか
- 根拠：なぜそう判断したか
- 結果：実際にどうなったか
- 次回：同じ場面なら何を変えるか
数行でも構いません。数週間分たまると、「エスカレーションが早すぎる」「共有が遅れがち」といった自分の傾向が見えてきます。チームの振り返りで共有すれば、個人の経験がチームの教訓になります。
チームのオンボーディングに組み込む
プロジェクトマネージャーひとりの判断力が上がっても、チームの誰かが変更管理を知らずに作業を始めてしまえば、同じ問題は繰り返されます。新しく参画するメンバーが、最初の数週間で変更や報告のルートを理解できるように、オンボーディングの段階で判断の場面を体験してもらうことが大切です。
資料を読んでもらうだけでなく、「この場面で最初に何をするか」を選んでもらい、その理由を説明してもらう。この形にすると、ルールが場面と結びついて記憶に残りやすくなります。具体的な設計方法は、新人PMO・中途入社者のオンボーディング研修をゲームで設計する方法で紹介しています。
PDUと継続学習の考え方
PMP資格は取得して終わりではありません。資格を維持するには、3年ごとに60 PDU（Professional Development Units）を取得する必要があります。PDUの取得を、期限までに要件を満たす作業として扱うこともできますが、実務の判断を磨く機会として計画すると、学んだことが現場に戻りやすくなります。
たとえば、振り返りで見えてきた自分の弱点、エスカレーションの判断やステークホルダーとの合意形成などに合わせて学習テーマを選ぶと、学習と実務がつながります。
なお、First RunはPDUを付与しておらず、PMIの認定を受けたプログラムでもありません。PDUの対象となる活動や報告の方法は、PMIの公式情報で確認してください。First Runは、PDUとは別に、判断の練習や新しいメンバーのオンボーディングに使うものとして位置づけています。
実務の壁を越えるチェックリスト
- 変更要求を受けたとき、その場で受諾も拒否もせず、影響分析に回せているか
- 「ほぼ完了」「たぶん大丈夫」を、残作業と期日という事実に分解できているか
- 遅延やリスクを、原因・影響・代替案とセットで早めに共有できているか
- 手続きを飛ばした相手に、ルールではなく目的で説明できているか
- エスカレーションの前に、自分の権限でできる調整を試みたか
- 承認された変更について、ベースラインの更新と共有まで行ったか
- 自分の判断を、状況・判断・根拠・結果・次回の形で記録しているか
- 新しく参画するメンバーが、変更や報告のルートを最初の数週間で理解できる仕組みがあるか
- PDUの学習テーマを、実務で見えた課題と結びつけて選んでいるか
まとめ
PMP合格は、プロジェクトを見るための共通の言葉と視点を手に入れたことを意味します。ただ、その視点を目の前の状況に当てはめ、順序立てて行動に移す力は、合格後に意識して育てる必要があります。
シナリオ演習で場数を補い、振り返りで判断を教訓に変え、その教訓をチームのオンボーディングに組み込む。この循環ができると、知識と実務のあいだの壁は少しずつ低くなっていきます。PMPの学習経験をクエストの設計に活かした考え方はPMPの学習経験をオンボーディングのクエストに変える方法で紹介しています。遊び方は初心者向けマニュアルをご覧ください。
※ PMP®およびPMBOK®は、Project Management Institute, Inc.の登録商標です。First RunはPMIと提携しておらず、PMIによる承認や推奨を受けたものではありません。
実務シナリオをクエストで体験してみませんか
PMOを含む5つの職種の実務シナリオを、ブラウザからFirst Runでプレイできます。