インフラエンジニアの職務経歴書テンプレート/フォーマット【PDF/スマホダウンロード可】

インフラエンジニアの職務経歴書テンプレートはこちら

インフラエンジニアの職務経歴書の書き方・例文

① 年月日（提出日）と氏名

【例文】

提出日：2025年4月11日 氏名：藤井 雄介

【書き方】

年月日は「作成した日」ではなく、実際に提出する日付を記載するのが正しいルールです。インフラエンジニアの転職活動では、複数社に同時応募するケースも多く、作成してから提出までに時間が空くことがあります。使い回しをすると日付が古いままになりがちですので、送付・持参する直前に必ず確認・更新する習慣をつけましょう。

氏名はフルネームで正式に記載します。ふりがなを求められている場合は、名前の上に小さく添えてください。

② 職務要約（職務概要）

【例文】

新卒にてSIerに入社し、インフラエンジニアとして8年間従事。オンプレミス環境でのサーバー設計・構築・運用保守を3年間担当した後、クラウド移行プロジェクトに参画。以降5年間はAWS・Azureを活用したクラウドインフラの設計・構築・運用を中心に担当し、IaCによるインフラ自動化・CI/CDパイプライン構築まで経験の幅を広げてきた。直近では10名規模のプロジェクトでインフラリードを担い、大手製造業向けの基幹システムクラウド移行において可用性99.9%以上を維持しながらインフラコストを年間30%削減した実績を持つ。より開発寄りのSRE・DevOps領域に挑戦したいという思いから、転職活動中。

【書き方】

職務要約は採用担当者が最初に目を通す「キャリアのダイジェスト」です。3〜5行程度にコンパクトにまとめ、以下の4点を盛り込みましょう。

• これまでのキャリアの流れ（どんな会社で、何年間、どんなインフラ領域を担当してきたか）
• 得意な技術領域・スキルスタック（オンプレ・クラウド・ネットワーク・セキュリティなど主要なものを端的に示す）
• 担当してきた規模と役割（プロジェクト規模・チームでの役割・リード経験の有無）
• 転職の方向性（なぜ転職するのか、次に何をしたいのか）

インフラエンジニアの採用担当者は「どんな技術スタックを持ち、どのフェーズを、どのくらいの規模で経験してきたか」を真っ先に確認します。技術力と実績の幅がひと目でわかる職務要約を意識して書きましょう。

③ 活かせる経験、知識、スキル

【例文】

クラウド・仮想化

• AWS（5年／EC2・S3・RDS・VPC・Lambda・CloudFormation・ECS・EKS）
• Azure（2年／Azure VM・Azure SQL Database・Azure DevOps・Azure AD）
• VMware vSphere（3年／仮想マシン設計・運用）
• Docker・Kubernetes（3年／コンテナ設計・オーケストレーション）

オンプレミス・サーバー

• Linux（Red Hat Enterprise Linux・CentOS・Ubuntu／8年）
• Windows Server（2016・2019／Active Directory・DNS・DHCP・IIS）
• ストレージ管理（NetApp・EMC）
• バックアップ・リストア設計・運用（Veeam・Acronis）

ネットワーク

• ネットワーク設計・構築（LAN・WAN・VPN・ロードバランサー）
• Cisco機器の設定・管理（ルーター・スイッチ）
• ファイアウォール設定・管理（Palo Alto・FortiGate）
• DNS・DHCP・NTPサーバーの構築・運用

IaC・自動化・DevOps

• Terraform（2年／AWS・Azureリソースのコード化・管理）
• Ansible（3年／サーバー設定自動化・構成管理）
• Python・Shellスクリプト（自動化スクリプト作成）
• GitHub Actions・Jenkins（CI/CDパイプライン構築）
• Git・GitHub（バージョン管理・チームコラボレーション）

監視・セキュリティ

• 監視ツール（Zabbix・Datadog・CloudWatch）
• ログ管理（Elasticsearch・Kibana・Fluentd）
• セキュリティ設計・脆弱性対応・IAM管理
• インシデント対応・障害対応・RCA（根本原因分析）

