DevOpsエンジニアの職務経歴書の書き方｜書類通過率を上げる実例テンプレート
DevOpsエンジニアの職務経歴書は、記載すべき技術スタックの種類が多く、かつ「何を・どの粒度で書けば採用担当者に伝わるか」の判断が難しい書類である。本記事では、書類通過率を左右する構造的な問題点を整理したうえで、採用担当者・技術面接官の双方が重視する記載要素、実務に即したテンプレートの型、そして陥りやすい落とし穴を順に解説する。
DevOpsエンジニアの職務経歴書が難しい理由
DevOpsエンジニアという職種は、インフラ・CI/CD・セキュリティ・開発者支援・組織改善など、担当業務の幅が極めて広い。そのため、職務経歴書を書く際に「すべての経験を並列に羅列する」か「絞りすぎて薄く見える」かという両極端に陥りやすい。
また、DevOpsは成果が「組織・プロセスの変化」として現れる場合が多く、コードを書くエンジニアと比較して定量化が難しいという特性がある。この点が書類評価においてネックになるケースは少なくない。
採用側が職務経歴書で確認したいのは、大きく次の3点に集約される。
- 技術的な実装力：どのツール・プラットフォームを、どの深さで扱えるか
- 課題解決の文脈：技術選定や改善活動の背景にある思考の筋道
- 組織・チームへの影響：変化をどう定量・定性的に示せるか
この3点を構造的に伝える書類設計が、通過率を左右する本質的な要因となる。
採用担当者が最初に見る「冒頭サマリー」の設計
職務経歴書の冒頭には、3〜5文程度のプロフィールサマリーを置くことが一般的だが、DevOpsエンジニアの場合、ここに含める要素として以下が有効である。
- 主要な経験領域（例：クラウドインフラ設計、CI/CDパイプライン構築、SRE的な運用改善）
- 代表的な技術スタック（多くても5〜7個程度に絞る）
- 組織規模・事業フェーズの文脈（スタートアップ、エンタープライズ、グローバルなど）
- キャリアで一貫して取り組んできたテーマ
「Kubernetes・Terraform・GitHub Actionsの経験があります」という羅列ではなく、「マイクロサービス移行期のプラットフォームチームにおいて、開発者の自律的なデプロイを支える仕組みを構築してきた」という文脈の提示が、読み手の解像度を高める。
スキルセクションの記載粒度
技術スタックの一覧は必要だが、書き方の粒度を誤ると「スキルシートを貼り付けただけ」という印象を与える。以下の分類軸で整理することが望ましい。
| カテゴリ | 記載例 | 粒度の目安 |
|---|---|---|
| クラウドプラットフォーム | AWS（EKS・RDS・IAM・CloudWatch等）、GCP | 使用サービスを括弧内に列挙 |
| コンテナ・オーケストレーション | Kubernetes（本番運用3年）、Docker | 経験年数・運用規模を添える |
| IaC | Terraform（モジュール設計経験あり）、Ansible | 設計レベルか利用レベルかを区別 |
| CI/CDツール | GitHub Actions、ArgoCD、Jenkins | パイプライン設計の有無を明示 |
| モニタリング・オブザーバビリティ | Datadog、Prometheus、Grafana | 構築か運用のみかを区別 |
| プログラミング・スクリプト | Python（自動化スクリプト作成）、Bash、Go（読み書き可） | 習熟度を正直に記述 |
| セキュリティ | SAST/DAST導入、シークレット管理（Vault） | 担当範囲を明示 |
「使ったことがある」と「設計・構築・運用まで担った」は評価が大きく異なる。後者を明確に伝えるためにも、粒度の補足説明を短い語句で添えることが重要である。
職務経歴の記述：STAR+数値の構造
各プロジェクト・職務の記述は、以下の構造で書くと技術的背景と成果が整理されやすい。
【プロジェクト概要】
事業内容・規模・当該プロジェクトの位置づけ
【担当業務】
自分が担った具体的な役割（設計・実装・推進・レビュー等）
【技術スタック】
プロジェクト内で使用した技術の組み合わせ
【成果・インパクト】
定量：〇〇を△△%改善、リードタイムをX日からY日に短縮 等
定性：組織として初めて△△を導入、チームの自律的デプロイを実現 等
定量化の難しい成果については、「定性でも文脈とセットであれば十分評価される」という認識を持つとよい。重要なのは、「課題があり→自分がこう判断し→この技術を選び→こう実装し→組織にこう影響した」という因果の流れが読み取れることである。
ケーススタディ：書類通過につながる記述の型
以下は、ある経験を「薄い記述」と「深い記述」で対比した例である。固有の数値はあくまで参考として読んでほしい。
【薄い記述の例】
CI/CDパイプラインの構築・運用を担当しました。GitHub ActionsとArgoCD等のツールを使い、デプロイの効率化に貢献しました。
【深い記述の例】
開発チーム拡大（10名→30名）に伴いデプロイ手順が属人化・長時間化していた課題に対し、GitHub Actions＋ArgoCD＋Helmを組み合わせたGitOpsパイプラインを設計・構築。各チームが独立してステージング環境へデプロイできる仕組みを整備した。結果として、リリースリードタイムを平均5日から1日未満に短縮。またオンボーディング手順のコード化により、新規エンジニアの初回デプロイまでの期間が約2週間から3日程度に改善した。
差異は情報量だけではない。「なぜその技術を選んだか」「誰のどの課題を解いたか」「どの程度の影響が出たか」が読み取れるかどうかが、技術面接官の「この人に会ってみたい」という判断を左右する。
年収レンジと書類評価の関係
職務経歴書の質は、受けるポジションの年収レンジとも密接に関係する。以下は一般的な市場の傾向であり、企業規模・事業フェーズによって大きく異なる点に留意してほしい。
| 経験年数の目安 | 想定される役割 | 年収レンジの目安 |
|---|---|---|
| 2〜4年 | ツール運用・パイプライン保守が中心 | 500〜700万円前後 |
| 4〜7年 | プラットフォーム設計・チームリード | 700〜1,000万円前後 |
| 7年以上 | 組織横断のDevOps戦略・採用・マネジメント | 1,000〜1,300万円前後 |
上位レンジのポジションを狙う場合、書類で求められるのは「技術の深さ」だけでなく、「組織・プロセスを変えた実績」と「技術選定の意思決定プロセス」の記述が重要になる傾向がある。
よくある質問
Q. 技術スタックが多すぎて絞れない場合、どう整理すればよいですか？
応募ポジションのJDを起点に、「現職でメイン利用しているもの」「設計・構築まで担当したもの」を優先して前に出す方法が有効です。使用経験があるだけのツールは「利用経験あり」と補足し、深度の違いを明示することで読み手の誤解を防げます。
Q. SRE経験とDevOps経験は分けて書くべきですか？
役割の定義が企業によって異なるため、書類上は「担当した業務内容」で整理することをお勧めします。SREとしてSLO設計・エラーバジェット管理を担っていたのであればその文脈を明示し、DevOpsエンジニアとしてのCI/CD改善と並列に記載しても問題ありません。名称よりも実態の記述を優先してください。
Q. 社内ツールや非公開プロジェクトの実績はどこまで書いてよいですか？
秘密保持義務の範囲を確認したうえで、具体的な製品名や顧客名を伏せた形で「業種・規模感・技術的な取り組み内容・成果の方向性」を記述するのが基本的な判断軸です。「toB向けSaaSプロダクト（月間アクティブユーザー数万規模）のインフラを担当」といった抽象化は一般的に認められる範囲です。
Q. GitHub等のポートフォリオリンクは添付すべきですか？
公開できるリポジトリがあれば添付することは有効ですが、「書類の補完」として位置づけるのが適切です。職務経歴書本文に文脈が十分に記載されていれば、ポートフォリオは加点要素にとどまります。逆に、書類の記述が薄くポートフォリオで補おうとするアプローチは、採用担当者の段階で止まるリスクがあります。
まとめ
DevOpsエンジニアの職務経歴書で通過率を左右するのは、技術スタックの量ではなく「課題→判断→技術選定→成果→組織への影響」という因果の流れを記述できているかどうかである。スキルセクションは深度の違いを明示し、職務記述はSTAR＋数値の構造で整理することで、技術面接官が読んでも採用担当者が読んでも解像度が高い書類になる。年収レンジが上がるほど、技術の実装力に加えて「組織を動かした実績」の記述が差別化要因になる傾向がある。書類の質に自信が持てない場合や、現在の市場での評価軸を確認したい場合は、担当領域に詳しいキャリアアドバイザーへの相談を選択肢に入れてみてほしい。