インフラエンジニアが設計構築へ転職するには？必要スキルと求人の見極め方

運用保守から設計構築へ進みたいとき、「もっと勉強する」だけでは準備を選びにくいものです。まず、次に自分が作りたい資料や、判断したい作業を一つ決めます。

私が多拠点の案件で経験した資料と設定の照合、試験の失敗を交えて説明します。大きな案件を一人で担当したという話ではありません。いまの作業に理由や確認結果を加え、次の工程へつなげる材料として読んでください。

設計構築の中で、次に担当したい工程を選ぶ

設計構築には、方式を選ぶ基本設計、値を具体化する詳細設計、設定と手順を作る構築、条件を確かめる試験、本番への導入があります。「設計構築をしたい」を、この中の作業へ分けます。

IP表の値を考えたいのか、構築手順を書きたいのか、試験項目を作りたいのか。次の担当が見えると、現在の経験から何を追加すればよいかを考えられます。

用語の補足：パラメータシートとconfigは何？

パラメータシートは、機器へ設定する値を整理した表です。configは機器の設定です。値を決める資料と、実機へ反映する設定を対応させて確認します。

パラメータシートは設定値の表、configは機器の設定、証跡は結果を確認できるログや画面です。表の各工程で、誰が何を決め、その後に何を渡すかを読むと、資料名が仕事へつながります。

運用でも変更の設計を考えることがあり、構築でも決定済みの値を投入する担当があります。職種名だけで区切らず、自分が考えた範囲と実行した範囲を見て、増やしたい担当を選びます。

多拠点の案件で必要だった、抜けを拾う仕組み

拠点が増えると、設定を作る量だけでなく、違いを拾う作業も増えました。

私は業界未経験から約1年のころ、金融系の支店ネットワークで初めてPLを担当しました。PLはプロジェクトリーダーで、案件の作業やメンバーの進め方をまとめる役割です。10支店規模から、多いものでは60支店の案件がありました。

支店数の多い案件では、configを作成したルーター・スイッチが約400台、検証ログが1,000ファイルを超えました。詳細設計・構築・試験はメンバーで分担しています。この台数を私一人で設計・作業したという意味ではありません。

難しかったのは、共通の設定と支店ごとの値、試験項目とログを対応させ、抜けを拾うことです。テンプレートが合っていても、支店固有の値まで正しいとは限りません。分担した結果をレビューで合わせる必要がありました。

既存の図と現地の構成が違うこともあり、現行設定、配線、変更履歴を照合しました。台数の多さだけより、どんな前提や差分を確かめたかが、その後にも使える経験になりました。

運用の手順に、理由と確認結果を添える

手順どおりの運用にも、次の工程につながる材料があります。変更前の状態、変える値、正常な結果、失敗時に戻す条件が、手順に書かれているかを読みます。

足りない確認があれば、追記案を作って担当者へ相談します。自分の権限を越えて本番の設定を変える必要はありません。まず、既存の作業をどう判断するかを整理するところから始められます。

表では、障害対応を不具合調査へ、手順に沿った変更を構築・移行手順へ対応させています。同じ作業でも、なぜその確認が必要かを説明できると、手順を作る側の考え方へ近づきます。

提案が採用されたら、抜けていた確認、追加した内容、レビュー担当、実施結果を残します。提案までなら提案と書きます。その範囲を正しく説明できる記録が、転職で伝える材料になります。

個人検証は、図・設定・試験を一組にする

個人検証では、コマンドを集める前に、何を実現したいかを書きます。例なら端末網172.27.81.0/24からアプリ網172.27.92.0/24のサーバーを使い、必要な通信だけを通す目的です。

その目的から、構成図、IP表、ルール、設定、手順、試験を一組にします。値を入れた後にPingが通っただけでは、許可対象外の通信を止める条件まで確かめたことにはなりません。

用語の補足：異常系試験って何？