【書き方】

インフラエンジニアの職務経歴書において、スキルセクションは採用可否を大きく左右する重要な項目です。採用担当者だけでなく、技術面接官も詳しく確認するため、技術的な正確さと読みやすさの両立が求められます。以下のポイントを意識して記載しましょう。

技術領域ごとに分類して整理する

「クラウド」「オンプレ・サーバー」「ネットワーク」「IaC・自動化」「監視・セキュリティ」などのカテゴリに分けて記載することで、採用担当者がスキルセットを一目で把握できます。

経験年数・具体的な利用サービスを添える

技術名だけでなく「〇年」「具体的なサービス名・バージョン」を添えることで、採用担当者が実力を正確に評価しやすくなります。

応募先に合わせて優先度を調整する

応募するポジション・技術スタックに関連性の高い技術を上位に記載し、関連性の低い技術は省略するなどメリハリをつけることが重要です。

④ 会社（勤務先）概要

【例文】

株式会社〇〇テクノロジーズ

• 事業内容：大手企業向けITシステムの設計・構築・運用保守・クラウド移行支援
• 設立：1998年
• 資本金：5億円
• 従業員数：1,200名
• 売上高：280億円（2024年3月期）
• 主要取引先：製造業・金融機関・官公庁・流通業
• 上場区分：東京証券取引所スタンダード市場上場
• インフラ部門規模：インフラエンジニア約180名

【書き方】

NTTデータ・富士通・NECなど全国的に知名度のある大手SIerや企業であれば概要の記載を省略できますが、中堅・中小規模のSIer・ITベンダー・受託開発会社に勤務している場合は必ず記載しましょう。採用担当者が会社の規模感・事業領域・取引先を正確に把握することで、担当してきたインフラの難易度・品質水準をより正確に評価してもらえます。

記載する基本項目は以下の通りです。

• 会社名
• 事業内容（SIer・クラウドインテグレーター・自社開発・SES・データセンターなど業態がわかるように）
• 設立年・資本金・従業員数・売上高
• 主要取引先・業界（どの業界のインフラを担当してきたかが伝わると有効）
• 上場区分
• インフラ部門の規模（チームの大きさが伝わると採用担当者の理解が深まる）

インフラエンジニアの職務経歴では「どんな規模・業態の会社で、どんな業界のインフラを担当してきたか」が採用判断に直結します。会社概要を丁寧に記載することで、プロジェクト経歴の説得力が格段に増します。

⑤ 職務経歴

【例文】

株式会社〇〇テクノロジーズ（2017年4月〜現在） 役職：インフラリード（2022年4月より）

▼ 担当プロジェクト

【大手製造業向け 基幹システムクラウド移行プロジェクト】

• 期間：2022年6月〜2024年9月（約2年3ヶ月）
• 規模：総工数1,500人月・チーム人数：10名（インフラリード担当）
• 技術スタック：AWS（EC2・RDS・S3・VPC・CloudFront・CloudFormation・ECS）・Terraform・Ansible・Datadog・Python
• 担当フェーズ：要件定義〜設計〜構築〜テスト〜移行〜運用引き継ぎ
• 役割：インフラリード（全体設計・チームマネジメント・クライアント折衝）

主な担当業務：

• クライアントとのインフラ要件ヒアリング・非機能要件定義
• AWSを活用したクラウドインフラ全体設計（ネットワーク・サーバー・DB・セキュリティ）
• Terraformによるインフラのコード化（IaC）・モジュール設計
• Ansibleを使ったサーバー設定の自動化・構成管理
• GitHub ActionsによるCI/CDパイプラインの構築
• Datadogを用いた監視設計・アラート設定・ダッシュボード構築
• オンプレ→クラウドへのデータ移行計画・実施
• インフラチームメンバー10名の作業分担・技術レビュー・進捗管理

実績・取り組み：

• 可用性99.9%以上を維持しながらインフラコストを年間約30%削減
• Terraformによるインフラのコード化でインフラ構築時間を従来比60%短縮
• 移行期間中の障害ゼロを達成・クライアントから高い評価を受け追加案件を受注

