ネットワーク移行計画とは何か

ネットワーク更改では、 新しいルーターやスイッチを設置しただけでは利用者の通信は切り替わりません。

既存機器から新機器へケーブルを接続し直したり、 ルーティングを変更したり、 ファイアウォールポリシーやDNSなどを切り替えたりして、 実際の通信経路を新環境へ移す必要があります。

設計が正しくても移行は失敗する

新環境の設計や設定が正しくても、 次のような理由で移行作業が失敗することがあります。

• 現行環境の接続先を把握できていなかった
• 作業対象外と思っていたシステムが依存していた
• DNSやルーティングの切り替え順序が不適切だった
• 作業時間内に正常性確認が終わらなかった
• 誰が最終判断するのか決まっていなかった
• 障害発生後も調査を続け、切り戻し可能時間を超えた

移行計画・作業手順書・切り戻し計画の違い

実務では、移行計画、作業手順書、切り戻し計画を 混同しないことが重要です。

移行計画が上位にあり、 その具体的な実行方法として作業手順書や切り戻し手順がある、 と考えると整理しやすくなります。

ネットワーク移行の全体像

移行作業だけを見るのではなく、 事前準備から移行後の監視までを一つの流れとして考えます。

特に重要なのは、 「切り替え完了」と「移行完了」を分けることです。

ケーブルや経路を切り替えただけでは、 業務が正常に使えることを確認できていません。 通信試験・業務確認・監視確認まで終わって、 初めて移行完了と判断します。

移行方式を決める

移行計画を作るときは、 最初に「どのような単位で新環境へ移すか」を決めます。

方式比較の例

移行計画を作る前に確認する情報

移行計画の品質は、 現行環境と新環境をどれだけ正確に把握できているかで変わります。

移行タイムラインの作り方

移行計画では、 当日の作業だけでなく数週間前からの準備を時系列で整理します。

事前準備から移行後までの例

1. T-30日 設計・移行方式の確定 対象範囲、方式、停止時間、体制、主要リスクを確定する。
2. T-14日 新環境の構築・単体試験 新機器の設定と基本動作を確認する。
3. T-7日 手順書レビュー・リハーサル 作業手順、所要時間、確認方法、切り戻し手順を確認する。
4. T-1日 最終事前確認 構成変更の有無、障害状況、バックアップ、 機材、連絡先を確認する。
5. T当日 本番移行 事前確認、切り替え、試験、判定を実施する。
6. T+1日 移行後監視 ログ、トラフィック、アラート、利用者申告を確認する。
7. T+数日 旧環境撤去判断 安定稼働を確認して旧機器や旧回線の撤去へ進む。

当日のスケジュール例

切り替え当日の基本フロー

本番切り替えでは、 いきなり新機器へ通信を変更してはいけません。

1．現行環境の正常性を確認する

作業開始前に現行環境が正常であることを確認します。

事前に障害が発生している状態で作業を開始すると、 移行後に発生した問題なのか、 作業前から存在していた問題なのか判断しにくくなります。

2．設定・状態を保存する

• running-configなどの設定
• ルーティングテーブル
• ARP・MACアドレス情報
• インターフェース状態
• 隣接状態
• ログ
• 監視画面

作業前後を比較できる情報を残しておくと、 障害調査にも役立ちます。

3．切り替える

配線変更、ルーティング変更、VLAN変更、 ファイアウォール変更などを手順に従って実施します。

4．ネットワーク試験を実施する

• インターフェース状態
• VLAN
• ルーティング
• OSPF・BGP等の隣接
• 主要宛先への疎通
• 冗長経路
• DNS・DHCP
• インターネット・クラウド接続

5．業務確認を実施する

pingが成功しただけでは、 業務サービスが利用できるとは限りません。

必要に応じて顧客やアプリケーション担当と連携し、 実際の業務システムへログインできることなどを確認します。

Go／No-Goと切り戻し判断を事前に決める

移行作業で難しいのは、 問題が発生したときに 「調査を続けるか、旧環境へ戻すか」 を判断する場面です。

本番中に考え始めるのではなく、 判断条件を事前に決めておきます。

切り戻し開始時刻を決める

たとえば、 業務開始が翌朝8:00、 切り戻しに最大2時間必要で、 切り戻し後の確認に1時間必要だとします。

余裕時間を1時間確保するなら、 遅くとも4:00ごろには切り戻し開始を判断する必要があります。

体制・役割分担を決める

大きな移行になるほど、 作業者だけでは完結しません。

連絡ルールも決める

障害時に全員が個別に発言すると、 情報が混乱します。

• 進捗を誰へ報告するか
• 障害を誰へエスカレーションするか
• 顧客への報告者は誰か
• Go／No-Goの最終決定者は誰か
• 連絡手段は電話・Teams・Slackなど何を使うか

移行リスクを整理する

移行計画には、 起こり得る問題と対策を事前に整理します。

リスクは「発生確率」だけで見ない

発生する可能性が低くても、 発生した場合の影響が非常に大きければ対策が必要です。

特に基幹ネットワークでは、 単純に「起こりそうか」ではなく、 発生確率 × 業務影響 の両方で優先度を考えます。

移行計画書に記載する項目

実務で移行計画書を作る場合は、 次のような構成にすると整理しやすくなります。

簡易テンプレート

ネットワーク移行計画でよくある失敗

1．作業手順だけを作る

コマンドや配線変更だけを詳細に書いても、 誰が判断するか、いつ切り戻すか、 何をもって成功とするかが決まっていなければ 移行全体を管理できません。

2．pingだけで試験を終える

ICMP疎通が成功しても、 DNS、TCP、認証、ファイアウォール、 実際のアプリケーション通信が正常とは限りません。

3．正常系しか試験しない

冗長構成の場合は、 回線断や機器障害を想定した切り替え確認も必要です。

4．新環境だけを見る

移行では現行ネットワークとの依存関係が重要です。 新環境の設定だけを確認しても不十分です。

5．切り戻し判断を先延ばしにする

本番作業中は復旧させたい気持ちが強くなりますが、 調査を続けるほど切り戻し可能時間が減ります。

6．業務担当者を巻き込んでいない

ネットワーク担当だけでは、 実際の業務が正常に利用できるか判断できない場合があります。

顧客・上司へ移行計画をどう説明するか

技術に詳しくない相手へは、 コマンドやルーティング方式から説明するより、 業務への影響を中心に説明します。

説明例

技術を業務影響へ変換する

ネットワーク移行で使われる英語表現

実務で使える表現

自分の言葉で説明する課題