インフラエンジニアの運用から構築へ｜キャリアアップの実践法

運用の仕事は、担当者が替わっても回るように作られています。手順どおりに対応して、障害を防いで、次の人へ引き継ぐ。ちゃんと頑張っているのに、任される仕事も評価も変わらない。この仕組みの中では、自分の工夫が見えにくいんです。

「このままずっと運用なのかな」と感じても、能力が足りないと決めつけないでください。構築の担当者が見たいのは、設定を考え、資料にして、確かめた実績です。その材料は、いま使っている監視設定や復旧手順書にもあります。

まずは、いまの業務で残せる実績を作る。次に、それを持って社内の構築案件に入れないか相談する。この記事では、この順番で話します。転職を考えるときも、社内でどこまでできるかを確かめておくと比べやすくなります。

運用から抜けられない本当の理由

手順が整っているほど、自分の工夫が見えにくくなる

アラートを見て、手順書を開いて、担当部署へ連絡する。誰が担当しても同じように対応できるのは、運用の強みです。ただ、その中で気づいたことや工夫したことは、普通に日報を書くだけでは残りません。

たとえば、いつもと違うログに気づいて確認する順番を変えたとしても、記録が「監視・一次対応」だけなら、読み手には分からないままです。構築の担当者も、それだけでは「この人に何を任せられるか」を判断できません。

仕事を増やす前に、すでに自分が判断している部分を見直してみてください。設定の変更案や、変更後の確認項目を考えているなら、そこは書き残せる実績です。

「何も起きなかった」の裏にある仕事を残す

ディスクの空き容量が減っていることに気づき、担当者へ連絡して障害を防いだ。でも、日報には「容量確認、異常なし」。これだと、何もしなくても問題が起きなかったように見えてしまいます。

「ログの増え方を確認し、保存期間の見直しを提案した」まで書くと、伝わる内容が変わります。使用量の推移と変更案、確認した結果も添えておきましょう。

次の更改では何を見直すか。そうした話にも、この判断の記録を使えます。

夜勤手当は時間帯への対価であり、判断への対価ではない

夜勤を増やせば、手当を含む給与は変わります。一方で、設定や方式を決める仕事を任されるかは別の話です。

構築へ移る話が出たら、「夜勤が減った後の給与」と「実際に任される作業」を両方確認してください。パラメータシートを作れるのか。試験まで担当できるのか。

監視・運用と構築では、年収の推定基準額も変わる

工程が変わると、年収の目安にも差が出ます。whoamiが工程別に整理した、30代の推定基準額はこちらです。勤務地・企業規模による補正をかける前の金額です。

工程	30代の推定基準額
監視・運用	441万円
構築（ネットワーク）	519万円
構築（サーバ）	520万円
設計・上流	594万円

監視・運用と比べると、ネットワーク構築は＋78万円、サーバ構築は＋79万円。ネットワーク構築から設計・上流にも、＋75万円の差があります。工程ごとの推定値なので、異動や転職でそのままこの金額が増えるわけではありません。次に担当する仕事を考えるための目安にしてください。

出典：doda「平均年収ランキング2025」の職種別×年代別データを、whoamiが5つの工程区分へ再編したもの。差額は上表から算出しています。

工程ごとの年収差はこちらで詳しく整理しています。

構築の現場は、何を「実績」と見ているか

パラメータシート・構成図・台帳で、設定とつながりを見せる

構築の仕事では、機器を操作する前に「どんな設定を入れるか」「どこにつなぐか」を資料にします。まず知っておきたいのは、次の成果物です。

成果物	書く内容の例
パラメータシート	スイッチのVLAN・ポート設定、サーバのIPアドレス・DNS・NTP・マウント設定
構成図	機器間の接続、接続ポート、ネットワークの区分、通信経路、冗長化の関係
構成管理台帳	機器名、設置場所、型番、OS・ファームウェア、用途、管理担当、更新日

台帳と実機のOSバージョンを照らし合わせる作業なら、運用でも出番があります。

違いを見つけたら、「違っていました」で終わらせず、何を見て確認したか、いつ確認したかを残して更新する。ここまでできると、更改前の現状調査を相談するときにも話が通じます。資料を写した部分と、自分で調べて直した部分は分けておきましょう。

単体試験仕様書・切替手順書には、確かめ方と戻し方を書く

単体試験仕様書は、「何を操作して、どうなれば合格か」を決める資料です。サーバなら時刻同期や名前解決、サービスの起動状態。スイッチならポート設定やVLANの所属を確認します。期待する結果と、実際の結果を並べて残します。

