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

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

職種：クラウドエンジニア ｜更新日 2026/7/4

クラウドエンジニアの職務経歴書は、「何を使ったか」ではなく「何を設計・改善したか」が評価の分岐点になる。AWSやGCPといったプラットフォーム名を列挙するだけでは書類通過率は上がらない。採用担当者や技術面接官が確認したいのは、アーキテクチャ上の意思決定の背景、運用改善の定量的な成果、そして組織・プロジェクトへの貢献範囲である。

本記事では、クラウドエンジニアの職務経歴書において「通過する書類」と「通過しない書類」を分ける構造的な差異を解説し、実務で応用できるテンプレートの型を提示する。

採用担当者がクラウドエンジニアの書類で最初に確認すること

技術的な深さと「守備範囲」の読み取り

クラウドエンジニアという職種名は広義であり、インフラ構築・コスト最適化・SRE的な運用・DevOpsパイプライン整備まで、実務の射程は人によって大きく異なる。採用担当者はまず、その候補者が「どの層を、どの深さで担当してきたか」を職務経歴書から読み取ろうとする。

そのため、記述の粒度が重要になる。「AWSを用いたインフラ構築」という一文では、VPC設計から始めたのか、既存環境の保守だけを行ったのかが判別できない。「マルチAZ構成のVPC設計からECS/Fargateへのコンテナ移行まで一貫して担当」と書けば、担当範囲が格段に伝わりやすくなる。

スキルセットの裏付けとしての実績

スキルシートに記載されたサービス名が「業務での実績」で裏付けられているかどうかも、精度の高い採用担当者は注意深く確認する。「使用経験あり」と「設計責任を持って導入した」は全く異なる習熟度を示す。職務経歴の各プロジェクト記述が、スキルシートの内容と整合しているかを意識して記述する必要がある。

職務経歴書の全体構成

クラウドエンジニアの職務経歴書は、以下の順序で構成するのが標準的かつ読みやすい。

1. 職務要約（3〜5行）
2. スキルサマリー（プラットフォーム・資格・言語など）
3. 職務経歴（プロジェクト単位、逆年代順）
4. 資格・認定
5. 自己PR（任意）

採用担当者が最初に読む「職務要約」と、最も評価の重みが置かれる「職務経歴の各プロジェクト記述」の質が、書類通過率に直結する。

各セクションの書き方

職務要約：専門領域と貢献の方向性を3〜5行で示す

職務要約は、書類全体の「導線」として機能する。技術スタック・担当フェーズ・規模感・強みの方向性を、簡潔かつ具体的にまとめる。

書き方の例（NG）

AWSを中心としたクラウドインフラの構築・運用に5年間携わってきました。チームとの協力を大切にし、課題解決に取り組んでいます。

この記述では、具体的な担当フェーズも成果の方向性も伝わらない。

書き方の例（推奨）

AWSを主軸としたクラウドインフラ設計・構築に5年従事。直近3年はBtoBのSaaSプロダクト（ユーザー数30万人規模）を対象に、マイクロサービス移行とコスト最適化を主導。IaCによるインフラ管理の標準化やCI/CDパイプライン整備を通じ、デプロイ頻度の向上と障害対応コストの削減に貢献してきた。

職務要約は「何者か」を宣言する場であり、謙虚さよりも正確な自己定義が求められる。

スキルサマリー：サービス名の羅列ではなく習熟度を示す

スキルシートはカテゴリに分けて整理し、可能な限り習熟度の目安を付記するとよい。「使用可能」と「設計・導入経験あり」を同列に並べると、実際のスキル水準が読み取りにくくなる。

年数はあくまで目安であり、年数そのものより「何を設計・担当したか」の内容が重要であることは、職務経歴のプロジェクト記述で補完する。

職務経歴：STAR構造でプロジェクトを記述する

職務経歴の各プロジェクトは、以下の要素を意識して記述すると採用担当者が内容を理解しやすくなる。

• Situation（背景・状況）：どのような組織・プロダクト・フェーズだったか
• Task（課題・目標）：何が問題で、何を達成しなければならなかったか
• Action（担当内容）：自分が具体的に何を設計・実装・意思決定したか
• Result（成果）：定量的な改善や貢献の事実

ケーススタディ：書類通過率が上がるプロジェクト記述の型

