システム移管とは｜ビジネスサイドのための IT 用語集

 システム移管とはシステム移管は稼働中のシステムの運用、保守、改修を担う組織や担当者が交代するときに、担当と責任を後任へ引き継ぐことです。引き継ぐのはシステムではなく、稼働させ続けるための情報と権限です。対象は運用手順書、構成図などの構成資料、アカウントや鍵情報、ライセンス、未解決の不具合とその経緯です。担当者の退職や異動、担当組織の変更、内製化で必要になることがあります。
マンションの管理人の交代に近い作業です。鍵だけでなく、どの部屋で雨漏りが発生したかといった経緯まで引き継ぎ、後任が一人で管理できるようになって終わります。
データを別の環境や保存先へ移動するデータ移行や、新旧のシステムを同時に稼働させる並行稼働とは対象が異なり、システム移管ではシステムは同じまま担い手だけが交代します。両者を同じ案件で行う場合もあります。
 担当交代で何が発生するか引き継ぎで欠落しやすいのは、運用で蓄積した経緯と、資料に記載されない権限や構成の情報です。IPA（情報処理推進機構）のシステム再構築ユーザガイドでは、長期運用のシステムで担当者の異動や退職が避けられないため、業務知識の一部が欠落した断片化の状態は必ず発生するとされています。
設計書を更新しないまま修正を累積すると、設計書、ソースコード、稼働中のシステムの間にずれが生じる場合もあります。
デジタル庁の実践ガイドブックの事例では、担当者の異動が急に決定し、口頭で概要を説明するだけになったとされています。後任が検討経緯を引き継がないまま回答や指示をした結果、完成したシステムが当初の目的を達成しなかったと整理されています。
 効果引き継ぎが完了していれば、定常作業や障害対応が担当交代で停止するリスクを低減できる
複数人への知識共有と資料の継続的な更新により、特定の担当者への依存を低減できる
契約や技術の制約の範囲で、運用の担い手を社内外から再選定できる
 コストとリスク旧担当は資料の整理と説明に工数を要する。引き継ぎへの対応は旧担当と新担当の双方に必要で負担が生じる
両者の作業期間が重複する場合は、説明と確認の工数が発生する。検証環境や追加アカウントを用意する場合は利用料も増加する
引き継ぎが不十分だと移管直後に問合せや手作業の補正が増加し、障害の初動も遅延する
ライセンスを旧担当の組織が保有している場合、契約条件によって譲渡に制約があり、新担当による運用や保守に支障が生じることがある
受け手に運用できる人材がいなければ、採用や育成を要する
担当の境目が曖昧な期間は障害対応が停止する場合もある。旧担当と新担当が協議して、連絡の受け手、復旧の担当、業務再開の判断者を事前に決定する
 何を引き継げば運用は停止しないか期限が近いもの、停止したときの業務影響が重大なもの、代わりに対応できる人がいないものを優先します。証明書の期限が来月なら更新の確認が先で、復旧の方法を把握している人が前任者だけならバックアップと復旧の確認が先です。
日常運用に必要な情報: 管理画面やサーバーのアカウント、ドメインや証明書の更新期限と更新担当、ライセンス、定期処理とその実施者、バックアップと復旧の方法
障害対応に必要な情報: 構成図、監視の項目、連絡先、過去の障害と対処
改修に必要な情報: 設計書、ソースコード、変更の権限と開発環境、未解決の課題と決定の理由
名前解決はドメイン名から接続先を特定する仕組みです。ドメインを更新しないと名前解決が停止し、サイトやメールを利用できなくなることがあります。
サーバー証明書が期限切れになると、ブラウザで接続エラーになり、利用できなくなることがあります。
引き継ぎ対象の例にはクラウドサービスの管理に必要なアカウントや鍵情報が含まれます。新担当がログインできることと、旧担当の不要な権限が削除されていることを確認します。AWS（Amazon Web Services）のベストプラクティスでは、長期アクセスキーが必要なIAM（AWSの権限管理）ユーザーは、退職時などにアクセスキーを更新することが推奨されています。
最上位権限を保有するルートユーザーの連絡先メールアドレスも、個人でなく組織で管理するグループのものにすることが推奨されています。
契約や運用上の要件がなく、停止しても業務への影響が軽微で、機密情報や重要な外部連携がなく、改修の予定もないシステムは設計書の整備を省略できます。アカウント、定期処理、障害時の連絡先、停止と復旧の手順、データの保存と削除の方針は引き継ぎます。利用者数だけでは重要度を判定できません。
 引き継ぎの期間と完了は何を基準にするか期間は日数でなく、受け手が旧担当の支援なしで運用できたかで決定します。月次や年次の重要な作業を抽出し、新担当と旧担当で、実作業、検証環境での実施、想定訓練のどれで確認するかを先に決定します。確認できない作業は旧担当の支援期間と問合せ先を合意します。
政府の情報システムの事業者間の引き継ぎでは、1か月程度を設定するのが一般的だが十分でないケースが多く、不足すると業務運営に支障が生じるおそれがあるとされています。設計・開発事業者から運用事業者への引き継ぎに3か月を確保し、双方で運用手順書を完成させた省庁もあります。民間では参考値にすぎず、定期作業の周期で決定します。
完了条件は開始前に決定します。理解度の確認方法と完了条件は引継ぎ計画書に記載するとされています。条件の例は次のとおりです。
定常作業を新担当が旧担当の支援なしで実施できる
バックアップから復旧し、必要なデータを参照できることを新担当が確認している
未解決の課題について、経緯と次の対応のほか、担当者と期限が確定している
新担当がすべての管理画面にログインでき、旧担当の不要な権限が削除されている
改修も引き継ぐ場合は変更を検証して稼働中のシステムへ反映する手順を新担当が実施できる
旧担当の支援終了日を完了日にすると、確認が長期化したとき支援を利用できないため、新担当は支援を延長できるかを先に確認します。
 前任者も資料もすでにないとき何から開始するか担当者が退職済みで設計書も更新されていないなら、引き継ぎでなく調査が最初の作業です。完全な仕様の把握は目標とせず、まず停止させず稼働できる状態を確保します。資料がない場合は調査に期間と工数を要することがあるため、調査期間を先に想定します。
稼働しているものの棚卸し: アカウント、稼働中のサーバーやサービス、定期処理を、ログ、請求書、閲覧を許可された前任者のメールから抽出する
稼働中の状態を出発点にする: 設計書・ソースコード・稼働中のシステムの間にはずれが生じている場合があるため、差分が意図した変更か、不具合や暫定対応かを業務要件と比較して判定する
最小限の運用手順を新担当が作成する: 再起動、バックアップ、監視の確認から始め、運用しながら修正する
確認できた事項と未確認の事項を分類して記録する: 未確認の事項がある状態で運用を継続してよいかの判断者を決定する
前任者への質問: 退職後も期間と範囲を決定して回答してもらえるかを確認する
 よくある誤解 資料を受領すれば移管は完了する引き継ぎ資料に課題名と対応結果だけが記載されていると、決定の理由や試行した対策が分かりません。新担当が定常作業と障害対応を実施できると確認するまでは完了しません。障害対応は実際の障害の前に、想定訓練で確認します。
 担当の交代が決定してから引き継ぎを開始しても準備を完了できる交代は急に決定することがあります。先の事例では準備の時間がなく、日常的に文書化していれば活用できたと記載しています。急病や介護でも突然の交代が起こりうるため、日常的な文書化と、複数名で運用に関与する体制が備えになります。