ネットワークエンジニア1〜3年目が身につけるべき技術ロードマップ

対象レベル: ネットワークエンジニア1〜3年目
読了時間: 約15分
この記事で分かること: 経験年数ごとに学ぶべき技術と、実務で目指すべき到達地点

ネットワークエンジニアとして働き始めたものの、次のような不安を感じていないでしょうか。

  • 監視や定型作業ばかりで、技術が身についている実感がない
  • CCNAは取得したが、その後に何を勉強すればよいか分からない
  • コマンドは入力できても、ネットワークの動作を説明できない
  • 障害が発生すると、詳しい人に判断を任せてしまう
  • 設計・構築案件へ進むために必要な能力が分からない

ネットワーク分野には、ルーティング、スイッチング、ファイアウォール、クラウド、セキュリティ、自動化など、数多くの学習テーマがあります。

そのため、興味のある技術を手当たり次第に学んでいると、知識は増えても「仕事で何ができるようになったのか」が見えにくくなります。

大切なのは、資格や製品名を集めることではありません。

ネットワークの動作を理解し、障害を切り分け、設計理由を説明できるようになること

本記事では、ネットワークエンジニア1〜3年目を対象に、身につけるべき技術を実務レベルのロードマップとして解説します。


目次

結論:1〜3年目で目指すべき成長ステップ

最初に、3年間の全体像を整理します。

経験年数成長テーマ目指す状態
1年目基礎を理解するネットワークがどのように通信しているか説明できる
2年目障害を切り分ける情報を集め、原因箇所を絞り込み、報告できる
3年目設計・構築へ進む要件から構成を考え、設計理由を説明できる

経験年数は、あくまで目安です。

1年目から構築を経験する人もいれば、3年間監視業務を担当する人もいます。そのため、「何年働いたか」ではなく、次のような実務能力を基準に現在地を判断してください。

Level 1:手順書作業者

  • 指示されたコマンドを実行できる
  • 手順書に沿って監視・設定変更ができる
  • 基本的なネットワーク用語を理解している

Level 2:自立型エンジニア

  • 障害発生時に必要な情報を収集できる
  • 正常時と異常時の違いを確認できる
  • 原因候補を整理してエスカレーションできる

Level 3:設計・構築エンジニア

  • 顧客要件からネットワーク構成を検討できる
  • 複数の構成案を比較できる
  • 採用した設計の理由を説明できる
  • テスト・移行・障害時の動作まで考えられる

目標は、単にLevel 3へ進むことではありません。

技術を使って問題を解決し、その判断を相手に説明できるエンジニアになることが重要です。


1年目:ネットワークの基礎を「説明できる」状態にする

1年目の最優先事項は、幅広い製品を触ることではなく、ネットワーク通信の基本的な仕組みを理解することです。

設定コマンドだけを覚えても、想定外の障害には対応できません。

「この設定を入れると、通信がどのように変化するのか」を説明できる状態を目指しましょう。

1. TCP/IPとOSI参照モデル

最初に理解したいのが、通信を階層に分けて考える方法です。

最低限、次の要素を説明できるようにします。

  • MACアドレスとIPアドレスの違い
  • EthernetフレームとIPパケットの関係
  • TCPとUDPの違い
  • ポート番号の役割
  • ARPによるアドレス解決
  • デフォルトゲートウェイの役割
  • DNSによる名前解決
  • DHCPによるIPアドレスの割り当て

OSI参照モデルは、7階層を暗記することが目的ではありません。

障害が発生したときに、「物理的な問題なのか」「IP設定の問題なのか」「アプリケーションの問題なのか」を分けて考えるために使います。

例えばWebサイトへ接続できない場合でも、原因はさまざまです。

  • LANケーブルが抜けている
  • VLANが間違っている
  • デフォルトゲートウェイへ到達できない
  • DNSで名前解決できない
  • TCP 443番ポートが遮断されている
  • Webサーバーが停止している

