インフラ／クラウド職の職務経歴書｜書き直して反応が変わった点

2020年に転職活動をしたとき、自分の職務経歴書に自信が持てませんでした。当時の私は4年ほどのインフラ経験があり、Linuxサーバーの運用・監視、ネットワーク機器の設定変更、障害対応と原因調査を主な業務としていました。しかし最初に書いた職務経歴書は「何をやったか」の羅列になっていて、エージェントの担当者から「もう少し具体的に書きましょう」とフィードバックをもらいました。

書き直してみると、3社のエージェントに書類を出した結果の反応が変わりました。書類通過率が上がったかどうかは正確には分かりませんが、「この経験は面白いですね」と言われる部分が増え、面接でのやり取りが深くなった実感があります。何を変えたかを振り返ると、主に3つの点でした。

この記事では、私が実際に書き直した際の考え方と、インフラ・クラウド系職種の職務経歴書を改善するための具体的な方法をまとめます。例は全て架空のものです。

職務経歴書で最も変えた点：規模を数字で書く

インフラ系の職務経歴書で最も効果が大きいのは「規模を数字で書くこと」です。

Before（変更前）:

サーバーの運用保守を担当。障害対応と監視対応を行った。

After（変更後）:

Linuxサーバー約60台（Webサーバー20台、DBサーバー10台、バッチサーバー30台）の運用保守を担当。3名チームで24時間監視を分担し、月平均15件の障害アラートに対応。

数字が入ると、採用担当者が「この人がどの規模の環境を扱えるか」を判断できるようになります。60台と600台では求められるスキルが違います。20台の小規模環境しか知らない人と、600台規模の環境を扱ってきた人では、経験の厚みが伝わります。

書くべき数字の例:
- サーバー台数（種類別に分けると尚良し）
- チームの人数と自分の役割
- 対応した障害件数・月次、週次の目安
- 監視対象のシステム数・サービス数
- リードした場合はプロジェクト期間と関わった人数

「正確な数字が分からない」という場合は「約◯◯台」「◯◯台規模」という書き方で構いません。あいまいな「多数のサーバー」という書き方より、「約100台規模」のほうがずっと伝わります。

「自分の判断」を書くことで主体性が伝わる

インフラ系で経験が浅い段階だと、「言われたことをやっていた」という感覚で職務経歴書を書いてしまうことがあります。しかし実際には、日々の業務の中で何らかの判断をしているはずです。

Before（変更前）:

障害対応を行った。

After（変更後）:

障害発生時の一次対応（ログ確認・サービス再起動・上長・ベンダーへのエスカレーション判断）を担当。再発防止のため手順書を更新し、対応時間を平均30分短縮。

「担当した」だけでなく「どんな判断をしたか」「何が変わったか」を書くことで、受け身ではなく主体的に動いていたことが伝わります。

判断を書くときのポイント:
- 「〜を判断した」「〜を提案した」「〜を整備した」という動詞を使う
- 結果（改善効果）を書けると尚良し（ただし確認していない数値は書かない）
- 小さな改善でも、自分が関わった改善は書いて構わない

私の場合、「監視ツールのアラートが多すぎて対応漏れが起きていた問題を改善するため、担当者と相談してアラートのしきい値と重要度設定を見直した」という経験を書いたところ、面接で「どんな判断でしきい値を設定したの？」という深掘りの質問が来ました。これは「書いてよかった」と感じた経験です。

技術スタックを具体的に書く

「Linux、ネットワーク、AWS」という書き方は情報量が少ないです。採用担当者はどのディストリビューション・バージョン・サービスを使っていたかを知りたがっています。

Before（変更前）:

AWS、Linux、ネットワーク

After（変更後）:

OS: CentOS 7.x / Amazon Linux 2
クラウド: AWS（EC2, VPC, ALB, S3, CloudWatch）
監視: Zabbix 5.x
ネットワーク: Cisco Catalystシリーズ（VLAN設定・ルーティング設定）
IaC: Terraform（業務で使用開始）

技術を書くときに気をつけたいのは「使えると言えるレベルか」の自己評価です。よく使う書き方:
- 業務で使用: その技術を日常的に業務で使っている
- 構築経験あり: プロジェクトで実際に構築した経験がある
- 学習中: 個人で学んでいるが業務での使用経験は少ない