以下は、中堅SaaS企業でインフラ刷新を担当したエンジニアの職務経歴記述の例（実際の案件を類型化したもの）。

【プロジェクト名】ECサイト向けSaaSのクラウドインフラ刷新（2022年4月〜2024年3月）

【組織・規模】 従業員200名規模のSaaS企業。インフラチーム4名。月間アクティブユーザー約50万人規模のプロダクトを対象とした。

【背景・課題】 オンプレミス環境で稼働するモノリシックなシステムが、トラフィック増大に伴いスケールの限界を迎えていた。また、手動オペレーションが多く、デプロイ頻度は月2回程度に留まっており、障害対応に1件あたり平均4時間を要していた。

【担当内容】

• AWS上でのマイクロサービスアーキテクチャ設計をリード。ECS/Fargateを中心とした構成を設計し、既存のRDSからの移行計画を策定
• TerraformによるIaC化を主導。全インフラのコード管理を実現し、環境差異を排除
• GitHub ActionsとCodePipelineを組み合わせたCI/CDパイプラインを構築
• CloudWatchおよびDatadogを活用した監視体制を整備し、アラートのチューニングを実施
• セキュリティ面ではIAMの最小権限設計とSecurity Hubによる継続的な診断体制を導入

【成果】

• デプロイ頻度：月2回→週3〜4回（チームの開発サイクルに合わせた自動化による）
• 障害対応時間：平均4時間→平均40分（監視精度の向上とランブックの整備による）
• インフラコスト：前年比で約20%削減（リザーブドインスタンスとSpot Instanceの組み合わせによる最適化）
• 翌年度の新機能リリース数が前年比1.8倍に向上（デプロイ安定性の改善が寄与）

このような記述では、担当者が「このエンジニアは何を考え、何を意思決定し、どのような成果をもたらしたか」を具体的に把握できる。成果は100%の精度でなくても、目安の数値と根拠を添えて記述することで信頼性が高まる。

書類通過率を下げやすい記述パターン

以下は実際に散見される、評価されにくい記述の傾向をまとめたものである。

よくある質問

Q. 担当プロジェクトが多すぎる場合、どれを書けばよいですか？

すべてを同じ粒度で記載する必要はない。応募先の求める経験・スキルセットと最も重なるプロジェクトを詳述し、残りは1〜3行程度の概要に留めるとよい。応募先ごとに「どのプロジェクトを前面に出すか」を調整することが、書類の精度を高める。

Q. 数値の成果がない場合、どう書けばよいですか？

厳密な数値がなくても、「設計したアーキテクチャの規模感（ユーザー数・サービス数・チームの人数）」「担当した意思決定の範囲」「改善の方向性」を具体的に書くことで、経験の重さは十分に伝わる。「〜を主導した」「〜の設計判断を担った」といった記述も、担当範囲を示す有効な表現である。

Q. 在籍期間が短いプロジェクトや短期間の会社があります。どう扱えばよいですか？

在籍期間の短さを隠す必要はないが、「その期間に何を担当したか」を具体的に書くことで、短期間であっても実務の密度が伝わる。転職回数や在籍期間についての懸念は面接で補足できるが、職務経歴書では内容の充実度で印象を補うことが先決である。

Q. AWS資格を持っていると、書類評価にどの程度影響しますか？

資格はスキルの一定の目安として参照されるが、職務経歴の内容が優先される傾向にある。資格があっても実務記述が薄い書類より、資格がなくても設計・成果の記述が充実している書類の方が評価されやすい。資格はスキルサマリーに記載しつつ、職務経歴の内容で実力を示すことが望ましい。

まとめ

クラウドエンジニアの職務経歴書における最大の課題は、「使用経験の列挙」と「設計・意思決定の記述」が混在し、担当の深さが採用担当者に正確に伝わらない点にある。職務要約で全体像を宣言し、各プロジェクト記述では背景・課題・担当内容・成果をSTAR構造で整理することで、書類の読みやすさと説得力が大きく向上する。スキルシートの内容は職務経歴の記述で必ず裏付け、定量的な成果は目安であっても根拠とともに添えることが評価の分岐点になる。職務経歴書は「事実の羅列」ではなく「自分の市場価値を構造的に示す文書」として捉えることが、書類通過率を高める上での基本的な