階層ごとに確認する習慣をつけることで、闇雲にコマンドを実行する状態から抜け出せます。

2. IPアドレスとサブネット

ネットワークエンジニアにとって、IPアドレス設計は避けて通れません。

次の計算を、ツールだけに頼らず理解しておきましょう。

  • ネットワークアドレス
  • ブロードキャストアドレス
  • 利用可能なホストアドレス
  • サブネットマスク
  • CIDR表記
  • 必要なホスト数に応じたプレフィックス
  • サブネット分割

ただし、計算速度を競う必要はありません。

実務では、「将来の増設を考慮したアドレス数になっているか」「拠点や用途ごとに管理しやすく分割されているか」といった設計判断の方が重要です。

3. VLANとスイッチング

企業ネットワークでは、部署や用途ごとにネットワークを分割するためにVLANが使われます。

1年目では、次の内容を理解します。

  • アクセスポートとトランクポート
  • IEEE 802.1Q
  • VLAN間ルーティング
  • MACアドレステーブル
  • ブロードキャストドメイン
  • STPの基本動作
  • EtherChannelなどのリンク集約

コマンドを入力できるだけでなく、端末からデフォルトゲートウェイまでフレームがどのように転送されるかを図にしてみましょう。

4. ルーティングの基礎

ルーティングでは、最初から複雑なBGP設計へ進む必要はありません。

まずは、次の順番で理解します。

  1. 直接接続ルート
  2. スタティックルート
  3. デフォルトルート
  4. OSPFなどの動的ルーティング
  5. 経路選択の考え方

特に重要なのがルーティングテーブルです。

通信できないときに、宛先ネットワークへの経路が存在するか、どのネクストホップへ転送されるかを確認できるようにします。

5. DNS・DHCP・NAT・NTP

ネットワーク機器だけを見ていると、周辺サービスの問題を見落とします。

次のサービスについて、役割と基本的な通信の流れを理解しましょう。

  • DNS:名前とIPアドレスの変換
  • DHCP:IPアドレスなどの自動配布
  • NAT・NAPT:アドレスやポート番号の変換
  • NTP:機器間の時刻同期
  • SNMP:機器情報の取得と監視
  • Syslog:ログの転送と集約

特に時刻同期は、障害調査で重要です。機器ごとの時刻がずれていると、複数ログの前後関係を正しく追えません。

6. Linuxの基本操作

ネットワークエンジニアであっても、Linuxの基本操作は必要です。

監視サーバー、DNSサーバー、Webサーバー、自動化環境など、多くのシステムでLinuxが使われるためです。

最初は、次の操作を身につけます。

  • ファイルやディレクトリの操作
  • 権限の確認
  • テキスト検索
  • プロセスの確認
  • ログの確認
  • IPアドレスとルーティングの確認
  • DNS名前解決の確認
  • ポートの待ち受け状況の確認
  • SSH接続

pingtracerouteだけでなく、ipssdigcurlなどを使って、通信状態を確認できるようにしましょう。

1年目の到達チェック

次の質問に、自分の言葉で回答できれば1年目の基礎は身についています。

  • 同一VLAN内の端末同士は、どのように通信するか
  • 異なるネットワークへ通信するとき、デフォルトゲートウェイは何をするか
  • DNS障害とネットワーク障害をどのように切り分けるか
  • スタティックルートと動的ルーティングは何が違うか
  • VLANを分ける目的は何か
  • pingが成功してもWebサイトへ接続できないのはなぜか

Ciscoの現行CCNA試験でも、ネットワーク基礎、ネットワークアクセス、IP接続、IPサービス、セキュリティ基礎、自動化とプログラマビリティーが対象になっています。資格取得の有無にかかわらず、1年目の基礎範囲を確認する指標として利用できます。(Cisco)