業務レベルでない技術まで「経験あり」として書くと、面接での深掘りで困ります。学習中であることを正直に書くほうが、面接官からの信頼を得やすいです。

運用しか経験がない場合の書き方

「設計・構築の経験がなく、運用しかやっていない」という状況を悩みとして持つ人は多いです。しかし運用経験も、書き方次第で評価される職務経歴書になります。

書けることの例:

• 監視設計の経験がなくても、「監視ツールの設定変更や閾値調整の経験」は書ける
• 構築経験がなくても、「手順書の整備・改善の経験」は書ける
• 設計経験がなくても、「障害の原因調査と恒久対策の提案経験」は書ける
• 案件が複数あれば「多様な現場を経験した」という強みになる

運用しか経験がない場合に強調したいのは「現場の実態を知っている」という点です。設計者が見落としがちな運用上の問題（監視が拾えない異常、手順書が実態に合っていない、引き継ぎが難しい構成など）を指摘できるのは、運用経験者の強みです。これは転職先で「設計の実現性を高める視点」として評価されることがあります。

SES・客先常駐が複数の場合の書き方

SESや客先常駐の経験が複数ある場合、案件ごとに職歴を書くのが基本です。ただし、案件数が多い場合は以下のようにまとめることができます。

短期（数ヶ月程度）の案件が複数ある場合:

2019年4月〜2020年3月（SES期間）：複数の顧客先にて以下業務を経験
- 金融系顧客（5ヶ月）：Linuxサーバー監視・運用
- 流通系顧客（4ヶ月）：仮想化基盤（VMware）の運用
- 製造系顧客（3ヶ月）：ネットワーク機器の設定変更

在籍期間が1年以上の案件は詳しく、短い案件は簡潔にまとめると読みやすくなります。採用担当者が「この人の主な経験はどこか」を把握しやすくなります。

SESからの転職に際して、職務経歴書で伝えたいことの整理や、転職活動全体の進め方についてはSESから抜けたいときに検討した選択肢にも書いています。どんな動機でどういう選択肢を検討するかが職務経歴書の方向性にも影響します。

クラウドエンジニアとして書く場合の追加ポイント

オンプレからクラウドに移行した経験がある場合、その移行プロセス自体を書くと評価につながります。

書き方の例:

オンプレ環境のクラウド移行プロジェクトに参加（AWS移行、12ヶ月）。既存のLinux/VMware環境をAWS（EC2, RDS, ALB）に移行するための要件整理、移行計画作成、テスト環境構築を担当。本番移行後の運用引き継ぎドキュメントを整備。

クラウド経験を書く際に強調したいのは:
- 使ったサービス名（EC2、VPC、RDSなど具体的に）
- 担当した作業の範囲（設計・構築・移行・テスト・運用のどれか）
- プロジェクトの規模感（期間・人数・移行したサーバー台数など）

IaC（Terraform、Bicep、AnsibleなどのInfrastructure as Code）の経験は、最近の求人で高く評価される傾向があります。業務での使用経験があれば具体的に書き、個人で学習中であれば「学習中」と明記します。クラウドエンジニアとしてのキャリアパスについてはクラウドエンジニアのキャリアパスも参考にしてください。

職務経歴書のフォーマットと読まれ方

職務経歴書の形式は大きく分けて「編年体（時系列順）」と「キャリア別（スキルや職種ごと）」の2種類があります。インフラ・クラウド系では編年体が一般的です。

採用担当者が職務経歴書を見るとき、最初の10〜15秒で「この人を次に進めるかどうか」を判断することが多いと聞きます。最初に目が行くのは「直近の職歴」と「スキルセット」です。このため、スキルセクション（使用技術一覧）は早めに目に入る場所に置くのが一般的です。

読みやすい職務経歴書の構成例:
1. 職歴サマリー（2〜3行の自己PR）
2. スキルセット（使用技術・ツール・資格一覧）
3. 職務経歴（最新から順に）
4. 自己PR（なぜこの仕事が好きか、何を目指しているか）

文字数は多ければいいわけではなく、A4で2〜3ページが一般的な目安です。それ以上になると読みにくくなります。ただし、インフラ系は技術の列挙で量が増えやすいため、3〜4ページまでは許容範囲とも言われます。

書き直しで気をつけたこと

私が職務経歴書を書き直した際に、エージェントの担当者からもらったフィードバックをいくつか覚えています。

