DevOps・クラウドエンジニアの職務経歴書：指標、ツール、資格、記入例

良い DevOps・クラウドエンジニアの職務経歴書は、ツールを成果に結びつけます。何を自動化し構築したか、どの規模か、リリース、信頼性、セキュリティ、コストがどう変わったかを示しましょう。AWS、Docker、Kubernetes を並べるだけで終わらせず、実際のサービスと担当範囲を書きます。デプロイ頻度や復旧時間など、説明できる指標を使います。日本では案件ごとに期間、規模、担当工程をまとめる形式が一般的です。この記事では DevOps、クラウド、SRE、プラットフォームエンジニアを対象に、修正例と記入例を紹介します。

最初に確認されること

採用担当者は、クラウド基盤、環境の規模、担当範囲、改善の根拠を見ます。求人をよく読みましょう。プラットフォーム、SRE、クラウド移行では重視点が異なります。応募先に合わせた調整も参考になります。

• 冒頭：氏名、職種、連絡先、関連する成果があれば GitHub。
• 職務要約：経験年数、クラウド基盤、システムの種類、強み。
• スキル：分野別に、深く説明できるものだけ。
• 職務経歴：期間、チーム規模、担当工程、ツール、成果。
• 資格、主な個人開発、学歴。

ツール一覧ではなく成果を書く

行動、技術、規模、結果の順に書きましょう。設計、主導、運用、参加のどれかも明確にします。次の数字は例です。成果の書き方も参考になります。

修正前：Jenkins で CI/CD を担当。

修正後：GitHub Actions と Argo CD で 40 サービスの CI/CD を再構築。リリースを週 1 回から 1 日数回に増やし、変更失敗率を 18% から 7% に改善。

修正前：Kubernetes クラスターを管理。

修正後：1 日 200 万リクエストを処理する Amazon EKS 6 クラスターを運用。無停止のアップグレードを主導し、オートスケーリングでコンピュート費用を 24% 削減。

修正前：監視とオンコールを担当。

修正後：決済サービスに SLO と Prometheus、Grafana のアラートを導入し、不要な通知を削減。平均復旧時間を 55 分から 20 分に短縮。

修正前：Terraform を使用。

修正後：AWS 3 アカウントをポリシーチェック付きの再利用可能な Terraform モジュールへ移行し、環境構築を 3 日から 2 時間に短縮。

書く価値のある指標

DORA の指標はよく知られています。デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間です。可用性、障害件数、クラウド費用、ビルド時間も役立ちます。期間と背景を示し、説明できる数字だけを使いましょう。正確な数字がなければ、規模と確認できた変化を書きます。

スキルを分野別に整理する

分野別の一覧は読みやすく、ATS にも役立ちます。一度使っただけのツールは外しましょう。スキルの書き方も参考になります。

• クラウド：AWS（EKS、Lambda、IAM、VPC）、Azure、Google Cloud。
• IaC：Terraform、Ansible、CloudFormation、Pulumi。
• コンテナ：Docker、Kubernetes、Helm。
• CI/CD：GitHub Actions、GitLab CI、Jenkins、Argo CD。
• 可観測性：Prometheus、Grafana、ELK、Datadog。
• スクリプト・基盤：Linux、Bash、Python、Go、ネットワーク。
• セキュリティ：シークレット管理、イメージスキャン、最小権限。セキュリティ職の解説も参考に。

資格と個人開発

資格は経験を補うもので、代わりにはなりません。AWS Certified DevOps Engineer – Professional、Microsoft Certified: DevOps Engineer Expert、Google Professional Cloud DevOps Engineer、CKA、HashiCorp Terraform Associate などがあります。取得年と有効性を確認しましょう。資格の書き方も参考になります。個人開発は実際に動くものを示し、リポジトリ、構成、結果を書きます。プロジェクト欄も参考に。

経歴に合わせて調整する

• 未経験：検証環境、公開した個人開発、Linux、スクリプトを正直に示します。未経験の書き方も参考に。
• 開発から：リリース自動化、テスト、本番運用の責任。ソフトウェアエンジニアの解説も参考に。
• インフラ運用から：Linux、ネットワーク、バックアップ、障害対応、新しい自動化。キャリアチェンジも参考に。
• シニア：アーキテクチャ判断、移行の主導、コスト、育成。
• SRE：SLO、エラーバジェット、障害の振り返り、信頼性の改善。

短い記入例

人物と数字は架空ですが、形式は応用できます。

田中 大輔｜シニア DevOps エンジニア｜東京｜[email protected]｜GitHub

職務要約：EC と SaaS で 7 年の経験。AWS、Kubernetes、リリース自動化が専門です。

2021 年〜現在　ShopGrid シニア DevOps エンジニア。40 サービスの配信基盤を再構築し、週次から日次のリリースへ。EKS 6 クラスターを運用し、コンピュート費用を 24% 削減。

2018〜2021 年　DataLoop クラウドエンジニア。Terraform で 25 アプリケーションを AWS へ移行。新しいアラートと手順書で復旧時間を 55 分から 20 分に短縮。

スキル：AWS、Terraform、Kubernetes、Helm、GitHub Actions、Prometheus、Python。資格：CKA、AWS DevOps Engineer – Professional。学歴：2017 年　情報工学科 卒業。

よくある失敗

• 規模や成果のない長いツール一覧。
• チーム全体の移行を自分だけの成果にする。
• チュートリアルだけで Kubernetes と書く。
• 期限切れの資格を有効として示す。
• リポジトリに機密情報、内部ホスト名、顧客情報を残す。
• 面接で説明できない指標。

まとめ

最も有力な改善を選び、実際のシステムに結びつけ、求人に合わせましょう。最後に ATS チェッカーで確認します。