SRE転職の職務経歴書で「何を書けばいいか分からない」と悩んでいませんか？
SRE経験がないエンジニアの場合、自分の実務経験をどうSRE視点に翻訳するか迷い、結果として「担当業務をただ列挙した」だけの職務経歴書になってしまいがちです。
そのままでは、採用担当の目に止まらず書類選考で落ちてしまいます。SREポジションは求める人物像が明確で、書き方次第で通過率が大きく変わる職種です。
この記事では、採用担当が職務経歴書で実際に確認する5つのポイントと、SRE経験がない場合でも通過率を上げる書き方のフレームワークを解説します。
この記事でわかること
– 採用担当がSRE職務経歴書で見る5つのポイント
– 職務経歴書の基本構成とSRE向けの書き方
– SRE経験がない場合のインフラ経験の言い換え方
– NG例とOK例の具体的な比較
SRE転職で職務経歴書が重要な理由
書類選考通過率の現実
SRE転職では、書類選考の通過率が他のエンジニア職より低い傾向があります。理由は採用要件が具体的なため、採用担当者が職務経歴書を見た瞬間に「この人はSREとして機能するか」を判断できてしまうからです。
インフラエンジニアからSREへの転職を目指す場合、技術的なスキルが実際には十分あっても、職務経歴書の書き方が一般的なインフラエンジニアのフォーマットのままでは「SREとして自分を見せる」ことができていません。
書き方を変えるだけで書類通過率が変わる——これがSRE転職の職務経歴書の特徴です。
SRE採用担当が職務経歴書で何を見ているか
採用担当がSREの職務経歴書に求めるのは、「信頼性への思考習慣があるか」 です。
具体的には以下の観点で確認しています。
- 障害・トラブルを経験しているか（経験の有無ではなく向き合い方）
- 監視・アラートを自分で設計したことがあるか
- インシデント後に改善につなげているか
- 数値で語れる実績があるか
「Linuxサーバーの運用保守を担当していました」だけでは伝わりません。「何を監視し、どう自動化し、何を改善したか」を読み取れる書き方が必要です。
一般的なエンジニアの職務経歴書との違い
| 観点 | 一般的なエンジニア | SRE向けの書き方 |
|---|---|---|
| 技術スタック | 使ったツール列挙 | 監視・IaC・CI/CDを軸にカテゴリ整理 |
| 業務内容 | 作業を時系列で記述 | 信頼性・自動化・改善の観点で記述 |
| 実績 | 「〜を担当しました」 | 「〜により障害件数を50%削減しました」 |
| 成長 | 取得資格一覧 | 現在取り組んでいる技術・改善活動 |
SRE職務経歴書の基本構成
graph TD
A["職務経歴書の基本構成"] --> B["① プロフィール・スキルサマリー
（3〜5行で強みを凝縮）"]
A --> C["② 職務経歴
（プロジェクト単位で記述）"]
A --> D["③ 技術スタック一覧
（SRE観点でカテゴリ分け）"]
A --> E["④ 資格・学習中の技術"]
C --> C1["期間・規模・役割"]
C --> C2["担当業務（SRE視点の言語化）"]
C --> C3["定量的な実績・改善数値"]
B --> B1["採用担当が最初に読む
→ ここで印象が決まる"]
① プロフィール・スキルサマリー
職務経歴書の冒頭に3〜5行で自分の強みを凝縮します。採用担当が最初に読む場所で、ここで印象が決まります。
書き方の例（SRE向け）
AWSを中心としたクラウドインフラの構築・運用経験5年。CloudWatchを活用した監視設計と、Terraformによるインフラのコード管理を実務で経験。オンコール対応を通じたインシデント対応と事後改善（ポストモーテム）を継続的に実施。SREとして信頼性向上に携わりたく、転職を検討しています。
ポイントは「何ができるか（技術）」だけでなく「どう考えてきたか（信頼性思考）」を含めることです。
② 職務経歴の書き方（プロジェクト単位）
プロジェクトごとに以下の項目を記述します。
【プロジェクト名 / 期間 / 規模】
・サービス: ECサイト（月間PV: 200万）
・チーム: 5名（うちSRE: 2名）
・期間: 2023年4月〜2025年3月（2年）
【担当業務】
・CloudWatchによるメトリクス監視設計・アラートチューニング
・Terraformを用いたEC2・RDS・VPCのインフラコード管理
・GitHub Actionsを使ったCI/CDパイプライン構築・運用
・障害発生時の一次対応とポストモーテム作成
【実績・成果】
・アラートノイズを整理し、誤報アラート件数を月200件→30件に削減
・インフラのコード化によりデプロイ作業時間を平均2時間→20分に短縮
・オンコール対応体制を整備し、深夜対応件数を月8件→2件に削減
業務内容は 「何を」「どうやって」「どうなった」 のセットで書くのが基本です。実績の数字は「感覚値」ではなく、当時のデータやログから拾えるものを使いましょう。
③ 技術スタック一覧の書き方
SREに特化した技術スタックの整理方法を使います。一般的な「使用技術: AWS, Docker, Python, Ansible」という羅列ではなく、SRE観点でカテゴリを分けます。
■ クラウド・インフラ
AWS（EC2, RDS, ELB, VPC, S3, IAM）, GCP（BigQuery）
■ 監視・オブザーバビリティ
CloudWatch, Datadog, Prometheus, Grafana
■ IaC（インフラのコード管理）
Terraform（3年）, AWS CloudFormation（1年）
■ CI/CD・デプロイ
GitHub Actions, AWS CodePipeline, Jenkins
■ コンテナ・オーケストレーション
Docker, Kubernetes（EKS）
■ 言語・スクリプト
Python（運用自動化）, Bash（シェルスクリプト）, Go（入門レベル）
「何年使っているか」「得意レベルかどうか」も括弧書きで補足すると採用担当に伝わりやすくなります。
採用担当が実際に見る5つのポイント
graph TD
TOP["採用担当が見る5つのポイント"] --> P1["① 可観測性・監視設計の経験
CloudWatch / Prometheus / Grafana"]
TOP --> P2["② SLO/SLI/エラーバジェットの理解
数値での目標設定経験"]
TOP --> P3["③ IaCとCI/CDの実務経験
Terraform / GitHub Actions"]
TOP --> P4["④ インシデント対応と改善実績
ポストモーテム・MTTR改善"]
TOP --> P5["⑤ 定量的な実績の記述
「障害件数50%削減」等の数字"]
P1 --> PASS["✅ 書類選考通過"]
P2 --> PASS
P3 --> PASS
P4 --> PASS
P5 --> PASS
ポイント①：可観測性・監視設計の経験
SREの中核は「見えていないものを見えるようにする」ことです。CloudWatch・Datadog・Prometheus・Grafanaなどの監視ツールを 自分で設計した経験 があるかどうかを確認されます。
採用担当が確認すること
– 単純に「使っていた」のか、「設計・構築した」のか
– アラートの閾値設計・ノイズ削減に取り組んだ経験があるか
– メトリクス・ログ・トレースの三本柱を意識しているか
職務経歴書には「CloudWatchを使用」ではなく「CloudWatchでカスタムメトリクスを設計し、アラートの誤報率を80%削減した」のように 設計・改善の観点 を加えましょう。
ポイント②：SLO/SLI/エラーバジェットの理解
SREの採用担当が職務経歴書で最も確認するのが、SLO（サービスレベル目標）・SLI（サービスレベル指標）・エラーバジェットへの理解です。
経験がある場合は具体的な数値を書きます。
「稼働率99.9%をSLOとして設定し、SLIをALBの5xxエラー率で計測。エラーバジェットが20%を切った段階で機能開発を一時停止し、信頼性対応にリソースを集中させるルールをチームで合意した」
実務でSLOを設定した経験がない場合でも、「社内提案として試みた」「個人プロジェクトで設計した」など学習の姿勢を示せます。
ポイント③：IaCとCI/CDの実務経験
TerraformやAWS CloudFormationを使ったインフラのコード管理と、GitHub Actions・Jenkins・AWS CodePipelineを使ったCI/CDの実務経験は、現在のSRE採用でほぼ必須です。
確認されること
– 自分でゼロから書いたことがあるか（既存の流用だけではないか）
– チームで共同管理した経験（tfstateのS3管理・レビュー文化）
– 環境分離（dev/stg/prod）の設計経験
ポイント④：インシデント対応と改善実績
「障害が起きたとき、どう動くか」だけでなく「障害後に何を改善したか」を採用担当は読んでいます。
職務経歴書に書けるインシデント対応の実績例：
- ポストモーテムを作成し、障害の根本原因を特定した
- MTTR（平均復旧時間）を計測し、改善施策を実施した
- オンコール体制を整備し、一人あたりの対応件数を削減した
「障害対応の経験がある」という記述より、「対応して改善につなげた経験がある」という記述のほうが採用担当に刺さります。
ポイント⑤：定量的な実績の記述
これが最も差がつくポイントです。「〜を担当しました」という記述は、採用担当の印象に残りません。数字を使って実績を語ることが重要です。
| NG（印象に残らない） | OK（具体的・定量的） |
|---|---|
| CloudWatchでの監視対応を担当 | 誤報アラートを月200件→30件に削減し、オンコール対応負荷を65%低減 |
| Terraformでインフラを管理 | Terraform化によりインフラ構築時間を平均8時間→45分に短縮 |
| インシデント対応を経験 | P1インシデントのMTTRを平均120分→35分に改善（手順書整備・自動化） |
| 監視設定を改善した | SLO達成率を月次でレポート化し、四半期ごとにSLO見直しを実施 |
数字が出せない場合は「〇〇に改善した」という方向性と、「どんな施策をやったか」を具体的に書くだけでも大きく変わります。
SRE経験がない場合の職務経歴書の書き方
インフラ経験をSRE視点で言い換える
SRE経験がなくても、インフラエンジニアの経験はSRE視点で言い換えられます。以下のフレームワークを使ってください。
| 実際の業務 | SRE視点での言い換え |
|---|---|
| サーバーの死活監視を設定 | 監視設計（CloudWatchアラート）で障害の早期検知を実現 |
| EC2のAMIバックアップ設定 | DR対応のためのバックアップ設計（RTO・RPOを意識） |
| Ansibleでサーバーセットアップ自動化 | IaCによるインフラの再現性確保・属人化排除 |
| 障害発生時の一次対応 | インシデント対応フローの実践（エスカレーション・通知含む） |
| 定期的なパッチ適用作業 | 計画的なメンテナンス実施（変更管理の一環） |
キーワードは「信頼性」「自動化」「再現性」「改善」。これらの観点で自分の業務経験を見直すと、書けることが増えます。
個人プロジェクト・ポートフォリオの活用
実務でSRE的な業務がなかった場合、個人プロジェクトで補完することは有効です。
記述できる内容の例
– 個人ブログ・Webサービスに CloudWatch + Terraform で監視環境を構築
– GitHub Actionsで自動デプロイパイプラインを構築（CI/CD実践）
– GrafanaとPrometheusで自宅サーバーの監視ダッシュボードを構築
GitHubリポジトリのURLを添えると「実際に動くものを作った証拠」になります。
資格・学習中の技術の書き方
資格欄は取得済みのものだけでなく、「学習中」「取得予定」も記載することで、成長意欲を示せます。
■ 保有資格
AWS Solutions Architect - Associate（2024年取得）
AWS SysOps Administrator - Associate（2025年取得）
■ 学習中・取得予定
Certified Kubernetes Administrator（CKA）: 2026年6月取得予定
Terraform Associate: 2026年内取得予定
■ 自己学習
Udemy「AWS×SRE入門コース」受講中
SRE本（Google著）精読・実践メモをGitHubで公開
NG例とOK例を比較する
職務内容の書き方
NG例（よくある書き方）
・AWS環境のサーバー管理・運用保守を担当
・障害発生時の対応
・定期的なバックアップ確認
・パッチ適用作業の実施
OK例（SRE視点の書き方）
・CloudWatchを使った監視アラートの設計・チューニング（誤報率80%削減）
・Terraformによるインフラコード管理の導入（新規環境構築時間を1/6に短縮）
・インシデント発生時のエスカレーションフロー整備と手順書作成
・週次ポストモーテムの主導による再発防止策の継続実施
技術スタックの書き方
NG例
使用技術: AWS, Linux, Python, Docker, Ansible, Jenkins, Git
OK例
■ 監視・オブザーバビリティ
CloudWatch（3年/設計・チューニング経験あり）, Datadog（1年/ダッシュボード構築）
■ IaC
Terraform（2年/module設計・tfstate S3管理含む）
■ CI/CD
GitHub Actions（2年）, Jenkins（1年）
■ コンテナ
Docker（3年）, Kubernetes入門（学習中）
実績・成果の書き方
NG例
・監視体制の強化に貢献しました
・インフラの安定性向上を図りました
OK例
・CloudWatchアラートのノイズ削減により、オンコール呼び出し件数を月40件→8件に改善
・Terraform導入による環境構築の自動化で、月次15時間のルーティン作業をほぼゼロ化
まとめ
SRE転職の職務経歴書で採用担当が見ているのは、「SREとしての思考習慣があるか」です。
重要なポイントをまとめます。
- 可観測性・監視設計の経験: 設計・チューニングの観点で書く
- SLO/SLI/エラーバジェットの理解: 数値目標を設定・運用した経験を書く
- IaCとCI/CDの実務経験: 自分で構築・設計した経験を強調する
- インシデント対応と改善実績: 「対応した」より「改善につなげた」を書く
- 定量的な実績: 必ず数字を入れ、前後比較で示す
SRE経験がない場合でも、インフラ経験をSRE視点で言い換えることで、書類通過率を大きく高められます。
書き方を変えたあとは、転職エージェントのプロフェッショナルに添削してもらうのも有効な手段です。SRE転職に強いエージェントを活用すると、職務経歴書のブラッシュアップから求人紹介まで一括でサポートしてもらえます。
関連記事
– SRE求人票から逆算｜AWSエンジニアがSRE転職に必要なスキルと優先順位
– SRE転職のポートフォリオの作り方 – GitHubで何を見せるか
– SREのキャリアパス – シニアSRE・SREマネージャーへの道
コメント