「数字がないと規模が伝わらない」という点は繰り返し言われました。「サーバーを運用していた」では何台か分かりません。「20台規模」なのか「500台規模」なのかで全然違います。

「責任範囲を明確に」というフィードバックも多かったです。「チームで対応した」だけでなく、「そのチームでの自分の役割は◯◯だった」まで書くと、採用担当者が採用後の配置をイメージしやすくなります。

「アクションと結果のセット」で書くことも強調されました。「監視設定を見直した（アクション）→アラート件数が30%削減した（結果）」という形です。結果が出ていなくても「〜を目的として〜を行った」という書き方でアクションの意図は伝わります。

転職活動をどう進めるか、エージェントの使い方も含めた全体像についてはIT・エンジニアの転職活動の進め方に詳しくまとめています。職務経歴書は転職活動の一部に過ぎませんが、書類選考という最初のハードルを越えるための重要なツールです。

職務経歴書のセルフレビューで確認すること

職務経歴書を書いたあと、自分でチェックする際のポイントをまとめます。

数字の確認: すべての職歴に数字が入っているか。台数、期間、人数、件数のいずれかが含まれているかを確認します。「数字がない記述」は、規模感が伝わらない記述です。

動詞の確認: 「担当した」「行った」だけになっていないか。「設計した」「構築した」「改善した」「提案した」「整備した」「調整した」のような主体的な動詞を使っているか確認します。

技術スタックの確認: 技術の羅列になっていないか。単に「AWS」と書くだけでなく、どのサービスを、どんな業務で使ったかが分かるかを確認します。

矛盾がないか: 在籍期間、プロジェクト期間、技術のバージョンなどに矛盾がないかを確認します。在籍期間と担当プロジェクトの期間が合わないと疑問が生じます。

読みやすさ: 1つの職歴の記述が長すぎないか。箇条書きと段落のバランスが取れているか。採用担当者が短時間で要点を把握できるかを意識します。

自分で見直すのが難しい場合は、転職エージェントに添削を依頼するのが有効です。エージェントの担当者は多くの職務経歴書を見ているため、業界の傾向を踏まえたフィードバックをもらえます。

応募先ごとに職務経歴書を変えるか

職務経歴書を1種類作って全求人に送るか、応募先ごとに調整するかという問いがあります。基本的には「共通ベース＋応募先に合わせた強調点の調整」が現実的です。

たとえば、クラウド設計を中心とする会社に応募するときは、クラウド関連の経験を詳しく書き、運用保守の記述はコンパクトにします。逆に、オンプレの大規模環境を持つ会社に応募するときは、物理サーバーやネットワークの経験を前面に出します。

応募先の求人票を読んで「この会社が求めている経験はどこか」を特定し、その部分の記述を厚くする、という作業を毎回やるのが手間ですが、これが書類選考の通過率を左右することがあります。

また、「自己PR」のセクションは応募先に合わせて変えることが多いです。相手の会社の事業内容や課題に触れながら、「自分の経験がどう貢献できるか」を具体的に書くと印象が変わります。

経験年数が少ない場合のアプローチ

経験年数が1〜2年で転職する場合、職務経歴書の「量」は少なくなります。これをカバーするためのアプローチがあります。

学習姿勢を示す: 業務以外での学習（資格取得、個人検証環境での実験、技術書の読書）を職務経歴書に含めることができます。「AWSの学習として個人のAWSアカウントでVPCを設計・構築し、ECSでコンテナを動かす環境を作成」のように具体的に書くと、「動ける人」という印象になります。

貢献した経緯を丁寧に書く: 経験が短い分、「ここで自分が動いた」という部分を丁寧に書きます。たとえば「先輩エンジニアの指示で〜をやった」ではなく「指示を受けた後、自分でドキュメントを読んで設定を行い、動作確認まで担当した」のように、自分の行動範囲を明示します。

志望動機との接続: 経験が少ない場合、「なぜこの会社に応募したか」が重要になります。職務経歴書の自己PRセクションで、現在のスキルと応募先の業務をつなぐ文章を丁寧に書くことが必要です。

資格・学習歴の書き方

インフラ・クラウド系の資格は、職務経歴書で一定の評価を受けます。書き方のポイントは以下の通りです。

取得済みの資格は「取得年月・資格名・発行機関」の形で書きます。たとえば「2024年6月：AWS Certified Solutions Architect – Associate（Amazon Web Services）」のように。