1年目に作りたい成果物

  • 小規模ネットワークの構成図
  • IPアドレス管理表
  • VLAN一覧表
  • 基本的なパラメーターシート
  • 通信確認手順書
  • ネットワーク用語を説明した自分用ノート
  • 検証環境の構築記録

成果物を作ることで、「勉強した」から「説明できる」へ一歩進めます。


2年目:障害を自力で切り分けられるようにする

2年目のテーマは、設定作業からトラブルシューティングへの移行です。

障害対応では、コマンドを多く知っている人よりも、必要な情報を順序立てて集められる人が評価されます。

1. 障害切り分けの基本手順

障害が発生したら、いきなり設定変更をしてはいけません。

基本的には、次の順序で整理します。

  1. 何が起きているかを確認する
  2. 影響範囲を確認する
  3. 発生時刻と直前の変更を確認する
  4. 正常な通信と異常な通信を比較する
  5. 通信経路を区間ごとに分ける
  6. 原因候補を挙げる
  7. 仮説を検証する
  8. 暫定対応と恒久対応を分ける

例えば、特定のサーバーへ接続できない場合は、次のように範囲を狭めます。

  • 全ユーザーに発生しているか
  • 特定拠点だけか
  • IPアドレスを指定すれば接続できるか
  • 同じVLAN内からは接続できるか
  • 特定ポートだけ接続できないか
  • 往路と復路の経路は同じか
  • 直前に設定変更や機器交換がなかったか

障害対応では、正解を最初から当てる必要はありません。

確認した事実と推測を分けて整理することが重要です。

2. パケットキャプチャー

パケットキャプチャーは、ネットワークの動作を目で確認できる強力な方法です。

Wiresharkなどを使って、次の通信を確認してみましょう。

  • ARP要求とARP応答
  • DHCPによるアドレス取得
  • DNS問い合わせと応答
  • TCPの3ウェイハンドシェイク
  • TCP再送
  • ICMP
  • TLS接続開始時の通信
  • 通信切断時のFINとRST

パケットを見るときは、すべての項目を読む必要はありません。

最初は次の4点を確認します。

  • 誰が送信したか
  • 誰が受信したか
  • どのプロトコルか
  • 期待する応答が返っているか

「ネットワーク機器の設定上は問題がない」場合でも、パケットを見ることで端末、サーバー、アプリケーション側の問題を発見できることがあります。

3. 冗長化技術

2年目では、正常時だけでなく障害時の動作を理解します。

学習対象の例は次のとおりです。

  • STPによるループ防止
  • リンクアグリゲーション
  • VRRPやHSRPなどのゲートウェイ冗長化
  • 動的ルーティングによる経路切り替え
  • ファイアウォールの冗長化
  • 回線冗長化
  • 負荷分散

冗長化構成では、「機器が2台あるから安全」とは限りません。

次の点まで確認する必要があります。

  • 何が故障したら切り替わるか
  • 切り替わりに何秒かかるか
  • 通信セッションは維持されるか
  • 障害をどのように検知するか
  • 復旧後に自動で元へ戻すか
  • 冗長化されていない共通部分はないか

4. ファイアウォールとVPN

ネットワークとセキュリティは、別々に考えられません。

2年目では、次の内容を学びます。

  • ステートフルインスペクション
  • セキュリティポリシー
  • 送信元・宛先NAT
  • オブジェクト管理
  • ログの読み方
  • IPsec VPN
  • IKE
  • リモートアクセスVPN
  • 認証と認可
  • 最小権限の考え方

ファイアウォール障害では、「許可ルールがあるか」だけで判断しないことが重要です。

ルーティング、NAT、戻り通信、セッション情報、暗号化条件なども確認します。

5. 監視とログ分析

監視ツールのアラートを確認するだけでなく、その値が何を意味するかを理解します。

  • CPU使用率
  • メモリー使用率
  • インターフェース使用率
  • エラー・破棄パケット
  • リンク状態
  • 遅延
  • パケットロス
  • ジッター
  • セッション数
  • ルート数
  • 機器温度
  • 電源状態