【金融機関向け オンプレミスサーバー更改・仮想化プロジェクト】

• 期間：2019年6月〜2022年5月（約3年）
• 規模：総工数600人月・チーム人数：8名（サブリード担当）
• 技術スタック：VMware vSphere・Red Hat Enterprise Linux・Windows Server・NetApp・Zabbix・Cisco
• 担当フェーズ：基本設計〜詳細設計〜構築〜テスト〜移行
• 役割：サブリード（サーバー仮想化設計・構築リード）

主な担当業務：

• 物理サーバーから仮想環境（VMware vSphere）への移行設計・構築
• RHEL・Windows Serverの設定・チューニング・セキュリティ強化
• NetAppストレージの設計・構築・データ移行
• Zabbixによる監視設計・運用監視体制の整備
• ネットワーク機器（Cisco）の設定変更・VLAN設計
• 手順書・設計書の作成・品質レビュー

実績・取り組み：

• 物理サーバーを仮想化することで管理台数を150台から40台に集約・運用コスト削減
• 障害対応手順書を整備し、平均復旧時間（MTTR）を従来比40%短縮
• サーバー設定の標準化・チェックリスト化により構築品質を均一化

【運用保守業務（2017年4月〜2019年5月）】

主な担当業務：

• 複数クライアントのLinux・Windowsサーバーの日常監視・障害対応
• バックアップ・リストア作業・パッチ適用・定期メンテナンス
• インシデント対応・エスカレーション・RCA（根本原因分析）レポートの作成
• 監視ツール（Zabbix）のアラート対応・チューニング
• 運用手順書の整備・改訂

実績・取り組み：

• 監視アラートの見直しと自動対応スクリプト作成により、夜間対応件数を月平均50%削減
• 障害対応ナレッジベースを整備し、チーム全体の対応速度向上に貢献

【書き方】

職務経歴はインフラエンジニアの職務経歴書において最も重要なセクションです。採用担当者だけでなく、技術面接官も詳しく確認するため、技術的な正確さと読みやすさを両立させることが求められます。

時系列は新しい順（逆年代順）に記載する

直近のプロジェクトが採用担当者にとって最も重要な情報です。現職・最新のプロジェクトから順番に書き下ろしましょう。

プロジェクト単位で記載する

インフラエンジニアはプロジェクトごとに担当システム・技術・役割が大きく変わるため、「プロジェクト単位」での記載が基本です。各プロジェクトに以下の情報を盛り込みましょう。

• プロジェクト概要（何のインフラを、誰のために構築・運用したか）
• 規模感（総工数・チーム人数）
• 技術スタック（OS・クラウド・ミドルウェア・ツール）
• 担当フェーズ（要件定義〜運用保守のどこを担当したか）
• 自分の役割・立場（リード・サブリード・メンバーなど）
• 具体的な担当業務
• 実績・工夫した点

数字・規模感を積極的に盛り込む

インフラエンジニアの職務経歴では以下のような形で定量的に示すことができます。

• インフラコスト削減率・可用性の数値
• 構築時間の短縮率・自動化による効率化
• 管理サーバー台数・仮想化による集約台数
• 障害件数・MTTRの改善率
• 担当したチームメンバーの人数

⑥ 資格・特技など

【例文】

資格

• AWS認定ソリューションアーキテクト – プロフェッショナル（2023年取得）
• AWS認定DevOpsエンジニア – プロフェッショナル（2024年取得）
• Microsoft Azure Administrator Associate（AZ-104）（2022年取得）
• Linux Professional Institute Certification（LPIC-2）（2020年取得）
• ネットワークスペシャリスト試験（2021年取得）
• Kubernetes認定管理者（CKA）（2023年取得）
• 情報処理安全確保支援士（2022年取得）

特技・その他

• Terraformを用いたマルチクラウドIaCの設計・実装（個人GitHubで公開中）
• PythonによるAWS運用自動化スクリプトの作成・社内展開
• 技術ブログの運営（月1〜2本／AWS・Kubernetes関連の記事を執筆）
• 社内インフラ勉強会の企画・運営（月1回・参加者20名規模）

