インフラエンジニアの職務経歴書｜採用側が見ている実務経験の書き方

はじめに

転職活動を始めたインフラエンジニアが最初に直面するのが、職務経歴書の作成です。設計書や手順書を書き慣れているエンジニアでも、自分自身の実務経験を採用側に伝わる形で言語化する機会は多くありません。その結果、製品名を羅列しただけのスキルシートや、「ネットワークの構築・運用に従事」の一行で終わる職務経歴になりがちで、経験の深さが伝わらないまま書類選考を通過できないケースがあります。

筆者は転職メディアのライターではなく、事業会社で採用する側として書類選考・面接を担当した経験があります（データベース・クラウドデータ基盤領域のエンジニア採用）。本記事では、その経験をもとに「選考する側は職務経歴書のどこを見ているか」という視点から、インフラエンジニアの職務経歴書の書き方を整理します。

結論を先に述べると、書類選考で評価されるのは保有資格や製品名の一覧ではなく、「どの規模の環境で、どの役割を担い、何を解決してきたか」まで言語化された実務経験です。同じ経験年数でも、この具体化ができているかどうかで書類の印象は大きく変わります。本記事では、その具体化の方法を記載例とあわせて紹介します。

採用側は職務経歴書のどこを見ているか

書き方のテクニックに入る前に、まず「読む側」の視点を整理します。選考側が何を確認しようとしているかがわかれば、職務経歴書に何を書くべきかは自然に決まります。

なお、筆者が担当していたのは事業会社におけるデータベース・クラウドデータ基盤領域のエンジニア採用であり、すべての企業・職種に当てはまる基準ではありません。その前提のうえで、インフラエンジニアの選考にも共通しやすい観点を紹介します。

資格と実務経験の評価バランス

筆者が選考で最も重視していたのは、資格よりも実務経験の内容と年数です。

資格が無意味ということではありません。CCNA・CCNP やネットワークスペシャリスト、AWS 認定資格などは、基礎知識を体系的に習得している証明になり、特に経験の浅い候補者にとっては有効な補強材料になります。ただし、資格の一覧だけでは「実務で何ができる人か」は判断できません。たとえば CCNP を保有していても、実際に経路設計や障害の切り分けをどこまで担ってきたかは、資格欄からは読み取れないためです。

逆に、資格欄が薄い場合でも、実務経験が具体的に記述されていれば選考は先に進みます。筆者の経験では、書類選考の判断材料はほぼ職務経歴の記述内容であり、資格は同水準の候補者が並んだときの補足情報という位置づけでした。

この傾向は転職エージェント側の解説とも一致しており、採用担当者が確認する要素として「テクニカルスキル」「プロジェクトマネジメントスキル」「顧客折衝スキル」の 3 点が挙げられています。

参考: ネットワークエンジニアの職務経歴書の書き方（リクルートダイレクトスカウト）
「テクニカルスキル」「プロジェクトマネジメントスキル」「顧客折衝スキル」
https://directscout.recruit.co.jp/contents/article/9933/

いずれも資格ではなく、実務のなかでしか身につかない要素です。職務経歴書の主役は資格欄ではなく職務経歴欄である、という前提をまず押さえておくことをおすすめします。

書類選考の短時間で確認されるポイント

書類選考に長い時間はかけられません。筆者の場合、最初に読むのは職務要約、次にスキル一覧、そのあとに直近のプロジェクトという順序で、この短い流れのなかで以下の 3 点を確認していました。

環境の規模と構成

拠点数、ユーザー数、機器台数、オンプレミスとクラウドの構成比など。「大規模ネットワークの運用」ではなく「20 拠点・2,000 ユーザー規模」のように数値で書かれているかどうかで、経験の再現性を判断できます。

担当フェーズと役割

要件定義・設計・構築・運用のどのフェーズを、主担当として担ったのかサポートとして関わったのか。同じプロジェクト名でも、役割によって評価は大きく変わります。

課題解決の実績

障害対応、構成改善、運用の自動化など、「任された作業」から一歩踏み込んだ行動があるか。ここは経験年数だけでは測れない、候補者ごとの差が最も表れる部分です。

とくに 3 点目は経験年数の解釈にも直結します。同じ「経験 5 年」でも、運用監視のみの 5 年と、設計から障害対応まで含む 5 年では評価がまったく異なります。採用側は年数そのものではなく、年数に見合う経験の深さを見ています。職務経歴書は、この深さを伝えるための書類だと考えると、書くべき内容が絞りやすくなります。

