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

SREの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：SRE ｜更新日 2026/7/4

SRE（Site Reliability Engineering）の職務経歴書は、インフラエンジニアやバックエンドエンジニアのそれと記述の型が大きく異なります。採用担当者や技術面接官が確認したいのは「何を構築したか」ではなく「信頼性・可用性・効率性をどのように定義・改善したか」という思考の軌跡です。本稿では、書類選考を通過しやすい職務経歴書の構成原則から、SREに特有の記述パターン、よく見られる失敗例まで、実務的な観点で解説します。

SRE職務経歴書の評価軸を理解する

SREポジションの採用担当者が職務経歴書を読む際、技術スタックの列挙よりも優先して確認するポイントが3つあります。

信頼性への定量的な関与 SLO（Service Level Objective）・SLI（Service Level Indicator）・エラーバジェットをどのように定義・運用したか。具体的な数値（可用性の目標値や改善幅など）が記載されているかどうか。

オートメーション思考の有無 手動作業を削減するためにどのような自動化を設計・実装したか。Toil削減の文脈で語れるエピソードがあるか。

組織・開発チームとの協働 開発チームとのオンコール体制設計、ポストモーテム文化の導入など、技術と組織の両面に関与した経験があるか。

これらの観点を念頭に置くと、「何を書くべきか」の優先順位が自然と定まります。

職務経歴書の全体構成

SREの職務経歴書は、以下の5ブロックで構成するのが標準的です。

1. 職務要約：SREとしての専門領域と経験年数を2〜4文で簡潔に示す
2. スキルサマリー：技術領域・ツール・資格を分類整理する
3. 職務経歴（メイン）：各社での役割・課題・アプローチ・成果を記述する
4. プロジェクト詳細（任意）：特に訴求したいプロジェクトを深掘りする
5. 学習・資格・登壇歴：継続的な学習姿勢と専門性の補強

紙面が2〜3ページに収まることを意識しつつ、職務経歴の項目に全体の60〜70%の分量を割くことが理想です。

スキルサマリーの書き方

スキルサマリーは採用担当者が最初にスキャンする箇所です。カテゴリを区切って記述すると視認性が高まります。

「SRE実践」カテゴリは、インフラエンジニアとの差別化において重要です。ツールだけでなくSREの思想・実践に親しんでいることを明示する意図があります。

職務経歴の書き方：STAR変形型テンプレート

SREの職務経歴記述において効果的なのは、STAR法（Situation / Task / Action / Result）をSRE文脈に合わせて変形した型です。

記述テンプレート

【役割】SREエンジニア（チーム人数：X名）
【期間】20XX年X月〜20XX年X月

■ 担当領域
〇〇サービス（月間アクティブユーザー数：〜XX万人規模）の信頼性・可用性設計と運用改善

■ 背景・課題
・デプロイ頻度の増加に伴い、障害発生時の平均復旧時間（MTTR）が長期化していた
・アラートが適切に整理されておらず、オンコール担当のアラート疲労が顕在化していた

■ 取り組み
・SLI/SLO を開発チームと共同定義し、エラーバジェットによるリリース可否判断フローを導入
・Prometheus / Grafana を用いてアラートルールを全面的に見直し、ノイズとなるアラートを削減
・Runbookの整備とオンコールローテーションの再設計により、対応負荷を分散

■ 成果
・MTTR を平均XX分から約XX分に短縮（約XX%改善）
・アラート件数を月間XX件→XX件程度に削減し、オンコール対応工数を週あたりXX時間削減
・エラーバジェット消費の可視化により、開発チームとのリリース調整コストが低減

この型のポイントは、「何を作ったか」ではなく「なぜ取り組んだか（背景・課題）」と「どの程度改善されたか（成果）」を軸に記述することです。成果数値は概算・目安であっても記載することで、採用担当者の解像度が高まります。数値が開示できない場合は「一定幅の改善」「チームでの定性評価として改善を確認」など、背景を添えた代替表現で補うとよいでしょう。

ケーススタディ：経歴の「見え方」を変えた記述の改善例

改善前（インフラエンジニア的な記述）

AWSを用いてECS / RDSの構築・運用を担当。Terraformによるインフラのコード化を推進。CloudWatchによる監視設定を行った。