また、単発の値だけでなく、普段の状態との比較が重要です。

平常時の値を知らなければ、現在の値が異常かどうか判断できません。

6. 変更作業の品質を高める

2年目になると、設定変更を任される機会が増えます。

作業前には、最低限次の内容を整理します。

  • 変更目的
  • 対象機器
  • 影響範囲
  • 事前確認
  • 作業手順
  • 確認項目
  • 切り戻し条件
  • 切り戻し手順
  • 連絡先
  • 作業完了の判断基準

技術的に正しい設定でも、切り戻し方法がなければ安全な変更とはいえません。

2年目の到達チェック

次の行動ができれば、自立型エンジニアへ近づいています。

  • 障害の影響範囲を整理できる
  • 正常時と異常時の差分を確認できる
  • 通信経路を区間に分けて調査できる
  • ログとパケットから原因候補を絞れる
  • 確定した事実と推測を分けて報告できる
  • 設定変更の切り戻し条件を決められる
  • 原因不明の状態でも、顧客へ現在の状況を説明できる

2年目に作りたい成果物

  • 障害切り分けフロー
  • 障害報告書
  • 作業手順書
  • 切り戻し手順書
  • テスト項目書
  • 正常時のログ・パケット記録
  • 検証結果報告書
  • 課題管理表

この段階からは、技術だけでなく報告能力も評価されます。

例えば、原因がまだ確定していなくても、次のように整理して伝えられます。

10時15分から東京拠点の一部ユーザーで業務システムへ接続できない状態が発生しています。現在、拠点ルーターまでは正常に通信できることを確認済みです。WAN回線または接続先側を中心に調査しており、次回は10時45分を目安に状況を報告します。

このように、影響、確認済み事項、調査中の範囲、次回報告時刻を伝えることで、原因確定前でも相手の不安を減らせます。


3年目:設計・構築・クラウド・自動化へ広げる

3年目のテーマは、「決められた構成を作る」から「要件に合う構成を考える」への移行です。

設計では、唯一の正解が存在しないことも少なくありません。

コスト、性能、可用性、セキュリティ、運用負荷などを比較し、適切な構成を選ぶ必要があります。

1. 要件をネットワーク設計へ変換する

設計を始める前に、顧客や利用部門の要望を整理します。

確認する項目の例は次のとおりです。

  • 利用者数
  • 拠点数
  • 端末やサーバーの台数
  • 利用するアプリケーション
  • 必要な通信先とポート
  • 通信量
  • 許容停止時間
  • セキュリティ要件
  • 運用時間
  • 監視方法
  • 将来の増設計画
  • 予算
  • 移行可能な時間帯

「止まらないネットワークにしてほしい」という要望だけでは、設計できません。

どの程度の停止時間まで許容できるのか、どこまで冗長化するのか、障害時に誰が対応するのかを具体化します。

2. 基本設計と詳細設計

基本設計では、システム全体の方針を決めます。

  • 物理構成
  • 論理構成
  • IPアドレス設計
  • VLAN設計
  • ルーティング方式
  • 冗長化方式
  • セキュリティ方針
  • 監視方針
  • バックアップ方針
  • 命名規則

詳細設計では、基本設計を実際の設定に落とし込みます。

  • インターフェース設定
  • VLAN ID
  • IPアドレス
  • ルーティング設定
  • フィルタリングルール
  • NAT設定
  • VPNパラメーター
  • SNMP設定
  • Syslog設定
  • NTP設定
  • 管理者アカウント
  • タイムアウト値

設計書では、設定値だけでなく「なぜその値にしたのか」を残すことが重要です。

3. テスト設計と移行設計

構築が完了しても、通信できることを確認するだけでは不十分です。

