保守引継ぎで最初に確認すべきこと
前回は、保守引継ぎが失敗する原因について解説しました。
多くのケースでは、
- 担当者への依存
- ドキュメント不足
- 運用ルールの属人化
- 管理情報の未整理
が問題となります。
そして実際に引継ぎを行うと、必ず最初に発生するのが、
「何が残っていて、何が残っていないのか分からない」
という課題です。
保守引継ぎを成功させるためには、まず必要な情報を整理し、現状を把握することが重要です。
今回は、保守引継ぎ時に確認すべき資料や情報について整理します。
1. システム概要資料
最初に必要となるのがシステムの全体像です。
最低限、以下の内容が確認できる状態にしておくことが望まれます。
- システム名称
- 利用部門
- 利用人数
- 主な機能一覧
- 他システムとの連携有無
- 利用時間帯
保守担当者は、まずシステムが何のために存在しているのかを理解する必要があります。
この情報がないと、障害発生時の影響範囲すら判断できません。
2. システム構成図・インフラ情報
保守引継ぎで最も重要な資料の一つが構成図です。
理想的には以下の内容が整理されている状態が望ましいでしょう。
- Webサーバ
- アプリケーションサーバ
- データベースサーバ
- 外部サービス連携
- ネットワーク構成
- クラウド利用状況
構成図が存在しない場合は、まず簡易的な構成図から作成することをおすすめします。
完璧な図を作る必要はありません。
「どこで何が動いているか」が分かるだけでも大きな効果があります。
3. アカウント・接続情報
保守引継ぎ案件で非常に多いのが、
「ログインできない」
という問題です。
次の情報は必ず確認しておきましょう。
- サーバ接続情報（SSH、RDP）
- データベース接続情報
- クラウド管理画面
- DNS管理画面
- SSL証明書管理情報
- メールサービス管理画面
- ソースコード管理ツール
引継ぎ完了後に初めて
「AWSに入れない」
「ドメイン管理者が退職済み」
という問題が発覚することも少なくありません。
保守開始前に必ず確認しておくべき項目です。
保守引継ぎ前に、会社として管理できる状態へ移行しておくことをおすすめします。
4. 運用手順書
保守担当者はシステムを開発するだけではありません。
日常的な運用を継続する必要があります。
そのため、以下の手順が整理されていることが重要です。
- 定期作業
- 月次処理
- バックアップ確認
- ログ確認
- ジョブ監視
- リリース作業
- 障害発生時の初動対応
特に月次処理や請求処理などは担当者しか知らないケースもあります。
こうした業務手順こそ優先的に文書化しておきましょう。
5. ソースコードと開発環境
ソースコードがあるだけでは、システムを保守できるとは限りません。
実際には次の情報も必要です。
- ソースコードの保管場所
- バージョン管理ツール
- 使用フレームワーク
- 開発手順
- ビルド手順
- デプロイ手順
保守引継ぎの現場では、
「ソースコードはあるがリリース方法が分からない」
というケースが非常に多くあります。
システムを再構築できる状態になっているかを確認することが重要です。
6. 障害履歴と問い合わせ履歴
過去の障害情報は貴重な資産です。
以下の情報が残っていると、保守引継ぎ後の対応が大きく変わります。
- 過去の障害一覧
- 発生原因
- 対応内容
- 恒久対策
- 問い合わせ履歴
- 既知の制約事項
障害履歴がない場合、同じ問題を何度も調査することになり、保守効率が低下します。
資料が揃っていない場合はどうするか
実際には、すべての資料が揃っているケースはほとんどありません。
その場合は、次の順番で優先的に整理していくことをおすすめします。
- ログイン情報
- 構成図
- 障害対応手順
- バックアップ手順
- 運用手順書
- 設計書
まずは障害発生時に対応できる状態を目指すことが重要です。
完璧なドキュメント整備はその後でも問題ありません。
「何があるか」よりも
「何が存在しないか」
を把握することが重要です。
不足情報を把握できれば、保守移管の難易度やリスクを判断しやすくなります。
まとめ
保守引継ぎでは、単に設計書を受け取るだけでは十分ではありません。
確認すべき情報は多岐にわたります。
- システム概要
- 構成図
- アカウント情報
- 運用手順書
- ソースコードと開発環境
- 障害履歴
特にログイン情報や障害対応手順は、保守開始直後に必要になるため優先的な確認が必要です。
次回は、実際の保守引継ぎで利用できるチェックリストをもとに、引継ぎ時の確認ポイントを実践的に解説します。
