第1回で完成させた「要件定義書」という名の地図を手に、次はいよいよネットワーク構築の航路を描く「設計」フェーズです。要件が完璧でも、それを形にする設計図が不正確では、目的地にはたどり着けません。性能のボトルネック、セキュリティホール、将来の拡張性の欠如といった問題は、多くがこの設計段階に起因します。
本記事では、この複雑で奥深いネットワーク設計のプロセスを、大きく5つのステップに分解して徹底解説します。単に技術を羅列するのではなく、「なぜこの技術を選ぶのか」「なぜこの構成が必要なのか」という設計の思考プロセスを重視して説明を進めます。
この「なぜ」を理解する力は、ネスペ午後試験で長文の問題文から設計者の意図を読み解く際に、強力な武器となるはずです。さあ、要件を「動く形」に変える設計の世界へ進みましょう。
目次
技術・製品の調査と評価│RFI・RFPとPoCの活用法
設計の最初のステップは、要件定義書で定められた性能や機能を実現できる技術・製品・サービスを選び出すことです。世の中には無数の選択肢があるため、効率的かつ客観的に情報を集め、評価するプロセスが重要になります。
情報収集の効率化：RFIとRFPの使い分け
複数のベンダーやメーカーから情報を集める際、ビジネスの現場ではRFIとRFPという文書が使われます。この2つは目的が異なり、段階的に使い分けるのが一般的です。
| 文書 | 目的 | 依頼内容の例 |
|---|---|---|
| RFI (Request for Information) 情報提供依頼 |
「どんな製品があるか知りたい」 広く情報を集め、市場動向や技術の実現性を調査する段階。 |
「当社の要件を満たせそうなSD-WANソリューションについて、製品カタログや導入事例などの情報を提供してください。」 |
| RFP (Request for Proposal) 提案依頼書 |
「最適な製品を提案してほしい」 具体的な要件を提示し、詳細な構成案や見積もりを依頼する段階。 |
「別紙の要件定義書に基づき、当社に最適なネットワーク構成案と、機器費用・構築費用・保守費用を合わせた見積もりを提案してください。」 |
RFIで選択肢を絞り込み → RFPで具体的な提案を受ける
【仕事例】PoCで「机上の空論」をなくす
製品カタログや提案書だけでは、実際の性能や自社環境との相性は完全には分かりません。特に新しい技術を導入する際には、「本当に要件を満たせるのか？」というリスクが伴います。そこで重要になるのがPoC（Proof of Concept：概念実証）です。
【身近な例え】
PoCは、洋服の「試着」や自動車の「試乗」のようなものです。カタログスペックだけを信じて高価な買い物をするのではなく、実際に触れてみて、着心地や乗り心地を確かめますよね。ITの世界でも同様に、本格導入前に小規模な環境で機器を借りてテストを行い、性能や機能、運用性を評価します。
- 評価ポイントの例：
- 性能検証：想定される最大負荷をかけた際、スループットや遅延が要件を満たすか。
- 機能検証：必須とされた機能（例：特定のVPN方式）が、問題なく動作するか。
- 相互接続性検証：既存の他社製品（例：認証サーバー）と正常に連携できるか。
PoCで得られた客観的な評価結果は、最終的な製品選定における最も強力な判断材料となります。手間はかかりますが、導入後の「こんなはずじゃなかった」という失敗を防ぐために、極めて重要なプロセスです。
ネットワーク設計の核心│物理・論理からセキュリティ・可用性まで
技術や製品の選定が終わったら、いよいよネットワーク全体の具体的な設計図を作成していきます。ネットワーク設計は大きく「物理設計」と「論理設計」に分かれますが、これに加えて「セキュリティ」と「可用性」の観点も統合して考える必要があります。ここでは、この4つの重要な設計要素について解説します。
1. 物理設計：モノの配置と繋がりを決める
物理設計とは、ネットワーク機器やケーブルといった「物理的なモノ」を、どこに、どのように設置し、接続するかを決める設計です。
【身近な例え】
家の「間取り」や「配線計画」に相当します。サーバーラックをどこに置くか、デスクの島ハブからメインスイッチまでどうケーブルを這わせるか、といった物理的な配置を決定します。
- 主な設計項目：
- 物理トポロジ：スター型、メッシュ型など、機器間の物理的な接続形態を決定。
- 設置場所（ファシリティ）：サーバーラックの配置、電源容量、空調などを考慮。
- 配線（ケーブリング）：ケーブルの種類（光/メタル）、経路、ポートの対応関係を定義した「配線構成図」を作成。
2. 論理設計：情報の流れ道を設計する
物理的な繋がり（道路）の上に、情報の流れ方（交通ルール）を定義するのが論理設計です。目には見えませんが、ネットワークの振る舞いを決定する中心的な部分です。
- 主な設計項目：
- IPアドレッシング：ネットワーク全体で重複なく効率的にIPアドレスを割り当てる計画。部署やサーバーセグメントごとにアドレス範囲を分割。
- VLAN（仮想LAN）：物理的な接続に捉われず、スイッチ内部で仮想的な放送ドメイン（LAN）を分割する設計。セキュリティ向上や不要なトラフィックの抑制に繋がる。
- ルーティング：異なるネットワーク間の通信経路を決定する設計。静的（スタティック）ルーティングと、OSPFなどの動的（ダイナミック）ルーティングを使い分ける。
3. セキュリティ設計：守りを固める
| 対策 | 設計内容の例 |
|---|---|
| 境界防御 | インターネットと社内ネットワークの境界にファイアウォールを設置。許可された通信（Web閲覧など）以外をすべてブロックする。 |
| ネットワーク分離 | VLANを使い、サーバーセグメント、クライアントPCセグメント、ゲストWi-Fiセグメントなどを分離。万が一ウイルス感染しても被害を限定的にする。 |
| 不正侵入対策 | 重要なサーバーが集まるセグメントの通信をIDS/IPSで監視し、不正なアクセスを検知・防御する。 |
4. 可用性設計：止まらない仕組みを作る
障害が発生してもサービスを継続させるための「冗長化」を設計します。1台の機器や1本の回線が故障しても、自動的に予備の経路に切り替わる仕組みを組み込みます。
- 主な冗長化技術：
- 機器の冗長化 (VRRP/HSRP)：ルーターやL3スイッチを2台一組で稼働させ、片方が故障したらもう片方が処理を引き継ぐ。
- 経路の冗長化 (OSPFなど)：ダイナミックルーティングプロトコルを使い、ある経路がダウンしたら自動的に迂回経路を計算させる。
- リンクの冗長化 (LAG)：複数の物理ポートを束ねて1本の論理リンクとして扱うことで、帯域増強と耐障害性を両立させる。
目的：デフォルトゲートウェイの冗長化により、片系故障時も通信を継続する。
- IETF標準。マルチベンダー対応。
- 複数ルータで 仮想IP と 仮想MAC を共有。クライアントは仮想IPをGWとして設定。
- 通常時は マスター が転送を担当。ダウン時は バックアップ が自動昇格（フェイルオーバー）。
- 優先度（Priority）でマスター選出可。必要に応じてプリエンプト設定。
- Cisco独自（参照RFCあり）。基本的にCisco機器向け。
- VRRP同様、仮想IP と 仮想MAC を共有。クライアントは仮想IPをGWとして設定。
- アクティブ が転送担当、スタンバイ が待機。障害時に自動昇格。
- トラッキング機能でIFダウンや経路喪失を優先度に反映し、迅速に切替可能。
| 項目 | VRRP | HSRP |
|---|---|---|
| 標準化 / ベンダー | IETF標準、マルチベンダー | Cisco独自（Cisco中心） |
| 役割名称 | マスター / バックアップ | アクティブ / スタンバイ |
| 基本動作 | 仮想IP/MAC共有、優先度でマスター選出、障害時に昇格 | 仮想IP/MAC共有、優先度＋トラッキングで迅速切替 |
| 負荷分散 | 基本なし（1台が転送担当） | 基本なし（1台が転送担当） |
| 適用シーン | 異機種混在環境 | Cisco中心のネットワーク |
- クライアント側のGWは 仮想IP を設定（物理アドレス変更不要）。
- 回線/IF/経路の状態を トラッキング に反映（特にHSRP）。
- 切替時間（Hello/Dead/Holdタイマ）と プリエンプト の有無を要件に合わせ調整。
※ ルータ分散利用（負荷分散）が必要なら、Cisco環境では GLBP も検討。
これら4つの要素を総合的に検討し、詳細な「ネットワーク構成図」や各種設定パラメータを定義した「設計書」としてまとめるのが、このステップのゴールです。
業務運用計画の策定│新システムへのスムーズな移行
優れた設計書が完成しても、それだけではプロジェクトは終わりません。新しいネットワークが稼働した「後」の、日々の運用やシステム移行まで見据えて計画を立てることが、プロジェクトを真に成功させる鍵となります。技術的な設計だけでなく、「人」がどう関わっていくのかを定義するのが、この業務運用計画です。
「守り」の運用計画：監視と障害対応
ネットワークを安定稼働させるための、「守り」の側面に関する計画です。問題の発生をいち早く察知し、迅速に解決するための体制と手順を明確にします。
【身近な例え】
これは、建物の「防災計画」や「警備体制」を決めるのに似ています。火災報知器（監視）をどこに設置するか、警報が鳴ったら誰が（担当者）、どう動くか（障害対応フロー）を事前に決めておくことで、いざという時に被害を最小限に抑えられます。
| 計画項目 | 定義内容の例 |
|---|---|
| 監視体制 | ・何を（監視項目）、どのくらいの頻度で（監視間隔）、どうやって（監視ツール）監視するのか。 ・異常を検知した場合の通知方法（メール、アラートなど）。 |
| 障害対応フロー | ・障害発生時の一次切り分け手順。 ・担当者レベルで解決できない場合の、上位者やベンダーへのエスカレーションフローと連絡先リスト。 |
| 定期メンテナンス | ・OSのアップデートや設定バックアップなど、定期的に行う保守作業の計画。 |
「攻め」の運用計画：システム移行
業務への影響を最小限に抑えつつ、現行システムから新システムへといかにスムーズに切り替えるかを計画する、「攻め」の側面です。移行計画の策定は、関係各所との調整が非常に重要となります。
- 移行方式の検討：
- 一斉移行：あるタイミングで一気に新システムへ切り替える。移行期間は短いが、問題発生時の影響が大きい（ハイリスク・ハイリターン）。
- 段階移行：部署や拠点ごとなど、段階的に新システムへ移行する。影響範囲を限定できるが、移行期間が長引き、新旧システムが混在する複雑な状態になる。
- 並行稼働：一定期間、新旧両方のシステムを並行して動かし、安定性を確認してから旧システムを停止する。最も安全だが、コストと手間が最大になる。
【仕事例】
例えば、全国に支社がある企業のネットワークを切り替える場合、影響の少ない小規模な支社でまず「段階移行」を実施して手順を確立し、問題がないことを確認してから、本社の基幹システムを週末に「一斉移行」するといった、複合的な計画が立てられます。
これらの運用・移行計画を設計段階でしっかりと文書化し、関係者の合意を得ておくことが、後の工程である「構築」や「テスト」の具体的な作業計画へと繋がっていきます。
失敗しない作業計画の立て方│WBSと影響範囲の最小化
設計書と運用計画が固まったら、いよいよ構築フェーズに向けた具体的な「作業計画」を作成します。ここでは「誰が」「いつ」「何を」やるのかを詳細に定義し、プロジェクト全体のスケジュールを管理可能なレベルまで落とし込みます。精緻な作業計画は、プロジェクトを遅延なくスムーズに進めるための羅針盤となります。
WBSでタスクを分解し、担当と期限を明確化
作業計画の作成には、第1回の記事でも触れたWBS（Work Breakdown Structure）が再び活躍します。設計フェーズで作成した設計書を元に、構築に必要な作業をすべて洗い出し、階層的に分解していきます。
【仕事例：ファイアウォール導入のWBS】
- 1. 機器手配
- 1.1. 見積もり取得・発注（担当：購買部、期限：10/10）
- 1.2. 納品・検品（担当：情報システム部、期限：10/25）
- 2. 物理設置作業
- 2.1. データセンター入館申請（担当：Aさん、期限：11/1）
- 2.2. ラッキング・配線作業（担当：Bさん、期限：11/5）
- 3. 論理設定・テスト
- 3.1. 初期設定投入（担当：Aさん、期限：11/10）
- 3.2. テスト仕様書作成（担当：Cさん、期限：11/12）
- 3.3. テスト実施・結果報告（担当：Aさん、Cさん、期限：11/20）
- 4. 切り替え作業
- 4.1. 最終設定バックアップ（担当：Aさん、期限：11/28）
- 4.2. 本番切り替え（担当：全員、日時：11/30 2:00-4:00）
このようにタスクを細分化し、それぞれの「担当者」と「完了期限」を明確にすることで、作業の進捗管理が容易になり、誰かのタスクが遅れた場合に全体へどう影響するかが一目で分かるようになります。このWBSを元に、ガントチャートなどの工程管理表を作成するのが一般的です。
利用者への影響を最小限にするための方策
ネットワークの切り替え作業は、既存の業務を一時的に停止させる可能性があります。そのため、作業計画においては、利用者への影響をいかに最小限に抑えるかを徹底的に考え、関係者への周知調整を行う必要があります。
【身近な例え】
これは、道路工事の時間帯に似ています。交通量の多い日中に工事をすれば大渋滞を引き起こしますが、交通量の少ない深夜に行えば影響は少なくて済みますよね。ネットワーク作業も同様に、利用者が少ない時間帯を狙って行います。
- 影響を最小化する計画のポイント：
- 作業日時の調整：業務影響の少ない深夜や休日に作業時間を設定する。
- 事前告知の徹底：作業日時、影響範囲、作業内容を記載した通知を、事前に全利用者および関係部署へ展開する。
- コンティンジェンシープラン（緊急時対応計画）：作業が失敗した場合に、元の環境へ速やかに戻すための「切り戻し手順」を準備しておく。
特に「切り戻し手順」の準備は極めて重要です。万が一の事態を想定し、「何分以内に復旧できなかったら、ただちに切り戻しを開始する」といった判断基準まで決めておくことで、大規模なシステムダウンを未然に防ぎます。
設計レビューの重要性│手戻りを防ぐ最終チェックポイント
すべての設計書と計画書が完成したら、構築作業に移る前に必ず行うべきなのが「設計レビュー」です。これは、作成した設計書に抜け漏れや間違いがないか、関係者を集めて多角的に検証する会議体のことです。ここでのチェックが、後の工程で発生する致命的な手戻りや、プロジェクトの失敗を防ぐ最後の砦となります。
なぜ設計レビューが不可欠なのか？
設計者一人の視点では、どうしても思い込みや見落としが発生しがちです。客観的な第三者の視点を入れることで、設計の品質を大きく向上させることができます。
【身近な例え】
これは、小説家が編集者に原稿を読んでもらうのに似ています。自分で書いた文章の誤字脱字や矛盾点には、なかなか気づけないものですよね。他人の目を通すことで、自分では見つけられなかった問題点が明らかになります。
【仕事例】設計レビューの主な観点
設計レビューでは、参加者がそれぞれの専門的な立場から、以下のような観点で設計書を隅々までチェックします。
| レビューの観点 | チェック内容の例 | 主なレビュー参加者 |
|---|---|---|
| 要件との整合性 | 「要件定義書にある全ての要件が、設計に漏れなく反映されているか？」 | プロジェクトマネージャー、顧客担当者 |
| 実現可能性・妥当性 | 「選定した技術や構成で、本当に性能要件を満たせるのか？机上の空論になっていないか？」 | 技術リーダー、他のエンジニア |
| 運用・保守性 | 「完成後の運用担当者が、無理なく保守できる設計になっているか？監視はしやすいか？」 | 運用・保守チームの代表者 |
| コスト・スケジュール | 「この設計は、定められた予算と期間内に構築可能か？」 | プロジェクトマネージャー、購買担当 |
レビューで指摘された問題点は、必ず設計書にフィードバックし、修正します。そして、全ての指摘事項が解決されたことを関係者全員で確認し、「この設計で構築を進める」という承認（サインオフ）を得て、設計フェーズは正式に完了となります。
この厳格なプロセスを経ることで、プロジェクトは初めて、手戻りのリスクを最小限に抑えた状態で、次の「構築・テスト」フェーズへと進むことができるのです。
まとめ
今回は、要件定義という「地図」を元に、ネットワークの具体的な「航路」を描く設計フェーズの5ステップを解説しました。
- 技術・製品の調査と評価：実現手段の候補を客観的に選ぶ
- ネットワーク設計の核心：物理・論理・セキュリティ・可用性を定義する
- 業務運用計画の策定：完成後の「守り」と「移行」を計画する
- 作業計画の立て方：構築作業を具体化し、リスクを管理する
- 設計レビュー：第三者の視点で品質を高め、手戻りを防ぐ
設計とは、単に機器の構成図を描くだけでなく、「どう作るか（作業計画）」そして「どう使うか（運用計画）」までを考え抜く、非常に重要な工程です。この設計書の品質が、後の構築・運用フェーズの成否を大きく左右します。
次回、連載第3回では、この完成した設計書を元に、いよいよ機器に命を吹き込む「構築・テスト」フェーズへと進んでいきます。