テストでは、次の観点を確認します。

  • 正常系の通信
  • 異常系の通信
  • 冗長切り替え
  • 経路切り替え
  • フィルタリング
  • NAT
  • VPN
  • 監視
  • ログ出力
  • バックアップ
  • 性能
  • 復旧

移行設計では、作業そのものだけでなく、失敗した場合を考えます。

  • 切り替え方法
  • サービス停止時間
  • 旧環境との並行稼働
  • 切り戻し条件
  • 切り戻しに必要な時間
  • データや設定のバックアップ
  • 関係者への連絡方法
  • 移行後の監視体制

4. クラウドネットワーク

3年目までには、オンプレミスだけでなく、AWSやAzureなどのクラウドネットワークにも触れておきたいところです。

最初に学ぶ内容は次のとおりです。

  • 仮想ネットワーク
  • サブネット
  • ルートテーブル
  • セキュリティグループ
  • ネットワークACL
  • インターネット接続
  • NAT
  • ロードバランサー
  • DNS
  • VPN接続
  • 専用線接続
  • ハイブリッドネットワーク
  • クラウド上の監視とログ

クラウドでは、物理的なケーブルやポートが見えにくくなりますが、IPアドレス、ルーティング、DNS、ファイアウォールといった基本原理は変わりません。

MicrosoftのAzure Network Engineer向け領域でも、コアネットワーク、ハイブリッド接続、アプリケーション配信、プライベートアクセス、ネットワークセキュリティが主要範囲として整理されています。クラウド製品の操作だけでなく、従来のネットワーク基礎と組み合わせて理解する必要があります。(Microsoft Learn)

5. IPv6

IPv4だけでなく、IPv6の基本も学んでおきましょう。

  • IPv6アドレスの表記
  • プレフィックス
  • リンクローカルアドレス
  • グローバルユニキャストアドレス
  • マルチキャスト
  • Neighbor Discovery
  • SLAAC
  • DHCPv6
  • IPv4とのデュアルスタック

RFCは最初から全文を暗記するものではありません。分からない仕様を一次情報で確認する習慣をつけることが大切です。IPv6の基本仕様はRFC 8200として公開され、RFC Editorはインターネット標準に関する公式な情報源を提供しています。(RFC Editor)

6. Python・Ansible・APIによる自動化

複数機器の設定確認やバックアップを毎回手作業で行うと、時間がかかるだけでなく、確認漏れや入力ミスが発生します。

3年目では、小さな定型作業から自動化を始めます。

Pythonで学ぶ内容

  • 変数
  • 条件分岐
  • 繰り返し
  • 関数
  • ファイル操作
  • CSV・JSON
  • 例外処理
  • HTTPリクエスト
  • 正規表現

Ansibleで学ぶ内容

  • インベントリー
  • Playbook
  • YAML
  • 変数
  • テンプレート
  • ネットワーク機器への接続
  • showコマンドの一括実行
  • コンフィグバックアップ
  • 設定投入
  • 実行結果の保存

Ansibleの公式ドキュメントでも、ネットワーク自動化の入門として、コマンド、Playbook、インベントリーを使った管理方法が案内されています。まずは設定変更の全自動化ではなく、情報取得やバックアップなど、失敗時の影響が小さい作業から始めましょう。(Ansible Docs)

APIで学ぶ内容

  • REST API
  • HTTPメソッド
  • ステータスコード
  • JSON
  • 認証
  • APIドキュメントの読み方
  • Postmanなどを使った動作確認

Gitで学ぶ内容

  • リポジトリー
  • commit
  • branch
  • diff
  • merge
  • 設定ファイルの変更履歴
  • 自動化コードのレビュー

自動化の目的は、エンジニアを不要にすることではありません。

人が判断すべき作業に時間を使うため、定型作業を機械に任せること

これがネットワーク自動化の基本的な考え方です。

7. 技術を顧客へ説明する能力

3年目になると、技術的に正しいだけでは不十分です。