切替手順書では、作業前の確認から変更の順番、正常に動いているかの確認、中止する条件、元に戻す手順まで考えます。たとえば「疎通確認」だけでは、どこからどこへ、何が通ればよいのか分かりません。送信元・宛先、確認する通信、期待する応答まで書きます。

運用で「この手順だと、復旧したか判断できない」と困った経験はありませんか。その気づきは、試験項目を考えるときに使えます。自分が迷ったところを、次の人が迷わず確認できる形に直す。ここにも構築につながる仕事があります。

「触ったことがある」から「作って、レビューを受けて、確かめた」へ

「Linuxを使っていました」「Cisco機器を触れます」。これだけだと、ログを見ていたのか、設定案を作っていたのかが分かりません。

たとえば、「パラメータシートの変更案を作成。構築担当者のレビューを受け、検証環境で名前解決と時刻同期を確認」と書いてみます。

運用での改善は、そのまま新規構築の担当歴になるわけではありません。ただ、設定の理由を説明し、資料を作って検証した経験は伝えられます。

いまの運用業務の中で作れる実績

ここからは、業務中に作れる実績を挙げます。担当範囲や作業時間は、責任者と相談して決めてください。本番の設定を変えるときは、現場の変更管理に沿って承認を受けます。変更権限がなくても、記録の整理や改訂案づくりから始められます。

監視閾値と通知条件を見直す

Zabbixなどから、同じ通知が何度も届いていませんか。まずは、対象ホスト、監視項目、発生した時間帯で履歴を整理してみてください。

CPU使用率が一時的に跳ねただけなのか、負荷が続いているのか。アラート履歴と性能グラフを並べると、調べるべき点が見えてきます。

そのうえで、閾値、条件が続く時間、復旧条件、通知先の見直し案を作ります。通知が減っただけでは、見直しがうまくいったとは言えません。必要な異常を拾えるか、検証環境で通知を試し、変更後の記録でも確かめます。

残しておくもの： 対象項目、変更前後の条件、変えた理由、期待する通知、試験結果、変更後の確認結果。不要な通知に重要な異常が埋もれる問題は、GoogleのSRE文献でも扱われています。

復旧手順書に「どう判断するか」を足す

「サービスを再起動する」。手順書がここで終わっていたら、初めて担当する人は困ります。どんな状態なら再起動してよいのか。実行した後、何を見れば復旧と判断できるのか。この抜けを埋めていきます。

Linuxサーバなら、実行前に見るサービス状態や関連ログを書きます。再起動する条件と、自分では進めず上位担当者へ連絡する条件も分けてください。実行後は、プロセスが起動したかに加えて、対象システムが正常に使えるかまで確認します。

コマンド、期待する結果、結果が違った場合の連絡先を足したら、別の担当者にも読んでもらいましょう。判断に迷う箇所を聞いて直します。動作確認は、承認された検証環境で行います。

残しておくもの： 元の手順で足りなかった箇所、追加した判断条件、改訂履歴、レビューの指摘、確認結果。まだ試していない項目は「未検証」と書きます。切替手順書でも必要になる、作業の順番と異常時の分岐を考える経験です。

障害を直した後に、原因と再発防止まで調べる

「容量が足りなかったので、ログを削除して復旧」。ここで報告を終えると、同じことが起きる理由が残ります。何が容量を使ったのか、もう少し追ってみましょう。

使用量の推移、ログが増えた時刻、ログローテーションの設定、関連ジョブの実行結果を並べます。設定どおりに古いログが消えていたのか。特定の処理で急に増えたのか。

原因が分かったら、対策と、その効果を確かめる方法まで考えます。保存期間を短くするなら、調査や監査に必要なログが残るかも確認が必要です。容量を追加する案なら、その後も同じ増え方をしたときにどう監視するかを添えます。

残しておくもの： 発生から復旧までの時系列、根拠となるログ、原因の仮説、調べた結果、恒久対策案、担当者の判断。事実と仮説は分けて書きます。提案までなのか、実施後の効果まで確かめたのかも書いておくと、自分が担当した範囲が伝わります。

構成情報の収集をスクリプト化し、台帳と照らし合わせる

ホスト名やOS情報を毎回手で確認しているなら、シェル、PowerShell、Pythonなどで一覧にする作業も候補です。最初から機器へ自動接続する仕組みを作る必要はありません。承認済みの方法で集めたファイルを、台帳と同じ形式に整えるところから始められます。

出力する項目をそろえ、情報を取れなかった機器は「取得失敗」と分かるようにします。取得した日時も残してください。古い情報をそのまま表示すると、今回も正常に取れたように見えてしまうからです。

