運用保守の仕事の中でも、特に緊張感が高いのが「サーバーのリプレース」です。
老朽化した機器の入れ替え、OSのサポート終了に伴う移行、クラウドへの移行——。理由はさまざまですが、いずれも「動いているシステムを、別の環境に移す」という、リスクの高い作業です。
リプレースは、失敗すると影響が大きい。だからこそ、慎重な計画と進め方が求められます。
私は19年の運用保守の中で、何度もリプレース案件に関わってきました。今回は、サーバーのリプレース作業で失敗しないための進め方を、実務目線で解説します。
リプレースが失敗する典型パターン
まず、リプレースが失敗する典型的なパターンを見ておきましょう。
1. 現行環境の調査不足
「今、何が動いているか」を正確に把握できていないまま進めてしまう。移行後に「あの機能が動かない」「あのバッチが漏れていた」と発覚するパターンです。
2. テスト不足
スケジュールに追われて、テストを削ってしまう。結果、本番移行後に不具合が続出する。これは本当によくある失敗です。
3. 切り戻し計画がない
「移行したけど、問題が起きた」というとき、元に戻せない。これが最も怖いパターンです。
4. 関係者との調整不足
顧客や利用部門への説明・調整が不十分で、移行のタイミングや影響について認識がずれる。
これらを防ぐことが、リプレース成功の鍵になります。
進め方①：現行環境を徹底的に調査する
リプレースの成否は、現行環境の調査で8割決まると言っても過言ではありません。
調査すべきこと
- インストールされているソフトウェア、バージョン
- 稼働しているサービス、プロセス
- 定期実行されているバッチ、スケジュールタスク
- 他システムとの連携（接続先、接続元）
- ファイアウォール、ネットワーク設定
- ユーザーアカウント、権限設定
- ライセンス
特に見落としがちなのが、**「たまにしか動かないもの」**です。月次バッチ、年次処理、めったに使われない機能——これらは調査時に見落とされやすく、移行後に問題になります。
「ドキュメントに書いてあること」だけでなく、「実際に動いているもの」を確認することが重要です。ドキュメントが古い可能性もあるので、実機の調査は必須です。
進め方②：移行方式を決める
現行環境を把握したら、**どうやって移行するか（移行方式）**を決めます。
主な移行方式
- 新規構築＋データ移行：新環境を一から構築し、データだけを移す（クリーンな環境になるが、構築工数がかかる）
- イメージ移行（P2V、V2Vなど）：現行環境のイメージをそのまま移す（工数は少ないが、不要なものも引き継ぐ）
- 段階移行：一部ずつ移行していく（リスクは分散されるが、期間が長くなる）
どの方式を選ぶかは、システムの規模、許容できる停止時間、予算、期間などによって変わります。それぞれのメリット・デメリットを踏まえて、慎重に決めましょう。
進め方③：テスト計画をしっかり立てる
リプレースで、絶対に削ってはいけないのがテストです。
スケジュールが厳しくなると、「テストを削って納期に間に合わせよう」という誘惑にかられます。でも、テストを削ると、本番で問題が起きる確率が跳ね上がります。
私が経験から学んだのは、**「見積の段階で、テスト工数をしっかり確保する」**ことの重要性です。後から削られないよう、最初から必要な工数を計上しておく。これが、品質を守る現実的な方法です。
テストすべき項目
- 基本動作（サービスが起動するか、機能が使えるか）
- 連携テスト（他システムとの接続が正常か）
- バッチ処理（定期実行される処理が正常に動くか）
- 性能テスト（想定される負荷に耐えられるか）
- 障害テスト（異常時に想定通り動くか）
特に連携テストは重要です。単体では動いても、他システムとつなぐと動かない、というケースは多いです。
進め方④：切り戻し計画を必ず用意する
リプレースで最も重要なのが、切り戻し計画です。
「移行したけど、想定外の問題が起きた」というとき、元の環境に戻せるかどうかが、被害を最小限に抑える鍵になります。
切り戻し計画に含めるべきこと
- どういう状態になったら切り戻すか（判断基準）
- 切り戻しの具体的な手順
- 切り戻しにかかる時間
- 切り戻しの判断を、誰がいつするか（デッドライン）
特に「切り戻しの判断デッドライン」は重要です。「〇時までに問題が解決しなければ、切り戻す」という時間を決めておく。これがないと、ずるずると復旧作業を続けて、業務開始時刻に間に合わなくなります。
また、切り戻しができるよう、現行環境をすぐには壊さないことも大切です。移行後、しばらくは旧環境を残しておく。これが安全網になります。
進め方⑤：関係者との調整を丁寧に
リプレースは、多くの関係者が関わる作業です。調整を丁寧に行いましょう。
調整すべき相手
- 顧客・利用部門（移行日時、停止時間、影響範囲）
- 社内チーム（作業分担、当日の体制）
- ベンダ（機器、ソフトウェアのサポート）
- 他システムの担当者（連携先への影響）
特に、移行のタイミングは、顧客の業務カレンダーを踏まえて慎重に決めます。繁忙期、月末、決算期などは避けるのが基本です。
そして、決まったことは必ず文書で共有する。口頭だけの合意は、後で認識のズレを生みます。
進め方⑥：当日の体制と役割分担を明確に
リプレース当日は、複数のメンバーが関わることが多いです。役割分担を事前に明確にしておきましょう。
- 誰が作業を実施するか
- 誰が確認を担当するか
- 誰が顧客への報告を担当するか
- 問題が起きたとき、誰が判断するか
特に「判断者を明確にしておく」ことが重要です。当日、想定外のことが起きたとき、「誰が切り戻しを判断するか」が決まっていないと、対応が遅れます。
また、作業は必ず複数人体制で。一人作業だと、ミスに気づけません。作業者と確認者を分ける「ダブルチェック体制」が理想です。
まとめ
サーバーのリプレース作業で失敗しないための進め方をまとめます。
- 現行環境を徹底的に調査する（成否の8割はここで決まる）
- 移行方式を決める（規模・停止時間・予算を踏まえて）
- テスト計画をしっかり立てる（テスト工数は最初から確保）
- 切り戻し計画を必ず用意する（判断基準とデッドラインを決める）
- 関係者との調整を丁寧に（タイミング、文書での共有）
- 当日の体制と役割分担を明確に（判断者を決める、複数人体制）
リプレースは、リスクの高い作業です。でも、しっかり準備すれば、確実に成功させられます。
特に「調査」「テスト」「切り戻し計画」の3つは、絶対に手を抜かないでください。ここを丁寧にやるかどうかで、リプレースの成否が決まります。
コメント