運用引き継ぎ・定着確認シートのテンプレート
プロジェクトは、いつか終わります。終わったあとも、作ったしくみは動き続けます。動かすのは運用部門です。
この受け渡しがうまくいかないと、プロジェクトのメンバーが解散したあとに「誰も中身を知らない」という状態が生まれます。障害が起きても直せない。改善の要望が出ても誰も対応できない。作ったものが、だんだん劣化していきます。
この記事では、運用部門への引き継ぎを確実に行い、定着したことを確認するためのシートを紹介します。
■ 背景・よくある課題
よくある状態 | なぜ起きるか | その結果 |
|---|---|---|
ある日を境に「今日からお願いします」 | 引き継ぎを1回のイベントだと考えている | 運用部門が対応できず、結局PJメンバーが呼び出される |
ドキュメントを渡して終わり | 文書があれば引き継げると思っている | 書いていないことが起きたとき、誰も判断できない |
運用部門が引き継ぎ計画を知らない | PJ側だけで計画している | 要員が確保されておらず、押しつけになる |
ベンダーに丸投げする | 社内に知識をもつ人がいない | 仕様変更のたびに言い値になる |
定着したかどうかを測っていない | 引き継ぎの完了条件がない | いつまでもPJが解散できない、または問題を抱えたまま解散する |
一番多いのが1つめです。引き継ぎを「渡す日」として計画すると、必ず失敗します。引き継ぎは期間であって、日ではありません。
■ 3か月かけて主役を入れ替える
物流会社サンフィールド運輸（年商96億円・拠点14か所・車両318台）が、配車・運行管理システム（C1・2025年6月2日稼働）を運用部門へ引き継いだときの進め方です。
やっていることは単純です。問い合わせや障害に、誰が対応するかの割合を、3か月かけて入れ替えていきます。
第1段階（稼働〜30日）：PJが対応し、運用部門は横で見ます。この時期は問い合わせが多く、運用部門に任せると回りません。
第2段階（31〜60日）：運用部門が一次対応し、PJが内容を確認します。間違った回答をしていたら、その場で直します。
第3段階（61〜90日）：運用部門が対応し、PJはわからないことを聞かれたときだけ答えます。
完了（91日〜）：PJは解散します。
重要なのは、第2段階で運用部門が間違えられる期間を作っていることです。PJが横にいるうちに間違えておけば、実害は出ません。誰もいなくなってから初めて間違えるより、はるかに安全です。
■ 引き継ぐものは5種類
引き継ぎというとドキュメントを思い浮かべますが、実際には5種類あります。
種類 | 中身 | 渡し方 |
|---|---|---|
① 文書 | 設計書・運用手順書・障害対応手順・連絡先一覧 | 保管場所を決めて渡す。最新かどうかを確認する |
② 権限 | システムの管理者権限・クラウドの契約者・監視ツールのアカウント | 台帳を作って移管する。個人アカウントを残さない |
③ 契約 | ベンダーの保守契約・ライセンス・回線 | 契約の窓口を運用部門に変更する |
④ 判断の勘どころ | なぜこの設計にしたか。触ってはいけない箇所。過去にやって失敗したこと | 並走期間の会話で伝える。文書では伝わらない |
⑤ 人のつながり | 業務部門の誰に聞けばよいか。ベンダーの誰が詳しいか | 実際に引き合わせる。顔を合わせる場を作る |
④と⑤は、文書に書けません。だから並走期間が必要になります。3か月の並走は、この2つを渡すための時間だと考えてください。
■ テンプレートの項目
運用引き継ぎ・定着確認シートは、次の12項目で作ります。
# | 項目 | 書くこと |
|---|---|---|
1 | 引き継ぎの対象 | システム名・業務名 |
2 | 引き渡す側／受ける側 | PJ側とその担当者／運用部門とその担当者（個人名） |
3 | 並走の期間 | いつからいつまで。3段階の日付 |
4 | 文書の一覧と保管場所 | 受け渡す文書と、最新版かどうかの確認 |
5 | 権限の移管 | アカウント名と移管の完了日 |
6 | 契約の窓口変更 | 契約名と、窓口の変更日 |
7 | 運用部門の体制 | 何名が担当するか。既存業務との兼務状況 |
8 | 教育の計画 | 運用部門向けの研修。内容と日程 |
9 | 完了の条件 | これを満たしたら引き継ぎ完了とする条件 |
10 | 定着の確認項目 | 数字で測れる項目。次の節で説明 |
11 | 残る課題 | 引き継ぎ時点で未解決のこと。誰が引き取るか |
12 | 完了の承認 | PgM・運用部門長・業務部門長のサイン |
7の運用部門の体制を書く欄を必ず入れてください。「運用部門が引き継ぎます」と書いてあっても、実際には既存業務で手一杯という状態がよくあります。何名が、どのくらいの時間を割けるのか。ここが空欄のままの引き継ぎ計画は、たいてい押しつけになっています。
■ 記入例：サンフィールド運輸 C1
項目 | 内容 |
|---|---|
対象 | 配車・運行管理システム（2025年6月2日稼働・14拠点・利用者186名） |
引き渡す側 | C1プロジェクト（PM 河野／技術担当2名） |
受ける側 | 情報システム課（課長 岸本／担当 山根・藤井）＋ 運行管理部（担当 小田） |
並走期間 | 2025/06/02 〜 2025/08/29（3か月・3段階） |
運用部門の体制 | 情報システム課2名（うち1名は他システムと兼務・本件に0.5人月／月）、運行管理部1名（0.3人月／月） |
教育の計画 | 6月：システム構成と障害対応（4h）／7月：マスタ保守とデータ修正（4h）／8月：年次処理と繁忙期の運用（3h） |
残る課題 | 荷主240社のうち12社の請求フォーマット対応が未完了 → C3で対応。それまでは手作業（運行管理部が引き取り） |
完了の条件と定着の確認
確認項目 | 基準 | 2025/08/29 の実績 | 判定 |
|---|---|---|---|
問い合わせの一次解決率（運用部門だけで解決） | 80%以上 | 86% | ○ |
PJへのエスカレーション件数（直近4週） | 週3件以下 | 週1.8件 | ○ |
障害対応の訓練 | 想定障害3件を手順書だけで対応できる | 3件すべて完了 | ○ |
マスタ保守の実施 | 運用部門だけで1か月分を実施 | 7月・8月とも完了 | ○ |
文書の最新化 | 並走期間に出た変更がすべて反映されている | 28件中28件反映 | ○ |
権限の移管 | PJメンバーの管理者権限がすべて削除されている | 6件中6件削除 | ○ |
契約の窓口変更 | 保守契約の窓口が運用部門になっている | 完了（2025/07/15） | ○ |
「一次解決率80%以上」というのが、定着を測るのにいちばん使える指標です。運用部門が自分たちだけで答えられる割合——これが引き継ぎの成否そのものです。
また「PJメンバーの管理者権限がすべて削除されている」も忘れないでください。権限が残っていると、いつまでも「河野さんに聞けばやってくれる」という状態が続きます。権限を切ることで、引き継ぎが本当に完了します。
■ 運用ルール
タイミング | やること | 誰が |
|---|---|---|
稼働の3か月前 | 運用部門を計画づくりに入れる。体制と要員を確認する | PgM・PM・運用部門長 |
稼働の1か月前 | 文書の一覧を作り、不足を洗い出す | PM・運用部門 |
並走期間中、毎週 | 問い合わせの一次解決率を記録する | 運用部門 |
各段階の終わり | 次の段階に進んでよいかを判断する | PgM・PM・運用部門長 |
並走期間の終わり | 定着の確認項目を判定し、完了を承認する | PgM・運用部門長・業務部門長 |
完了の1か月後 | 一次解決率が維持されているかを確認する（フォローアップ） | PgM |
最初の行が、もっとも大事です。運用部門を計画づくりの段階から入れる。これをやらないと、「聞いていない」「人がいない」で必ずもめます。稼働の3か月前では遅いくらいで、本来はPJの計画段階から入ってもらうのが理想です。
最後の「完了の1か月後のフォローアップ」も、入れておくとよい工夫です。PJが解散した直後に一次解決率が落ちるなら、まだ何かが渡りきっていません。
■ 活用シーン
PJの解散の判断：完了の条件が満たされているかで判断できます。
運用部門の要員要求の根拠：必要な人月を、実績の問い合わせ件数から示せます。
次のPJの計画：C1の並走期間の実績が、C2以降の計画の前提になります。
プログラム終結の条件：全PJの引き継ぎが完了していることが、終結の条件の1つになります。
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
ある日を境に一気に渡す | 運用部門が対応できず、PJが呼び出され続ける | 3か月かけて、対応の割合を段階的に入れ替える |
文書を渡して終わり | 書いていないことが起きたとき判断できない | 並走期間の会話で「判断の勘どころ」を伝える |
運用部門の体制を確認していない | 押しつけになり、引き継ぎが形だけになる | 体制欄を必須にし、計画段階から運用部門を入れる |
PJメンバーの権限が残る | いつまでもPJ側に頼る状態が続く | 完了の条件に「権限の削除」を入れる |
定着を測っていない | 問題を抱えたまま解散する | 一次解決率など、数字で測れる条件を決める |
残る課題を引き取る人が未定 | 宙に浮いたまま忘れられる | 課題ごとに引き取り先を明記し、承認をとる |
■ 導入効果
項目 | 以前のシステム更新 | 今回（C1） |
|---|---|---|
並走の期間 | 2週間 | 3か月 |
解散後3か月のPJメンバーへの問い合わせ | 月14件 | 月1件 |
運用部門の一次解決率 | 約50%（推定・測っていない） | 86% |
ベンダーへの追加発注（軽微な変更） | 年11件・620万円 | 年3件・180万円 |
PJメンバーの管理者権限 | 2年後も一部が残っていた | 並走終了時に全件削除 |
並走期間を2週間から3か月に延ばした分のコストは、PJ側の工数で約1.2人月です。一方で、ベンダーへの追加発注が年440万円減っています。引き継ぎにかける時間は、投資として見合います。
■ まとめ
引き継ぎは日ではなく期間です。3か月かけて、対応の主役を入れ替えます。
渡すものは5種類。文書・権限・契約に加えて、判断の勘どころと人のつながりがあります。後の2つは文書では渡せません。
運用部門を計画段階から入れます。体制欄が空欄の引き継ぎ計画は、押しつけになります。
完了の条件は一次解決率など数字で決めます。
PJメンバーの管理者権限を削除して、はじめて引き継ぎが完了します。
完了の1か月後にフォローアップし、一次解決率が維持されているかを見ます。
次回は、プログラムそのものを終わらせてよいかを判断する「プログラム終結判定チェックリスト」のテンプレートを紹介します。