複数の資格がある場合は関連性が高いものを前に書きます。ITインフラ系の求人なら「ネットワーク・サーバー・クラウド」の順で書くと、評価者にとって見やすくなります。

学習中の技術や取得予定の資格は「取得予定：2026年◯月 AZ-104」のように書いて構いません。「今勉強している」ことを示すのは、成長意欲を伝えるうえで有効です。

ただし、資格の記述は補足的なものです。職歴の記述が充実していれば、資格は「プラスアルファ」の要素として機能します。資格が充実していても職歴の記述が薄いと、「資格はあるが実務が浅い人」という印象になりやすいです。資格だけに頼らず、実務での経験を軸にした書き方を心がけましょう。資格の取得順や学習計画についてはAzureの資格取得の順番と学習方法も参考になります。インフラエンジニアの資格選びの全体像についてはインフラ系の資格と転職の関係でも触れています。

職務経歴書の提出後にやること

職務経歴書を送ったあと、選考結果を待つだけでなく「フィードバックを集める」という姿勢が重要です。

書類選考を通過したら、面接で「職歴のどの部分に興味を持ったか」「どんな点を確認したかったか」を逆質問として聞くと、次回の職務経歴書の改善に活かせます。面接官が「この経験は面白いですね」と言ったポイントは、アピールできている部分です。逆に「ここはどういう意味ですか」と聞かれた部分は、説明が不足していた部分です。

書類選考で落ちた場合は、エージェントを通じて「書類で何が足りなかったか」のフィードバックをもらえることがあります。全部の会社からフィードバックが得られるわけではありませんが、もらえた場合は次の改善の材料になります。

転職エージェントを使っている場合は、担当者に職務経歴書を定期的に見直してもらうと効率的です。応募先が変わるたびに「この会社の求人に合わせてどこを強調すればいいか」を相談するだけでも、自分では気づかない改善点が見えてきます。

また、複数の会社に並行して応募している場合は、「どの会社でどの版の職務経歴書を送ったか」を記録しておくことが大切です。面接で職務経歴書の内容について聞かれたとき、どの内容を強調した版を送ったかが分からなくなると準備がしにくくなります。スプレッドシートや手帳で応募管理をしながら職務経歴書のバージョンも管理すると混乱が防げます。

職務経歴書の準備と並行して、面接での話し方を練習しておくことも重要です。面接での準備方法についてはエンジニア面接で実際に聞かれた質問と準備方法に詳しく書きました。職務経歴書で伝えたことを面接でさらに深く説明できるように準備することが、転職活動の精度を上げます。

まとめ

インフラ・クラウド系の職務経歴書は、書き方を変えるだけで伝わり方が大きく変わります。

最も効果があったのは「規模を数字で書く」「自分の判断を書く」「技術を具体的に書く」の3点です。「運用しかやっていない」という状況でも、この3点を意識して書き直すと、職務経歴書の印象は変わります。

書くことが見つからないと感じているなら、日常業務の中の「当たり前にやっていること」を棚卸しするところから始めてみてください。障害対応、手順書の更新、監視の調整、メンバーへの引き継ぎ。こういったことは書いてよい実績です。自分では「たいしたことではない」と感じていることが、採用担当者には「現場を知っている」ことの証拠として映ることがあります。

職務経歴書は完成させて終わりではなく、応募するたびに内容を見直すものです。面接で「ここを詳しく聞かれた」「ここが反応が良かった」という実績をフィードバックして改善していくのが現実的なアプローチです。

最後に、職務経歴書は「見てもらうもの」です。採用担当者が短時間で読んで「この人と話してみたい」と感じてもらうための文書です。そのために必要なのは「自分をよく見せること」ではなく「自分の経験を正確に・具体的に伝えること」です。自信がない部分も含めて、正直に書いて適切にアピールすることが、ミスマッチの少ない転職につながります。転職活動全体の進め方についてはIT・エンジニアの転職エージェントの選び方も参考にしてください。

職務経歴書の質を上げることと、転職の準備を同時に進めることで、活動全体のスピードが上がります。書けば書くほど「自分が何ができるか」が整理されてくる感覚があるので、最初から完璧を目指すより、まず書いてみて改善していく方が現実的です。インフラエンジニアとしてのキャリアの方向性と照らし合わせながら、どのポジションに応募するかを決めていくのが効率的な転職活動のやり方です。