動画と記事で学ぶ / 設計・構築
ネットワーク要件定義で何を聞き、何を成果物に残すかを実務例で解説。通信・可用性・性能・セキュリティ・運用・移行のヒアリング項目と基本設計への受け渡しを整理します。
ここからは、検索目的に合わせて再構成した記事本文を読めます。図解・手順・コマンド例がある場合は本文内で確認できます。
ネットワーク要件定義は、利用者・業務・拠点・通信・可用性・性能・セキュリティ・運用・移行の条件を確認し、設計が判断できる要件として合意する仕事です。ヒアリング記録だけで終えず、要件一覧、業務通信一覧、現行・将来構成、未決事項を成果物にします。
この記事はネットワークエンジニア転職ガイドの各論です。工程の全体像から確認したい場合はそちらへ。
ネットワーク要件定義とは何を決める工程？
要件定義では、製品や設定値を先に決めるのではなく、『誰が、どこから、何へ、どの品質で接続し、障害時にどこまで継続・復旧するか』を決めます。設計で選択肢を比較できるよう、必須条件、希望条件、制約、対象外を分けます。
要件定義で確認する8分類のヒアリング項目
ヒアリングは、利用者・拠点、通信、可用性、性能、セキュリティ、運用、保守、移行の8分類で行います。質問への回答だけでなく、根拠資料、承認者、未確定事項、確認期限を同じ行へ残します。
| 分類 | 質問例 | 確認する資料 | 要件として残す内容 |
|---|---|---|---|
| 利用者・拠点 | 誰がどの場所・端末から使う？ | 組織図、拠点一覧 | 人数、場所、端末、将来増 |
| 通信 | どこからどこへ何を通信する？ | 業務フロー、現行FW | 送信元、宛先、プロトコル、ポート |
| 可用性 | 何分の停止まで許容できる？ | SLA、障害記録 | 冗長範囲、RTO、保守時間 |
| 性能 | 帯域・遅延・同時接続の条件は？ | 回線利用率、利用統計 | 平均・ピーク・成長率 |
| セキュリティ | 分離・認証・ログの基準は？ | 規程、監査指摘 | ゾーン、権限、保持期間 |
| 運用 | 誰が監視・変更・障害対応する？ | 運用体制、手順 | 監視、通知、責任分界 |
| 保守 | 機器・回線の保守条件は？ | 契約、EOL一覧 | 保守時間、交換、予備品 |
| 移行 | 停止・並行稼働・切り戻し条件は？ | 業務カレンダー | 移行期間、判定者、戻し方 |
現行調査と業務フローをどう整理する？
現行構成図、IP・VLAN表、経路、FWポリシー、回線、監視、障害記録を集め、利用部門の業務フローと照合します。資料と実機が一致しない場合は、どちらかを正しいと決めつけず、現行差分として確認者と期限を付けます。
利用者・業務操作
↓
送信元端末 -> 名前解決 -> 宛先IP -> Protocol/Port -> 応答
↓
可用性・性能・Security・運用・移行の条件を追加可用性・性能・セキュリティを数値と条件で定義する
『止まらない』『高速』『安全』では設計できません。許容停止時間、対象時間帯、ピーク帯域、遅延の測定区間、同時接続、ログ保持、認証方式、通信分離、障害時の縮退条件など、測定・判定できる条件へ変えます。根拠がない数値は仮定と明記し、確認期限を置きます。
運用・保守・障害対応の責任分界を決める
構築後に誰が監視し、一次切り分け、ベンダー連絡、設定変更、バックアップ、証明書更新、機器交換を行うかを決めます。24時間対応が必要なら、当番人数、連絡経路、判断権限、保守契約の受付時間まで確認します。
移行要件では停止・判定・切り戻しを確認する
移行要件は作業日だけではありません。並行稼働の可否、停止できる業務、データ・セッションの扱い、切替順序、正常判定者、切り戻し開始条件、旧環境を残す期間を合意します。
| STEP | 実施内容 | 完了確認 |
|---|---|---|
| 1 | 業務停止可能時間と禁止日を確認 | 作業窓が確定 |
| 2 | 切替対象と依存関係を整理 | 順序と影響範囲が読める |
| 3 | 正常判定の通信・監視・利用者確認を定義 | 誰が何を判定するか明確 |
| 4 | 中止・切り戻し条件と所要時間を定義 | 判断期限内に戻せる |
| 5 | 旧環境の保持・廃止条件を合意 | 移行後の責任者が明確 |
要件定義の成果物と基本設計への引き継ぎ
記入例：「業務サーバーへ接続できること」だけでは設計・試験へ渡せません。誰が、どこから、いつ、何へ、どの条件で接続し、失敗をどう判定するかまで記録します。
| 項目 | 要件の記入例 | 設計・試験への引き継ぎ |
|---|---|---|
| 要件ID | NW-SEC-01 | 設計書と試験成績書で同じIDを使う |
| 通信 | 社員端末VLAN10→業務サーバーVLAN20、TCP/443のみ | FW・ACLの許可条件と拒否条件を作る |
| 可用性 | 片系障害後も業務通信を継続する | 切替条件、許容停止時間、異常系試験を合意する |
| 未決事項 | 送信元の対象端末範囲は業務部門へ確認中 | 担当者と期限を残し、推測で設定値を確定しない |
成果物には要件IDを付け、基本設計の章と受入試験へ追跡できるようにします。議事録は発言記録、要件一覧は合意済み条件、課題・未決一覧は今後の確認事項として役割を分けます。
| 成果物 | 役割 | 完了確認 |
|---|---|---|
| 要件一覧 | 必須・希望・制約・対象外を整理 | 承認者と根拠がある |
| 業務通信一覧 | 通信の5要素と業務目的を整理 | 正常・拒否条件が分かる |
| 現行・将来構成図 | 対象範囲と接続関係を共有 | 境界と責任分界が明確 |
| 課題・未決一覧 | 仮定と確認期限を管理 | 担当者と期限がある |
| 移行要件 | 停止・判定・切り戻しを合意 | 作業窓内で成立する |
この内容は、設計構築チャンネルの動画でも解説しています。
関連する記事
次の解説を続けて読むと、今回の内容を隣接する工程や確認方法へ広げられます。
まとめ：設計が判断できる条件へ具体化して合意する
ネットワーク要件定義では、利用者、通信、可用性、性能、セキュリティ、運用、保守、移行を確認し、測定・判定できる条件へ変えます。要件ID、根拠、承認者、未決事項を残し、基本設計と受入試験へ引き継げる状態が完了です。