【書き方】

インフラエンジニアの転職において、資格は技術力の客観的な証明として採用担当者・技術面接官の両方から強く評価されます。取得年を必ず添えて記載しましょう。特にAWS・Azureの上位認定資格やネットワークスペシャリスト・Kubernetes認定などは、即戦力としての評価に直結します。

インフラエンジニアの転職で評価されやすい資格は以下の通りです。

• AWS認定資格（ソリューションアーキテクト・DevOpsエンジニア・セキュリティなど）
• Google Cloud認定資格（Professional Cloud Architect・Network Engineerなど）
• Microsoft Azure認定資格（AZ-104・AZ-305・AZ-400など）
• LPIC（Linux Professional Institute Certification）2級・3級
• ネットワークスペシャリスト試験（IPA）
• Kubernetes認定資格（CKA・CKAD・CKS）
• 情報処理安全確保支援士（IPA）
• CCNA・CCNP（Cisco認定）
• VMware認定資格（VCP）

資格だけでなく、GitHubでのIaCコード公開・技術ブログ・社内勉強会の企画・運営など自主的な技術活動は、採用担当者に学習意欲と実践力を強くアピールできます。GitHubのURLや技術ブログのURLを合わせて記載しましょう。

⑦ 自己PR

【例文】

私の強みは、「オンプレミスからクラウドまで幅広いインフラ経験に裏打ちされた設計力」と「IaCと自動化でインフラをコードとして管理し、運用効率を継続的に改善するDevOps思考」の2点です。

SIerでの8年間、金融・製造・流通業界の幅広いインフラ設計・構築・運用に携わってきました。オンプレ環境での基礎を固めた後、クラウド移行プロジェクトへの参画を機にAWSとTerraform・Ansibleを習得し、インフラのコード化・自動化を現場に根付かせることに注力してきました。直近の基幹システムクラウド移行プロジェクトでは、TerraformによるIaCの徹底で構築時間を従来比60%短縮し、可用性99.9%以上を維持しながらインフラコストを年間30%削減することができました。

技術の習得に対しては業務外でも積極的に取り組んでおり、AWS認定プロフェッショナル・Kubernetes認定管理者（CKA）の取得に加え、社内勉強会を月次で企画・運営するなど、チーム全体の技術力向上にも貢献しています。

貴社においても、これまでのクラウドインフラ設計・IaC推進の経験を活かし、インフラの信頼性向上と開発速度の加速をSREの視点から支えていきたいと考えております。

【書き方】

自己PRはインフラエンジニアの職務経歴書の締めくくりとして、「この人と一緒にインフラを任せたいか」「自社の技術スタック・チームに合う人材か」を採用担当者・技術面接官が感じ取る重要なセクションです。以下の構成で書くと、技術力と人柄が両立した自己PRに仕上がります。

①強みを明示する（冒頭で結論から）

冒頭に「私の強みは〇〇です」と明確に述べましょう。インフラエンジニアの強みとして評価されやすいのは「クラウド設計・構築の実績」「IaC・自動化による運用効率化」「ネットワーク・セキュリティの専門性」「障害対応・可用性維持の実績」「チームリードとしてのマネジメント経験」などです。2点程度に絞って簡潔に示しましょう。

②エピソードで裏付ける

強みを述べたら、それを証明する具体的なエピソードを添えます。「どんなインフラ課題があり・どう取り組み・どんな定量的な成果が出たか」を意識して書くと説得力が格段に増します。コスト削減率・可用性・障害件数・自動化による工数削減など、数値を用いたエピソードを積極的に盛り込みましょう。

③業務外の技術活動も添えると効果的

資格取得・技術ブログ・GitHubでのコード公開・勉強会運営など、業務外での自主的な技術習得の取り組みを添えることで「向上心があり、自走できるエンジニアだ」という印象を与えることができます。

④応募先への貢献イメージで締める

