PM Knowledge Base

外観

7. プロマネ育成カリキュラム（8週間プログラム） ​

新任〜中堅プロジェクトマネージャーを対象に、PMBOK第8版の考え方を 「知っている」から「使える」に移す8週間の研修プログラム案。 週1回・90分のワークショップ形式を想定。

7.0 全体設計方針 ​

  • 講義（インプット）は最小限にし、自分のプロジェクトを教材にした演習を中心に置く
  • 各回の最後に「次回までに実務で1つ試すこと」を必ず1つ決める（宿題ではなく実践課題）
  • メンター（先輩PM）が各回にコメンテーターとして参加し、演習後のディスカッションを担当

図：8週間ロードマップ（知っている→使える）

 W1 全体像 ─▶ W2 原則1-3 ─▶ W3 原則4-6 ─▶ W4 領域で診断
                                                  │
 W8 総合ｹｰｽ+批判 ◀─ W7 AI/ｱｼﾞｬｲﾙ ◀─ W6 成功の二軸 ◀─ W5 ﾌﾟﾛｾｽ+ﾃﾝﾌﾟﾚ
   └── 各回の最後に「次回まで実務で1つ試す」＝実践課題を必ず1つ決める
 インプット(講義)は最小。自分のプロジェクトを教材にした演習が中心。

7.1 週次プラン ​

Weekテーマ教材主要演習実践課題（次回まで）
1PMBOKの全体像・なぜ第8版か01、07自分の組織のプロジェクトが「予測型／適応型／ハイブリッド」のどれに近いか議論。09で本研修の対象範囲（PMP対策ではない等）を共有直近プロジェクトの進め方を1枚で図示する
26つの原理原則①（1〜3）02原則1〜3のセルフチェックを自分のプロジェクトで実施✕がついた項目1つに対する改善アクションを1つ実行
36つの原理原則②（4〜6）02原則4〜6のセルフチェック＋チームの心理的安全性の簡易サーベイチームに1つ、悪いニュースを歓迎する具体的な合図を導入
4パフォーマンス領域で現状を診断する033.4の領域別ヘルスチェックを実施しグループ発表最も弱い領域について、原因を1原則に紐づけて報告
5プロセスの基礎とテーラリング＋実践テンプレート04、10自分のプロジェクトで「省略しているプロセス」「過剰にやっているプロセス」を洗い出す。RACI・リスク登録簿（10）を自分のプロジェクトで試作テーラリング方針を1文でチームに共有
6成功の評価軸：成果とプロセス05直近プロジェクトを2軸マトリクスでプロット、象限別の議論次回レビューで成果・プロセスを別枠で報告する形式に変更
7AIとプロジェクトマネジメント／アジャイルとの橋渡し06、08AI活用マップ（6.5）を作成し、委ねる範囲／人間判断範囲を線引き。8.4のアプローチ診断で自分のプロジェクトの予測型/適応型領域を仕分けAI活用ガイドラインの草案を1ページ作成
8総合ケーススタディ＋批判的視点＋修了評価全ファイル、特に097.2のケーススタディをグループで分析・発表。9.4「疑うべき点」演習で締めくくる自分のプロジェクトに対する90日改善計画を作成

7.2 総合ケーススタディ（Week8用） ​

ケース：「予定通り終わったが誰も使わなかった社内ツール」 ​

半年かけて開発した社内申請システムが、予算内・スケジュール内で完成した。 QAも通過し、重大な不具合もなかった。しかしリリース3ヶ月後の利用率は5%未満。 現場は「そもそも今のExcel運用で十分」と回答している。

議論の観点（ファシリテーター用ガイド）

  1. 05_success_criteria.md の2軸マトリクスでは、 このプロジェクトはどの象限に位置するか（想定回答：③手堅い失敗）
  2. どの原則の実践不足がこの結果につながったと考えられるか （想定回答：原則2「価値に注力する」の検査・適応が不足。要件定義時の仮説を 途中で誰も再検証していない）
  3. どのパフォーマンス領域のモニタリングがあれば、途中で軌道修正できたか （想定回答：ステークホルダー領域＝エンドユーザーの継続的な関与不足）
  4. このプロジェクトのふりかえりを、原則6「権限付与された文化」の観点から見ると 何が言えるか（想定回答：現場から「使わないと思う」という声が早期に 出ていた可能性があるが、報告経路がなかった／聞かれなかった）

7.3 評価ルーブリック（修了時の到達確認） ​

評価軸Level 1（要育成）Level 2（一人前）Level 3（他者を指導できる）
原理原則の理解6原則を説明できない6原則を自分の言葉で説明できる具体的なプロジェクト事例に紐づけて説明できる
パフォーマンス領域の運用領域という概念を知らない定期レビューで領域別に振り返れる弱い領域を早期に検知し先手で対応できる
プロセス・テーラリングプロセスを一律に適用しようとするプロジェクト特性に応じて省略・追加を判断できるチーム全体にテーラリング方針を説明し合意形成できる
成功評価の二軸QCDのみで成功を判断する成果とプロセスを分けて評価できる二軸評価を組織のレビュー標準に落とし込める
AIとの向き合い方AI活用の判断基準がない委ねる範囲と人間判断範囲を線引きできるチームのAI活用ガイドラインを主導して作成できる
批判的思考（フレームワークを疑う力）PMBOKの手続きを無条件に踏襲する過剰な手続きに気づき、テーラリングで軽量化できる（09）フレームワークの限界を踏まえた上で、組織に合わせた運用ルールを設計できる

各軸でLevel2以上を修了基準とする。Level1が残る軸は、個別メンタリングで 該当する資料ファイルの演習を再実施する。

7.4 ファシリテーターへのメモ ​

  • Week2・3の「セルフチェック演習」は、正直に✕をつけられる空気づくりが最重要。 最初にファシリテーター自身の過去プロジェクトの✕を開示すると効果が高い
  • Week6の2軸マトリクスは、「プロセス成功だが成果失敗」の事例が出やすい組織ほど 議論が深まる。無理に「成功事例」ばかり集めない
  • Week7のAIテーマは技術の話に寄りすぎないよう注意する。論点は常に 「PMとしての説明責任がどこにあるか」に戻す（06.2）
  • Week8の12：批判的視点は、研修全体を「型の暗記」で 終わらせないための最重要パート。ファシリテーターは「PMBOK通りにやったのに 失敗した経験」を先に自己開示し、フレームワークへの健全な懐疑心を示すこと