キャリアメディア / 職務経歴書

インフラエンジニアの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：インフラエンジニア ｜更新日 2026/7/4

インフラエンジニアの職務経歴書は、「何を構築したか」だけを書いても通過率は上がりにくい。採用担当者や技術面接官が実際に評価しているのは、技術スタックの組み合わせ、規模感・複雑度、そして意思決定への関与度の三軸である。この三軸を意識して整理することが、書類選考を通過する職務経歴書の骨格となる。

以下では、インフラエンジニア特有の評価基準を踏まえたうえで、各セクションの書き方・表現の粒度・よくある落とし穴を順に解説する。

インフラエンジニアの職務経歴書が難しい理由

アプリケーションエンジニアと比較した場合、インフラエンジニアの職務経歴書には固有の難しさがある。

第一に、成果が「稼働し続けていること」に集約されやすい点が挙げられる。「システムが落ちなかった」は価値ある実績だが、それ単体では差別化にならない。

第二に、作業の性質がプロジェクトごとに異なりにくいという問題がある。オンプレミスのサーバー構築であれば、OS設定・ネットワーク設定・監視設定というフローが繰り返されるため、読む側には「同じ作業を繰り返してきた人」と映りやすい。

第三に、クラウドとオンプレミスの混在が読みにくさを生む。どの環境で何を担当したかが整理されていないと、技術の深さより広さだけが印象に残ってしまう。

これらの課題を解決するには、単なる業務の列挙ではなく、「規模・難度・判断」の観点から経験を再構成する必要がある。

全体構成とセクションの役割

インフラエンジニアの職務経歴書は、以下の五段構成が標準的な骨格となる。

とくに重要なのは「職務要約」と「職務経歴（プロジェクト別）」の二か所である。この二か所が曖昧だと、他のセクションがどれほど充実していても書類全体の印象が薄くなる傾向がある。

職務要約：最初の7行で評価の8割が決まる

採用担当者が職務経歴書を最初に読む際、多くの場合は職務要約を起点に全体を流し読みする。そのため、職務要約には以下の三要素を凝縮させることが重要となる。

1. 領域の深さ（オンプレ中心か、クラウドネイティブか、その両方か）
2. キャリアの一貫性または変遷の論理
3. 強みの実務的な根拠

書き方の例（Before）

サーバーやネットワークの構築・運用を7年間経験してきました。クラウドも扱えます。

書き方の例（After）

オンプレミス基盤の設計・構築から、AWS・Azureを用いたクラウド移行まで7年の経験を持つ。直近3年はSRE的なアプローチを取り入れ、障害対応の自動化（Terraform・Ansible）やSLI/SLOの整備に注力してきた。インフラの「作れる」から「壊れにくく・変えやすくする」方向へ軸をシフトしている。

後者は、技術の変遷を自分のキャリア観として語れており、読み手に「現在進行形で成長している人材」という印象を与えやすい。

スキル・技術スタック：「並べる」ではなく「分類して深さを示す」

スキル欄を単純なキーワード羅列にする書き方は、インフラエンジニアにとって特に評価が下がりやすい。「Linux、Windows、AWS、Azure、Cisco、Docker、Kubernetes、Terraform…」と並べても、熟練度・実務での役割・利用規模がわからないからだ。

推奨するのは、カテゴリ分類＋習熟度コメントの付加である。

この形式にすることで、採用担当者・技術面接官の双方が「どの技術がどの程度使えるか」を短時間で読み取れるようになる。

職務経歴（プロジェクト別）：三軸で書く

三軸の定義

インフラエンジニアの経験を評価する際、技術面接官は以下の三軸で暗黙的に判断していることが多い。

• 技術軸：どの技術を使い、どの程度の複雑さだったか
• 規模軸：サーバー台数・ユーザー数・トラフィック量・チーム規模
• 判断軸：設計判断・技術選定・エスカレーション経路のどこに関与したか

この三軸をプロジェクト記述に織り込むことで、単なる「作業記録」ではなく「エンジニアとしての判断の記録」になる。

プロジェクト記述のテンプレート