インフラエンジニアの職務経歴書の基本構成

職務経歴書に決まった様式はありませんが、インフラエンジニアの場合は「職務要約 → スキル一覧 → プロジェクト単位の職務経歴 → 資格 → 自己 PR」の構成が読みやすく、選考側が知りたい情報の順序とも一致します。前章で述べたとおり、選考側は職務要約から読み始めるため、まず職務要約の完成度を高めることをおすすめします。

職務要約に入れるべき要素

職務要約は 3〜5 文程度で、以下の 5 要素を盛り込みます。

1. 経験年数と業務領域: 「インフラエンジニアとして 8 年、ネットワークの設計・構築・運用に従事」のように、年数と領域を最初の 1 文で示す
2. 扱ってきた製品・技術: 主要な機器ベンダー（Cisco、Fortinet、YAMAHA 等）やクラウド（AWS、Azure 等）を代表的なものに絞って記載する
3. 環境の規模: 拠点数、ユーザー数、機器台数など、規模を示す数値を 1 つ以上入れる
4. 担当フェーズ: 要件定義・設計・構築・運用のうち、どこを主担当としてきたか
5. 強み: 障害対応、冗長化設計、クラウド移行など、直近で最もアピールできる経験を 1 つ

このうち選考側の目に留まりやすいのは 3 の規模と 4 のフェーズです。「ネットワークの運用に従事」だけでは判断材料になりませんが、「20 拠点・2,000 ユーザー規模の社内ネットワークを 3 名チームで運用（主担当）」まで書かれていれば、任せられる業務範囲をこの 1 文で推定できます。

プロジェクト単位の職務経歴とスキルシートの関係

職務経歴欄は、会社単位の羅列ではなくプロジェクト（案件）単位で区切り、それぞれに「期間・概要・環境（製品・規模）・担当業務・役割・実績」を記載する形式が、インフラエンジニアには適しています。経験の幅と深さが構造的に伝わるためです。

注意したいのは、SES や常駐で使っているスキルシートをそのまま職務経歴書に流用しないことです。常駐先に提出するスキルシートは技術要素の網羅性を重視した書式であり、転職の書類選考で求められる「課題解決の実績」や「主体性」が抜け落ちやすい構造になっています。この点は転職メディア側でも同様の指摘があります。

参考: ネットワークエンジニアの職務経歴書テンプレートと書き方ガイド（doda）
“安易な使い回しは避けてください”
https://doda.jp/guide/syokureki/resume/it05.html

スキルシートは「何を扱えるか」の一覧、職務経歴書は「何を解決してきたか」の記録、と役割を分けて考えることをおすすめします。既存のスキルシートを土台にする場合は、各プロジェクトに実績・工夫の 1〜2 文を追記する形が現実的です。

技術経験を評価につなげる記載例

この章では、インフラエンジニアの主要な経験領域ごとに、評価につながりにくい書き方（Before）と、選考側に伝わる書き方（After）を対比して紹介します。共通する原則は、製品名・作業名で終わらせず、「規模・役割・結果」まで書き切ることです。

ネットワーク機器・構成経験の書き方（規模・冗長構成の示し方）

ネットワーク経験は、機器名の羅列になりやすい代表的な領域です。

Before（伝わらない例）

・Cisco ルーター、スイッチの設定
・FortiGate の運用

After（伝わる例）

・拠点間ネットワークの設計・構築（20 拠点、Cisco ISR/Catalyst、OSPF による経路制御）
・FortiGate の HA 構成（Active-Passive）の設計・運用、ファームウェアアップグレード計画の策定と実施

選考側が読み取りたいのは「触ったことがある」ではなく「どの規模・構成で任されていたか」です。ルーティングプロトコルの利用経験（OSPF、BGP 等）や冗長構成（HA、スタック、リンクアグリゲーション等）の設計・運用経験は、それ自体が設計力の証明になるため、該当する経験があれば省略せず記載することをおすすめします。冗長構成の設計観点については、関連記事『FortiGate HA の設定と確認コマンド｜Active-Passive の冗長化とフェイルオーバー』も参考になります。

