次の担当者が運用できるシステム引継ぎの進め方

まず、業務利用者、運用担当、今後の開発担当を分けます。利用者には操作と例外対応、運用には監視・復旧・障害受付、開発には構成・版・ビルドの情報が必要です。全員へ同じ資料を送っても、必要なものが届いたとは限りません。

作業ごとに受領者と、できる必要があることを記載します。新しい運用担当は警告を受けて連絡できればよく、自分でコードを直す必要はない場合もあります。技術作業を別会社へ委託するなら、その会社と支援範囲を決め、責任の空白をなくします。

引継ぎと受入れは近い時期でも、製品が要件を満たす確認と、受領側が業務を続けられる確認では目的が異なります。システムの受入テスト、何を確認する？を参考に、引継ぎ書で案件を終える前に必要な製品確認を整理できます。

別のチームが運用するなら、引継ぎ条件は協業の初期に決めます。最終週に資料を求めて初めて権限や契約の不足に気付くと、前任側に対応時間が残らないことがあります。学習、実施、再確認の時間を計画に含めます。

一覧には項目、保管先、版、受領者、確認方法を記載します。受領対象の個別開発部分は、稼働版とコードを照合し、配置手順や試験・本番環境の違いを示します。内容がそろっていても、古い版の手順では誤った作業につながります。

次に、稼働環境、ドメイン、保存先、連携サービスのアカウントを確認します。名義、支払者、受領側への権限を明確にします。コードを持っていてもサービスの管理権限とは別です。パスワードやキーを広く共有する資料へまとめないようにします。

ライセンスと契約は別に確認します。移管可能なもの、利用だけが認められるもの、再購入・再発行が必要なものを分けます。移管できないサービスは代替策を合意して動作確認してから旧アカウントを閉じます。開発費の支払いだけで全構成要素の所有権を判断しません。

不具合、制約、契約期限、約束した追加対応も引継ぎ対象です。残件には担当、影響、確認時期を置きます。「後で支援する」だけでは、問題が起きたときに待つべきか自ら対応すべきか判断できません。

サービスをやめる場合のデータの受取り方も確認します。何を、どの形式で出せて、受領側が開いて照合できるかを見ます。出力成功でも添付ファイルや関連付けが不足する場合があります。旧データやアカウントの処理は、責任者が保管要件を確認してから行います。

適切な環境で、受領側が合意した作業を実施します。例えば、受け取ったコードと手順で試験版を配置し、注文を一連の流れで確認します。前任側は不足を記録し、必要なときだけ補助します。前任者の操作を見るだけでは、引き継げると確認したことになりません。

止まったら、手順、権限、構成要素のどれが不足したかを確認し、直して再実施します。範囲に応じて警告の受信やバックアップの所在も試します。対象環境と未確認事項を残し、試験環境での成功をすべての本番事象への保証にしません。

引継ぎ中にソフトウェアが変わったら、資料と参照版も更新します。受領側が練習した版と本番が違う場合があるためです。基準とした時点と、その後の変更を記録し、確認結果が稼働版にも当てはまるか、再確認が必要かを判断できるようにします。

署名前に、障害窓口、合意した対応時間、別途見積りとなる修正を決めます。ソフトウェア保守には何が含まれる？を参考に、受領した資産と、引継ぎ後も続く保守の責任を分けて確認できます。

認められた支援に必要な権限まで直ちに削除することも、広い権限を無期限に残すことも避けます。残す権限には目的、管理者、見直す時期を決めます。責任が移った時点から障害窓口を明確にし、二社の間に空白を作らないようにします。

移管後の権限は、古いアカウント一覧ではなく、今後も認められる作業に合わせます。業務に合ったアクセス権限の決め方では、残す権限、制限、担当変更時の確認を整理しています。

重要な項目が未完了なら、一括で受領済みにせず、不足と完了条件を記録します。Fenixへの相談では、引き継ぐ人と担当作業から整理すると、実施して確認できる引継ぎ計画につながります。

Fenixへ相談する