【プロジェクト名】：○○社 基幹システムのクラウド移行（オンプレ → AWS）
【期間】：20XX年X月 〜 20XX年X月（約1年）
【チーム規模】：インフラ担当3名（うち自分がリード）、開発側6名
【担当領域】：移行設計・Terraform実装・移行テスト・本番切り替え

【概要】
〜500台規模のオンプレミス環境をAWSに移行するプロジェクト。レガシーDB（Oracle RAC）を含む複数システムの依存関係整理から担当。

【担当業務と貢献】
・現行環境のヒアリング・依存関係マップの作成（Drawio）
・Terraformによるネットワーク・セキュリティグループ・EC2の構成管理コード化
・移行方式（リホスト vs リプラットフォーム）の比較検討資料作成、PM・アーキテクトへの提案
・RTO/RPO要件に基づくバックアップ・DR設計
・本番移行当日のロールバック手順作成と指揮

【定量的な成果・変化】
・手動構築に比べ構築時間を約40%短縮（Terraform導入効果）
・移行後の障害件数：旧環境比で月平均2件 → 0.5件程度に減少

このテンプレートで特に重要なのは「移行方式の比較検討資料作成、提案」の部分である。多くのエンジニアはこういった判断への関与を書き漏らしやすいが、採用担当者側からすると、作業者なのか、意思決定に参加できる人材なのかを区別する最重要情報となる。

定量表現の作り方：数字がない場合の対処法

「成果を数字で書きなさい」とはよく言われるが、インフラエンジニアは成果の定量化が難しい場合も多い。そのような場合の代替アプローチを以下に示す。

よくある質問

Q1. 運用・保守メインの経験しかないが、どう書けば評価されるか？

運用・保守経験は「障害対応の深さ」「問題の根本原因分析（RCA）への関与」「改善提案の実績」という観点で記述すると評価が上がりやすい。例えば「障害を検知して復旧させた」だけでなく、「再発防止策として監視アラートの閾値見直しと自動スケーリング設定を追加提案した」まで書けると、主体性が伝わりやすくなる。

Q2. 資格（AWS認定等）は職務経歴書にどう書くべきか？

資格は「取得年月＋業務での活用」を添えることで、単なる資格欄よりも信頼性が増す傾向がある。たとえば「AWS Solutions Architect – Professional（20XX年X月取得、設計レビューや技術選定に活用）」という形が望ましい。また、資格取得後に関与したプロジェクトとの紐付けが職務経歴内で読み取れると、採用担当者に「使える知識」として認識されやすい。

Q3. オンプレ中心のキャリアでクラウド系のポジションに応募する場合、どう書くべきか？

オンプレの強みを「クラウド移行の基礎力」として位置づける書き方が有効である。ネットワーク設計・サーバー仮想化・セキュリティ設計の経験は、クラウド環境でも本質的に同じ知識体系が求められる。加えて、個人または業務での学習実績（ハンズオン構築、認定取得、LT登壇等）を職務経歴書の末尾に「スキルアップ・学習活動」として追記することで、転換意欲と自主性を補足できる。

Q4. 職務経歴書はどの程度の長さが適切か？

一般的には、経験年数5年未満であればA4で1〜2枚程度、5年以上であれば2〜3枚程度が目安となる。ただし、長さ自体より「1プロジェクトあたりの記述密度の均一性」の方が読みやすさに影響しやすい。10年分の経験があっても、直近3〜5年のプロジェクトに記述の重みを置き、古い案件は簡略化するバランスが読みやすい職務経歴書の構成となる。

まとめ

インフラエンジニアの職務経歴書で書類通過率を高めるには、技術キーワードの網羅よりも「技術・規模・判断」の三軸を意識した記述が重要となる。職務要約でキャリアの文脈を示し、プロジェクト記述で意思決定への関与を具体的に記すことで、採用担当者と技術面接官の双方に刺さる書類になりやすい。定量表現が難しい場合も、複雑度・プロセス変化・チームへの影響という代替指標で価値を言語化できる。オンプレ・クラウド・SRE的役割のいずれであっても、「作業をこなした記録」から「判断の記録」へ視点を変えることが、書類の質を一段引き上げる鍵となる。現職での経験整理に迷いがある場合は、キ