network設計者の一日は、会議だけでもconfig作成だけでもありません。要件確認、現行調査、構成図・設計書更新、review対応、試験・移行調整を、project phaseと期限に応じて配分します。会議のoutputを設計判断へ反映できるかが仕事の中心です。
ネットワーク設計の一日は何をする?
先に答えると、network設計者の一日は、会議だけでもconfig作成だけでもありません。要件確認、現行調査、構成図・設計書更新、review対応、試験・移行調整を、project phaseと期限に応じて配分します。会議のoutputを設計判断へ反映できるかが仕事の中心です。
会議では何を決める?
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| 要件確認 | 利用者・traffic・availability・security | 要件一覧と未決事項 |
| 基本設計 | 方式・冗長化・zone・address方針 | 論理構成図、方式設計 |
| 詳細設計 | interface・VLAN・route・parameter | 物理構成図、parameter sheet |
| review | 前提・例外・運用性を検証 | 指摘表とdecision log |
09:00 課題・schedule確認
10:00 要件会議 → 未決事項/決定事項
11:00 構成図・方式設計
13:30 詳細設計・parameter
15:30 peer review
17:00 test/移行調整・翌日計画
設計書・構成図をどう更新する?
設計書・構成図をどう更新する?では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 会議前に論点と選択肢を用意 | 決める事項を明確化 |
| 2 | 決定を構成図・設計書へ即日反映 | 議事録だけで終わらせない |
| 3 | review指摘を原因別に整理 | 設計不足・誤記・前提差 |
| 4 | testとoperationへtrace | 要件→設計→試験を結ぶ |
# 設計成果物の対応例
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承認
review指摘へどう対応する?
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 会議が多く設計時間がない | 論点未整理・役割不明 | agendaとownerを決める |
| reviewが手戻り | 前提・要件trace不足 | 設計冒頭に前提と対象外 |
| 図と表が不一致 | 更新元が複数 | 正本とversionを統一 |
| 求人が実質運用 | 設計成果物を作らない | 一日の時間配分と成果物を質問 |
設計職求人をどう見分ける?
設計職を目指すなら、図を描けるだけでなく、なぜその方式を選び、何を棄却し、試験でどう確かめるかを説明します。求人面接では『設計書を修正する』のか『要件から方式を決める』のかを分けて確認します。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ:会議の決定を設計・試験へtraceさせる
会議の決定を設計・試験へtraceさせることが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
