システム保守の引き継ぎを進める5つの確認

はじめに

システムの保守担当者が交代するとき、「資料は渡したはずなのに、新しい担当者が障害に対応できない」ということがあります。契約、設計書、管理画面の権限、日々の確認作業が別々の場所にあり、古い担当者だけがつながりを知っているためです。

引き継ぎの目的は、ファイルを渡すことではなく、受け取る側が決められた範囲の運用を継続できるようにすることです。この記事では、受注管理システムの保守委託先を変更する架空の会社を例に、発注者が確認したい5項目と、資料の受領から引き継ぎ完了を判断するまでの手順を整理します。担当者の異動でも考え方は共通しますが、実施範囲は契約や社内規程に合わせて決めてください。

引き継ぎと運用設計の違い

システム運用設計書の作り方では、日々の作業や障害対応を誰が行うかを整理しました。保守の引き継ぎでは、その決めごとを新しい担当者が実際に引き受けられるかを確認します。設計書に「毎朝、連携結果を確認」と書かれていても、閲覧権限がなければ実施できません。資料の最新版がどれか分からない場合も、作業可能とはいえません。

一覧の状態は少なくとも「未受領」「受領済み」「内容・利用を確認済み」「不足・保留」に分けましょう。ファイルを受け取っただけで、内容が現行環境と一致していることや、必要な権限を使えることまで確認した扱いにしないのがポイントです。

保守の引き継ぎで確認したい5項目

1. 契約範囲と責任分担

最初に、旧担当者、新担当者、発注側の役割と切替日を確認します。問い合わせ受付、監視、障害の一次切り分け、修正作業、業務再開の判断は同じ担当者とは限りません。「ベンダーが保守する」だけでは、夜間の連絡や外部サービスの障害時に誰が動くか分からないためです。

IPAの情報システム・モデル取引・契約書は、受託開発や保守運用に関するモデル契約を公開しています。モデルをそのまま自社の契約とみなさず、現行の契約書と個別条件を確認し、不明点は契約担当者に相談します。秘密保持、成果物の利用範囲、外部への再提供も契約や社内方針に沿って扱いましょう。

2. 資料とシステム構成

次に、現在の構成を理解するための資料を洗い出します。画面や機能だけでなく、連携先、運用上の依存関係、変更履歴までたどれることが大切です。

• 構成図、環境一覧、利用サービスと契約名義
• 仕様書、ソースコードや設定の管理場所、変更履歴
• 定常作業の手順書、障害記録、未解決の課題
• 外部連携の窓口、データの受け渡し、実施時間
• バックアップの対象、保存先、復元手順と直近の確認状況

資料ごとに保管先、更新日、管理者、現行環境との照合者を記録します。受注システムの例なら、注文一覧の画面だけでなく、出荷システムへの連携と、連携失敗時に誰が気づくかも対象です。資料がない場合は「なし」と記録し、担当者への聞き取りや現行環境の確認を誰がいつ行うか決めます。見つからない資料の内容を推測で埋めないようにします。

3. アカウント・権限と契約名義

引き継ぎ資料に管理画面のURLがあっても、新担当者が安全に利用できるとは限りません。システム、クラウド、ドメイン、外部サービスごとに、管理者、利用者、承認者、契約・請求の名義を確認します。退職者個人のメールアドレスに更新通知が届く設定や、旧委託先しか管理できない契約がないかも見ます。

パスワードや秘密鍵をチェックリストやメール本文に書き込まず、組織が認めた安全な方法で、必要な人に必要な範囲の権限を付与します。新しい担当者のアクセス確認が終わったら、切替手順に従って旧担当者の不要な権限の解除・認証情報の更新を検討します。共有アカウントが残る場合は影響範囲を確認し、業務停止を招かない手順を先に合意してください。

誰が何にアクセスできるかだけでなく、ログを誰が確認するかもセットで決めましょう。

4. 日常作業と障害時の判断

資料を受け取ったら、日常作業と障害対応を一つずつたどります。受注データの連携なら、「いつ、どの画面で、何件を確認するか」「失敗時に誰に何を伝えるか」「再送前に何を確認するか」を具体的にします。二重登録の恐れがある作業は、新担当者の判断だけで本番実行せず、承認と停止条件を先に決めます。

AWSの運用準備に関するガイダンスは、定常手順と問題調査の手順を用意し、運用の準備状況を一貫して確認する考え方を示しています。自社のシステムでも、通常処理、問い合わせ、障害発生をそれぞれ例にし、手順と判断者を照らし合わせてください。

バックアップの存在と復元できることは別です。復元の確認は、対象や場所、データ保護、業務への影響を関係者が承認した環境で計画します。実施できていない場合は未検証とし、実施担当と期限を残します。

5. 並走・未解決事項・完了条件

新担当者が資料を読んだ後、旧担当者の説明を受けながら作業を確認し、その後は新担当者が主体となって旧担当者が見守る期間を設ける方法があります。期間や実施範囲は、業務の重要度と契約条件に応じて決めます。実際に作業できない場合は、手順の読み合わせや安全な検証環境での確認を検討し、未実施の理由を残します。

引き継ぎ一覧には、項目ごとの確認者、確認日、証拠の保存場所、未解決事項、担当者、期限を記録します。たとえば「外部連携の障害窓口は確認済み、夜間連絡先は未確定」と分ければ、未確定のまま全面完了と誤認せずに済みます。リスクを残して切り替える場合は、残る影響、暫定対応、承認者を明示しましょう。

引き継ぎを進める順番

1. 現行契約と次の契約を確認し、対象・切替日・連絡窓口を決める。
2. 資料、契約、権限、定常作業、課題を一覧にし、管理者を記入する。
3. 受け取った資料を現行環境や業務担当者の説明と照らし、差分を残す。
4. 権限確認と作業の読み合わせ、承認された範囲での実地確認を行う。
5. 未解決事項と代替策を確認し、発注側と新旧担当者で切替の可否を判断する。

重要なのは、切替日を迎えたことだけで引き継ぎ成功としないことです。新担当者が対応できる範囲と、引き続き旧担当者や別の専門家の支援が必要な範囲を明確にします。切替後も、問い合わせの滞留や手順書の食い違いを確認し、必要に応じて更新します。

散在する議事録や業務資料の関係を整理したい場合は、Kakusillで既存資料をもとに業務フローや要求のたたき台を作る方法もあります。AIが整理した結果はそのまま保守手順の正本とせず、現場・保守担当者が事実と権限を確認してから合意してください。

まとめ

システム保守の引き継ぎでは、契約範囲、資料、権限、日常・障害対応、完了条件を分けて確認します。資料を受け取ったかだけでなく、新担当者が必要な作業を安全に行えるか、未解決事項の責任者が決まっているかまで見届けることが大切です。

まずは一つの重要業務を選び、普段の確認から障害時の連絡までを新旧の担当者とたどってみてください。業務や仕様の整理に困っている場合は、お問い合わせからご相談いただけます。