この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第70回です。
今回は上級編の最終回です。 これまで学んだ要件定義、基本設計、高度なネットワーク技術、 クラウド、セキュリティ、自動化、移行、障害対応、顧客説明を、 1つの企業ネットワーク更改案件に統合します。
上級編総合ケーススタディ｜要件定義から設計・移行・障害対応まで実践
「知っている」から「案件を進められる」へ。 架空の企業ネットワーク更改案件を題材に、 顧客要望の整理、構成案比較、ネットワーク設計、 セキュリティ、監視、移行、切り戻し、障害対応、 顧客説明までを一連の流れとして考えます。
上級編では、個別の技術を学ぶだけでなく、 「なぜその設計にするのか」を要件から説明すること を重視してきました。
実務では、「BGPが分かる」「VPNを設定できる」 「クラウドのルートテーブルを設定できる」といった個別スキルだけでは、 ネットワーク案件全体を進められません。
顧客の業務を理解し、要件を整理し、複数案を比較し、 技術・コスト・運用・リスクを考慮して設計し、 最後に関係者へ説明する必要があります。
このケーススタディを終えるとできること
- 顧客要望から不足情報を洗い出せる
- 要望を性能・可用性・セキュリティなどの要件へ変換できる
- 複数のネットワーク構成案を比較できる
- IP・VLAN・ルーティング・冗長化を設計できる
- クラウド・WAN・セキュリティを統合して考えられる
- 監視・ログ・運用まで含めて設計できる
- 移行・試験・切り戻しを計画できる
- 障害発生時に事実と仮説を分けて原因分析できる
- 設計理由を顧客や経営層へ説明できる
- 成果物をポートフォリオとして整理できる
今回の総合ケーススタディのゴール
顧客要望を聞き、要件を整理し、複数案を比較し、 設計・移行・運用・障害対応まで一貫した判断ができるかを確認します。
今回は、正しい製品名やコマンドを1つ当てる問題ではありません。
同じ要件でも、予算、運用体制、既存設備、 納期などによって採用する構成は変わります。
重要なのは、 判断した理由を、要件・制約・リスクと結びつけて説明できること です。
上級編のゴールは「最も高度な技術を選ぶこと」ではありません。
顧客に必要なネットワークを、制約を踏まえて現実的に設計し、 「なぜこの構成なのか」を説明できることです。
ケース：複数拠点とクラウドを持つ企業ネットワーク更改
あなたは、ABCソリューション株式会社の ネットワーク更改プロジェクトを担当するネットワークエンジニアです。
既存ネットワークの老朽化に加え、 クラウド利用、Web会議、リモートワークが増加しています。 顧客から、次の相談を受けました。
「今のネットワークは障害も増えてきたので更改したいです。 本社と各拠点、クラウドを安定して接続したいです。 回線障害が起きても業務を止めたくありません。 セキュリティも強化したいですが、 運用担当者は増やせないので、できるだけ管理を複雑にしたくありません。」
現在分かっている情報
| 項目 | 現状・条件 |
|---|---|
| 本社 | 東京・約500名 |
| 支店 | 大阪・名古屋・福岡の3拠点、各50〜100名 |
| クラウド | 業務Webシステムとデータ分析基盤を利用 |
| リモート利用 | 在宅勤務者が社外から業務システムへ接続 |
| WAN | 既存の拠点間回線は単一経路 |
| インターネット | 本社へ集中して外部通信 |
| 課題 | 回線障害、Web会議の遅延、クラウド通信増加 |
| セキュリティ | 社内利用者・サーバー・管理通信の分離が不十分 |
| 運用 | ネットワーク担当者3名。24時間常駐ではない |
| 移行 | 平日日中の長時間停止は不可 |
注意： この時点で機器構成を決めてはいけません。
「止めたくない」「安定させたい」「セキュリティを強化したい」 という表現だけでは、設計条件として不十分です。
STEP1：顧客要望から要件を整理する
最初に行うのは、製品選定ではなく要件整理です。
可用性
どの障害まで継続させるのか、 何分の停止まで許容できるのかを確認します。
性能
利用者数、アプリケーション、通信量、 遅延要求、将来増加を確認します。
セキュリティ
分離対象、許可通信、認証、 管理アクセス、ログ要件を整理します。
クラウド
接続先、通信経路、帯域、 冗長化、アドレス重複などを確認します。
運用
監視、通知、ログ、バックアップ、 変更管理、障害対応体制を確認します。
移行
作業可能時間、停止許容、 並行期間、試験、切り戻し条件を確認します。
追加ヒアリングで確認する質問
- ネットワーク停止時に最も影響する業務は何か
- 本社・支店・クラウドのどの通信を継続させる必要があるか
- 許容停止時間は何分か
- 現在およびピーク時の通信量はどの程度か
- Web会議利用者の同時接続数はどの程度か
- クラウド通信は今後どの程度増える予定か
- インターネット出口を本社へ集中する必要があるか
- 拠点ごとのインターネット接続を許可できるか
- どのネットワークを分離する必要があるか
- リモートアクセス対象者と接続先は誰か
- 監視通知を誰が受けるか
- 夜間・休日に障害が起きた場合の対応体制はどうするか
- 既存設備で継続利用しなければならないものは何か
- 予算の上限または優先順位はあるか
- 更改完了期限はいつか
ヒアリング後の要件例
| 分類 | 要件 | 背景・理由 |
|---|---|---|
| 可用性 | 単一回線障害時にも、 本社・支店から主要業務システムへの通信を継続できること | 停止すると受発注・顧客対応に影響するため |
| 性能 | Web会議と業務システムの通信品質を優先し、 ピーク時間帯の帯域不足を抑えること | 会議の音声断や業務レスポンス低下が発生しているため |
| クラウド | 各拠点からクラウドへの通信を安定して提供できること | クラウド利用が今後増加するため |
| セキュリティ | 利用者、サーバー、管理ネットワークを論理的に分離し、 必要な通信だけを許可すること | 不要な横方向通信と管理機器へのアクセスを抑えるため |
| 運用 | 障害・性能劣化を集中監視し、 少人数でも状態を把握できること | 運用担当者を増員できないため |
| 移行 | 業務影響を最小限にし、 問題発生時に旧構成へ戻せること | 平日日中の長時間停止が許容されないため |
技術を業務影響へ変換して考えます。
「回線を2本にするか」ではなく 「回線停止時にどの業務を継続させる必要があるか」から考えることで、 冗長化の必要性と投資理由を説明しやすくなります。
要件整理の詳細は、 第1回「ネットワーク要件定義とは何か」 から振り返ることができます。
STEP2：構成案を3案比較する
要件が整理できたら、すぐに1つの構成へ決めず、 複数案を比較します。
今回比較する3案
案A
既存方式を延長
- 拠点間WANは従来方式を継続
- 本社集中型インターネット
- 必要箇所のみ冗長化
特徴： 変更範囲を抑えやすい。
案B
WAN冗長化＋クラウド最適化
- 主要拠点の回線を冗長化
- クラウド向け経路を最適化
- 通信を用途別に制御
特徴： 可用性・性能・コストのバランスを取りやすい。
案C
SD-WAN・SASEを全面採用
- 拠点通信を集中管理
- 複数回線を動的利用
- クラウド型セキュリティを活用
特徴： 柔軟性は高いが、導入・運用変更の影響も大きい。
評価表を作成する
| 評価項目 | 重み | 案A | 案B | 案C |
|---|---|---|---|---|
| 可用性 | 25 | 2 | 4 | 5 |
| 性能・クラウド対応 | 20 | 2 | 4 | 5 |
| セキュリティ | 20 | 3 | 4 | 5 |
| 運用性 | 15 | 3 | 4 | 4 |
| 移行リスク | 10 | 5 | 4 | 2 |
| コスト | 10 | 5 | 3 | 2 |
この点数はケーススタディ上の例です。 実案件では、評価基準と重みを顧客要件に合わせて決定します。
今回は案Bを採用する
このケースでは、 WAN冗長化＋クラウド通信の最適化を行う案B を採用することにします。
案Cは将来性がありますが、 今回は短期間での移行と少人数運用という制約があります。 全面刷新による運用変更リスクを考慮し、 段階的な拡張が可能な案Bを採用します。
方式選定では「一番高機能な案」を選ぶのではありません。
要件を満たしながら、コスト、納期、運用スキル、 移行リスクを含めて最も現実的な案を選びます。
比較方法は、 第63回「構成案を比較する評価表」 も確認してください。
STEP3：選定した構成案を基本設計へ落とし込む
次に、採用案を実際のネットワーク構成へ変換します。
総合ケーススタディの論理構成イメージ
1．IPアドレス設計
アドレスは、将来の拡張と経路集約を考慮して、 拠点や用途ごとに規則性を持たせます。
| 用途 | アドレス例 | 設計意図 |
|---|---|---|
| 東京本社 | 10.10.0.0/16 | 本社内の各VLANを集約 |
| 大阪支店 | 10.20.0.0/16 | 拠点単位で識別しやすくする |
| 名古屋支店 | 10.30.0.0/16 | 拠点単位で識別しやすくする |
| 福岡支店 | 10.40.0.0/16 | 拠点単位で識別しやすくする |
| クラウド | 10.100.0.0/16 | オンプレミスと重複しない範囲を確保 |
詳細は 第11回「IPアドレス設計」 を参照してください。
2．VLAN・セグメント設計
| VLAN | 用途 | 主な制御方針 |
|---|---|---|
| VLAN 10 | 一般利用者 | 業務上必要なサーバー・インターネット通信を許可 |
| VLAN 20 | サーバー | 許可された利用者・システムからのみ接続 |
| VLAN 30 | 管理 | 管理端末・管理経路を限定 |
| VLAN 40 | 音声・会議系 | 必要に応じて通信品質を優先 |
| VLAN 50 | ゲスト | 社内ネットワークへの通信を禁止 |
3．ルーティング設計
ルーティングでは、 「正常時にどの経路を使うか」だけでなく、 障害時にどの経路へ切り替わるか を設計します。
- 拠点内では必要に応じて動的ルーティングを利用する
- WAN側では主経路・バックアップ経路を明確化する
- クラウド側とオンプレミス側の経路広告範囲を整理する
- デフォルトルートの向きを明確にする
- 経路集約できるアドレス設計と組み合わせる
- 非対称経路がファイアウォールへ与える影響も確認する
詳細は 第13回「ルーティング設計」 を振り返ってください。
4．冗長化設計
冗長化する対象
- WAN回線
- インターネット回線
- ルーター
- ファイアウォール
- コアスイッチ
- クラウド接続経路
確認すべき障害
- 物理回線断
- 通信機器停止
- 上位経路障害
- クラウド側接続障害
- 経路制御不良
- 電源障害
機器を2台にしただけでは、 ネットワーク全体が冗長化されたとは限りません。
回線、電源、経路、上位接続、設定、 切り替え条件まで確認して初めて、 単一障害点を減らせます。
冗長化については 第14回「冗長化設計」 も確認してください。
5．クラウド接続設計
クラウド接続では、 単にVPNや専用線を接続するだけではなく、 オンプレミスとのルーティング、冗長化、 セキュリティ、DNS、監視まで一体で考えます。
- オンプレミスとクラウドのIPアドレス重複がないか
- クラウドへの主経路とバックアップ経路は何か
- クラウドから社内へ戻る経路が正しいか
- どの通信をオンプレミス経由にするか
- どの通信をクラウド側で直接外部へ出すか
- 名前解決をどこで行うか
- 障害時にどこまで監視できるか
関連記事： オンプレミスとクラウドをVPNで接続する ／ 専用線接続の基本
STEP4：セキュリティ・監視・運用を設計する
セキュリティは「通信できる／できない」だけではない
セキュリティ設計では、 ネットワークを用途ごとに分離し、 必要な通信だけを許可する考え方を基本にします。
利用者
業務に必要なシステムのみ接続
サーバー
公開範囲と接続元を制御
管理
管理端末・管理経路を限定
ゲスト
社内ネットワークと分離
ファイアウォールポリシー例
| 送信元 | 宛先 | 通信 | 方針 |
|---|---|---|---|
| 利用者VLAN | 業務Web | HTTPS | 許可 |
| 利用者VLAN | 管理VLAN | 任意 | 拒否 |
| 管理端末 | ネットワーク機器 | 管理通信 | 許可 |
| ゲストVLAN | 社内ネットワーク | 任意 | 拒否 |
| ゲストVLAN | インターネット | 必要通信 | 許可 |
詳細は 第42回「ファイアウォールポリシー設計」 と 第48回「ネットワークセグメンテーション」 を参照してください。
監視設計
冗長化したネットワークでは、 「通信できているから正常」と判断しないこと が重要です。
たとえば主回線が停止し、 バックアップ回線だけで通信している場合、 利用者から見るとサービスは使えていても、 冗長性は失われています。
| 監視対象 | 確認内容 |
|---|---|
| 機器 | 死活、CPU、メモリ、温度、電源 |
| インターフェース | リンク状態、帯域使用率、エラー、破棄 |
| WAN | 回線状態、遅延、ロス、経路切り替え |
| ルーティング | ネイバー、経路数、想定経路 |
| VPN・クラウド接続 | トンネル状態、到達性 |
| セキュリティ | 拒否ログ、認証失敗、異常通信 |
| 設定 | 変更履歴、バックアップ、差分 |
自動化をどこへ使うか
運用担当者が少ないため、 すべてを手作業で確認する設計は避けます。
- 機器情報をSSHやAPIで定期取得する
- 設定バックアップを自動化する
- Gitで変更差分を残す
- テレメトリーや監視データを可視化する
- 定型的な設定変更をAnsibleなどで標準化する
- 大量ログの一次整理にAIを補助的に利用する
自動化の目的は「PythonやAnsibleを使うこと」ではありません。
手作業によるミスを減らし、 少人数でもネットワーク状態を把握・管理できるようにすることです。
関連記事： ネットワーク自動化とは何か ／ Gitによる設定管理 ／ テレメトリーと可視化
STEP5：移行・試験・切り戻しを計画する
良い設計が完成しても、 移行で失敗すれば業務影響が発生します。
そのため、設計と同じくらい 「どう新環境へ切り替えるか」 を具体化します。
事前構築
新機器の設定、クラウド側設定、 監視設定などを可能な範囲で事前に準備します。
単体・事前試験
インターフェース、ルーティング、冗長化、 セキュリティポリシーなどを確認します。
段階的切り替え
可能であれば、一度に全拠点を変更せず、 影響を限定しながら段階的に移行します。
疎通・業務試験
pingだけではなく、 実際の業務システムやクラウド利用まで確認します。
冗長化試験
回線断、機器停止などを想定し、 バックアップ経路への切り替えを確認します。
監視確認
障害イベントが監視システムで検知され、 適切な通知が発生することを確認します。
切り戻し条件を事前に決める
| 条件 | 判断例 |
|---|---|
| 主要業務通信が復旧しない | 一定時間を超えた場合は切り戻し |
| 原因不明の重大障害 | 調査時間を確保できない場合は切り戻し |
| 複数拠点で通信不可 | 影響範囲が拡大した場合は切り戻し |
| 予定時間を超過 | 業務開始時刻から逆算して判断 |
切り戻しは「失敗したら考える」のではなく、 作業前に条件・手順・責任者まで決めます。
関連記事： 第65回「ネットワーク移行計画の作り方」 ／ 第66回「切り戻し計画の作り方」
STEP6：移行後に発生した障害を分析する
移行から1週間後、 東京本社と大阪支店でクラウド業務システムへの接続が 一時的に不安定になる障害が発生しました。
- 10:02 利用者から「クラウド業務システムが遅い」と申告
- 10:04 大阪支店でも同様の申告
- 10:06 インターネット閲覧は可能
- 10:08 監視上、WAN主回線の状態変化を確認
- 10:10 バックアップ経路へ切り替わっていることを確認
- 10:13 バックアップ回線の使用率が高いことを確認
まず事実と仮説を分ける
| 分類 | 内容 |
|---|---|
| 事実 | 複数拠点でクラウド通信が遅い |
| 事実 | 一般的なインターネット閲覧は可能 |
| 事実 | WAN主回線に状態変化があった |
| 事実 | バックアップ経路へ切り替わっている |
| 仮説 | バックアップ回線の帯域不足で性能劣化している可能性 |
| 仮説 | 切り替え後の経路が想定と異なる可能性 |
調査の流れ
- 10:02〜10:05 影響確認 対象拠点、対象システム、利用者範囲を確認
- 10:05〜10:10 ネットワーク状態 回線、ルーティング、トンネル状態を確認
- 10:10〜10:15 性能確認 バックアップ回線の使用率・遅延・ロスを確認
- 10:15〜10:20 暫定対応 重要通信を優先し、不要通信の抑制を検討
- 復旧後 原因分析 主回線障害とバックアップ設計の妥当性を分析
今回の根本原因候補
調査の結果、主回線障害によってバックアップ回線へ切り替わったものの、 バックアップ回線では通常時と同じ通信量を十分に処理できず、 クラウド業務通信の遅延が発生したと仮定します。
ここで重要なのは、 「回線障害が原因だった」で終わらせないことです。
直接原因
主WAN回線の障害によってバックアップ経路へ切り替わった。
設計上の課題
バックアップ回線利用時の帯域・優先制御について、 業務継続に必要な性能検証が不足していた。
再発防止策
- バックアップ回線に必要な最低帯域を再評価する
- 重要アプリケーションを識別してQoSを検討する
- 冗長化試験に性能確認を追加する
- 主回線断時のバックアップ帯域使用率を監視する
- 一定使用率を超えた場合のアラートを追加する
- 障害時に制限できる非重要通信を整理する
「通信が切り替わった＝冗長化成功」とは限りません。
障害時にも必要な性能で業務を継続できるかまで確認して、 初めて可用性要件を満たしていると言えます。
原因分析の考え方は 第69回「大規模障害の原因分析」 も参照してください。
STEP7：設計と障害を顧客・経営層へ説明する
顧客へ設計案を説明する
説明例
「今回の構成では、主要拠点のWAN回線とネットワーク機器を冗長化します。 これは機器を増やすこと自体が目的ではなく、 単一の回線・機器障害が発生した場合でも、 受発注などの主要業務を継続するためです。 また、クラウド利用増加を考慮し、 通信経路と帯域も将来拡張できる構成にしています。」
技術名を並べるのではなく、 要件 → 設計 → 業務上の効果 の順番で説明します。
障害発生時の初報
初報例
「10時02分頃から、一部拠点でクラウド業務システムへの接続遅延を確認しています。 現在、東京本社と大阪支店で影響を確認しており、 一般的なインターネット通信は利用可能です。 WAN回線の状態変化を確認しているため、 経路切り替えとの関連を調査しています。 原因はまだ確定していません。」
原因が確定していない段階では、 仮説を事実として伝えないことが重要です。
経営層へ再発防止策を説明する
説明例
「今回、回線の切り替え自体は正常に動作しましたが、 バックアップ回線利用時に通信量が集中し、 一部業務のレスポンスが低下しました。 今後はバックアップ時にも重要業務を維持できるよう、 帯域設計と優先制御を見直します。 あわせて、回線切り替え後の性能低下を早期検知できる監視を追加します。」
上級エンジニアに求められるのは、 技術を詳しく説明することだけではありません。
技術を、業務影響・コスト・リスク・改善効果へ翻訳する力 が重要です。
関連記事： 顧客に冗長化を説明する方法 ／ 経営層にセキュリティ投資を説明する方法
総合ケーススタディで使える英語表現
海外ベンダーやクラウドサービスのサポートへ問い合わせる場合、 技術用語だけでなく、 影響範囲・発生時刻・暫定対応を整理して伝えます。
| 英語 | 意味 |
|---|---|
| Business impact | 業務影響 |
| Failover | 障害時の切り替え |
| Redundant path | 冗長経路 |
| Root cause | 根本原因 |
| Mitigation | 影響を抑えるための暫定対策 |
| Corrective action | 是正措置 |
| Preventive action | 再発防止策 |
| Rollback plan | 切り戻し計画 |
ベンダー問い合わせ例
We experienced intermittent connectivity to our cloud environment after the primary WAN link failed over to the backup link.
主WAN回線からバックアップ回線へ切り替わった後、
クラウド環境への通信が断続的に不安定になりました。
The issue affected users at multiple branch offices.
この問題は複数の支店の利用者へ影響しました。
We would like to confirm whether the routing behavior after failover is expected.
切り替え後のルーティング動作が想定どおりか確認したいです。
英語で問い合わせる場合も、 「困っています」だけではなく、 発生時刻、影響範囲、構成、ログ、実施済み調査、 確認したい事項を整理して伝えます。
最終成果物を作る
このケーススタディの価値は、 記事を読んで終わることではありません。
実際に資料を作成し、 「自分ならこの案件をどう設計するか」 を形にしてください。
作成する成果物
- 要件定義シート
- 現状課題一覧
- 構成案比較表
- 採用案と選定理由
- 物理構成図
- 論理構成図
- IPアドレス設計表
- VLAN一覧
- ルーティング設計
- 冗長化設計
- WAN・クラウド接続設計
- セキュリティ方針
- ファイアウォール通信要件表
- 監視項目一覧
- ログ設計
- 移行計画
- 試験計画
- 切り戻し計画
- 障害報告書
- 再発防止策
- 顧客説明用1ページ資料
成果物同士をつなげる
上級編では、 各資料が独立していてはいけません。
| 要件 | 設計 | 試験 |
|---|---|---|
| 単一回線障害時にも主要業務通信を継続できる | 主回線＋バックアップ回線を設計 | 主回線を停止し、業務通信の継続を確認 |
| 管理ネットワークを一般利用者から分離する | 管理VLANとアクセス制御を設計 | 一般利用者から管理通信できないことを確認 |
| 障害を早期検知できる | 回線・機器・経路の監視を設定 | 障害発生時に監視通知されることを確認 |
要件 → 設計 → 試験を追跡できる資料を作れると、 設計理由を説明しやすくなります。
総合理解度チェック
問題1． 顧客から「止まらないネットワークにしてください」と言われました。 最初に行うべき対応として最も適切なのはどれですか。
- ルーターを2台購入する
- 最も高価な回線を2本契約する
- 停止時の業務影響や許容停止時間を確認する
- すべての機器を二重化する
解答を見る
先に「何を継続する必要があるのか」を要件として確認し、 その後に必要な冗長化方式を決めます。
問題2． 3つの構成案を比較するとき、 技術機能以外に確認すべきものを4つ挙げてください。
解答例を見る
- コスト
- 運用性
- 移行リスク
- 納期
- 既存設備との互換性
- 運用担当者のスキル
問題3． 主回線障害時にバックアップ回線へ正常に切り替わりました。 これだけで冗長化試験は合格と言えるでしょうか。
解答を見る
切り替え後に主要業務通信を継続できるか、 必要な性能を維持できるか、 監視通知が発生するかなども確認する必要があります。
問題4． 障害発生直後の顧客報告で、 原因が確定していない場合に重要なことは何ですか。
解答を見る
事実、影響範囲、現在の対応状況を伝え、 仮説を確定原因として説明しないことです。
問題5． 上級ネットワークエンジニアにとって、 「設計理由を説明できる」とはどういうことでしょうか。
解答例を見る
採用した技術や構成を、 顧客要件、業務影響、コスト、リスク、 運用条件などと結びつけて説明できることです。
最終課題：あなた自身のネットワーク提案を作る
ここからが上級編の本当の総合演習です。
この記事で示した設計例をそのまま写すのではなく、 あなた自身の判断で構成案を作ってください。
課題1．不足している要件を10個挙げる
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
6．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
7．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
8．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
9．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
10．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題2．3つの構成案を作る
少なくとも次の観点で比較してください。
- 可用性
- 性能
- セキュリティ
- クラウド対応
- 運用性
- コスト
- 移行リスク
課題3．採用案を1つ選び、理由を書く
選定理由：
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題4．論理構成図を作る
次の要素を最低限含めてください。
- 東京本社
- 3支店
- クラウド
- インターネット
- WAN
- ファイアウォール
- 主要なネットワークセグメント
- 主経路・バックアップ経路
課題5．設計レビューを自分で行う
次の質問へ答えられるか確認してください。
- なぜこのIPアドレス体系にしたのか
- なぜこのVLAN分割にしたのか
- なぜこのルーティング方式にしたのか
- 単一障害点はどこに残っているか
- 回線障害時はどの経路へ切り替わるか
- クラウド障害時の影響は何か
- 不要な通信をどこで制御するか
- 障害をどの監視項目で検知するか
- 切り戻し条件は明確か
- 要件を満たしたことをどの試験で確認するか
課題6．顧客へ3分で説明する
次の質問へ、専門用語をできるだけ減らして答えてください。
「現在より費用が増えるのに、 なぜ回線や機器を冗長化する必要があるのですか？」
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
説明例を見る
今回のネットワークでは、 回線や主要機器が1つ故障しただけで 受発注やクラウド業務が停止しないようにすることを目的としています。
冗長化によって初期費用は増えますが、 1つの故障で全社業務が停止するリスクを下げられます。 すべてを二重化するのではなく、 業務影響の大きい部分を優先して冗長化することで、 コストと可用性のバランスを取っています。
上級編修了判定
次の項目を自分で確認してください。
| 評価項目 | できる | 要復習 |
|---|---|---|
| 顧客の曖昧な要望を具体的な要件へ変換できる | □ | □ |
| 要件と制約を分けて整理できる | □ | □ |
| 複数の構成案を比較できる | □ | □ |
| IP・VLAN・ルーティングを設計できる | □ | □ |
| 冗長化方式と障害時の動作を説明できる | □ | □ |
| クラウド接続を含むネットワークを設計できる | □ | □ |
| セキュリティとセグメンテーションを設計できる | □ | □ |
| 監視・ログ・設定管理まで考慮できる | □ | □ |
| 移行・試験・切り戻しを計画できる | □ | □ |
| 障害時に事実と仮説を分けて分析できる | □ | □ |
| 原因・暫定対応・恒久対応を整理できる | □ | □ |
| 設計理由を顧客要件から説明できる | □ | □ |
| 技術を業務影響・コスト・リスクへ翻訳できる | □ | □ |
| 成果物一式を自分で作成できる | □ | □ |
すべてを完璧に暗記している必要はありません。
分からない技術があっても、 要件を整理し、必要な情報を調べ、 根拠を持って判断し、その結果を説明できる ことが重要です。
この成果物をポートフォリオにする
設計案件の経験が少ない場合でも、 このケーススタディを自分で完成させることで、 「設計工程をどう考えているか」を示す練習になります。
ポートフォリオに入れたい構成
- 案件背景
- 顧客要望
- 要件一覧
- 構成案比較
- 採用案
- ネットワーク構成図
- 主要設計
- セキュリティ方針
- 監視方針
- 移行・切り戻し
- 想定リスク
- 設計判断の理由
実務で作成した顧客資料を、 許可なくポートフォリオへ掲載してはいけません。
学習用として公開する場合は、 今回のような架空案件として自分で作成してください。
まとめ
- 上級編の最終ゴールは、 個別技術を知ることではなく、 要件からネットワーク全体を設計できること
- 顧客要望はそのまま設計せず、 性能・可用性・セキュリティ・運用・移行などの要件へ変換する
- 構成案は複数作り、 技術、コスト、運用、移行リスクなどで比較する
- IP、VLAN、ルーティング、冗長化、 クラウド、セキュリティを個別ではなく関連付けて設計する
- 監視・ログ・自動化もネットワーク設計の一部として考える
- 移行前に試験項目、切り戻し条件、判断者を決める
- 障害対応では事実と仮説を分け、 直接原因だけでなく設計・運用上の背景まで分析する
- 技術を業務影響・コスト・リスクへ翻訳して顧客へ説明する
- 要件 → 設計 → 試験を追跡できる成果物を残す
「なぜこのネットワークなのか」を説明できることが、 上級編で身につけたい最も重要な力です。
ネットワーク上級編 修了
ここまでで、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 全70記事は終了です。
第1回では、 顧客の曖昧な要望を具体的なネットワーク要件へ変えるところから始めました。
その後、IPアドレス、VLAN、ルーティング、冗長化、 BGP、WAN、クラウド、セキュリティ、自動化、 設計書、移行、顧客説明、障害分析まで学んできました。
最後に残るのは、 学んだ技術を使って問題を解決し、 自分の判断を相手へ説明し、 成果物として残すこと です。
上級編では、要件定義から基本設計、BGP、WAN、 クラウド、セキュリティ、自動化、 設計レビュー、移行、顧客説明、障害分析までを学びました。
この総合ケーススタディで作成した資料は、 自分の弱点を確認するための復習教材として、 また設計力を示す学習ポートフォリオとして活用できます。
コメント