この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第1回です。
第1章では、顧客から聞いた要望を整理し、 ネットワーク設計で判断できる具体的な条件へ変換する 要件定義を学びます。
ネットワーク要件定義とは何か？顧客の要望を設計へ変える方法
「止まらないネットワークにしたい」 「もっと速くしたい」 「セキュリティを強化したい」。 顧客から聞く言葉は、そのままではネットワークを設計できません。 要件定義では、こうした曖昧な要望を、 可用性・性能・セキュリティ・運用・移行などの 具体的な設計条件へ変換します。
中級編までは、すでに存在するネットワークを構築・検証したり、 障害原因を調査したりすることが中心でした。
上級編では、その一つ前の工程へ進みます。 「そもそも、どのようなネットワークを作るべきなのか」 を考える仕事です。
要件定義は、設計を始める前に 何を実現しなければならないのかを決める工程 です。
この記事を読み終えるとできること
- ネットワーク要件定義の役割を説明できる
- 要望・要件・設計の違いを区別できる
- 要件定義で確認すべき分類を整理できる
- 曖昧な要望を具体的な条件へ変換できる
- 要件と制約条件を区別できる
- 要件定義の結果を設計へ引き継げる
ネットワーク要件定義とは何か
ネットワーク要件定義とは、 顧客や利用者の要望・課題・制約を整理し、 ネットワークが満たすべき具体的な条件へ変換する工程です。
たとえば、顧客から次のような要望を受けたとします。
顧客： 「業務で使っているネットワークなので、 できるだけ止まらない構成にしてください。」
この言葉だけでは、 ネットワークエンジニアは設計できません。
なぜなら、 「できるだけ止まらない」の意味が人によって違う からです。
- 機器を2台にすればよいのか
- 回線も2本必要なのか
- 電源も冗長化するのか
- 障害時は自動で切り替える必要があるのか
- 何分以内なら停止してもよいのか
- メンテナンスによる計画停止は許容されるのか
これらを確認し、 設計時に判断できる条件まで具体化する のが要件定義です。
要件定義では、機器や設定を先に決めません。
最初に「何を実現する必要があるのか」を整理し、 その後に「どう実現するか」を設計します。
要望から設計までの全体像
ネットワーク案件では、 顧客の要望がそのまま設計になるわけではありません。
REQUIREMENTS TO DESIGN｜ 顧客の要望をネットワーク設計へ変換する
例：拠点間ネットワークを作る場合
| 段階 | 内容例 |
|---|---|
| 要望 | 東京本社と大阪支店を安全につなぎたい |
| 要件 | 本社・大阪間で業務システム通信を可能にする。 通信を暗号化する。 回線障害時にも業務を継続できるようにする。 |
| 方式検討 | インターネットVPN、閉域網、SD-WANなどを 可用性・性能・コスト・運用性で比較する。 |
| 設計 | 採用方式、回線、ルーティング、 冗長化、暗号化、監視方式などを決定する。 |
上級編では、この 要件 → 方式比較 → 設計 の流れを繰り返し扱います。
要望・要件・設計の違い
要件定義で特に重要なのが、 要望・要件・設計を混同しないこと です。
| 項目 | 意味 | 例 |
|---|---|---|
| 要望 | 顧客が実現したいこと | ネットワークを止まりにくくしたい |
| 要件 | システムが満たすべき条件 | 主要機器の単一障害で通信を継続できること |
| 設計 | 要件を実現する具体的な方法 | ルーターを2台構成とし、 冗長経路を構成する |
「ルーターを2台にしてください」は、 要件とは限りません。
顧客が製品・台数まで指定している場合でも、 その背景にある目的を確認する必要があります。 本当に必要なのは 「障害時も業務を継続すること」 かもしれません。
目的と手段を分ける
要件定義では、 顧客から具体的な製品名や技術名が出てきた場合も、 一度その理由を確認します。
たとえば、 「BGPにしてください」と言われた場合でも、 次のように確認します。
- なぜBGPが必要なのか
- 複数ISPとの接続が必要なのか
- 経路制御を細かく行いたいのか
- 既存環境との統一が理由なのか
- 運用チームがBGPを前提としているのか
要件は「何を満たすか」、 設計は「どう満たすか」です。
なぜネットワーク要件定義が重要なのか
設計の基準になる
要件が明確であれば、 冗長化、帯域、回線、セキュリティ方式などを 根拠を持って選択できます。
認識違いを防げる
顧客とエンジニアの 「止まらない」「速い」「安全」の 認識差を減らせます。
試験条件を作れる
要件が具体化されていれば、 完成後に要件を満たしているか試験できます。
見積もりがしやすい
機器数、回線、作業範囲、試験内容などが明確になり、 コストや工数を算出しやすくなります。
変更管理ができる
当初要件を記録しておけば、 後から追加された要求を 「要件変更」として管理できます。
設計理由を説明できる
「なぜこの構成なのか」を、 顧客要件へ結びつけて説明できます。
設計レビューで強い説明：
「一般的に冗長化した方がよいから2台にしました」 ではなく、 「主要業務について単一機器障害時も通信継続が必要という 可用性要件があるため、ルーターを冗長化しています」 と説明します。
ネットワーク要件定義で確認する10分類
要件定義では、 通信方式だけを確認してはいけません。
ネットワークを導入して 実際に運用するところまで考え、 複数の視点から確認します。
1．目的・対象範囲
- なぜ導入・更改するのか
- 現在どのような問題があるか
- 今回の対象範囲はどこまでか
- 対象外は何か
- 何を最優先するか
2．現行構成
- 現行ネットワーク構成図
- 機器・型番・OS
- IPアドレス体系
- VLAN構成
- ルーティング方式
- 既知障害や課題
3．利用者・端末・拠点
- 利用者数
- 端末数
- PC・電話・IoTなどの種類
- 拠点数
- 無線LAN利用者数
- リモート利用者
4．通信量・性能
- 利用アプリケーション
- 平均・ピーク通信量
- 必要帯域
- ポート速度
- 遅延・ロス・ジッター
- 将来の増加見込み
5．可用性・冗長化
- 停止した場合の業務影響
- 許容停止時間
- 冗長化対象
- 自動・手動切り替え
- 計画停止可能時間
6．セキュリティ
- ネットワーク分離
- 許可・禁止通信
- 利用者・端末認証
- 管理アクセス
- ログ保存
- 社内規程・業界基準
7．WAN・クラウド接続
- 拠点間通信
- インターネット出口
- クラウド利用
- クラウド接続方式
- IPアドレス重複
- 回線事業者の制約
8．運用・監視・保守
- 運用担当者
- 監視対象
- 障害通知
- ログ管理
- 設定バックアップ
- 変更管理
9．移行・試験
- 一括・段階移行
- 新旧並行期間
- 切り戻し条件
- 試験項目
- 受け入れ判定
- 作業可能時間
10．予算・スケジュール・成果物
- 予算
- 利用開始日
- 機器・回線納期
- 他プロジェクトとの依存関係
- 必要な成果物
- 要件の承認者
すべての案件で、 すべての項目を同じ深さまで確認する必要があるわけではありません。
案件の規模、業種、対象範囲、契約条件に応じて、 確認項目を追加・削除します。
曖昧な要望を具体的な要件へ変換する
要件定義で重要なのは、 顧客の言葉をそのまま要件定義書へコピーすることではありません。
曖昧な表現を、 設計・試験・運用で確認できる条件 へ変換します。
ネットワークを速くしたい
現在の通信量、ピーク値、必要帯域、 利用アプリケーション、許容遅延などを確認する
絶対に止めたくない
許容停止時間、業務影響、冗長化対象、 障害切り替え方式、計画停止の可否を確認する
セキュリティを強くしたい
守る対象、想定リスク、通信制御、 認証方式、管理経路、ログ保存、規程を確認する
将来増えても困らないようにしたい
将来の利用者数、端末数、拠点数、通信量、 IPアドレス消費量などを確認する
数値化できるものは数値化する
「多い」「速い」「すぐ」 「ほとんど止められない」 といった表現は、 人によって解釈が変わります。
可能な項目は数値へ変換します。
| 曖昧な表現 | 確認する情報 |
|---|---|
| 利用者が多い | 現在○人、3年後○人 |
| 通信量が多い | 平均○Mbps、ピーク○Mbps |
| すぐ復旧したい | 許容停止時間○分以内 |
| ログを長く保存したい | 保存期間○か月・○年 |
| 大勢がWi-Fiを使う | エリア別の想定同時接続数 |
良い要件は、 後から「満たしたか」を確認できます。
試験方法を想像できない要件は、 まだ具体化が足りない可能性があります。
ネットワーク要件定義の進め方
- プロジェクトの目的を確認する なぜ新規導入・更改するのか、 現在何が問題なのかを確認します。 技術ではなく、 まず業務上の目的を把握します。
- 対象範囲と対象外を決める LAN、WAN、無線LAN、 ファイアウォール、クラウド、 監視など、 今回どこまで対応するのかを明確にします。
- 現状を把握する 構成図、機器、IPアドレス、 VLAN、回線、ルーティング、 利用者、既知障害などを確認します。
- 顧客の要望を聞く 性能、可用性、セキュリティ、 運用、将来拡張などについて確認します。
- 曖昧な表現を具体化する 「速い」「止めたくない」 といった言葉を、 数値や条件に変換します。
- 制約条件を整理する 予算、納期、既存設備、 指定製品、作業可能時間、 社内標準などを整理します。
- 未決事項を課題化する その場で回答できない項目は、 担当者と回答期限を設定して管理します。
- 要件を文書化する 誰が読んでも同じ意味になる表現で 要件を整理します。
- 顧客・関係者と合意する 設計開始前に、 要件・前提・制約・対象外について 認識を合わせます。
要件定義は1回の打ち合わせで 終わるとは限りません。
ヒアリング → 調査 → 課題確認 → 再ヒアリング を繰り返しながら内容を固めることがあります。
要件と制約条件を区別する
要件定義では、 実現したい条件 だけでなく、 設計の自由度を制限する条件 も確認します。
| 種類 | 例 |
|---|---|
| 要件 | 回線障害時も業務通信を継続したい |
| 制約 | 既存契約の回線事業者を 継続利用する必要がある |
| 要件 | 管理通信を一般利用者ネットワークから 分離する |
| 制約 | 既存スイッチを今年度中は 継続利用する |
| 要件 | 新拠点からクラウドへ接続する |
| 制約 | サービス開始日は3か月後で 変更できない |
実務では、 理想的な技術構成がそのまま採用できるとは限りません。
予算・納期・既存設備・運用スキルなどの制約を踏まえて、 現実的な構成を選択します。
要件定義書には何を残すのか
要件定義で確認した内容は、 後から追跡できる形で文書へ残します。
要件定義で残したい主な情報
- プロジェクトの目的
- 背景・現状課題
- 対象範囲
- 対象外
- 現行構成
- 利用者・端末・拠点条件
- 性能要件
- 可用性要件
- セキュリティ要件
- WAN・クラウド接続要件
- 運用・監視要件
- 移行・試験要件
- 制約条件
- 前提条件
- 未決事項・課題
- 要件の優先順位
- 承認者・合意状況
要件には理由も残す
要件だけでなく、 なぜその要件が必要なのか も記録しておくと、 後工程で役立ちます。
| 要件 | 理由・背景 | 設計への反映 |
|---|---|---|
| 主要ネットワーク機器の単一障害時にも 業務通信を継続できること | ネットワーク停止時に、 受発注業務が停止するため | 機器・経路・電源の 冗長化方式を基本設計で検討 |
| 管理通信を一般利用者用ネットワークから 分離すること | 一般端末からネットワーク機器の 管理画面へアクセスさせないため | 管理用VLANおよび アクセス制御を検討 |
要件と設計を関連付けておくと、 「なぜこの設定・構成が必要なのか」 を後から追跡できます。
良い要件と悪い要件の違い
| 悪い例 | 改善例 |
|---|---|
| ネットワークは高速であること | 対象アプリケーションの通信量とピーク値を踏まえ、 必要帯域を確保すること |
| 障害に強いこと | 指定した単一障害発生時にも、 主要業務通信を継続できること |
| セキュリティを強化すること | 管理ネットワークへの接続元を 指定端末・指定経路に制限すること |
| 将来拡張できること | 3年間の利用者・端末・拠点増加計画を考慮して アドレス・ポート・帯域に余裕を確保すること |
ポイントは、 設計者と顧客が同じ意味で解釈できること です。
要件定義でよくある失敗
1．いきなり製品を選ぶ
「CiscoかFortinetか」などを先に決めてしまうと、 要件より製品機能が設計の中心になってしまいます。
2．顧客の言葉をそのまま書く
「速く」「安全に」「止まらないように」では、 設計条件にも試験条件にもなりません。
3．現行環境を見ない
新規設計だけを考えると、 IP重複、既存ルーティング、 運用方法などの問題を見落とします。
4．現在だけを見る
現在の利用者数だけでなく、 将来の端末・拠点・クラウド利用増加も確認します。
5．対象外を書かない
「やること」だけでなく、 「今回やらないこと」も明確にします。
6．未決事項を放置する
回答待ち項目は、 担当者と期限を設定し、 課題管理します。
要件が決まっていないまま設計を進めると、 後工程ほど修正コストが大きくなります。
IPアドレス、VLAN、回線、冗長化、 機器台数まで決めた後で前提が変わると、 多くの設計をやり直す可能性があります。
顧客・上司へ要件定義をどう説明するか
技術に詳しくない相手には、 「要件定義」という言葉だけでは 目的が伝わりにくい場合があります。
説明例：
「これから機器構成を決める前に、 まず新しいネットワークで何を実現する必要があるかを整理します。 利用人数、必要な通信速度、停止できる時間、 セキュリティ、運用方法、移行条件などを確認し、 その条件をもとに構成案を作成します。」
このように説明すると、 要件定義が単なる「質問会」ではなく、 後の設計判断に必要な情報を整理する工程 だと伝わります。
技術をビジネス影響へ変換する
要件を確認するときは、 技術用語だけでなく業務への影響も確認します。
| 技術的な確認 | 業務的な確認 |
|---|---|
| 回線を冗長化するか | 回線停止時にどの業務が停止するか |
| 帯域を何Mbpsにするか | どのアプリケーションを何人が使うか |
| VLANをどう分割するか | どの利用者・端末を分離する必要があるか |
| ログを何年保存するか | 監査・障害調査で どの期間のログが必要か |
上流工程では、 技術を業務・コスト・リスクへ翻訳する力 が重要になります。
要件定義で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Requirement | 要件 |
| Business requirement | 業務要件 |
| Technical requirement | 技術要件 |
| Availability requirement | 可用性要件 |
| Performance requirement | 性能要件 |
| Security requirement | セキュリティ要件 |
| Operational requirement | 運用要件 |
| Constraint | 制約条件 |
| Assumption | 前提条件 |
| Scope | 対象範囲 |
| Out of scope | 対象外 |
ヒアリングで使える表現
What is the primary objective of this project?
このプロジェクトの主な目的は何ですか？
How many users and devices will connect to the network?
何人の利用者と何台の端末がネットワークへ接続しますか？
What level of network availability is required?
どの程度のネットワーク可用性が必要ですか？
Are there any technical or budget constraints?
技術面または予算面の制約はありますか？
What is the expected growth over the next three years?
今後3年間でどの程度の増加を想定していますか？
理解度チェック
用語暗記ではなく、 要件定義と設計を区別できるか確認しましょう。
問題1． ネットワーク要件定義の説明として 最も適切なものはどれですか。
- ネットワーク機器へ設定を投入する工程
- 顧客の要望や制約を、 ネットワークが満たすべき条件へ整理する工程
- 障害発生時にログを確認する工程
- ルーターの機種を決定する工程
解答を見る
要件定義では、 顧客の要望・課題・制約を整理し、 設計で使用できる具体的な条件へ変換します。
問題2． 次のうち「設計」に該当するものはどれですか。
- 主要機器の単一障害時も 業務通信を継続したい
- ネットワーク停止によって 受発注業務へ影響する
- ルーターを2台構成として冗長化する
- 停止許容時間を確認する
解答を見る
「ルーターを2台構成とする」は、 要件を実現するための具体的な方法なので 設計です。
問題3． 顧客から 「できるだけ速いネットワークにしてほしい」 と言われました。 最初の対応として適切なものはどれですか。
- 最速のスイッチを選定する
- すべて100Gbpsで設計する
- 利用アプリケーション、通信量、 ピーク値などを確認する
- 要件定義書へ 「高速であること」と記載する
解答を見る
「速い」は曖昧です。 必要な性能を判断するための情報を確認します。
問題4． 「今年度中は既存スイッチを 継続利用しなければならない」は、 要件と制約のどちらに近いでしょうか。
解答を見る
設計時に自由に変更できない条件であり、 設計可能な選択肢を制限するため、 制約条件として整理します。
問題5． 要件を具体化するときに重要な考え方を 2つ挙げてください。
解答例を見る
- 曖昧な表現を可能な限り 数値・条件へ変換する
- 後から要件を満たしたか 試験・確認できる形にする
実践演習： 曖昧な顧客要望を要件へ変換する
あなたは、 ある企業のネットワーク更改を 担当することになりました。
顧客から聞いた内容
「今のネットワークは古くなってきたので更改したいです。 業務で使うため、なるべく止まらないようにしてください。 最近Web会議を使う人も増えていて、 ネットワークが遅いという声があります。 将来的にはクラウド利用も増やす予定です。 ただし予算はできるだけ抑えたいです。」
課題1．不足している情報を洗い出す
この情報だけでは設計できません。 顧客へ追加で確認すべき質問を 10個考えてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
6．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
7．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
8．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
9．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
10．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 現在のネットワーク構成図はありますか？
- 利用者数・端末数は何台ですか？
- 現在の通信量とピーク時間帯は どの程度ですか？
- 「遅い」と感じるアプリケーションは何ですか？
- ネットワーク停止時に 影響する業務は何ですか？
- 許容できる停止時間はどの程度ですか？
- どこまで冗長化する必要がありますか？
- 今後利用予定のクラウドサービスは何ですか？
- 今後3年程度で 利用者・通信量はどの程度増える予定ですか？
- 予算の上限または目安はありますか？
課題2．要望を要件候補へ変換する
次の顧客要望から、 どの分類の要件を確認する必要があるか 考えてください。
| 顧客の要望 | 確認すべき要件分類 |
|---|---|
| なるべく止まらないようにしたい | ＿＿＿＿＿＿＿＿＿＿ |
| Web会議が遅い | ＿＿＿＿＿＿＿＿＿＿ |
| クラウド利用を増やしたい | ＿＿＿＿＿＿＿＿＿＿ |
| 予算を抑えたい | ＿＿＿＿＿＿＿＿＿＿ |
解答例を見る
- 止まりにくくしたい： 可用性・冗長化
- Web会議が遅い： 通信量・性能
- クラウド利用： WAN・クラウド接続、性能、セキュリティ
- 予算： 予算・スケジュール・成果物／制約条件
課題3．要件と設計を分離する
次の文章が 「要件」か「設計」かを判断してください。
- 回線障害時も主要業務通信を 継続できること
- インターネット回線を2回線契約する
- 管理ネットワークを 利用者ネットワークから分離すること
- 管理用VLANとして VLAN 100を使用する
解答を見る
- 要件
- 設計
- 要件
- 設計
課題4．簡易要件定義シートを作る
最後に、 次の形式で要件を整理してください。
| 分類 | 顧客回答 | 要件 | 未決事項 |
|---|---|---|---|
| 目的 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| 性能 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| 可用性 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| クラウド | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| 予算 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
自分の言葉で説明する課題
後輩エンジニアから 「要件定義と基本設計は何が違うんですか？」 と質問されました。
1分程度で説明してください。
基本設計とは、 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
説明例を見る
要件定義は、 顧客が何を実現したいのかを確認し、 性能・可用性・セキュリティ・運用など、 ネットワークが満たすべき条件を整理する工程です。
基本設計は、 その要件を実現するために、 IPアドレス、VLAN、ルーティング、 冗長化、回線などの方式を 具体的に決める工程です。
簡単に言えば、 要件定義は「何を満たすか」、 設計は「どう満たすか」 を決めます。
まとめ
- ネットワーク要件定義とは、 顧客の要望・課題・制約を ネットワークが満たすべき条件へ変換する工程
- 要望 → 要件 → 方式検討 → 設計 の順番で具体化する
- 要件は「何を満たすか」、 設計は「どう満たすか」
- 「速い」「止まらない」「安全」 といった曖昧な言葉を、 数値や確認可能な条件へ変換する
- 性能だけでなく、 可用性、セキュリティ、運用、 移行、予算、スケジュールまで確認する
- 要件だけでなく、 その背景・理由・制約・未決事項も記録する
- 良い要件は、 設計後に 「満たしたかどうか」を試験・確認できる
上級編で最も重要なのは、 技術を知っていることではなく、 「なぜその設計にするのか」を 要件から説明できることです。
次の記事：現状構成を把握する方法
要件定義の全体像が分かったら、 次に必要なのは 現在のネットワークを正確に把握すること です。
現行構成図、機器一覧、IPアドレス、 VLAN、ルーティング、回線、設定、 既知障害などを どの順番で確認すればよいのかを解説します。
コメント