システム保守の引継ぎは、ただ「担当者が変わる」だけの話ではありません。
引継ぎが不十分なまま運用が続くと、障害対応が遅れる・改修ができない・最終的に誰も触れない、といったブラックボックス化が起こります。
この記事では、情報システム担当者向けに、保守引継ぎで最低限押さえるべきチェックリストをまとめます。
担当者の退職、ベンダー変更、保守会社の切替、内製化など、どのケースでも使える内容です。
なお、本記事は「情報システム担当者のための実践ガイド」という連載記事とも関連していますので、ぜひ合わせてお読みください。
第1回：なぜ保守運用は開発以上に重要なのか？
第2回：よくある保守運用の失敗パターン
第3回：強い保守運用体制を作るには
第4回：システム引継ぎを円滑にするチェックリスト
第5回：これからの保守運用に求められる視点
システム保守の引継ぎが失敗する典型パターン
まず最初に、引継ぎが失敗する現場でよくあるパターンを整理します。
- 「仕様書はあります」と言われたが、現状と一致していない
- ソースはあるが、ビルド・デプロイ手順が分からない
- 本番環境の構成が誰も説明できない
- 障害対応が「経験者の勘」に依存している
- ログイン情報や証明書の管理が属人化している
つまり、引継ぎで重要なのは「資料の有無」ではなく、運用できる状態になっているかです。
保守引継ぎチェックリスト（全体像）
引継ぎは以下の7領域に分けて考えると抜け漏れが減ります。
- 1. システム概要・業務要件
- 2. 環境構成（インフラ・ネットワーク）
- 3. アカウント・権限・秘密情報
- 4. 運用手順（日次・月次・障害時）
- 5. 監視・ログ・バックアップ
- 6. ソースコード・改修・リリース
- 7. 契約・費用・外部ベンダー
ここからは、実務で使える形でチェック項目を具体化します。
1. システム概要・業務要件のチェック
まずは「何のためのシステムか」を説明できる状態にします。ここが曖昧だと、改修判断ができなくなります。
最低限そろえるべき情報
- このシステムが支えている業務（対象部門・業務範囲）
- 主要な機能一覧（画面・帳票・バッチなど）
- 利用者数・利用頻度・業務ピーク
- 「止まったら困る」機能と許容停止時間
- 運用上の注意点（例：月末締め、棚卸、請求処理など）
よくある落とし穴
- 仕様書があっても「現場が実際にどう使っているか」が書かれていない
- 例外運用（手作業）だけが属人化している
2. 環境構成（インフラ・ネットワーク）のチェック
保守引継ぎで最も事故が起きるのが、環境構成が不明なまま運用が始まるケースです。
チェック項目
- 本番・検証・開発環境の区分（それぞれ存在するか）
- サーバ一覧（OS、CPU、メモリ、ディスク、役割）
- ミドルウェア構成（Web/AP/DB、バージョン）
- ネットワーク構成（IP、FW、VPN、公開範囲）
- ドメイン・DNS・SSL証明書の管理者
- 外部連携（メール、API、SFTP、決済、外部サービス）
最低限ほしい成果物
- 構成図（ざっくりでも良い）
- サーバ一覧表
- 本番環境への接続方法（VPN、踏み台など）
3. アカウント・権限・秘密情報のチェック
引継ぎで一番怖いのが「ログインできない」状態です。特に担当者退職後に発覚すると、復旧に時間がかかります。
チェック項目
- クラウド管理アカウント（AWS/Azure/GCPなど）
- サーバログイン（SSH、RDP、踏み台）
- DB管理ユーザー
- WordPressなどCMSの管理者
- ドメイン管理（レジストラ）
- SSL証明書の発行元と更新方法
- APIキー、SMTPパスワード、外部サービスの認証情報
ポイント
「誰が持っているか」ではなく、会社として管理できる状態にしておくのが重要です。
4. 運用手順（日次・月次・障害時）のチェック
運用手順がないと、引継ぎ後の現場はこうなります。
- 問題が起きるまで気づかない
- 起きたら慌てて調べる
- 復旧できる人がいない
日次・週次でやっていること
- エラーログ確認
- ジョブの成功/失敗確認
- ディスク容量確認
- ユーザー問い合わせ対応の流れ
月次・年次でやっていること
- 証明書更新
- ドメイン更新
- ライセンス更新
- 請求・締め処理の運用
障害時の対応フロー
- 一次切り分け（何を見ればよいか）
- 復旧手順（再起動、切替、ロールバック）
- 連絡体制（社内、ベンダー、利用部門）
- 復旧後にやること（再発防止、報告）
5. 監視・ログ・バックアップのチェック
引継ぎ後に「バックアップが取れていなかった」が発覚すると致命的です。
チェック項目
- 監視の有無（死活、CPU、メモリ、ディスク、HTTP）
- 通知先（メール、Slack、Teamsなど）
- ログの保存期間と保存先
- バックアップ対象（DB、ファイル、設定）
- バックアップの世代数
- リストア手順（復元できるか）
ここが重要
バックアップは「取っている」だけでは意味がありません。復元できることが重要です。
6. ソースコード・改修・リリースのチェック
保守は「運用」だけではなく、改修が発生します。ここが引き継げていないと、保守はすぐに詰みます。
チェック項目
- ソースコードの保管場所（Git、SVN、ZIPなど）
- ブランチ運用ルール（あるなら）
- ビルド方法（ローカル/CI）
- デプロイ方法（手動/自動）
- 本番反映の手順とチェック項目
- 過去の改修履歴（チケット、変更理由）
よくある落とし穴
- ソースはあるが「どれが最新か分からない」
- 手元のPCにしか開発環境がない
7. 契約・費用・外部ベンダーのチェック
意外と抜けるのがここです。引継ぎ後に「契約が誰名義か分からない」「更新通知が届かない」といったトラブルが起こります。
チェック項目
- クラウド費用（請求先・支払方法）
- 保守契約の内容（範囲・SLA・対応時間）
- ドメイン・証明書・メールの契約情報
- 外部ベンダー一覧（連絡先、担当者）
- 委託先が保有している情報の範囲
引継ぎを成功させるコツ（重要）
チェックリストを埋めるだけでは、実際の引継ぎは成功しません。ポイントは次の3つです。
1) 「資料がある」ではなく「運用できる」を基準にする
実際にログインし、実際にバックアップを確認し、実際に復旧できるかまで確認します。
2) 1回の引継ぎで終わらせない
引継ぎは最低でも「並走期間」を設けた方が安全です。
3) ブラックボックスを前提に計画する
「全部揃っているはず」と考えると失敗します。現場の多くは、揃っていないのが普通です。
保守引継ぎが難しいときの現実的な選択肢
ここまで読んで、「やることが多すぎる」「現担当者に時間がない」と感じた方も多いと思います。
実際、保守引継ぎは
- 調査
- 整理
- ドキュメント化
- 運用設計
- 体制づくり
をまとめて行う必要があり、片手間では進みません。
当社では、こうした課題に対して「システム開発・保守引継ぎサービス」を提供しています。
- 既存システムの現状調査（構成・運用・課題の洗い出し）
- 引継ぎに必要な情報の整理とドキュメント整備
- 運用手順・障害対応フローの整備
- 保守運用の引継ぎ（担当交代・ベンダー切替の支援）
- 必要に応じた改修・改善（運用で詰まらない形へ）
「担当者退職が迫っている」「ベンダーを変えたいが引継ぎが不安」「今の保守が破綻している」などの場合は、選択肢のひとつとしてご覧ください。
こんな課題に困ったら 担当者が定年、退職 自社開発を行ったが、担当者が退職。設計書やマニュアルも無く、システムに詳しい担当者もいないため、引継ぎが出来ない。 システム会社が廃業 長く使っている社内システムを今後も使い続けたいが、システム開発を委...
まとめ
システム保守の引継ぎは、技術よりも「情報の整理」と「運用できる状態づくり」が重要です。
- 引継ぎは7領域に分けると漏れが減る
- バックアップは「復元できるか」まで確認する
- ログイン情報・契約情報は会社で管理する
- ブラックボックスは前提として計画する
保守運用は、引き継げた瞬間に価値が生まれます。ぜひチェックリストとして活用してみてください。