数値の示し方は、拠点数・ユーザー数のほかに「機器台数」「回線構成（IPoE/PPPoE、専用線等）」も有効です。転職メディア側でも、規模を数値で明記することが推奨されています。

参考: ネットワークエンジニアの職務経歴書テンプレート（日経転職版）
“ネットワークの規模を表す数字（サーバ台数や拠点数等）を明記しましょう”
https://career.nikkei.com/knowhow/shokureki/000286/

障害対応・運用経験の書き方

運用・保守の経験は「監視業務に従事」の一行で片付けられがちですが、採用側の視点では、障害対応の記述こそ候補者の実力差が最も表れる部分です。前章で述べた「課題解決の実績」に直結するためです。

Before（伝わらない例）

・ネットワークの監視、障害対応

After（伝わる例）

・社内ネットワーク（2,000 ユーザー規模）の運用・障害対応。一次切り分けから復旧まで主担当として対応
・拠点間通信断の障害で、経路情報の調査により原因を特定し復旧（対応時間 2 時間）。再発防止として監視項目を追加

ポイントは 3 つあります。1 つ目は切り分けのプロセスが書かれていること。「障害対応をした」ではなく「どう原因に到達したか」が書かれていると、トラブルシューティングの再現性を判断できます。2 つ目は対応時間や影響範囲の数値。3 つ目は再発防止まで踏み込んだかです。復旧で終わらず監視や構成の改善につなげた経験は、運用フェーズの候補者を差別化する実績になります。

すべての障害を書く必要はありません。代表的な 1〜2 件を選び、上記 3 点を含めて 2〜3 行で書く形が読みやすく、面接での深掘りにもつなげやすい分量です。

クラウド・セキュリティ経験の書き方

オンプレミス中心の経歴でも、クラウドとセキュリティの経験は部分的でも記載する価値があります。筆者が採用側として書類を見ていた際も、クラウド（AWS、GCP 等）とデータ基盤・セキュリティ領域の経験は、専任でなくてもプラス評価の対象でした。インフラの求人では、オンプレミスとクラウドの橋渡しができる人材が慢性的に不足しているためです。

Before（伝わらない例）

・AWS の知識あり
・セキュリティ対策の実施

After（伝わる例）

・オンプレミスから AWS への移行プロジェクトに参画（VPC 設計、Site-to-Site VPN 構築を担当）
・FortiGate の UTM 機能（IPS、Web フィルタリング）の運用と、脆弱性公開時のファームウェア更新対応
・WAF（AWS WAF）の導入検証とルールチューニングを担当

「知識あり」という表現は、実務経験の裏付けがないと判断されやすいため避けることをおすすめします。資格学習のみの段階であれば、資格欄または自己 PR 欄に「学習中」として書くほうが誠実に伝わります。逆に、脆弱性対応（アドバイザリーの確認、影響調査、パッチ適用計画）のような地味な実務は、書類で省略されがちですが、セキュリティ運用の実経験として評価される要素です。WAF の選定・運用の考え方については、関連記事「WAF の比較・選定ガイド」（内部リンク URL: 公開時に確定）で詳しく扱っています。

評価を下げやすい書き方と注意点

ここまで「評価につながる書き方」を紹介してきましたが、逆に、内容は悪くないのに書き方で損をしているケースもあります。筆者が書類選考で実際に判断に迷った、あるいは評価を保留したパターンを 2 つ紹介します。

製品名の羅列だけで終わるスキルシート

技術要素の一覧だけで職務経歴書が構成されているケースです。

・Cisco、FortiGate、YAMAHA RTX、Linux、AWS、Zabbix
・ルーティング、スイッチング、ファイアウォール、VPN

この形式の問題は、嘘がないにもかかわらず「検証環境で触った程度」なのか「本番環境で設計・運用を任されていた」のかを、読み手が区別できない点にあります。選考側は判断材料がない項目を高く評価することができないため、経験が深い候補者ほどこの書き方は損になります。

改善方法はこれまでの章で述べたとおりで、製品名に「規模・役割・結果」を組み合わせることです。すべての製品について詳述する必要はなく、応募先の求人内容に関連する 2〜3 領域を厚く書き、残りは一覧にとどめる強弱の付け方が現実的です。求人票に記載された業務内容と自分の経験の重なりを意識して、厚く書く領域を選ぶことをおすすめします。

