PMの引き継ぎチェックリスト|炎上させない交代の段取りと文書テンプレ
本ページはプロモーションが含まれています
PM交代時の引き継ぎ失敗はほぼ「情報量」ではなく「順序」の問題だ。引き継ぎ資料の必須項目、同席期間の設計、後任者が最初の30日で確認すべき手順を具体的に解説する。
PMの交代で炎上するプロジェクトの大半は、引き継ぎの「情報量」ではなく「順序」に問題がある。本記事では、引き継ぎ資料に何を書くべきかのチェックリスト、同席引き継ぎの段取り、後任PMが最初の30日で確認すべき手順、そして実務でよくある失敗パターンを具体的に示す。読み終える頃には、明日から使える引き継ぎドキュメントの雛形と、交代時に必ず確認すべき項目が手元に残るはずだ。
引き継ぎがうまくいかない本当の理由
引き継ぎが失敗したプロジェクトを後から検証すると、たいてい「資料はあった」ことがわかる。議事録も、課題管理表も、体制図も存在する。それでも炎上するのは、文書に残っていない情報の比率が想像以上に高いからだ。
具体的には次の3種類の情報が抜け落ちやすい。
- 決定の背景:「なぜこの仕様に決まったか」ではなく「その決定に反対した人が誰で、今も納得していないか」
- 暗黙の力学:会議での発言順や決裁権とは別に、実質的に誰の一言でプロジェクトが止まるか
- 未決事項の温度感:課題管理表に載っている項目のうち、どれが本当に緊急で、どれが放置されても構わないか
前任者の頭の中にしかないこれらの情報は、文書化しようとしても「言語化コストが高い」という理由で後回しにされる。引き継ぎ期間が短いプロジェクトほど、この後回しがそのまま炎上の火種になる。
引き継ぎの全体設計:いつ・何を・誰に
引き継ぎは「資料を渡す日」ではなく期間として設計する。最低でも2週間、可能なら1ヶ月を確保し、以下の3フェーズに分ける。
- 文書化フェーズ(1〜2週間):前任者が単独で資料を整備する期間。この段階では後任者はまだ関与しなくてよい。
- 同席引き継ぎフェーズ(1〜2週間):前任者と後任者が主要な会議・1on1に同席する期間。文書に書けない力学や温度感はここで伝わる。
- フォローアップフェーズ(交代後30日):前任者が完全に離脱した後、質問できる窓口を限定的に残す期間。
期間が確保できない場合でも、フェーズの順序自体は崩さない方がよい。同席なしでいきなり文書だけ渡すと、後任者は「何が重要な未決事項か」の優先順位をつけられないまま初動を誤る。
引き継ぎドキュメントチェックリスト
以下は最低限そろえるべき引き継ぎ資料の一覧だ。「作ってあるか」ではなく「更新日が直近1ヶ月以内か」で判断するとよい。古い憲章やステークホルダーマップは、無いよりましだが誤った前提を後任者に植え付けるリスクがある。
| 区分 | 項目 | 目的・注意点 |
|---|---|---|
| 合意文書 | プロジェクト憲章 | スコープ・目的の原点。当初と現状のズレを別紙で明記する |
| 体制 | ステークホルダーマップ | 決裁権と実質的な影響力を分けて記載する |
| リスク | リスク登録簿 | 「顕在化しかけたが収束した」リスクの経緯も残す |
| 課題 | 未決事項リスト | 各項目に「緊急度」「合意済みか未合意か」を明記 |
| 予算 | 予算消化状況・見込み | 契約変更や追加予算申請の交渉履歴を含める |
| 契約 | 契約・SOW・稼働条件 | ベンダー側の担当者交代予定も確認しておく |
| 技術 | 技術的負債・保留中の設計判断 | 「あえて先送りした」理由を残す |
| 履歴 | 過去の炎上とその収束方法 | 再発防止のために対応済みか未対応かを区別する |
このうち最も軽視されがちなのが「過去の炎上とその収束方法」だ。過去に一度収束した問題は再燃しやすい。前任者が水面下でどう抑え込んだかを知らないまま後任者が同じ火種に触れると、収束済みだった問題が再び表面化する。
プロジェクト憲章そのものの作り方についてはプロジェクト憲章(Project Charter)の書き方:炎上を防ぐ合意文書の作り方で解説している。引き継ぎ時点で憲章が形骸化している場合は、この記事を参考に更新してから渡すとよい。
同席引き継ぎの段取り
同席期間で最も効果が出るのは、ステークホルダーへの紹介の順番だ。次の順で回すと、後任者への信頼形成がスムーズになりやすい。
- スポンサー(経営層・意思決定者):交代の事実と権限移譲を明確に伝える場。前任者からの紹介という体裁を必ず取る
- 主要クライアント担当者:実務窓口。ここでの第一印象がその後の関係を左右する
- チームメンバー:日々の意思決定スタイルの違いを事前に説明しておく
- 主要ベンダー・外部パートナー:契約条件の交渉余地がある相手ほど早めに接点を持つ
この順番を逆にする、あるいは形式的なメール一斉送信だけで済ませると、後任者は「誰に何を確認すればよいか」を手探りで探すことになり、初動が2〜3週間遅れる。
よくある失敗パターン
引き継ぎの失敗は毎回似た形で起きる。代表的なものを挙げる。
- 資料だけ渡して終わる:口頭での背景説明がないため、文書の行間にある温度感が伝わらない
- 紹介が形式的:一斉メールで交代を告知するだけで、力学のある相手への個別説明を省略する
- 未決事項が「引き継いだことになっている」:課題管理表に載せただけで、実際には誰も合意していない判断が放置される
- 連絡経路の設計ミス:前任者への質問窓口を完全に断つと初動で詰まり、逆に無期限に残すと後任者の権限が曖昧なままになる
いずれも「引き継ぎ=文書の受け渡し」という誤解から生じる。引き継ぎの本質は権限と文脈の移譲であり、文書はその補助手段にすぎない。
後任PMが最初の30日でやること
資料を受け取った後、後任者側の初動も同じくらい重要だ。目安として次のように進める。
- Day1〜3:全資料に目を通し、違和感や矛盾をリストアップする(この段階では判断しない)
- Week1:主要ステークホルダーと個別に1on1を実施し、力学と温度感を自分の目で確認する
- Week2:受け取った憲章とスコープの現状にズレがないか検証する。ズレがあれば早期にスポンサーと合意を取り直す
- Week3〜4:想定される失敗シナリオを洗い出す。前任者から聞いた過去の炎上経緯を踏まえたPre-Mortem分析を行うと、同じ火種の再燃を事前に察知しやすい
新体制での最初のキックオフを行う場合は、プロジェクトKickoffミーティングを成功させる準備チェックリストの手順がそのまま使える。また、引き継ぎ直後に潜在リスクを洗い出す手法としてはPre-Mortem分析:プロジェクト開始前に「失敗を想定」して防ぐ技術が参考になる。
引き継ぎは一度きりのイベントではなく、交代後30日間を含めた一連のプロセスとして設計するものだ。文書・同席・フォローアップの3フェーズを崩さずに進めれば、交代のタイミングそのものが炎上の引き金になる事態は避けられる。
あわせて読みたい
プロジェクトのトラブル解決大全:引き継ぎ後に前任者が抑え込んでいた問題が再燃した場合の実務的な立て直し方が体系的にまとまっている。交代直後のトラブル対応の引き出しを増やしたい人向け。
PMBOK ガイド 第7版:引き継ぎ資料の構成に迷ったとき、憲章・ステークホルダー管理・リスク管理の標準的な枠組みを確認する基準として使える。