30代経理の職務経歴書｜通過率を上げる実践的な書き方
ショクレキ代行
ショクレキ代行
20代インフラエンジニアの職務経歴書｜通過率を上げる実践的な書き方
ショクレキ代行
📌 この記事でわかること
- 20代インフラエンジニアが採用担当者に評価される職務経歴書の書き方
- 経験が浅くても「即戦力候補」として見せる方法
- 担当インフラの規模・対応件数・改善実績を数字で伝えるコツ
- AWS/Azure/GCP・Kubernetes・Terraform への対応の見せ方
- 経験年数別（1〜2年・3〜4年・5年前後）の書き方の違い
- NG例・改善例つきで今日から使える例文
「運用・構築の実務経験は積んできたのに、職務経歴書に何を書けばいいかわからない」「資格は持っているがアピールできているか不安」20代インフラエンジニアの転職活動でよく聞く悩みです。
20代インフラエンジニアの転職市場では「経験の深さ」より「対応量とスピード」「クラウド・IaCへの適応力」「障害対応・改善経験」が評価されます。多くの20代が「大規模インフラを担当していない」「設計経験が浅い」と思い込み、自分を過小評価した職務経歴書を書いてしまっています。
採用担当者が20代インフラエンジニアに期待しているのは「完成された設計者」ではありません。「対応量と学習スピード」「自動化・コード化への姿勢」「他チームと協働できる素地」です。この3点を職務経歴書で伝えられれば、経験が浅くても十分に評価されます。
目次
採用担当は何を見ている？
20代インフラエンジニアの採用担当者が職務経歴書で確認しているのは、主に次の3点です。
| 観点 | 内容 |
| 担当インフラの規模と対応件数 | 担当してきたサーバー台数・ユーザー数・障害対応件数を確認している。「サーバー約120台の運用監視」「月間障害対応件数約30件」のような具体的な規模感が判断材料になる |
| クラウド・IaC・自動化への対応 | AWS・Azure・GCP・Terraform・Ansible・Kubernetes・Docker・GitHub Actionsへの対応経験を確認している。20代では「業務での使用経験」「個人学習レベル」を分けて書ける具体性が評価される |
| 障害対応・改善実績 | MTTR（平均復旧時間）改善・コスト削減・自動化による工数削減など、数字で改善を追ってきた姿勢があるか。「MTTRを平均45分→15分に短縮」「監視アラート整理で誤検知を月150件→月20件に削減」のような数字を意識する20代は希少で評価が高い |
よくある失敗（書類が通らない人に共通する3つのパターン）
パターン①：「インフラ運用を担当」で終わっている
「自社サービスのインフラ運用・監視を担当してきました」という記述では、採用担当者には何も伝わりません。担当サーバー台数・サービス規模（ユーザー数・トラフィック）・対応件数が書かれて初めて評価材料になります。
パターン②：使用技術を並べるだけで習熟度が伝わらない
「AWS・Linux・Docker・Kubernetes・Terraform・Ansible 使用経験あり」と並べるだけでは、どの技術をどう使えるかが判断できません。「AWS（EC2・RDS・S3・CloudFront・WAF を業務で日常運用）」「Terraform（業務でIaC実装経験あり、約200リソース管理）」のように、技術ごとに業務での使い方を書くことが重要です。
パターン③：障害対応・改善の実績が書かれていない
20代インフラエンジニアで最も差がつくのは「運用したか」より「運用をどう改善したか」です。「障害対応・運用改善でMTTRを短縮した」だけでなく「障害発生時のランブック整備とアラート閾値見直しにより、月間障害対応件数を45件→18件、MTTRを平均45分→15分に短縮」のような改善プロセスが書けるかが評価の分かれ目です。
書き方のポイント｜20代インフラエンジニアならではの伝え方
ポイント①：担当インフラの規模を冒頭に明記する
「BtoB SaaSサービス（月間アクティブユーザー約30万人・月間トラフィック約8TB）のAWS基盤運用を担当。EC2 約80台・RDS 約12インスタンス・ElastiCache 約8ノード規模」のように、サービス規模とインフラ規模を冒頭に書くことで業務のスケール感がつかめます。
ポイント②：使用技術と使い方をセットで書く
クラウド（AWS・Azure・GCP）・コンテナ（Docker・Kubernetes）・IaC（Terraform・CloudFormation・Ansible）・CI/CD（GitHub Actions・GitLab CI・Jenkins）・監視（CloudWatch・Datadog・New Relic・Mackerel）への対応を、業務での使い方とセットで書きましょう。「AWS（EC2・RDS・S3・CloudFront・WAFを業務日常運用）」「Terraform（約200リソースをコード管理、レビュー・適用フローも整備）」のように具体性を持たせます。
ポイント③：自動化・改善実績を数字で書く
20代インフラエンジニアが差別化できるポイントは「自動化への姿勢」です。「Ansible Playbook 整備によりサーバー初期構築時間を1台あたり3時間→30分に短縮」「Terraform 化により環境構築時間を従来比80%削減」「GitHub Actions による CI/CD 整備で、デプロイ回数を週1回→週5回に拡大」のような数字を職務経歴書に書きましょう。
20代インフラエンジニアならではの悩みに答える
「設計経験が浅く、運用中心だがどうアピールすればいい」
運用中心の経験は「現場の問題を一番知っている」という強みとして書けます。「障害対応300件以上の経験から、よくある障害パターンと対応手順を整理しチームのランブックに体系化」のように、運用の深い経験を仕組み化に活かしている書き方が評価されます。設計に挑戦している段階なら「現在 AWS Solutions Architect Associate を取得し、小規模システムの設計提案を開始」と書きましょう。
「資格をどう書けばアピールにつながる」
取得資格は「いつ取ったか」「業務でどう活かしているか」をセットで書くと評価が高まります。「AWS SAA（2024年取得）→ 業務で AWS設計レビュー時の判断軸として活用」「LPIC Level 2（2023年取得）→ Linux サーバートラブルシューティングで実務に活用」のような書き方が効果的です。学習中の資格（CKA・AWS SAP など）も「2026年取得目標」と書くと意欲が伝わります。
例文
例①：BtoB SaaS・AWS運用担当（経験1年半・第二新卒）
従業員数約80名のBtoB SaaS企業（月間アクティブユーザー約15万人）にて、AWSインフラの運用・監視を担当。インフラチーム3名体制。
【業務内容】
・AWS環境の運用・監視（EC2 約60台・RDS 約8インスタンス・S3・CloudFront）
・障害対応・一次切り分け（24時間オンコール体制で月平均5回担当）
・Terraform による IaC 実装・既存リソースのコード化
・CloudWatch・Datadog による監視設定・アラート閾値設計
・開発チーム5名からのインフラ問い合わせ対応（月平均20件）
【実績】
・月間障害対応件数：入社時45件 → 1年半後18件に削減（60%減）
・MTTR：平均45分 → 15分に短縮（ランブック整備とアラート閾値見直しによる）
・Terraform 化：手動構築だった約200リソースをコード管理に移行
・AWSコスト削減：Reserved Instance・Spot活用提案で月額インフラコスト約20%削減
・取得資格：AWS SAA（2024年）・LPIC Level 1・2（2023年）
【主な取り組み】
入社初期は障害対応の手順が属人化しており、引き継ぎや夜間対応に時間がかかっていた。障害パターンを「リソース枯渇・ネットワーク・認証・データベース」の4類型に整理し、それぞれの一次対応手順をランブックとして文書化。チーム全員が同じ手順で対応できるようになり、MTTRが大幅に改善した。Terraform 化では既存リソースのインポートから着手し、レビュー必須のPRフローを導入することで、変更管理の透明性を確保した。
自己PRでのアピールポイント
インフラ運用担当として「障害対応の仕組み化」と「IaC・自動化推進」を1年半で実行してきた経験を持つ。現場で発生した課題を仕組みで解決するスタイルで、次の職場でもインフラ運用の改善と自動化推進に貢献したい。AWS SAA取得後は設計レビューにも参加できるよう成長を続けている。
例②：受託開発・複数案件インフラ担当（経験3年・中堅手前）
従業員数約120名のSI・SES企業にて、複数クライアント（金融・小売・メディアの計5社）のAWS/オンプレ混在環境の構築・運用を担当。
【業務内容】
・複数クライアントのインフラ設計・構築・運用（AWS・オンプレ Linux）
・Terraform・Ansible による環境構築の標準化
・Kubernetes（EKS）クラスタの構築・運用（クライアント2社で導入）
・監視基盤（Datadog・Prometheus・Grafana）の設計・実装
・クライアント側担当者への技術提案・導入支援
【実績】
・担当案件数：3年間で計8案件（うち新規構築5件・運用改善3件）
・AWS コスト最適化：クライアント平均で月額インフラコストを15〜25%削減
・環境構築時間：Terraform/Ansible 標準化により従来1週間→1日に短縮
・EKS 移行プロジェクト：オンプレからの移行を計画通り完遂（クライアント2社）
・取得資格：AWS SAP（2025年）・CKA（2024年）・LPIC Level 3（2024年）
【主な取り組み】
複数クライアントを並行担当する中で、案件ごとの非効率を仕組みで解決することに注力した。Terraform モジュール・Ansible Role を社内で共通化し、新規構築時に再利用できるテンプレート集を整備。これにより新規案件の立ち上げ時間を従来比80%削減した。EKS 移行では、移行前のアプリ設計から開発チームと議論して、コンテナ前提の設計に変えることで運用負荷も同時に削減できた。
自己PRでのアピールポイント
複数案件のクラウド構築・運用を並行担当してきた経験と、Terraform・Ansible・Kubernetes での自動化・標準化の実績が強み。「クライアントごとの個別最適と、組織全体の共通化のバランスを取る」スタイルで、次の職場でもインフラ標準化と新規案件展開の両立に貢献したい。
例③：自社サービス・SREサブリーダー候補（経験5年・20代後半）
従業員数約300名のメガベンチャー（月間アクティブユーザー約500万人）にて、SREチームのメンバーとして勤務。3年目からサブリーダーとして後輩2名の指導も担当。
【業務内容】
・自社サービスのAWS/EKS基盤の運用・改善（EC2約200台・EKSクラスタ3つ）
・SLO/SLI設計・エラーバジェット管理・ポストモーテム実施
・CI/CDパイプライン整備（GitHub Actions・ArgoCD）
・後輩SRE2名のコードレビュー・案件指導
・開発チーム10名との連携（インフラ要件相談・キャパシティプランニング）
【実績】
・サービス可用性：99.9% → 99.95% に向上（5年継続）
・MTTRを月平均で従来比40%削減（オンコールローテーション・ランブック整備による）
・AWSコスト：月額インフラコストを2年間で約30%削減（リソース最適化・Spot活用）
・CI/CDパイプライン整備により、デプロイ回数を週2回→週10回に拡大
・後輩2名の育成：両名がオンコール一次対応を独立してできるレベルに成長
【主な取り組み】
SREサブリーダーとして「運用の属人化排除」と「開発チームとの協働」に注力した。オンコール対応を週次でローテーションする仕組みに変更し、特定メンバーへの負荷集中を解消。ポストモーテムを毎月運用化し、障害から学んだ知見をチームに蓄積する文化を作った。開発チームとの連携では「インフラの制約を早期に開発に伝える」ことを意識し、設計段階からインフラチームが参画する仕組みを導入。これによりリリース後の障害発生率が大幅に低下した。
自己PRでのアピールポイント
SREサブリーダーとして「運用と開発の橋渡し」「自動化・仕組み化による属人性排除」を5年間追求してきた経験を持つ。次の職場でもSRE組織の生産性向上と、開発チームとの協働文化づくりに取り組みたい。
書き方ステップ
① 担当したインフラ環境を書き出す
担当サービス・サーバー台数・ユーザー数・トラフィック規模・使用クラウドを書き出します。インフラ職のスケール感の起点になります。
② 数字を3軸で探す
規模（サーバー台数・ユーザー数・トラフィック）、改善（MTTR短縮・コスト削減・障害件数削減）、自動化（IaC化したリソース数・デプロイ頻度向上・構築時間短縮）の3軸で数字を探します。
③ 使用技術と使い方をセットで整理する
クラウド（AWS・Azure・GCP）・コンテナ（Docker・Kubernetes）・IaC（Terraform・Ansible）・CI/CD・監視ツールを、業務での使い方と一緒に書き出します。
④ 取得資格と業務での活用を書く
AWS・Azure・GCP・LPIC・CKA・CKAD などの資格を、取得時期と業務での活用方法とセットで書きましょう。
⑤ 障害対応・改善プロセスを1〜2件詳しく書く
「どんな障害・課題に対し」「どう原因分析・対策実施したか」「結果どう改善したか」のサイクルを1〜2件詳しく書き出します。20代の再現性を示す核心部分です。
NG例 → 改善例｜通らない書き方の直し方
失敗①：担当業務の抽象的な記述
失敗②：技術使用の羅列
失敗③：改善プロセスが見えない
失敗④：自動化・IaCへの取り組みが書かれていない
経験年数別アドバイス
経験1〜2年（第二新卒・若手）
「対応件数」と「資格取得・学習継続」が最大のアピールポイントです。大きな実績がなくても「障害対応300件以上」「AWS SAA取得」「Terraform 学習中・小規模リソースで運用開始」など、行動量と学習姿勢を具体的に書きましょう。
経験3〜4年（中堅手前）
「複数案件・複数環境の運用経験」「IaC・自動化の実装実績」「他チームとの連携経験」が評価の軸になります。改善実績の継続に加えて、「運用ノウハウのドキュメント化・チーム共有」を書くことで差別化できます。
経験5年前後（20代後半）
「サブリーダー・チームリードとしての実績」「SRE的観点（SLO/SLI設計・ポストモーテム）」「開発チームとの協働」が評価の軸になります。30代に近づくにつれ「個人運用の成果」より「チーム成果・仕組み化」が求められ始めます。
よくある質問
Q. インフラエンジニアからSREへのキャリア転換は可能ですか？
可能です。SREでは「コードで運用を改善する」スタイルが中心になるため、Terraform/Ansible/Python などのコーディング経験を職務経歴書で前面に出しましょう。SLO/SLI 設計・ポストモーテムへの関心や勉強会参加も書くと意欲が伝わります。
Q. オンプレ運用しか経験がない場合、クラウド転職は不利ですか？
不利ではありません。「オンプレでの運用経験 + 個人学習でクラウドキャッチアップ中」という書き方で十分通用します。AWS SAA・Azure AZ-104などの資格取得を進めて、学習姿勢を職務経歴書で示しましょう。
Q. 大規模インフラの経験がない場合、どうアピールすればいいですか？
規模より「実装・改善の質」が評価されます。「サーバー20台規模だが、Terraform 全面導入・CI/CD 整備・障害対応プロセス標準化を主導」のように、規模を補う取り組みの深さを書きましょう。
Q. 監視・運用ツールはどこまで書けばいい？
業務で日常使用しているものを「ツール名（用途・期間）」の形で書きましょう。「Datadog（監視ダッシュボード設計・アラート設定・3年）」「New Relic（APM設定・分散トレーシング設定・1年）」のように具体性を持たせます。
Q. 職務経歴書はA4何枚が適切ですか？
1〜2枚が目安です。担当インフラ規模・対応件数・使用技術・改善実績・取得資格など20代インフラエンジニアならではの情報を優先して記載しましょう。GitHub・技術ブログのURLも添えると評価が高まります。
まとめ
- 採用担当者は20代インフラエンジニアに「対応量と学習スピード」「自動化への姿勢」を求めている
- 担当インフラの規模（サーバー台数・サービス規模）を冒頭に明記する
- 使用技術は「使用経験あり」ではなく「何をどう使ったか」で書く
- 自動化・改善実績（IaC化したリソース数・MTTR短縮・コスト削減）を必ず書く
- 障害対応・改善プロセス（どう仕組み化したか）を1〜2件詳しく書く
- 取得資格と業務での活用方法をセットで記載する
20代インフラエンジニアの経験は「対応量と改善サイクル」として必ず評価されます。まずは担当インフラの規模・対応件数・改善した数字・使用技術の具体的な使い方を書き出すところから始めてみてください。
人事・採用担当として1,000名以上の面接、30社の採用支援に携わった経験をもとに、職務経歴書の作成代行・添削を行っています。
採用側での経験をもとに、評価される書類づくりをサポートしています。「経験はあるのに書類で落ちる」という方に特に支持をいただいています。
これまでのご支援数は370名以上。製造・IT・金融・医療・サービス業など、幅広い業界・職種に対応しております。
職務経歴書の書き方にお悩みの方は、お気軽にご相談ください！
