動画と記事で学ぶ / 設計・構築
ネットワークエンジニア 設計 1日は、meeting、design docs、レビューの関係を構成図と実際の設定・確認コマンドで追うと理解できます。実務では正常時の動作だけでなく、設定ミスや障害時に何を見るかまで押さえます。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
ネットワーク設計者の一日は、会議だけでも設定作成だけでもありません。要件確認、現行調査、構成図・設計書更新、レビュー対応、試験・移行調整を、project phaseと期限に応じて配分します。会議のoutputを設計判断へ反映できるかが仕事の中心です。
この記事はネットワークエンジニアの仕事内容の各論です。工程の全体像から確認したい場合はそちらへ。
ネットワーク設計の一日は何をする？
先に答えると、ネットワーク設計者の一日は、会議だけでも設定作成だけでもありません。要件確認、現行調査、構成図・設計書更新、レビュー対応、試験・移行調整を、project phaseと期限に応じて配分します。会議のoutputを設計判断へ反映できるかが仕事の中心です。
会議では何を決める？
それぞれの役割と、実務で見るところを次の表に整理します。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| 要件確認 | 利用者・トラフィック・可用性・セキュリティ | 要件一覧と未決事項 |
| 基本設計 | 方式・冗長化・zone・アドレス方針 | 論理構成図、方式設計 |
| 詳細設計 | インターフェース・VLAN・経路・パラメーター | 物理構成図、パラメーターシート |
| レビュー | 前提・例外・運用性を検証 | 指摘表と決定ログ |
09:00 課題・schedule確認
10:00 要件会議 → 未決事項/決定事項
11:00 構成図・方式設計
13:30 詳細設計・parameter
15:30 peer review
17:00 test/移行調整・翌日計画設計書・構成図をどう更新する？
作業の順序と、各ステップの完了条件を次の表にまとめます。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 会議前に論点と選択肢を用意 | 決める事項を明確化 |
| 2 | 決定を構成図・設計書へ即日反映 | 議事録だけで終わらせない |
| 3 | レビュー指摘を原因別に整理 | 設計不足・誤記・前提差 |
| 4 | 試験とoperationへ追跡 | 要件→設計→試験を結ぶ |
# 設計成果物の対応例
REQ-NW-012 高可用性
-> BD-HA-03 gateway冗長方式
-> DD-VRRP-01 parameter
-> TEST-HA-05 failover試験Decision: VRRP timerはdefaultを採用
Reason: 目標切替時間を満たし、過敏な切替riskを避ける
Evidence: 検証TEST-HA-05 / reviewer承認レビュー指摘へどう対応する？
症状ごとの原因候補と、次に確認することを次の表にまとめます。正常時の出力と並べて差を見ます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 会議が多く設計時間がない | 論点未整理・役割不明 | agendaと担当者を決める |
| レビューが手戻り | 前提・要件追跡不足 | 設計冒頭に前提と対象外 |
| 図と表が不一致 | 更新元が複数 | 正本とバージョンを統一 |
| 求人が実質運用 | 設計成果物を作らない | 一日の時間配分と成果物を質問 |
設計職求人をどう見分ける？
設計職を目指すなら、図を描けるだけでなく、なぜその方式を選び、何を棄却し、試験でどう確かめるかを説明します。求人面接では『設計書を修正する』のか『要件から方式を決める』のかを分けて確認します。
- 対象機器・インターフェース・VRF/VLAN
- 取得日時・タイムゾーン・ソフトウェアバージョン
- 変更前後の同一コマンド出力
- 期待値・実測値・判定者
- 異常時の停止条件と切り戻し結果
この内容は、設計構築チャンネルの動画でも解説しています。
関連する記事
まとめ：会議の決定を設計・試験へ追跡させる
要点は、会議の決定を設計・試験へ追跡させることです。その日に決めたことと、翌日へ持ち越した確認事項を分けて記録します。
このテーマを続けて学ぶ