最後は「貴社でどう活躍・貢献できるか」という視点で締めましょう。応募先がSRE・DevOps志向であれば「開発速度の向上・信頼性の向上への貢献」、クラウドインテグレーターであれば「最新クラウド技術を活用した顧客への価値提供」など、応募先の状況に合わせた貢献イメージを示すと熱意と適性が伝わります。

文字数は300〜400字程度が適切です。技術的な正確さを保ちながらも、技術に詳しくない採用担当者（人事担当など）にも伝わるよう、わかりやすい表現を心がけましょう。

よくある質問

Q. インフラエンジニアの職務経歴書はA4何枚が適切ですか？

A. A4用紙2〜3枚が基本です。プロジェクト経験が豊富な場合は3枚になっても問題ありませんが、それ以上になると読まれにくくなるため、直近3〜5プロジェクト程度に絞り込んで記載しましょう。古いプロジェクトや規模の小さいプロジェクトは「その他、〇件のインフラ構築・運用保守業務に従事」とまとめて記載する方法も有効です。

Q. 運用保守の経験しかない場合、設計・構築ポジションへの転職は難しいですか？

A. 運用保守の経験のみでも設計・構築ポジションへの転職は可能です。ポイントは運用保守の経験の中から「設計・構築への関与要素」を掘り起こすことです。たとえば「監視設定の見直し・チューニングを実施した」「障害対応で根本原因分析と恒久対策を提案した」「運用手順書の整備・自動化スクリプトの作成をした」などの経験は、設計・構築への適性を示す有力なエピソードです。また、AWSなどのクラウド資格の取得や個人環境での構築経験を合わせてアピールすることで、転職の可能性が大きく広がります。

Q. SES（客先常駐）でのインフラ経験は職務経歴書にどう書けばいいですか？

A. SESの経験も正社員と同様に、プロジェクト単位で詳しく記載しましょう。「所属会社：〇〇株式会社（SES契約）／常駐先：△△株式会社」という形で、所属会社と常駐先を明記することで採用担当者が状況を正確に把握できます。複数の常駐先で経験を積んでいる場合は、技術スタックの幅広さが強みになるため、それぞれのプロジェクトで使用した技術・自分の役割・実績を丁寧に記載しましょう。

Q. オンプレミス経験しかない場合、クラウドエンジニアへの転職は難しいですか？

A. オンプレミス経験しかない場合でも、クラウドエンジニアへの転職は十分に可能です。まずAWSやAzureの入門〜中級資格を取得し、個人アカウントでクラウド環境を実際に構築した経験をポートフォリオとしてまとめることが有効です。オンプレミスでのサーバー・ネットワーク・ストレージの深い知識は、クラウド設計においても直接的な強みになります。「オンプレの知識を持ちながらクラウドを習得している人材」として、移行プロジェクトへの適性をアピールしましょう。

Q. インフラエンジニアからSRE・DevOpsエンジニアへの転職を目指す場合、何をアピールすればいいですか？

A. SRE・DevOpsへの転職では「インフラの信頼性向上への取り組み」「自動化・IaCの実践経験」「開発チームとの連携経験」「SLI・SLO・エラーバジェットへの理解」をアピールすることが重要です。具体的には「Terraformでインフラをコード化した」「CI/CDパイプラインを構築した」「障害対応のMTTRを改善した」「監視・アラートの整備でインシデント対応を効率化した」などのエピソードが有効です。PythonやGoなどのスクリプト言語の経験も合わせてアピールしましょう。

Q. 担当プロジェクトの詳細を守秘義務の関係で書けない場合はどうすればいいですか？

A. 守秘義務がある場合でも「大手金融機関向け」「自動車メーカー向け」など、クライアントを特定できない範囲で業界・規模感を示す表現であれば記載して問題ありません。具体的なシステム名・機密性の高い仕様・詳細な構成情報は記載を避け、「基幹システムのクラウド移行」「社内インフラの仮想化プロジェクト」など一般的な表現で担当業務を説明しましょう。面接の場で詳細を説明できる準備をしておくことも大切です。