顧客や営業担当者へ、技術を次の言葉へ変換して説明する必要があります。

技術的な内容顧客に伝える価値
回線冗長化回線障害時の業務停止リスクを下げる
ファイアウォール不要な通信を遮断し、不正アクセスの可能性を減らす
監視システム障害を早期に検知し、影響の拡大を防ぐ
自動化作業時間と設定ミスを減らす
帯域増強通信遅延を改善し、業務を安定させる
クラウド接続拠点や在宅環境からクラウドサービスを安全に利用する

専門用語を使わないことが、分かりやすい説明ではありません。

専門用語を使う場合でも、「それが相手の業務にどのような影響を与えるか」まで説明することが重要です。

8. 技術英語

ネットワーク分野では、海外ベンダーの公式資料、エラーメッセージ、RFC、サポート情報など、英語の一次情報に触れる機会があります。

最初から英会話を完璧にする必要はありません。

次の順番で実務に取り入れましょう。

  1. エラーメッセージを英語のまま検索する
  2. 公式ドキュメントの該当箇所を読む
  3. 英語の検索キーワードを作る
  4. ベンダーへ問い合わせ文を書く
  5. 英語の会議で確認質問をする
  6. 構成や障害状況を英語で説明する

例えば、VPNが確立しない場合は、次のような単語を組み合わせて検索します。

  • tunnel not established
  • authentication failed
  • proposal mismatch
  • negotiation timeout
  • peer not responding
  • phase 1 failure
  • phase 2 failure

英語学習を独立した勉強にするのではなく、日々の障害調査と組み合わせることが継続のコツです。

3年目の到達チェック

次の項目に対応できれば、設計・構築エンジニアとしての土台ができています。

  • 顧客要望を技術要件へ変換できる
  • 複数の構成案を比較できる
  • 設計理由をコスト・性能・可用性・運用の観点から説明できる
  • 正常系と異常系のテストを設計できる
  • 移行と切り戻しを計画できる
  • オンプレミスとクラウドの通信経路を説明できる
  • 定型的な確認作業を自動化できる
  • 英語の公式資料から必要な情報を探せる

3年目に作りたい成果物

  • 基本設計書
  • 詳細設計書
  • ネットワーク構成図
  • IPアドレス設計書
  • 冗長化設計書
  • テスト計画書
  • 移行計画書
  • 自動化スクリプト
  • Ansible Playbook
  • 顧客向け構成説明資料
  • クラウド接続の検証記録

資格はロードマップの確認手段として使う

資格取得は、体系的に知識を学ぶ方法として有効です。

一方で、資格を取得しただけでは、設計や障害対応ができることの証明にはなりません。

資格学習と並行して、次の3つを実施しましょう。

1. 実際に構成する

仮想環境やクラウド環境を利用して、自分でネットワークを作ります。

設定例をコピーするだけでなく、一度構成を壊し、障害を発生させてから復旧させることが重要です。

2. 動作を説明する

作成した構成について、次の内容を説明できるようにします。

  • なぜこの構成にしたのか
  • パケットはどの経路を通るか
  • 機器が故障するとどうなるか
  • どのように障害を検知するか
  • 代替案には何があるか

3. 成果物として残す

構成図、設定、検証結果、失敗した内容、改善点を記録します。

職務経歴書に「CCNA取得」と書くだけでなく、面談で具体的な検証内容を説明できる状態を目指しましょう。


何から勉強すればよいか迷ったときの優先順位

学習テーマに迷ったら、次の順番で判断してください。

優先順位1:現在の業務で使う技術

仕事で触れている機器、プロトコル、監視ツールを優先します。

実務と学習を結びつけると、知識をすぐに確認できるためです。

優先順位2:現在の業務を理解するための基礎

監視対象のアラートやログについて、なぜ発生するのかを調べます。

「対応手順」だけでなく、「検知の仕組み」まで理解しましょう。

優先順位3:次の工程で必要な技術