改善後（SRE的な記述）

月間数百万リクエストを処理するAPIサービスの信頼性向上を担当。可用性目標（SLO）を設定していない状態から、開発チームと協議の上で月次可用性99.9%をSLOとして定義し、SLIとして成功レスポンス率・レイテンシP99を選定。Terraformによりインフラをコード管理しドリフトを排除。CloudWatchアラームを再設計し、意味のある閾値のみを残したことでオンコール件数を削減した。

同じ経験であっても、「信頼性の定義と改善」という文脈で語り直すことで、SREとしての思考回路が伝わりやすくなります。これはスキルセットを「盛る」行為ではなく、読み手に合わせた文脈の翻訳です。

SRE職務経歴書でよく見られる記述の問題点

ツールの羅列で終わっている

「Kubernetes / Terraform / Datadog を使用」という記述は、採用担当者に何も判断材料を与えません。「なぜ選択したか」「どのような規模・課題に適用したか」を一言添えるだけで情報密度が大きく変わります。

成果が「構築した」で止まっている

「EKSクラスタを構築した」は構築事実の報告であり、SREとしての成果ではありません。「構築した結果、デプロイ頻度が週次から日次に向上し、障害時の切り戻し時間が短縮された」という形まで記述を展開することが重要です。

SREと運用保守の違いが伝わらない

障害対応・監視・オンコール対応だけを列挙すると、運用保守エンジニアの経歴と区別がつきません。「改善のサイクルを設計した」「ポストモーテムを主導した」「開発チームへの信頼性文化の浸透を行った」など、エンジニアリングと組織の両面への関与が伝わる記述を加えることで差異が明確になります。

よくある質問

Q. 経験年数が2〜3年と浅い場合、どう書けばよいですか？

経験年数が短い場合でも、SREとしての思考軸が伝わる記述は可能です。担当した改善施策のスコープが小さくても「なぜその改善が必要だったか」「どのような指標で成果を確認したか」を丁寧に書くことで、思考の深さを示せます。また、個人学習・OSSへの貢献・社内勉強会の主導なども、SREへの職業的関心を補完する材料として有効です。

Q. 数値が社外秘で書けない場合、どのように対処すればよいですか？

多くの企業で詳細な数値は開示できないため、採用担当者もこの状況は理解しています。「X倍程度」「大幅な削減」という粒度でも、「改善の方向性・幅感」が伝われば評価の対象になります。数値の代わりに「チーム内でのフィードバックを受けて継続採用された」「本施策が社内標準として横展開された」といった定性的な事実を添えると説得力が補えます。

Q. 複数のクラウドプロバイダーに携わった経験がある場合、どう整理すべきですか？

スキルサマリーで両者を並記したうえで、職務経歴の文中ではどのプロジェクトでどちらを使ったかを明確にすることが重要です。「AWSとGCPどちらも使える」という万能感よりも、「このプロジェクトではAWSのEKSを採用し、その理由は〇〇だった」という文脈のある記述のほうが、技術選定への関与と思考力が伝わりやすくなります。

Q. SRE専任ポジションではなく、インフラエンジニアとしてSRE的な業務を兼務していた場合は？

職種タイトルがSREでなくても、SRE的な業務経験を職務経歴書に記載することは適切です。「担当業務の中でSLO設計・オブザーバビリティ改善・Toil削減に関与した」という形で明示し、スキルサマリーの「SRE実践」カテゴリに該当項目を加えることで、採用担当者がSRE経験として読める構造にできます。

まとめ

SREの職務経歴書において最も重要なのは、「信頼性の課題を構造的に把握し、改善サイクルを設計・実行した」という思考の軌跡を伝えることです。ツールや構築事実の列挙から、「背景・課題・取り組み・成果」という流れに記述を再構成するだけで、書類の印象は大きく変わりやすい傾向があります。数値は概算・目安であっても積極的に記載し、開示が難しい場合は定性的な事実で補うことで情報密度を維持できます。SREとしての専門性は、構成と文脈の工夫によって正確に伝達可能です。現状の職務経歴書で自分の経験が適切に伝わっているか確認したい方は、SRE領域に知見を持つキャリアアドバイザーへの相談も、客観的なフィードバックを得る手段として検討する価値があります。