故障や設定不足など、正常ではない条件でどう動くかを確認する試験です。通常時の成功だけでは分からない、切替や戻り経路も調べます。個人検証と、本番の計画された試験は範囲を分けます。

• 要件を一文で書き、許可する通信と対象外の通信を決める。
• 構成図、IP表、ルール、設定をそろえる。
• 設定投入前の確認と、投入後の正常判定を手順へ書く。
• 許可・拒否の両方を確認し、結果と時刻を残す。
• サービス停止や経路の抜けを一つずつ再現し、調査と復旧を記録する。

HTTPSの例はTCP/443ですが、選ぶツールがアプリやFWをどこまで再現できるかを確かめます。IP疎通だけの環境なら、その範囲の試験と明記します。再現していない機能の成功まで書かないためです。

失敗を試すなら、隔離した個人環境で一条件ずつ変え、調査と復旧を残します。面接には秘密情報を含まない図と値を使い、実務と区別して説明します。考えた理由と結果が対応すれば、小さな環境でも判断の流れを見せられます。

通常の疎通だけでは、待機側の誤りを見つけられなかった

通常時の通信が成功しても、待機側を使う条件はまだ確かめられていないことがあります。

支店更改では、待機側のIPsec設定で送信元・宛先を取り違えていたことがありました。主系を使う通常の疎通では表面化せず、回線・リンクを落として迂回させたときに通信が戻らず、調査で設定差に気づきました。

主系は普段使う側、待機系は故障時などに使う側です。IPsecはIP通信を保護する仕組みです。この経験では、普段の道での成功が、待機側の設定の正しさを証明していませんでした。

表のように、正常、片系障害、復旧、拒否を要件へ対応させます。要求が届くことと応答が戻ること、元へ戻した後の経路も分けて見ます。切替後に安定するまでの収束も、業務の許容条件と照合します。

実際の故障試験は、対象と判定条件を決めた計画で行います。学習では隔離した小さな環境から、通常は成功して別条件では失敗した理由を追う練習ができます。

求人では、作る資料とレビュー担当を聞く

求人に設計構築と書かれていたら、自分が作るものを聞きます。IP表の値を決めるのか、設定投入だけなのか、試験項目も考えるのか。同じ表現でも担当は違います。

希望する作業に合わせて、表の質問を選びます。全部を一度に聞くより、最初に任される資料と、そこで自分が決める範囲から話を具体化できます。

レビューと相談先も一緒に聞きます。構築補助から始めても、確認を受けて手順や試験を作る機会があるなら、次の担当へつながる可能性を考えられます。

本番の成功・中止を誰が判断するかも大切です。責任が大きいという説明だけで決めず、任される判断と支援を知ることで、今の準備で何を担当できるかを比較します。

職務経歴書は、自分がした作業を分けて書く

職務経歴書では、実行、作成、提案、判断を分けます。手順を改善したなら、何の確認を加え、誰がレビューし、どこまで実施したかを書くと、自分の役割が伝わります。

下の書き方は説明例です。設計値を別の担当が決めたなら、その事実も残します。チーム全体の機器台数を、自分一人で設計した台数と混ぜません。

説明用の書き方：
担当：既存拠点の設定変更と疎通試験
作成：変更前後の確認・切り戻しを含む作業手順
判断：影響する通信を整理し、追加の試験を提案
レビュー：設計値は設計担当が決定、手順はリーダー確認
結果：確認漏れを修正し、作業後の記録へ反映

提案しただけなら提案、採用されて実施したならその範囲を記載します。控えめに書くためではなく、次の職場でどの作業を任せられるかを判断してもらうためです。

CCNAの学習中でも、構成を選んだ理由、設定、期待した結果、実際の結果を一組で説明できます。いまの運用経験や個人検証を、こうした記録へ具体化することが、次の工程へ進む準備になります。

このテーマを続けて学ぶ

インフラエンジニアPM業務のルーティン。PMは長い目線では必須？→

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針