ネットワーク構築から設計へ進むには？必要スキル・設計書と経験の積み方

「ネットワークの構築は経験しているけれど、設計を任されるには何が足りないのだろう」。設定や試験には慣れていても、設計書を前にすると、どこから考えればよいか迷うことがありますよね。

構築から設計へ進む準備では、設定できることに加えて、要件に対してその構成を選ぶ理由を説明できることが大切です。機器やプロトコルの知識を、利用者の業務、停止の影響、運用方法、費用や期間の制約と結びつけて考えます。

この記事では、ネットワーク構築経験者に向けて、設計の仕事、基本設計と詳細設計、今の業務で積める経験、求人の確認点を整理します。年収相場の比較は、ネットワーク構築の年収と上流工程の記事で扱い、ここでは設計へ進む準備に集中します。

ネットワーク設計では、何を決める？

ネットワーク設計では、利用者が必要とする通信を、与えられた条件の中で実現する方法を考えます。何と何をつなぐかだけでなく、誰が使い、どの程度の停止が困り、どう運用するかも判断に関わります。

たとえば、拠点を増やす案件で「回線を追加する」だけでは、方針は決まりません。利用する業務、既存の接続先、停止できる時間、回線の手配期間、運用担当者が扱える構成などを確認する必要があります。

構築は設計で決めたことを形にする工程ですが、構築中に設計上の疑問や不足が見つかることもあります。そこで理由を確認し、問題を言葉にできた経験は、設計への接点になります。

設計者がすべてを一人で決めるわけではありません。顧客や利用部門、運用担当、別システムの担当者と前提をそろえ、権限のある人に判断を求めます。「わからない条件を確認できること」も必要な仕事です。

基本設計と詳細設計の違いを、成果物から理解する

工程名や文書の分け方は案件によって異なります。一般的な整理として、基本設計では構成や方式の方針を、詳細設計では実装するための値や具体的な設定を扱います。ただし、名前だけで担当経験を判断しないようにしましょう。

パラメータシートを作った経験があれば、値を転記したのか、方針に基づいて値を決めたのかを分けて振り返ります。どちらも仕事ですが、設計として説明できる判断の範囲は異なります。

既存の設計書を参考にする場合も、文章を置き換えるだけではなく、今回も同じ前提が成り立つかを確認します。機器、拠点数、利用者、接続先、保守体制が変わると、以前の方針をそのまま使えない場合があります。

応募先が「基本設計経験」を求めているなら、どの成果物と判断を想定しているか確認しましょう。自分の案件での工程名だけを伝えるより、作ったものと決めた範囲を説明すると会話が具体的になります。

設計の出発点は、要望を確認できる条件に変えること

「止まらないネットワークにしたい」「快適に使いたい」という要望は、そのままでは確認方法が決まりません。どの業務を、どの場所で、いつ使うのか。停止や遅延が起きた場合に何が困るのかを聞いて、設計に使える条件へ整理します。

利用する通信と、影響を受ける業務を確認する

まず、利用者と接続先の関係を整理します。社内端末、外部サービス、拠点間の通信など、必要な経路を把握します。実際の通信要件は、利用部門やアプリケーション担当と確認し、推測だけで決めないようにします。

通信量を考えるときも、普段の状況だけでなく、集中する時間や今後の変更予定を確認します。数値が未確認なら、仮定した内容と、いつ誰に確認するかを残しておくと、後から見直しやすくなります。

止められる時間と、復旧の考え方を確認する

すべてを同じ強さで冗長化する前に、どの障害を想定し、どの範囲まで継続させたいかを考えます。機器が二台あることだけでは、電源、回線、接続先などを含めた停止への備えは説明できません。

また、切り替えが自動でも、利用者への影響や確認方法を試験する必要があります。構成図上でつながっていることと、障害時に必要な通信が続くことを区別して考えましょう。

費用・期間・運用の制約を残す

技術的に実現できても、手配期間や予算、運用体制に合わなければ採用できないことがあります。比較した案と選ばなかった理由を残すと、後で前提が変わったときにも説明しやすくなります。

設計資料の参考として、CiscoのDesign Zoneにはキャンパス・拠点向けの設計資料が整理されています。自分の要件と照らして読むための資料であり、掲載構成をすべての案件へそのまま当てはめるものではありません。参考：Cisco「Design Zone – Campus and Branch」