運用担当であれば、構築や障害対応で使う技術を学びます。

構築担当であれば、設計書、要件整理、テスト設計を学びます。

優先順位4:クラウド・セキュリティ・自動化

ネットワーク基礎を固めたうえで、隣接領域へ広げます。

基礎を飛ばして製品操作だけを覚えると、想定外の問題に対応しにくくなります。


1〜3年目共通の勉強方法

検証前に予想を書く

コマンドを実行する前に、どのような結果になるか予想します。

予想と実際の結果が違った部分に、理解を深める材料があります。

正常時の状態を確認する

障害が起きてから初めてログを見るのではなく、正常時のルーティングテーブル、ARPテーブル、インターフェース状態、パケットを確認しておきます。

構成図を自分で描く

既存の構成図を見るだけでなく、実際の設定や配線から自分で構成を描いてみます。

分からない接続や役割が明確になります。

学んだ内容を他人に説明する

技術を説明しようとすると、理解が曖昧な部分に気づきます。

次の3段階で説明してみましょう。

  1. 同じチームのエンジニアに説明する
  2. 新人エンジニアに説明する
  3. 技術に詳しくない顧客へ説明する

失敗を記録する

成功した設定だけでなく、失敗した内容を記録します。

  • 何をしようとしたか
  • どのような問題が起きたか
  • 原因は何だったか
  • どのように確認したか
  • 次回は何を確認するか

失敗の記録は、将来の障害対応や設計レビューで役立つ自分だけのナレッジになります。


90日間で取り組む学習プラン

現在、監視や定型作業が中心であれば、次の90日プランから始めてみてください。

1〜30日目:通信の基礎を説明する

学習テーマ:

  • TCP/IP
  • ARP
  • DNS
  • DHCP
  • VLAN
  • スタティックルーティング
  • NAT

成果物:

  • 小規模ネットワーク構成図
  • 通信経路の説明資料
  • IPアドレス管理表

31〜60日目:障害を再現して切り分ける

学習テーマ:

  • ping
  • traceroute
  • nslookupまたはdig
  • ルーティングテーブル
  • ログ
  • パケットキャプチャー
  • ACL・ファイアウォール

検証する障害例:

  • デフォルトゲートウェイの設定ミス
  • VLANの設定ミス
  • ルート不足
  • DNS設定ミス
  • ファイアウォールによる通信遮断
  • TCPポートの待ち受け停止

成果物:

  • 障害切り分けフロー
  • 検証結果報告書
  • 障害報告書

61〜90日目:設計と自動化へ進む

学習テーマ:

  • IPアドレス設計
  • 冗長化
  • 監視設計
  • テスト設計
  • PythonまたはAnsible
  • Git

成果物:

  • 基本設計書の簡易版
  • テスト項目書
  • コンフィグ取得の自動化
  • 設計内容を説明する資料

90日間ですべてを習得する必要はありません。

重要なのは、知識を増やすだけでなく、毎月1つ以上の成果物を完成させることです。


まとめ:技術を知るだけでなく、使って説明できるようになる

ネットワークエンジニア1〜3年目で身につけたい能力は、次のように整理できます。

1年目

ネットワーク通信の基礎を理解し、自分の言葉で説明できるようにする。

2年目

障害発生時に情報を集め、影響範囲と原因箇所を切り分けられるようにする。

3年目

顧客要件から構成を考え、設計・テスト・移行まで計画できるようにする。さらに、クラウド、セキュリティ、自動化、英語の一次情報へ学習範囲を広げる。

ネットワークエンジニアの市場価値は、知っている製品やコマンドの数だけでは決まりません。

技術を使って問題を解決し、判断理由を説明し、その成果を証明できること

この状態を目指して、現在の業務に近い技術から一つずつ身につけていきましょう。

まずは、自分が現在どのレベルにいるかを確認し、3か月後までに作成する成果物を1つ決めることから始めてください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次