手作業で調べた結果と並べて、機器の取り違えや項目の抜けがないか確かめます。

残しておくもの： 入力と出力の仕様、スクリプト、実行条件、正常時・失敗時の試験結果、台帳との差分、更新履歴。別の担当者にも渡せる状態にしておくと、自分だけが使う便利ツールから、現場で使える成果物になります。

社内で構築案件に入る打診の仕方

次の更改・機器更新・移設の予定を聞く

実績が少し残せたら、次のスイッチ更改、サーバ更新、拠点移設の予定を上司や案件責任者に聞いてみてください。知りたいのは作業当日だけでなく、現状調査や資料づくりが始まる時期です。

更改の前には、構成図の更新、設定値の収集、台帳との照合、いまの監視設定の確認があります。対象の機器を普段から見ているなら、こうした作業から参加する話ができます。

客先常駐の場合は、自社の上司にも相談しましょう。いまの契約で担当できる作業と、次の配属で希望する作業を分けると、話を進めやすくなります。

「上流をやりたい」に、担当したい成果物を添える

「上流をやりたい」という希望だけでは、受け入れる側も何を任せるか迷います。そこで、作りたい資料と、すでに持っている材料を一緒に伝えます。たとえば、こんな相談です。

次のスイッチ更改で、現行ポート設定の収集とパラメータシートの作成を担当したいです。いま運用で使っている接続先台帳と照らし合わせて、不明点も洗い出します。設定を確定する前に、構築担当の方にレビューしてもらえますか。

サーバ更新なら、OS・サービス・マウント設定の現状調査や、単体試験仕様書の作成に置き換えられます。「ここまでなら、自分で調べて作れます」と話せると、任せる側も作業を切り分けやすくなります。

レビューしてもらう人と、担当する範囲を決める

話が進んだら、対象の機器、作る資料、提出時期、レビューしてもらう人を決めます。いつもの運用業務と重なったとき、どちらを優先するかも確認しておきましょう。

最初は設定値の転記からでも構いません。実機と照らし合わせ、合わない箇所を調べるところまで担当できれば、自分で確認した内容が残ります。レビューで直した理由も残し、次は試験項目の作成まで相談する。

案件の予定や担当範囲を確認しても、社内で構築に関わる機会がない場合は、社外の募集要件も見てみましょう。「構築」という名称に加えて、最初に作る成果物、レビューの体制、運用業務の割合を確認します。社内で得られる経験と比べたうえで、転職を選択肢に入れてください。

転職で構築ポジションを狙うときの職務経歴書

「監視していた」の中身を、機器・設定・判断で伝える

職務経歴書に「障害対応を担当」と書くだけでは、仕事の中身が伝わりません。どの環境で、何が問題になり、自分が何を担当して、何を残したのか。

実際にその作業を担当した場合なら、次のように書けます。

伝わりにくい書き方	担当した仕事が伝わる書き方
Zabbixで監視を担当	LinuxサーバのCPU監視について、アラート履歴と負荷推移を照合。閾値・通知条件の変更案を作成し、承認後の変更と通知試験を担当
手順書を更新	サービス再起動手順に、実行前のログ確認、実行条件、復旧確認を追加。運用責任者のレビューを受け、検証結果を添えて改訂
スクリプトを作成	OS情報の収集結果を台帳形式へ整形する処理を作成。取得失敗時の表示を実装し、手作業の結果と照合

削減時間を測っていなければ、「作業時間を大幅削減」と書くより、手入力をなくした箇所や、照合できるようになった項目を書くほうが説明できます。

実務・自宅での検証・提案した段階を分けて書く

会社の仕事として担当したことは実務欄へ。自宅で試したことは自己学習欄へ書きましょう。先輩が決めた設定を投入したなら、担当したのは投入前の確認、設定作業、試験のどこまでかを伝えます。

既存の構成図を直した経験を「ネットワーク設計」と書くと、方式を選んだ理由を聞かれたときに話が合わなくなります。「現行構成図を実機と照合し、接続先の違いを修正」なら、実際にやったことをそのまま説明できます。

資料の現物を見せたくなっても、社内の構成図や設定ファイルは持ち出しルールを確認してください。職務経歴書では、顧客名や接続情報を出さずに、対象機器、確認した項目、自分の担当を説明しましょう。

設計・上流へ進むために必要になるもの

要件を聞いて、「なぜこの構成か」を考える

構築では、決まった設定を入れて、試験で確かめます。設計に進むと、その手前にある「なぜ、その設定や構成にするのか」を考える仕事が加わります。