なお、経験年数の水増しや、チームの実績を自分単独の実績のように書くことは避けるべきです。面接では書類の記載内容を深掘りされるため、書類と面接の回答に差が出ると、記載内容全体の信頼性が下がります。書類は「面接で自信を持って話せる内容」だけで構成することが、結果的に最も評価につながります。

常駐先・守秘義務情報の扱い

SES や常駐勤務の経歴を書く際に、常駐先の企業名やシステムの詳細を記載してよいか、という問題です。結論としては、守秘義務に抵触し得る情報（常駐先の実名、システム構成の詳細等）は伏せた上で、業界・規模・担当範囲で具体性を出す方法を推奨します。

・金融系企業（従業員 5,000 名規模）の社内ネットワーク運用に常駐で従事
・製造業向け基幹システムのインフラ更改プロジェクトに参画（サーバー 50 台規模）

企業名がなくても、業界と規模がわかれば選考側は経験の文脈を十分に読み取れます。逆に、守秘義務への配慮を欠いた書類は、情報の取り扱いに対する姿勢そのものが懸念材料になります。この点は転職メディア側でも注意喚起されています。

参考: ネットワークエンジニア職務経歴書の書き方（Achieve Career）
“いくら職務経歴書といっても、実名を出してはいけません”
https://achieve.atimes.co.jp/career/column/1654

インフラエンジニアはセキュリティ意識を職務経歴書の書き方そのものでも見られている、と考えておくと判断に迷いにくくなります。契約上の扱いが不明な場合は、所属元に確認してから記載することをおすすめします。

提出前に第三者の視点を入れる選択肢

職務経歴書は自分で書き上げた時点では完成ではありません。本記事で紹介してきた観点はセルフチェックにも使えますが、自分の経験の価値は自分では気づきにくいという構造的な問題があります。筆者が選考側として書類を見ていた際も、面接で話を聞いて初めて「この経験を書類に書けばよいのに」と感じる候補者は少なくありませんでした。本人にとっての「当たり前の業務」が、採用側には評価対象になることがあるためです。

提出前に第三者のレビューを入れる方法としては、次の選択肢があります。

同僚・知人のエンジニアに見てもらう

技術的な文脈が通じる相手からのフィードバックは有効です。一方で、在職中の転職活動が社内に伝わるリスクには注意が必要です。

応募先の求人票と突き合わせてセルフレビューする

求人票の「業務内容」「歓迎スキル」の各項目に対応する記述が職務経歴書にあるかを確認する方法です。費用はかからず、応募先ごとの調整にも使えます。

転職エージェントの添削を受ける

エージェントは書類選考を通過した書類・しなかった書類の実例を蓄積しているため、「どの経験を厚く書くべきか」の相場観を持っています。無料の面談内で職務経歴書の添削や壁打ちを受けられる場合が多く、応募前に客観的な評価を一度入れておく手段として現実的です。

エージェントを利用する場合は、IT エンジニアの職種を専門に扱うサービスを選ぶと、技術経験の文脈が伝わりやすくなります。たとえば TechGo（テックゴー）は IT エンジニア転職に特化したエージェントで、求人カテゴリにインフラ・ネットワーク・クラウド・セキュリティエンジニアが含まれています。

TechGO（テックゴー）

なお、エージェントの利用は前提ではありません。本記事の観点でセルフレビューを行うだけでも書類の質は変わります。自分の書類を「選考する側の視点」で一度読み直すことが、手段を問わず最も重要なポイントです。

まとめ

インフラエンジニアの職務経歴書は、資格や製品名の一覧ではなく、実務経験を選考側に伝わる形で言語化するための書類です。採用側として書類選考を担当した経験からも、評価の分かれ目は経験の有無そのものではなく、「規模・役割・結果」まで書き切れているかどうかにありました。

• 書類選考で重視されるのは資格の一覧より実務経験の内容と年数
• 職務要約には経験年数・製品・規模・担当フェーズ・強みの 5 要素を記載
• 経験は製品名の羅列で終わらせず、規模・役割・結果まで言語化する
• 障害対応は切り分けの過程と再発防止まで書くと差別化につながる
• 常駐先の実名は伏せ、業界と規模の記載で具体性を担保
• 提出前に求人票との突き合わせや第三者レビューで客観的な視点を入れる

以上、最後までお読みいただきありがとうございました。