「担当者が来月退職します。システムの引継ぎが必要なのですが、何をすれば……」——こうした相談が来たとき、多くの現場では「とりあえず口頭で説明してもらった」「Excelにまとめてもらった」という対応になりがちです。しかし数ヶ月後、「あの件、どこに書いてありましたっけ」「これ誰に聞けばいいんでしたっけ」という状態になる。なぜそうなるのか。引継ぎに必要なものが体系的に整理されていないからです。なぜシステム引継ぎはいつも「足りない」のか※引継ぎが失敗する構造的な原因については、「なぜシステム引継ぎは失敗するのか」で解説しています。システムの引継ぎが不完全になる理由は、大きく3つあります。「操作方法」だけを引き継いで、「なぜそうなっているか」を引き継がない。 画面の操作手順はマニュアルに書けますが、「なぜこの処理はこの順番でやらなければいけないのか」「このデータは他のシステムとどう連携しているのか」という背景知識は、言語化されていないことがほとんどです。ベンダーや契約情報が個人管理になっている。 「このシステムのことは○○ベンダーの田中さんに連絡すれば分かる」という状態が続いていると、担当者が変わったときに誰に連絡すればいいか分からなくなります。田中さんも転職していた、ということも珍しくありません。「困ったことがない業務」は引継ぎの対象から漏れる。 月次処理・障害時の対応・年次バッチ処理など、頻度が低い業務は引継ぎ資料に含まれないことがあります。「そういえばあれ、引き継いでなかった」と気づくのは、その業務が必要になったときです。以下のチェックリストは、こうした「引継ぎの死角」を埋めるために設計しています。カテゴリ1：システム全体像・構成まず「今どんなシステムが動いていて、それぞれどう連携しているか」の全体像を引き継ぎます。これがないと、後続の担当者は「何があるか分からない」状態から始めることになります。□ 社内で稼働しているシステム一覧（名称・用途・バージョン）□ 各システムの利用部門と主な利用者□ システム間のデータ連携・連動関係の整理□ クラウドサービス・ SaaS一覧（契約中のもの含む）□ ネットワーク構成の概要（オンプレ・クラウドの区別）□ サーバー・端末の管理台帳（ハードウェア資産）□ 社外アクセス手段（VPN・リモートデスクトップ等）の設定情報□ ドメイン・ SSL証明書の管理状況と更新期限特に注意が必要なのは「連携しているか分からないシステム」の存在です。古い業務改善ツールや、担当者が個人的に導入した SaaSなどが、気づかないうちに他のシステムと連動している場合があります。一覧を作る際には「これだけのはず」ではなく、実際に使われているものを棚卸しする姿勢が必要です。カテゴリ2：ベンダー・契約・サポート窓口システムに関わる外部の関係先情報は、担当者の人脈に依存しやすい項目です。引継ぎ漏れが最も起きやすいカテゴリでもあります。□ ベンダー・SIer一覧（会社名・担当者名・連絡先）□ 各システムの保守契約内容（対象範囲・SLA・費用）□ 保守契約の更新期日と更新手順□ ソフトウェアライセンスの管理（ライセンス数・契約種別・更新期日）□ 障害時のベンダー連絡先と対応フロー□ エスカレーション先（ベンダーの上位窓口・緊急連絡先）□ 過去の問合せ履歴・対応記録の保管場所□ ベンダーとの契約書・覚書の保管場所「あのシステムの問合せ先はどこですか？」という質問に即答できない状態は、引継ぎが完了していないサインです。連絡先は会社・部署・担当者名・メール・電話の形式で整理し、「名刺ファイルの中にある」という状態を解消しておくことが必要です。カテゴリ3：日常運用・定期作業「いつも何を、どの順番で、どうやっているか」の記録です。毎日・毎週・毎月・毎年のサイクルで発生する作業を整理します。□ 日次・週次・月次の定型作業一覧と手順書□ 月次締め処理の手順と確認ポイント□ バックアップの設定内容・保存先・確認手順□ ログ監視・アラート対応の手順□ ユーザーアカウントの作成・削除・権限変更の手順□ 定期メンテナンス作業の内容と実施タイミング□ 年次処理（期末処理・マスタ更新等）の手順□ 入退社・異動時のシステム対応手順月次・年次の作業は「来月やれば分かる」という判断で後回しになりがちですが、実際にやってみると「あの操作はどこでやるんだったか」という状態になります。手順書は「前任者がいない状態で初めてやる人」が読んでも迷わないレベルの詳細さが求められます。カテゴリ4：障害対応・緊急時手順「困ったときに何をするか」の情報は、普段は使わないため引継ぎに含まれにくいですが、実際に必要になったときに最も重要な情報です。□ 障害発生時の一次対応手順（ログ確認・再起動等）□ 過去の障害事例と対応記録□ システムごとの「よく起きるトラブル」と対処法□ データ復旧手順（バックアップからの復元手順）□ 社内への報告・連絡手順とエスカレーション基準□ 外部（ベンダー・顧客）への連絡が必要な場合の対応フロー□ 緊急時の作業権限・承認フロー□ 障害対応後の事後確認・報告手順特に「再起動してはいけないシステム」「この順番で止めないと壊れるシステム」などの「暗黙のルール」は、担当者の頭の中にしかないことがあります。「やってはいけないこと」も含めて明示的に記録することが、障害時の二次被害を防ぎます。カテゴリ5：属人化している知識・判断基準最も引継ぎが難しいカテゴリです。マニュアルには書かれていないが、担当者が判断・処理していることを明示化します。□ 「例外処理」の一覧（通常フローに乗らないケースと対処法）□ 特定ユーザー・部署への特別対応事項□ ベンダーとの過去の合意事項・口約束の記録□ 「触れてはいけない設定・データ」の把握と理由□ 他部署との調整・確認が必要な事項一覧□ 「なぜそうなっているか分からないが動いている」箇所のメモ□ 将来の課題・文漏事項のメモ□ 「次の担当者へ伝えたいこと」の自由記述このカテゴリは、前任者と時間をかけて話しながら引き出す必要があります。「何か注意していることはありますか？」という問いかけではなく、「月末に何が起きますか？」「障害が起きたらまず何を見ますか？」など、具体的な場面を想定した問いかけで情報を引き出すことが有効です。このチェックリストを「埋められない」場合このチェックリストを見て、「これを埋められる人が社内にいない」「担当者はいるが、ここまで整理されていない」という場合、それ自体が属人化の現れです。チェックリストの空白は、リスクの所在を示しています。全項目を埋めることが目的ではなく、「どこが分かっていないか」を可視化することが最初のステップです。特に「カテゴリ5：属人化している知識・判断基準」で空欄が多い場合、担当者が退職した後に「あの人しか知らなかった」という状況が発生する可能性が高い状態です。退職・異動が決まってから動き始めると、時間的に間に合わないことがあります。現状を整理するために必要なのは、システムの仕様書ではなく、「今どんな状態になっているか」を調べる現行調査です。設計書がない・ベンダー依存が強い・担当者の頭の中にある——そうした状況でも、まず実態を把握することが引継ぎ整備の起点になります。外部ベンダーへの引継ぎを伴う場合は、「外部ベンダーへのシステム引継ぎで失敗しないための5つの注意点」も合わせて確認してください。ライクバードでは、グループ子会社・中堅企業向けのシステム現行調査（AI仕様解析）を提供しています。「引継ぎに備えて、まず今のシステムの実態を整理したい」という段階からご相談ください。→ システム現行調査（AI仕様解析）について詳しく見る