この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第8回です。
第1章では、顧客の要望を整理し、 ネットワーク設計で判断できる具体的な条件へ変換する要件定義を学びます。
移行・切り替え要件の整理｜停止時間・切り戻し・判定基準を決める
新しいネットワークを設計できても、 現行環境から安全に切り替えられなければプロジェクトは完了しません。 移行・切り替え要件では、移行方式、停止可能時間、新旧環境の並行期間、 切り替え判断、正常性確認、切り戻し条件などを事前に整理します。
ネットワーク更改では、 「新しい構成をどうするか」だけを考えていてはいけません。
実際のプロジェクトでは、 現在稼働しているネットワークから新しいネットワークへ どのように移行するかが重要です。
特に業務ネットワークでは、 切り替えに失敗すると多数の利用者やシステムへ影響するため、 要件定義の段階から停止時間や切り戻し条件まで確認しておく必要があります。
この記事を読み終えるとできること
- 移行要件と移行計画の違いを説明できる
- 一括移行・段階移行・並行運用を比較できる
- 許容停止時間と作業可能時間を整理できる
- 切り替えのGo／No-Go条件を整理できる
- 切り戻し条件を要件として定義できる
- 移行完了の受け入れ基準を整理できる
移行・切り替え要件とは何か
移行・切り替え要件とは、 現行ネットワークから新しいネットワークへ安全に移行するために、 移行方式・停止時間・判定条件・切り戻し条件など、 移行時に満たすべき条件を定義するものです。
たとえば、社内ネットワークのコアスイッチを 新しい機器へ更改する案件を考えてみます。
新しいネットワークの設計自体は完成していたとしても、 実際に切り替えるためには次のような確認が必要です。
- 業務を何分まで停止できるのか
- 平日夜間に作業できるのか
- 休日作業が必要なのか
- 全体を一度に切り替えるのか
- 部署や拠点ごとに段階的に移行するのか
- 旧ネットワークを何日残すのか
- 切り替え後に何を確認すれば成功と判断できるのか
- どの状態になったら旧環境へ戻すのか
- 誰が切り替え続行・切り戻しを判断するのか
「ネットワーク設計が正しい」ことと 「安全に移行できる」ことは別の問題です。
移行条件を確認しないまま詳細設計へ進むと、 作業直前になって「停止時間が足りない」 「切り戻す時間がない」と判明することがあります。
移行要件と移行計画の違い
要件定義では、 詳細な作業コマンドや作業手順まで作成するわけではありません。
| 項目 | 役割 | 例 |
|---|---|---|
| 移行要件 | 移行時に満たすべき条件を決める | 業務停止は30分以内とする |
| 移行設計・移行計画 | 要件を満たすための方式を決める | 旧・新機器を事前接続し、経路を切り替える |
| 作業手順書 | 実際の操作を時系列で定義する | 22:10に旧機器のポートをshutdownする |
要件定義では「何を守らなければならないか」を決めます。
その条件を満たす具体的な移行方式や作業順序は、 後続の設計・移行計画で決定します。
要件から計画へ変換する例
MIGRATION REQUIREMENT TO PLAN
移行方式を整理する
最初に確認したいのが、 どの単位・タイミングで新環境へ切り替えるかです。
大きく考えると、 一括移行・段階移行・新旧並行運用という考え方があります。
一括移行
決められた切り替え日に、 対象環境をまとめて新ネットワークへ移行します。
メリット
- 移行期間を短くできる
- 新旧環境を長期間維持しなくてよい
- 構成管理が比較的シンプル
注意点
- 1回の作業範囲が大きくなる
- 失敗時の影響範囲が大きい
- 事前検証の重要性が高い
段階移行
拠点・部署・VLAN・サービスなどの単位で、 複数回に分けて新環境へ移行します。
メリット
- 1回あたりの影響範囲を限定できる
- 初回移行で得た知見を次回へ反映できる
- 問題発生時の影響を抑えやすい
注意点
- 移行期間が長くなる
- 新旧ネットワーク間通信が必要になる
- 構成管理が複雑になる場合がある
並行運用
一定期間、 新ネットワークと旧ネットワークを両方利用できる状態にします。
メリット
- 新環境を確認しながら移行できる
- 旧環境を退避先として残せる
注意点
- 二重運用によるコスト増
- 経路やアドレス管理が複雑になる
- 旧環境をいつ廃止するか決める必要がある
実際の案件では、 「全体としては段階移行し、各拠点の切り替えは一括で行う」 といった組み合わせもあります。
停止時間と作業可能時間を整理する
移行要件で特に重要なのが、 業務をどこまで止められるかです。
「夜間なら止めても大丈夫」という表現だけでは不十分です。
確認したい情報
- 業務停止が許容される曜日
- 作業を開始できる時刻
- 業務再開が必要な時刻
- 許容される最大停止時間
- 24時間365日利用するシステムの有無
- バッチ処理やバックアップ時間との重複
- 海外拠点など時差の影響
- 月末・決算・繁忙期など作業禁止期間
作業時間と停止時間は同じではない
| 項目 | 例 |
|---|---|
| 作業可能時間 | 22:00〜翌5:00 |
| サービス停止可能時間 | 0:00〜0:30 |
| 正常性確認完了期限 | 翌3:00 |
| 切り戻し判断期限 | 翌2:00 |
| 業務利用開始 | 翌6:00 |
7時間の作業枠があるからといって、 ネットワークを7時間停止できるとは限りません。
切り替え作業だけで作業時間を使い切ってはいけません。
正常性確認と切り戻しに必要な時間も 作業時間の中へ確保する必要があります。
新旧環境の並行運用を整理する
段階移行では、 一部の利用者が旧ネットワーク、 別の利用者が新ネットワークを使う期間が発生することがあります。
その場合、 新旧環境が同時に存在しても正常に通信できるか を確認しなければなりません。
新旧ネットワークが共存する移行期間
新旧共存で確認するポイント
- 新旧ネットワーク間で通信が必要か
- 同じIPアドレス帯を使用していないか
- ルーティングループが発生しないか
- デフォルトゲートウェイをどちらへ向けるか
- DHCPをどちらから配布するか
- DNS登録をどのタイミングで変更するか
- ファイアウォールルールを新旧両方へ設定する必要があるか
- 監視対象をいつ新環境へ変更するか
段階移行では、 完成後の構成だけでなく「移行途中の構成」も設計対象 になることがあります。
移行対象と依存関係を整理する
ネットワークだけを変更するつもりでも、 実際には多くのシステムや担当者が関係します。
ネットワーク
- ルーター
- スイッチ
- ファイアウォール
- 無線LAN
- WAN回線
サーバー・サービス
- DNS
- DHCP
- 認証サーバー
- 業務システム
- クラウドサービス
外部サービス
- 通信事業者
- クラウド事業者
- データセンター
- セキュリティサービス
利用者・運用
- 利用部門
- サービスデスク
- 監視担当
- アプリケーション担当
- ベンダー
依存関係を確認する質問例
- ネットワーク変更と同時にサーバー変更がありますか
- 回線開通日は確定していますか
- DNS変更が必要ですか
- ファイアウォールルール変更が必要ですか
- クラウド側で設定変更が必要ですか
- 他チームの作業が完了しないと切り替えできませんか
ネットワーク単体では成功していても、 他システムとの連携ができなければ 業務としては移行失敗になることがあります。
切り替え開始の判定条件を決める
移行当日に作業者が集まったからといって、 必ず切り替えを開始するわけではありません。
切り替え前に、 作業を開始してよい条件を確認します。
Go条件の例
- 新機器の事前設定が完了している
- 事前試験がすべて合格している
- 設定バックアップを取得している
- 必要な関係者が待機している
- 通信事業者など外部ベンダーの準備が完了している
- 変更承認が取得済みである
- 利用部門の業務終了を確認している
- 障害や別作業が発生していない
GO
事前条件を満たしている
→ 切り替え開始NO-GO
必須条件を満たしていない
→ 延期・中止判定者も決めておくことが重要です。
技術担当者だけで判断するのか、 プロジェクト責任者や顧客責任者の承認が必要なのかを あらかじめ明確にしておきます。
切り戻し条件を決める
移行では、 「うまくいかなかったら戻す」だけでは不十分です。
どの状態になったら切り戻すのかを 事前に具体化しておきます。
切り戻し条件の例
時間による条件
1:30までに主要試験が完了しなければ 切り戻しへ移行する。
通信による条件
主要業務システムへの通信を 復旧できなければ切り戻す。
障害による条件
影響範囲を特定できない重大障害が発生した場合は 切り戻す。
承認による条件
業務部門による受け入れ確認が 完了できない場合は切り戻す。
時間を基準にする理由
障害対応を続ければ解決できそうでも、 作業可能時間には限界があります。
切り戻し判断のタイムライン例
切り戻し判断期限は、 業務開始時刻から逆算して決めます。
試験・正常性確認・受け入れ基準を整理する
切り替え作業が完了しただけでは、 移行成功とは判断できません。
「何を確認できたら新環境を正式利用してよいか」 を要件として整理します。
確認対象の例
| 分類 | 確認例 |
|---|---|
| 基本通信 | 主要VLAN間通信・デフォルトゲートウェイへの通信 |
| インターネット | 外部Webサイトへ正常に接続できる |
| 業務システム | 主要アプリケーションへログインできる |
| 冗長化 | 片系障害時に通信を継続できる |
| セキュリティ | 許可通信は通り、禁止通信は遮断される |
| 監視 | 新機器が監視システムへ登録されアラーム確認できる |
| ログ | Syslogなどが正常に保存される |
技術試験と業務確認を分ける
ネットワーク担当者がpingに成功しただけでは、 業務が正常に使えるとは限りません。
技術確認
- インターフェース状態
- ルーティング
- VLAN
- 冗長化状態
- 通信試験
- ログ・監視
業務確認
- 業務システムへログイン
- ファイル共有を利用
- 電話・会議システムを利用
- クラウドサービスへ接続
- 業務部門による確認
要件定義では、 誰が最終的に移行完了を承認するのかも確認しておきます。
関係者と連絡体制を整理する
大規模な移行では、 ネットワーク担当者だけで作業が完結することは少なくなります。
関係者の例
- 顧客のプロジェクト責任者
- ネットワーク担当
- サーバー担当
- アプリケーション担当
- セキュリティ担当
- 運用・監視担当
- 利用部門
- 回線事業者
- 機器ベンダー
決めておきたいこと
- 作業開始の承認者
- 切り戻しの判断者
- 正常性確認担当者
- 業務確認担当者
- 障害時のエスカレーション先
- ベンダーサポートへの連絡方法
- 利用者への事前通知方法
- 作業完了後の報告方法
「技術的に誰が作業するか」だけでなく、 「誰が判断するか」を決めることが重要です。
移行・切り替え要件のチェックリスト
要件定義では、最低限次の項目を確認します。
移行方式
- 一括移行か段階移行か
- 移行単位は何か
- 新旧環境を並行運用するか
- 旧環境をいつ廃止するか
時間
- 作業可能な曜日・時間帯
- 許容停止時間
- 正常性確認に使える時間
- 切り戻しに必要な時間
- 切り戻し判断期限
事前条件
- 事前試験の完了条件
- 設定・構成バックアップ
- 必要な機器・回線の準備
- 外部ベンダーの待機
- 変更承認
切り替え後
- 正常性確認項目
- 業務確認項目
- 受け入れ判定基準
- 監視開始条件
- 旧環境撤去条件
切り戻し
- 切り戻し条件
- 切り戻し判断者
- 切り戻し後の確認項目
- データや設定を元に戻せるか
移行・切り替え要件でよくある失敗
失敗1：停止時間を確認していない
設計後に「停止できるのは10分だけ」と判明し、 想定していた移行方式が使えなくなるケースです。
→ 許容停止時間は要件定義の早い段階で確認します。
失敗2：正常性確認時間を考えていない
切り替え作業だけで時間を使い切り、 十分な試験を行えなくなります。
→ 作業・試験・切り戻しを含めて時間を設計します。
失敗3：切り戻し条件が曖昧
障害が発生しても調査を続けるべきか戻すべきか判断できず、 時間だけが経過します。
→ 時刻・障害条件・影響範囲などで具体化します。
失敗4：新旧共存を考えていない
完成後の構成は問題なくても、 段階移行中に新旧ネットワーク間で通信できません。
→ 移行途中の構成も確認します。
失敗5：pingだけで成功と判断する
ネットワーク通信は成功していても、 DNSや認証、業務アプリケーションが利用できないことがあります。
→ 業務確認まで受け入れ条件へ含めます。
失敗6：判断者が決まっていない
切り戻すべき状況になっても、 誰が決定するのか分からず判断が遅れます。
→ Go／No-Goと切り戻しの責任者を明確にします。
顧客・上司への説明方法
移行要件を説明するときは、 技術方式だけではなく 業務への影響とリスクを中心に説明します。
伝わりにくい説明
「段階移行にして、 旧環境も残しながらルーティングを変更します。」
技術担当者には理解できても、 なぜその方式が必要なのかが伝わりにくい説明です。
伝わりやすい説明
「今回のネットワークは全社で利用しており、 一度に切り替えると障害発生時の影響範囲が大きくなります。 そのため、拠点単位で段階的に移行します。 各拠点の移行完了を確認してから次へ進むことで、 問題発生時の影響を限定します。」
このように、 要件 → リスク → 選択した方式 の順番で説明すると、設計意図が伝わります。
実務で使う英語表現
海外ベンダーの資料やプロジェクトでは、 移行作業に関する次の表現がよく使われます。
| 英語 | 意味 | 実務での使い方 |
|---|---|---|
| Migration | 移行 | Network migration |
| Cutover | 本番切り替え | Cutover window |
| Maintenance window | メンテナンス可能時間 | within the maintenance window |
| Downtime | 停止時間 | maximum allowable downtime |
| Rollback | 切り戻し | rollback procedure |
| Rollback criteria | 切り戻し条件 | define rollback criteria |
| Go / No-Go decision | 実施・中止判定 | Go/No-Go meeting |
| Validation | 正常性確認・検証 | post-cutover validation |
| Acceptance criteria | 受け入れ基準 | meet the acceptance criteria |
例：
The maximum allowable downtime is 30 minutes.
「許容される最大停止時間は30分です。」
理解度チェック
記事の内容を確認するため、 次の5問に答えてください。
問題1．移行要件として最も適切なものはどれですか。
- ルーターへ投入するCLIコマンド
- 業務停止は30分以内とする
- 22:05にLANケーブルを抜く
- showコマンドの実行順序
解答を見る
「停止30分以内」は移行時に満たすべき条件です。 具体的な操作方法は移行計画や作業手順書で定義します。
問題2．段階移行のメリットとして適切なものはどれですか。
- 必ず移行期間が短くなる
- 新旧環境が同時に存在しない
- 1回あたりの影響範囲を限定しやすい
- 切り戻しが不要になる
解答を見る
拠点や部署などに分けることで、 一度の変更による影響範囲を限定できます。
問題3．作業可能時間が22:00〜翌5:00の場合、 ネットワークを7時間停止してよいでしょうか。
解答を見る
作業可能時間とサービス停止可能時間は別です。 許容停止時間を個別に確認する必要があります。
問題4．切り戻し条件を事前に決める主な理由は何ですか。
解答を見る
障害発生時に調査を続けるか旧環境へ戻すかを 客観的に判断できるようにするためです。
問題5．次の空欄を埋めてください。
切り替え作業後は、ネットワーク機器の状態だけでなく、 実際に「（ A ）」が利用できることまで確認し、 移行の「（ B ）」を判断します。
解答を見る
B：完了・受け入れ
実践演習：本社ネットワーク更改の移行要件を整理する
次の案件を想定し、 移行・切り替え要件を整理してください。
案件条件
- 本社コアスイッチを新機器へ更改する
- 約500人がネットワークを利用している
- 平日の業務時間は8:30〜18:00
- ネットワーク停止は最大30分まで許容
- 作業は土曜日22:00〜翌5:00に実施可能
- 基幹システムへの接続が必須
- 旧機器は切り替え後1週間保持できる
- 翌月曜日8:00までに利用可能である必要がある
課題1．移行方式を考える
一括移行と段階移行のどちらが適しているか、 理由とともに考えてください。
理由：
解答例を見る
例：一括移行
コアスイッチが全社ネットワークの中心であり、 新旧環境を部分的に分離して運用することが難しい場合、 メンテナンス時間内に一括で切り替える方式が考えられます。
ただし停止可能時間が30分と短いため、 新機器の事前構築・事前試験を十分に行い、 本番では通信経路の切り替え作業を最小化する必要があります。
課題2．Go条件を3つ以上挙げる
2．
3．
解答例を見る
- 新コアスイッチの事前設定・事前試験が完了している
- 旧機器のコンフィグバックアップを取得している
- 関連システム担当者が待機している
- 変更作業の承認が完了している
- 利用部門の業務終了を確認している
課題3．切り戻し条件を考える
解答例を見る
- 切り替え後30分以内に主要通信を復旧できない
- 基幹システムへ接続できない
- 重大障害の原因を特定できない
- あらかじめ決めた切り戻し判断時刻を超える見込みとなった
課題4．移行完了の判定項目を作る
□
□
□
解答例を見る
- 主要VLAN間で正常に通信できる
- 基幹システムへ接続できる
- インターネットへ接続できる
- 冗長構成が正常である
- 監視システムから新機器を監視できる
- 利用部門による業務確認が完了している
自分の言葉で説明する課題
顧客から、 「移行手順は設計工程で考えればいいので、 要件定義では移行について確認しなくてもよいのでは？」 と質問されました。
30秒程度で説明してください。
説明例を見る
詳細な作業手順は後の工程で作成しますが、 移行方式を設計するためには、 事前に停止できる時間や作業可能時間、 新旧環境を並行運用できるか、 どの状態なら切り戻すかなどを確認する必要があります。
これらが分からないと、 要件を満たせない移行方式を設計してしまう可能性があるため、 要件定義の段階で条件を整理します。
まとめ
- 移行・切り替え要件は、 現行環境から新環境へ安全に移行するための条件を定義する
- 移行要件では「何を守るか」を決め、 詳細な移行方式や手順は後続工程で設計する
- 一括移行・段階移行・並行運用には、 それぞれ異なるメリットとリスクがある
- 作業可能時間と許容停止時間は分けて確認する
- 段階移行では、 新旧環境が共存する期間のネットワークも考慮する
- 切り替え開始前にはGo／No-Go条件を設定する
- 障害時は「いつ・どの状態なら戻すか」という 切り戻し条件を事前に決める
- 切り替え成功の判定には、 ネットワーク試験だけでなく業務確認も含める
- 作業者だけでなく、 切り替え・切り戻し・受け入れを判断する責任者も明確にする
良い移行設計は、作業手順を細かく書くことから始まるのではありません。 「何分止められるのか」「何を確認したら成功なのか」 「どこまで悪化したら戻すのか」を要件として明確にすることから始まります。
上級編では、要件定義から基本設計、 BGP・SD-WAN、クラウド、セキュリティ、 自動化、設計・提案まで順番に学びます。
コメント