設定の意味を説明する練習から始める

今の構築作業で、設定値を一つ選び、「何のために必要なのか」を説明してみてください。コマンドの意味に加えて、通信や運用のどの条件に対応しているかまで確認します。

たとえばVLANを分ける設定なら、分ける対象、通信を許可する範囲、アドレスの割り当て、障害時の影響を確認します。単に数を増やせばよいのではなく、何を分け、どこでつなぐ方針なのかを読み取ります。

経路の設定なら、通常時にどちらへ流れ、接続が失われた場合にどう変わるかを説明します。自分の知識だけでは確定できない機器の挙動は、対象機種・バージョンの資料や検証結果で確認してください。

答えを教わっただけなら、それは理解を深めた経験です。自分で比較案を作った、影響を調べた、レビューへ参加した場合は、その範囲を記録します。学んだことと、自分が判断したことを分ける習慣をつけましょう。

レビューで確認するのは、誤字だけではない

設計書のレビューでは、要件と構成、設定、試験、運用がつながっているかを確認します。値の誤りを探すことに加え、前提が不足していないか、想定していない障害や作業がないかを見ます。

レビューを受ける側では、完成したつもりの文書だけでなく、判断に迷っている点を先に示します。「どちらがよいでしょうか」だけより、「案Aは費用を抑えられるが、案Bはこの停止への備えが違う」と前提をそろえると相談しやすくなります。

指摘を受けたら、修正した箇所と理由を残しましょう。関連する図、設定値、試験項目へ変更が波及していないかも確認します。本文だけ直して図が古いまま、といったずれを防ぐことが大切です。

設計の経験が少ない段階では、担当者に確認観点を教わり、一部の資料からレビューへ参加する方法があります。最初から案件全体を任せてもらうことだけを目標にしなくても構いません。

移行・試験・運用まで考えると、構築経験が活きる

構築経験者の強みは、実際に作業するときの制約や、確認が難しかった場面を知っていることです。設計では、その経験を切り替え手順や試験の方針へつなげられます。

たとえば、設定を変更する順番によって一時的に通信が切れる、作業用の接続経路を失う、戻すための情報が足りない。こうした場面を経験していれば、移行時に先に確認したい条件を説明できます。

試験では「通信できた」で終わらず、誰が何を確認し、どの結果なら完了と判断するかを整理します。通常時の通信、切り替え時の影響、運用で必要な記録など、目的に対応した確認項目を作ります。

ただし、網羅的に項目を増やすだけでは、実施時間や確認体制に収まらないこともあります。重要な条件と対象範囲を合意し、実施しない部分や別の確認方法を使う部分も明確にしましょう。

運用への引き継ぎでは、構成や設定に加え、障害時にどこを見るか、誰に連絡するかも考えます。自分が構築後の運用を経験しているなら、設計へ戻せる気づきを一つ整理してみてください。

設計経験がないとき、今の現場で何から担当する？

上司や設計担当に、案件全体ではなく範囲を絞って相談します。既存構成の整理、試験項目の作成、設定変更の影響調査など、現在の担当からつながる仕事を選ぶと相談が具体的になります。

任せてもらう際は、どの資料をいつまでに作り、誰の確認を受けるかを決めます。「設計をやりたい」だけでなく、「次の変更で試験項目の案を作りたい」と伝えると、必要な支援も相談しやすくなります。

実務で機会がない場合は、架空の拠点追加などを題材に、要件、構成、設定方針、試験を一つの資料にまとめる学習もできます。その場合は、個人検証であることを明確にし、実務の設計経験と混ぜないでください。

運用経験から順に範囲を広げる考え方は、運用から構築へのキャリアアップ記事でも紹介しています。

架空の拠点追加で、判断の流れをまとめてみる

個人学習の題材として、既存の本社に小規模な拠点を追加する場面を考えてみます。最初に機器を選ぶのではなく、利用者、必要な接続先、業務の時間帯、停止時の影響、運用する人を仮定します。数値や条件は学習用に置いたものだと明記します。

