このページは、 ネットワーク上級編 「第7章：設計・提案・ケーススタディ」の章末課題です。
第61回〜第70回で学んだ内容を使い、 1つの企業ネットワーク更改案件を 設計・比較・レビュー・移行・顧客説明・障害分析 まで一貫して検討します。
第7章 実践演習｜設計・提案・ケーススタディ
ネットワーク設計では、技術的に通信できる構成を作るだけでは不十分です。 複数案を比較し、リスクを整理し、移行方法を決め、 顧客や経営層へ「なぜこの設計なのか」を説明する必要があります。 この演習では、実案件に近いケースを使って第7章の内容を総合的に実践します。
この章末課題では、模範解答を暗記するのではなく、 与えられた要件から自分で判断することを重視します。
実務では、すべての条件を満たす「唯一の正解」が存在しないこともあります。 コスト、可用性、移行リスク、運用性などを比較し、 選定理由を説明できることが重要です。
この演習で確認するスキル
- 要件から基本設計方針を作成できる
- 複数のネットワーク構成案を比較できる
- 設計レビューで確認すべき観点を整理できる
- 移行計画と切り戻し条件を作成できる
- 冗長化の必要性を顧客へ説明できる
- セキュリティ投資を経営視点で説明できる
- 大規模障害の原因を構造的に分析できる
- 技術・コスト・リスクをまとめて提案できる
案件シナリオ
あなたは、ABC商事のネットワーク更改プロジェクトに参加する ネットワークエンジニアです。
現在のネットワークは約8年前に構築されており、 機器の老朽化、クラウド利用の増加、 リモートワークの拡大を背景に全面更改を計画しています。
会社概要
| 項目 | 内容 |
|---|---|
| 会社 | ABC商事株式会社 |
| 従業員数 | 約1,200名 |
| 拠点 | 本社1拠点、支店8拠点 |
| クラウド | 業務システムの一部をクラウドへ移行済み |
| リモートワーク | 常時200〜300名程度 |
| 運用 | 情報システム部5名＋外部保守会社 |
現在の主な問題
インターネット回線が単一
本社のインターネット回線障害が発生すると、 クラウドサービスや外部通信が利用できなくなります。
コア機器が老朽化
一部機器が保守終了予定であり、 障害発生時の交換部品確保にも不安があります。
ネットワークがフラット
部署やサーバーの通信分離が十分でなく、 セキュリティ事故時の影響範囲拡大が懸念されています。
監視が限定的
死活監視が中心で、 帯域・ログ・性能劣化を十分に把握できていません。
顧客から提示された要件
- 平日日中の業務停止を可能な限り避けること
- 本社インターネット接続を冗長化すること
- 主要ネットワーク機器を冗長化すること
- クラウド通信の増加に対応できる帯域を確保すること
- 部署・サーバー・管理系ネットワークを分離すること
- リモートアクセス環境を継続利用できること
- 障害時に原因を早期特定できる監視を導入すること
- 切り替え作業は休日夜間に実施すること
- 障害時には旧環境へ戻せること
- 5年間利用することを想定すること
更改後ネットワークの概念イメージ
この演習では、ベンダー固有の製品名やコマンドは指定しません。 特定製品の設定方法ではなく、 設計思想と判断根拠を考えてください。
顧客要件をもとに、ネットワーク更改の基本設計方針を整理してください。
最低限含める項目
- インターネット接続方針
- コアネットワーク冗長化方針
- VLAN・セグメンテーション方針
- ルーティング方針
- セキュリティ方針
- クラウド接続方針
- 監視・ログ方針
- 移行方針
回答例を見る
- インターネット： 2回線構成とし、回線またはエッジ機器障害時にも通信を継続できる構成とする。
- コア： コアスイッチを冗長化し、単一機器障害による全社停止を防ぐ。
- セグメント： 利用者、サーバー、管理系などをVLANで分割する。
- ルーティング： 経路障害時に代替経路へ切り替え可能な構成とする。
- セキュリティ： 必要な通信のみ許可する方針とし、セグメント間通信を制御する。
- クラウド： 通信量と可用性を踏まえて接続方式を選定する。
- 監視： 死活だけでなく、帯域、CPU、ログ、インターフェース状態などを監視する。
- 移行： 事前検証を実施し、休日夜間に段階的に切り替える。
インターネット接続について、次の2案を比較してください。
構成案
案A：同一キャリア2回線
同じ通信事業者から2回線を契約し、 インターネット接続を冗長化します。
案B：異なるキャリア2回線
異なる通信事業者の回線を利用し、 キャリア障害も考慮した冗長化を行います。
次の評価軸で5段階評価を付け、 最終的にどちらを推奨するか判断してください。
| 評価項目 | 案A | 案B | 判断理由 |
|---|---|---|---|
| 可用性 | |||
| 障害分離 | |||
| コスト | |||
| 運用性 | |||
| 設計の複雑さ |
考え方の例を見る
高い可用性を優先する場合は、 キャリア単位の障害も分離できる案Bを選択する考え方があります。
一方、契約・障害窓口・設計・運用の単純さを重視する場合は、 案Aが適している場合もあります。
重要なのは「案Bのほうが高度だから選ぶ」のではなく、 顧客の可用性要件とコスト許容度から判断することです。
担当者が作成した設計書に、次の記載がありました。 レビュー担当者として問題点を指摘してください。
【インターネット設計】 ・インターネット回線を2回線用意する。 ・通常時は回線Aを使用する。 ・障害時は回線Bへ切り替える。 ・切り替え時間は短時間とする。 【コアネットワーク】 ・コアスイッチを2台設置する。 ・障害時はもう1台を利用する。 【監視】 ・ネットワーク機器を監視する。 ・障害発生時には担当者へ通知する。
課題
曖昧な部分、不足している情報、試験で確認できない表現を 5つ以上挙げてください。
指摘例を見る
- 「短時間」の具体的な目標値がない
- どの障害を検知して切り替えるのか不明
- 回線復旧後の戻し方が不明
- コアスイッチ間の役割分担が不明
- 冗長化方式が記載されていない
- コア間リンクの設計が不明
- 監視対象項目が不明
- 通知条件・通知先が不明
- ログ保存期間が不明
- 正常性確認方法が定義されていない
設計レビューでは、 「書いてあるか」だけではなく、「第三者が同じ判断を再現できるか」 を確認します。
新ネットワークへの切り替えを 土曜日22:00〜翌日04:00で実施するとします。
以下の作業を適切な順番に並べ、 必要な確認項目を追加してください。
- 新機器の正常性確認
- 旧ネットワークから通信を切り替える
- 業務通信試験
- 関係者への作業開始連絡
- 設定バックアップ取得
- 監視確認
- 新ネットワーク機器の最終設定確認
- 作業完了連絡
2. ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3. ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
一例を見る
- 関係者への作業開始連絡
- 旧環境・新環境の状態確認
- 設定バックアップ取得
- 新ネットワーク機器の最終設定確認
- 新機器の正常性確認
- 旧ネットワークから新ネットワークへ切り替え
- 基本疎通試験
- 業務通信試験
- 冗長化試験
- 監視確認
- ログ・エラー確認
- 関係者による業務確認
- 作業完了連絡
移行作業では、「問題が起きたら戻す」だけでは不十分です。 いつ、誰が、どの条件で戻すかを事前に決める必要があります。
次の項目を定義してください
- 切り戻し判断時刻
- 切り戻し判断者
- 切り戻し条件
- 切り戻し作業
- 切り戻し後の確認項目
- 関係者への連絡
切り戻し判断期限： 切り戻し判断者： 切り戻し条件： 1. 2. 3. 切り戻し手順： 1. 2. 3. 切り戻し後確認： 1. 2. 3.
切り戻し条件の例を見る
- 主要業務システムへの通信が一定時間以上復旧しない
- 原因特定および復旧見込みが判断期限までに得られない
- 複数部門で業務継続困難な通信障害が発生している
- 冗長化機能に重大な問題があり、翌営業日の安定運用が保証できない
切り戻しは「失敗したときに考える作業」ではありません。 移行作業を開始する前に実行可能性を確認しておく設計項目です。
顧客担当者から次の質問を受けました。
顧客： 「今まで1台で動いていたのに、なぜ機器を2台にする必要があるのですか？ 費用がほぼ倍になるように見えます。」
課題
技術用語をできるだけ使わず、 200文字程度で説明してください。
説明例を見る
1台だけで構成すると、その機器が故障した時点で その先の通信全体が利用できなくなる可能性があります。 2台構成にする目的は性能を2倍にすることではなく、 1台が故障してももう1台で業務を継続できるようにすることです。 障害による業務停止時間と、その間に発生する損失を減らすための投資として考えます。
顧客説明では、 「VRRPを使う」「HA構成にする」といった方式名よりも、 業務停止をどのように減らせるのか を説明することが重要です。
今回の更改では、 VLAN・ファイアウォールによるセグメンテーションと ログ監視強化を提案します。
しかし経営層から次の質問を受けました。
経営層： 「今も通信できているのに、なぜ追加のセキュリティ費用が必要なのですか？」
課題
次の3点を含めて説明してください。
- 現在のリスク
- 投資によって減らせる影響
- 完全にリスクをゼロにはできないこと
説明の方向性を見る
現在のネットワークは通信範囲が広いため、 1台の端末が侵害された場合に被害が他のシステムへ拡大する可能性があります。 ネットワークを適切に分離し、異常通信を監視することで、 事故そのものを完全になくすことはできなくても、 被害範囲の限定と早期発見が期待できます。
経営層には、 製品機能ではなく 業務停止、情報漏えい、復旧費用、信用低下などの事業リスク と結び付けて説明します。
更改から3か月後、 本社ネットワークで大規模障害が発生しました。
障害概要
| 時刻 | 事象 |
|---|---|
| 09:10 | 利用者から「社内システムへ接続できない」と連絡 |
| 09:12 | 監視システムで複数ネットワーク機器の到達不能を検知 |
| 09:15 | インターネット通信も不安定になっていることを確認 |
| 09:20 | コアスイッチ2台は稼働中だがCPU使用率が高騰 |
| 09:25 | 大量のブロードキャスト通信を確認 |
| 09:32 | 前日夜間にアクセススイッチの設定変更が行われていたことが判明 |
| 09:40 | 対象スイッチをネットワークから切り離したところ通信が回復 |
課題
次の4つに分けて整理してください。
- 直接原因
- 根本原因
- 影響拡大要因
- 再発防止策
根本原因：
影響拡大要因：
再発防止策：
分析例を見る
直接原因：
アクセススイッチ周辺で大量のブロードキャストが発生し、
コアネットワークへ負荷が波及した。
根本原因：
前日夜間の設定変更により、
ループを防止する設定や接続条件に問題が生じた可能性がある。
影響拡大要因：
異常トラフィックの抑制、
変更後監視、
影響範囲の分離などが不十分だった可能性がある。
再発防止策：
設定レビューの強化、
変更前後試験の追加、
異常トラフィック監視、
STP関連設計の再確認、
変更後の一定時間監視などを実施する。
なお、提示された情報だけでは、 具体的にどの設定が誤っていたかまでは断定できません。 実際のRCAでは設定差分・ログ・トポロジー・パケット情報を確認して原因を確定します。
最後に、ここまでの検討内容をまとめ、 顧客へ提出する「提案概要」を作成してください。
提案概要に含める項目
- 現在の課題
- 更改の目的
- 推奨構成
- 推奨理由
- 期待できる効果
- 残るリスク
- 移行方法
- 切り戻し方針
- 運用・監視方針
- 今後の課題
■ 1. 現在の課題 ・ ・ ■ 2. 更改の目的 ・ ・ ■ 3. 推奨構成 ・ ■ 4. 推奨理由 ・ ■ 5. 期待効果 ・ ■ 6. 残存リスク ・ ■ 7. 移行方針 ・ ■ 8. 切り戻し方針 ・ ■ 9. 運用・監視方針 ・ ■ 10. 今後の課題 ・
ポイント： 技術者向け設計書と顧客向け提案書は同じではありません。 顧客向け資料では、 「何を入れるか」だけでなく 「なぜ必要か」「何が改善するか」を説明します。
自己採点｜100点満点
各課題を次の基準で自己評価してください。
評価目安
| 得点 | 到達度 |
|---|---|
| 90〜100点 | 設計判断から顧客説明まで一貫して整理できている |
| 80〜89点 | 上級編第7章の内容を十分に理解している |
| 70〜79点 | 基本は理解しているが、判断理由や説明力に改善余地がある |
| 60〜69点 | 設計・移行・提案の一部を復習するとよい |
| 59点以下 | 第61回〜第70回を確認してから再挑戦する |
目標は80点以上です。
ただし、採点結果よりも重要なのは、 「その構成を選んだ理由」を自分の言葉で説明できることです。
第7章で身につけてほしい考え方
設計書は設定一覧ではない
設計書には、構成だけでなく、 なぜその方式を選択したかという判断理由が必要です。
最も高性能な構成が正解とは限らない
コスト、運用性、可用性、移行難易度などを比較し、 要件に適した構成を選択します。
移行と切り戻しも設計の一部
新しい構成が正しくても、 安全に切り替えられなければ実案件では使えません。
説明相手によって言葉を変える
技術者、顧客担当者、経営層では、 必要な情報と説明方法が異なります。
障害は個人のミスだけで終わらせない
直接原因だけでなく、 レビュー、試験、監視、運用プロセスまで含めて原因を分析します。
技術を事業価値へ変換する
冗長化やセキュリティを、 業務継続、損失削減、リスク低減という形で説明します。
まとめ
- 基本設計では、要件を具体的なネットワーク方針へ変換する
- 構成案は可用性・コスト・運用性・リスクなど複数軸で比較する
- 設計レビューでは曖昧な表現や試験不能な条件をなくす
- ネットワーク移行では事前確認、切り替え、正常性確認を計画する
- 切り戻し条件と判断期限を作業開始前に定義する
- 顧客には技術方式より業務への効果を説明する
- 経営層にはセキュリティを事業リスクとして説明する
- 大規模障害では直接原因・根本原因・影響拡大要因を分けて分析する
- 設計・提案エンジニアには、技術だけでなく判断理由を説明する力が必要
第7章のゴールは「設計書を書けること」ではありません。 要件から構成を考え、複数案を比較し、 リスクとコストを踏まえて選定し、 その理由を顧客へ説明できる状態になることです。
上級編を終えたら
第7章の章末課題まで完了したら、 ネットワーク上級編で学んだ 要件定義、設計、クラウド、セキュリティ、自動化、 提案・ケーススタディの内容を振り返ってください。
特に、自分が作成した以下の成果物は、 設計・構築工程を目指す際の学習ポートフォリオとして整理できます。
- 要件整理表
- ネットワーク構成図
- IPアドレス設計
- ルーティング設計
- 冗長化設計
- セキュリティ設計
- 監視設計
- 構成案比較表
- 移行計画
- 切り戻し計画
- 顧客向け説明資料
- 障害原因分析資料
コメント