ケース1: ソフトウェア開発プロジェクト（Predictive 中心）
ソフトウェアエンジニア出身のPMがリアルに経験するシナリオ。状況→判断→PMI流の正解を考える練習。
プロジェクト概要
背景
- 製造業A社の「在庫管理システム」を3年使った後、老朽化＋業務拡大で全面刷新
- 業務要件は概ね固まっており、現行業務をベースに設計する
- 規制要件: 個人情報保護、SOX法（米国子会社あり）
- 期間: 12ヶ月、予算: ¥150M、チーム: 内製5名 + ベンダー10名
ステークホルダー
| ステークホルダー | 役割 | 関心 |
|---|---|---|
| 業務部長（スポンサー） | 承認者・予算 | コスト・期日厳守 |
| 物流現場マネジャー | 主要利用者 | 使いやすさ・教育 |
| 経理部 | SOX法準拠 | 監査ログ・職務分離 |
| IT部長 | 内製5名の上司 | 内製チームの育成 |
| 外部ベンダーPM | 開発主導 | 売上・納期 |
| 情報システム監査人 | 監査 | コンプライアンス |
アプローチ
- Predictive中心（要件安定・規制要件あり）
- ただし開発フェーズは 2週間スプリントで内部的に反復実施（Hybrid）
シナリオ1: プロジェクト立ち上げ
状況
あなた（PM）がアサインされた直後、業務部長から「とにかく早く作って欲しい。WBSは見せなくていいから着手してくれ」と言われた。
質問
最初に何をすべきか？
選択肢
A) 即座に開発に着手し、結果で示す B) スポンサーの言う通り着手してWBSは後回し C) プロジェクト憲章を起案し、目的・スコープ・成功基準・主要リスクをスポンサーと合意。並行してステークホルダー識別と要件収集計画を立てる D) 別のスポンサーを探す
PMI流解説
正解は C。プロジェクト憲章は PMの権限の根拠。これなしで進めると、後で「そんな話聞いてない」「想定と違う」が頻発し、ベネフィット実現を損なう。
スポンサーの「早く作って」気持ちには、「最も早く価値を出す道筋を1週間で整理して提示します」 と返すのがPMI流。スピード感への共感を示しつつ、リスクを提示。
学習ポイント
- プロジェクト憲章は省略しない
- スポンサー要求にYes/Noで答えず、価値最大化の道筋 を提案する
- 早期の合意形成で後の手戻りを防ぐ
シナリオ2: 要件のばらつき
状況
要件定義中に、物流現場マネジャー（北海道・関東・九州拠点 計5名）から「自分の拠点は他と違う運用なので個別仕様にしてほしい」と各々から要望が来た。
質問
PMの最適行動は？
選択肢
A) すべての要望を実装 B) スポンサーが選んだ拠点を優先 C) 共通要件と拠点特有要件を分け、ファシリテーション会議で共通化を協議。残った特有要件は影響度評価し、優先順位付け D) 拠点長に任せる
PMI流解説
正解は C。要件をすべて実装はGold Plating＋スコープクリープ、却下は対立を生む。ファシリテーション（Brainstorming + Affinity Diagram + 投票）でWin-Winに近づける。
学習ポイント
- 要件は 共通 / 拠点特有 に層別
- ファシリテーション手法を使い分ける
- 残った要件は影響度（コスト・スケジュール・リスク）で順位付け
- 決定理由を記録（後の説明責任）
シナリオ3: ベンダーの遅延
状況
開発フェーズ中盤、ベンダーPMから「予定の半分しか進捗してない。残業対応で間に合わせる」と報告。原因を聞くと「開発者の経験不足と仕様変更の多発」。
質問
PMの優先対応は？
選択肢
A) ベンダーに違約金を要求 B) EVMでスケジュール・コスト差異を定量化。ベンダーPMと根本原因分析（Fishbone等）。仕様変更プロセスを見直し、必要ならスコープ削減を提案 C) ベンダーを切って別ベンダーに切替 D) スポンサーに即報告
PMI流解説
正解は B。
- まず データ（EVM: SPI/CPI、変更要求件数）で客観的に把握
- 根本原因（チーム能力・変更プロセス・要件の質）を分解
- 協働でリカバリ案を作る（Crashing なら追加コスト、Fast Tracking ならリスク、スコープ削減なら価値の優先順位）
スポンサー報告は必要だが、PMが解決案を持って報告するのが望ましい。
学習ポイント
- 数値（EVM）で議論する
- 根本原因分析（Fishbone, 5 Why）
- 「Crashing or Fast Tracking or スコープ削減」の3択を常に意識
- 即時のエスカレーション or 切替は最後の手段
シナリオ4: 重要メンバーの離職
状況
ベンダーのリードエンジニア（要件・設計を一手に把握）が個人都合で1ヶ月後退職。
質問
PMの行動は？
選択肢
A) ベンダーに違約金請求 B) Knowledge Transfer計画を即作成、後任者の同行・ペアプログラミング・ドキュメント整備。リスク登録簿に記録し、CCBで影響評価。 C) 自分が代役を務める D) プロジェクト中断
PMI流解説
正解は B。リスクが顕在化（Issue化）した状況。
- 知識継承計画 を即実行
- Workaround（暫定対応）と恒久対策を分ける
- 影響評価（スケジュール・品質）→ CCB
- リスク登録簿を 更新（再発防止）
学習ポイント
- リスクが Issue 化したら、即対応 + ナレッジ継承
- Bus Factor（重要人物依存）の発見と緩和
- ナレッジは個人保有でなくチーム保有へ
シナリオ5: スポンサーの方向転換
状況
プロジェクト6ヶ月時点、スポンサーが「経営方針が変わった。AIを使った需要予測機能も追加で入れたい」と言ってきた。
質問
PMの対応は？
選択肢
A) 即着手（顧客至上主義） B) 拒否 C) 影響分析（スコープ・スケジュール・コスト・品質・リスク・他PJへの影響）。代替案（フェーズ2分離、MVP優先など）を作成。CCBで議論し、ベネフィットの再評価をスポンサーと合意 D) 影響を考えず計画書のみ更新
PMI流解説
正解は C。
- 経営方針変更は 戦略整合の問題
- 単に追加するか拒否するかでなく、ベネフィット再評価
- フェーズ2分離 や MVP優先 などの代替案で価値を最大化
- CCBで意思決定 → ステアリングコミッティへ報告
学習ポイント
- ビジネス価値とプロジェクト価値の整合
- 代替案を必ず複数提示
- 大規模変更はスポンサーだけでなくステアリングコミッティへも
シナリオ6: テストでの大量バグ
状況
受入テスト前のシステムテストで、設計の根本ミスに起因するバグが30件発覚。修正に1ヶ月必要と判明。本番リリースまで2ヶ月。
質問
PMの最優先行動は？
選択肢
A) 隠して対応 B) Root Cause Analysis（Fishbone, Pareto）で根本原因特定。COQ（リワークコスト）を計算。ベネフィット最大化視点で、リリース延期 or スコープ縮小 or 並行リリース＋パッチ計画を選択肢化、CCBで合意 C) チームを叱責 D) ベンダー切替
PMI流解説
正解は B。
- 品質問題は 予防 > 検査 が原則だが、出てしまった以上Root Cause Analysis
- COQの「内部失敗コスト」が増大している状態
- 価値最大化のためには、完全リリース・部分リリース・延期・並行運用の選択肢比較
- スポンサー・ステアリングへ事実報告（隠さない=PMI倫理）
学習ポイント
- 品質問題は隠さない
- Root Cause Analysis は Pareto + Fishbone
- 価値最大化のための選択肢比較
- 倫理規範: Honesty
シナリオ7: 受入検収
状況
受入テスト中、現場マネジャー2人が「画面の挙動が要件と違う」「使いにくい」と検収拒否。仕様書通りに作っているが、実際の業務では非効率。
質問
PMの対応は？
選択肢
A) 仕様書通りなので強制検収 B) Validation（顧客要件適合）の観点で再評価。要件レビュー時のギャップを特定し、優先度高い改善は スプリントで対応、低優先は フェーズ2 で対応する合意を作る C) 全部作り直し D) スポンサー強制承認
PMI流解説
正解は B。
- Verification（仕様通り）は満たしていても Validation（要件適合）が不足
- 一方的押し付けは関係を壊す
- ギャップ分析→優先順位→協働で合意
- 場合によりベネフィット再評価
学習ポイント
- Verification と Validation の違い
- 仕様書よりも 顧客価値
- スプリント or フェーズ2 で柔軟対応
- ステークホルダーとの協働
シナリオ8: クローズフェーズ
状況
リリース成功。チームメンバーが「自分は次のPJの方が興味ある」と話題になり始めた。スポンサーは「祝勝会の準備よろしく」。
質問
PMの最優先タスクは？
選択肢
A) 祝勝会の準備 B) 即チーム解散 C) Lessons Learned 会議、ベネフィット実現計画、知識のOPA化、最終予算精算、契約終結、リソース解放、チーム称賛 D) 引継ぎ書類のみ作成
PMI流解説
正解は C。Closingフェーズの王道。
- レッスン・ラーンドは個人でなく OPA（組織のプロセス資産） へ
- ベネフィット実現は完了後3〜12ヶ月続く（PMは追跡 or スポンサーへ移管）
- チーム解散の前に 称賛・キャリアの会話
学習ポイント
- Closingプロセスを軽視しない
- 知識資産化はPMI重要視
- メンバーの次のキャリアを支援するのもサーバントPM
ケース全体の振り返り
抽出されたPMI流原則
- プロジェクト憲章なしに開始しない
- データ（EVM）で議論する
- 協働で問題解決
- 倫理規範: 隠さない・誠実に報告
- 価値最大化のための選択肢比較
- 顧客価値（Validation）を仕様通り（Verification）より優先
- 知識・ナレッジは組織資産化
- チームをサーバント支援する
自分のチェック
- 全シナリオで自分の答えと正解が一致したか
- 一致しなかった場合、PMI流原則のどれを忘れていたか
- 自分の現在の業務でこのケースのどこに似た状況があるか