次に、接続の候補を比較し、構成案に理由を添えます。一案だけ作って正解とするのではなく、費用、障害時の影響、変更のしやすさ、運用の負担など、何を優先したかを書きます。調べないとわからない部分は、未確認事項として残して構いません。

最後に、どの試験で要件を確かめるかを対応させます。必要な通信が通ることに加え、想定した経路の停止時や、設定を戻した後に何を確認するかを考えます。すべてを実機で試せない場合は、資料で確認したことと実際に検証したことを分けて記録します。

この資料は、実務の設計書の代わりではありません。要件から確認方法までをつなげて考えた学習の成果物です。面接で使う場合は、その位置づけと未検証の範囲を先に説明してください。

また、自分の職場の資料をそのまま題材にする必要はありません。公開できない構成やアドレスを含めず、架空の条件から作ることで、判断の考え方に絞って説明できます。

レビューを頼める相手がいるなら、「構成が正しいか」だけでなく、「前提として足りない質問は何か」を聞いてみましょう。答えを直すだけではなく、確認すべき条件が増えることも設計の学習になります。

設計の内容を説明するときは、聞き手に合わせることも大切です。利用部門には業務への影響や停止時間を、構築担当には設定と確認方法を、運用担当には障害時に見る場所を整理します。同じ構成でも、相手が判断するために必要な情報は異なります。

説明して質問を受けたら、資料の前提が足りなかったのか、相手の条件が新しくわかったのかを分けて振り返ります。その確認を次の資料へ反映することも、設計経験の一部です。

設計求人と年収を確認するときのポイント

求人票で設計経験が求められていたら、対象となるネットワーク、成果物、判断範囲、レビュー体制を確認します。「設計から構築まで」という説明だけでは、入社直後にどこを任されるかはわかりません。

「最初に担当する設計書は何ですか」「顧客への確認は誰が行いますか」「設計のレビュー担当はいますか」と聞いてみましょう。経験者の補助から始められるのか、主担当として判断する前提なのかで、必要な準備が変わります。

職務経歴書では、作成した資料と自分の判断を具体化します。詳しい構成は、インフラエンジニアの職務経歴書の記事を参考にしてください。設計の主担当ではなかった場合は、補助した範囲を明記します。

年収の整理には、whoamiの年収診断も利用できます。診断モデルには、従業員1,000人以上で＋13.1％、東京都で＋10.6％、クラウド実務経験ありで＋10.0％という補正設定があります。モデル上の条件であり、設計を一部担当しただけで特定の金額になるという意味ではありません。

面接では担当範囲と希望を合わせて伝えましょう。回答を組み立てる際は、経験者向けの面接対策も参考になります。工程名だけでなく、応募先が任せたい仕事との接点を説明します。

ネットワーク設計を目指す人のよくある質問

構築を何年経験すれば、設計に進めますか？

一律の年数では決められません。担当した設定や試験を、要件や構成の理由と結びつけて説明できるか、設計資料の作成と確認にどこまで関わったかを整理しましょう。

CCNPなどの資格は必須ですか？

応募先の要件によります。資格学習は技術の整理に役立ちますが、要件確認や設計判断の実務経験とは別です。必須資格と歓迎資格を分けて確認します。

パラメータシートを作れば設計経験になりますか？

担当内容によります。決められた値の転記か、方針に基づく値の検討かを分けて説明します。資料名だけでなく、どの判断を行ったかが大切です。

顧客との打ち合わせが苦手でも目指せますか？

目指せます。最初は確認事項と未決事項を整理し、経験者と同席して進める方法があります。入社直後にどこまで対外調整を担当するかは求人で確認しましょう。

クラウドが増えるとネットワーク設計は不要ですか？

接続先や構成が変わっても、必要な通信、アクセス範囲、接続の制約を考える仕事はあります。物理ネットワークの経験と、応募先のクラウド接続の要件との接点を確認してください。

今扱っている設定を、一つだけ理由まで説明してみよう

構築から設計へ進む準備は、すべての方式を暗記することから始めなくても構いません。今の設定や試験を一つ選び、どの要件に対応し、なぜ必要なのかを確認してみてください。

要件、比較案、選んだ理由、試験で確かめることをつなげて説明する。その経験を少しずつ増やすことが、設計の仕事へ近づく具体的な一歩になります。