フレームワーク活用ガイドひとことで言うと#
プロジェクトの担当者が交代するときに、「何を・どの順で・どう」引き継ぐかを体系化したプレイブック。暗黙知の言語化、文書の整理、引き継ぎセッションの設計を通じて、担当者交代による品質低下と情報ロスを最小化する。
押さえておきたい用語#
- 暗黙知（Tacit Knowledge）
- 文書化されていない経験や勘に基づく知識。「このクライアントは木曜の午後にメールを見る」「この機能の変更はキャッシュクリアが必要」など。
- 形式知（Explicit Knowledge）
- 文書・手順書・コードなど言語化・記録された知識を指す。引き継ぎではまず形式知を整理し、次に暗黙知の言語化を行う。
- シャドウイング
- 前任者の業務に後任者が同席して観察する引き継ぎ手法。会議の進行、クライアント対応の雰囲気など、文書では伝わらない部分を体感する。
- ランブック（Runbook）
- 定型作業の手順を一覧にしたオペレーションマニュアルである。引き継ぎ後に後任者が自力で作業を実行するための拠り所になる。
プロジェクト引き継ぎプレイブックの全体像#
こんな悩みに効く#
- PMが異動したらプロジェクトの状況を誰も把握していない
- 前任者にしかわからない「暗黙のルール」が多すぎる
- 引き継ぎ期間が短すぎて後任者が苦労する
基本の使い方#
前任者が以下の5つの文書を整理する。完璧を目指す必要はないが、「後任者がこれを読めば初日から動ける」状態を目指す。
- プロジェクト概要書: 目的・スコープ・現在のフェーズ・主要マイルストーン
- 関係者マップ: 誰が何の権限を持ち、誰と何を合意しているか
- ランブック: 定型作業の手順（デプロイ方法、レポート作成手順、承認フローなど）
- 未解決課題一覧: 現在抱えている課題・リスクとその対応状況
- 暗黙知メモ: 文書に書かれていないが重要なこと（「この人はメールよりSlack」「この機能は触らないほうがいい」など）
文書だけでは伝わらない部分を対面のセッションで補う。
- 全体像セッション（2時間）: 5点セットの解説、質疑応答
- シャドウイング（3〜5日）: 前任者の業務に後任者が同席（会議、クライアント対応、レビュー）
- 逆シャドウイング（2〜3日）: 後任者が主担当として業務を実行し、前任者が横で見守る
- 関係者紹介: クライアント・上長・他チームに後任者を正式に紹介するメールまたは会議を設定
前任者が離れた後の2〜4週間を「安定化期間」として、フォロー体制を維持する。
- 前任者への質問チャンネル（Slackの1対1チャット）を期間限定で維持
- 週1回30分のフォローアップセッションを設定
- 後任者はランブックを実際に使いながら更新・改善する
- 安定化期間の終了時に「引き継ぎ完了」を正式に宣言する
具体例#
状況: 受託開発PJ（残り6か月・チーム8名）のPMが異動。前任PMはクライアントとの関係構築に 1年半 を費やしており、暗黙の合意事項が多い。過去にPM交代で顧客満足度が 4.2 → 2.8 に急落した経験あり。
プレイブックに沿った引き継ぎ
- 前任PMが「暗黙知メモ」を20項目作成（例：「部長は金曜15時以降は電話に出ない」「仕様変更は必ず課長経由」）
- シャドウイング5日間で、クライアントとの週次会議を3回一緒に参加
- クライアント部長と前任・後任の3者ミーティングを実施し、正式に引き継ぎを宣言
| 指標 | 過去の交代時 | 今回 |
|---|---|---|
| 顧客満足度の変化 | 4.2 → 2.8 | 4.2 → 4.0 |
| 交代後1か月の問い合わせ件数 | 28件 | 8件 |
| 引き継ぎ起因のインシデント | 3件 | 0件 |
状況: 自社プロダクトの主要エンジニアが退職。この人にしかわからないデプロイ手順、障害対応のノウハウ、インフラの設定経緯が属人化している。退職まで 3週間。
ランブック中心の引き継ぎ
- 退職エンジニアがデプロイ・障害対応・バッチ処理の3つのランブックを作成
- 後任2名（バックアップ含む）が実際にランブックに沿って作業を実施、不明点をその場で追記
- 「なぜこの設定にしたのか」の経緯をADR（Architecture Decision Record）として5件記録
3か月後、引き継ぎ後に発生した障害は 2件 だったが、いずれもランブックの手順で後任が自力解決。「退職前に聞いておいてよかった設定の経緯が3回役に立った」と後任が報告。
状況: ECサイト運営企業。保守運用を委託しているベンダーAとの契約終了に伴い、ベンダーBに切り替え。ベンダーAは 3年間 運用しており、システムの癖やカスタマイズ経緯を熟知。ベンダーBはシステム未経験。
ベンダー間の引き継ぎプレイブック
- 自社PMが引き継ぎマネージャーを担当
- ベンダーAに「システム構成図」「カスタマイズ履歴」「FAQ集（過去の問い合わせ50件のQ&A）」の作成を契約に含める
- ベンダーA・B・自社の3者で週次引き継ぎセッションを 4週間 実施
- ベンダーBが単独で保守運用を開始してから 2か月間、ベンダーAに月10時間のフォロー枠を契約
切り替え後の障害対応時間は、ベンダーA時代の 平均2時間 に対しベンダーBは初月 平均4時間 だったが、2か月後に 平均2.5時間 まで改善。引き継ぎコストは 200万円 だったが、ベンダーBの月額が 30万円安い ため、7か月で回収できた。
やりがちな失敗パターン#
- 文書だけで引き継ぎを完結させる — ドキュメントは形式知しか伝えない。シャドウイングや対面セッションで暗黙知を移転するステップが不可欠
- 引き継ぎ期間を1週間未満にする — 最低2週間、理想は4週間。短すぎると「聞きそびれた」が大量に発生する
- 後任者が遠慮して質問しない — 「何でも聞いていい期間」を安定化期間として正式に設けることで、質問のハードルを下げる
- 前任者の退職・異動直前に引き継ぎを始める — 引き継ぎの準備（Phase 1）は前任者がいるうちに余裕を持って始める。退職1週間前では遅い
まとめ#
引き継ぎプレイブックは「準備→移転→安定化」の3フェーズで知識を確実に移す仕組みだ。最も重要なのは、文書にならない暗黙知を意図的に言語化するステップと、後任者が実際に手を動かして体験するシャドウイングの組み合わせ。引き継ぎの質はプロジェクトの継続的な品質に直結するため、「忙しいから省略」は最も高くつく判断になる。