たとえば「機器が故障しても業務を続けたい」という要望です。どの業務を止めたくないのか。どれくらいの停止なら許容できるのか。どの故障に備えるのか。機器や経路の冗長化、切替方式、監視項目を考えます。

要件と構成、確かめる試験を並べた表を作ると、話を整理できます。パラメータシートの設定値を見たときに、「この要件があるから、この設定です」と説明できる状態を目指しましょう。

選んだ方式と、選ばなかった方式の理由を話せるようにする

「前の案件と同じだから」で選んでいると、今回の条件に合うかが抜けてしまいます。拠点間の接続なら、静的ルーティングと動的ルーティングを比べてみてください。経路はどのくらい変わるのか。障害時にどう切り替えるのか。

方式比較表には、候補、満たせる要件、制約、選んだ理由を残します。複雑な方式を使うことより、現場で保守できるかまで説明することが大切です。

作った後の障害対応・バックアップ・更新まで考える

導入した日に動いていても、障害時の連絡先や復旧方法が決まっていなければ、その後は運用担当者が困ります。誰に何を通知して、どの手順で対応するのか。設計の段階で決めておきたい内容です。

バックアップなら、取れたかどうかに加えて、復元できるかも試します。証明書なら、有効期限の監視、更新する担当者、更新後の確認まで決めます。「夜中にこれで困った」という運用の経験は、こうした抜けに気づく材料になります。

資格の知識を、構成図や試験項目に使ってみる

資格そのものが年収をいくら上げるかを示す信頼できる公的統計は存在しません。資格は、上位工程へ移るための手段として機能します。

設計・上流を目指すときの学習候補には、ネットワークスペシャリスト、情報処理安全確保支援士、CCNP、LPIC-3があります。ネットワーク、セキュリティ、Linuxなど、次に担当したい仕事に合わせて選んでください。

学んだ内容は、構成図や試験項目に使ってみましょう。冗長化を学んだなら、どこが壊れたら通信が止まるかを図で確認する。権限管理を学んだなら、誰が何へアクセスできるべきかを整理する。資格名に加えて、その知識で何を考えたかまで話せるようにしておくと、担当したい仕事とのつながりが伝わります。

資格の内容は、IPAのネットワークスペシャリスト、情報処理安全確保支援士、CiscoのCCNP Enterprise、LPIのLPIC-3で確認できます。

よくある質問

構築未経験でも、運用から構築へ進めますか？

進めます。まずは、現状調査や試験項目づくりなど、担当できる作業から相談しましょう。運用で作った設定変更案や手順書の改訂が、そのときの材料になります。社外の募集を見る場合も、必要な構築経験と、入社後に最初に任される仕事を確認してください。

夜勤で勉強時間が取れない場合、何から始めればいいですか？

業務時間内に作れる実績から始めてください。 たとえば、復旧手順書の「再起動した後、何を見れば復旧と判断できるか」を整理する作業です。当直中や日勤帯に通常業務の余裕があり、責任者と相談できたら、ここから着手しましょう。前述の「復旧手順書に『どう判断するか』を足す」が参考になります。休憩や夜勤明けの睡眠を削る話ではありません。勤務中にも余裕がなければ、まず作業時間を確保できるか責任者と相談してください。

設定変更の権限がなくても、構築につながる実績を作れますか？

作れます。閲覧できるアラート履歴を整理したり、台帳を照合したり、手順書の改訂案を書いたりするところから始められます。調べた根拠と確認したい点を添えて、担当者へ渡してみてください。自分が案を作った範囲と、担当者が判断・実施した範囲は分けて残しましょう。

クラウドの個人学習は、実務経験として書けますか？

個人学習は、自己学習欄に書いてください。構成図、設定内容、試験結果があれば、何を試したかを伝えられます。環境を起動した画面だけでなく、通信経路や権限を選んだ理由、つながらなかったときに調べた項目まで残すと、検証の中身が分かります。仕事で担当した経験とは分けておきましょう。

社内異動と転職は、何を基準に選べばいいですか？

「次に何を作れるか」と「いつ、その仕事に入れるか」で比べてください。社内で機器更新のパラメータ作成や試験を担当できるなら、予定とレビュー役を確認します。機会がなければ、社外の募集でも同じ条件を見ます。

まとめ

明日の勤務では、いつも使っている復旧手順書から「ここ、判断に迷うな」と思う箇所を選び、改訂案を書いてみてください。何を確認して、どんな状態なら次へ進むのか。分かる範囲で言葉にできれば十分です。まだ確かめていない点は、そのまま残して構いません。まずは、次に使う人が迷わない手順に直すところから始めましょう。