転職や社内異動でSREの職務経歴書を書く方に向けて、技術リストの書き方を整理します。
エンジニア向けの職務経歴書指南では「技術キーワードを並べるだけでは評価されない」という指摘がよく出ます。DockerやAWS、CI/CDといった単語をずらりと並べても、採用側が知りたいのは「その技術で何を解決したか」です。これはSRE（サイトの信頼性を維持する役割）やインフラ担当者にとって、むしろ一般的なWeb開発者以上に重要な視点になります。
なぜなら、SREの仕事は個々のツールの操作よりも「障害が起きたときに何を判断し、どう仕組み化したか」に価値があるからです。以下では、職務経歴書のキーワード列挙をSRE文脈の実績表現に変換する具体的な手順を解説します。
キーワード列挙がなぜ評価されにくいのか
「Docker, Docker Compose, CI/CD, GitHub Actions, Linux, 監視」のような並記は、資格の有無しか伝えません。
これは採用側から見ると「触ったことがある」以上の情報を持たない記述です。
実務では、同じDockerでも「本番のコンテナ起動失敗をどう切り分けたか」「リソース制限（cgroupによるCPU/メモリの上限設定）をどう調整したか」の経験差が大きく効きます。
つまり技術名は「入り口」であって、評価対象は「その技術を使って何を構築・運用・修復したか」という一段深い情報です。
SRE視点での書き換え手順
技術リストをSREの実績表現に直す作業は、次の5つの観点に沿って棚卸しすると進めやすくなります。
1. SLO・可用性設計の経験を数値で書く
SLO（Service Level Objective、サービスレベル目標。可用性やレイテンシの許容範囲を数値で定義したもの）を設計・運用した経験があれば、必ず数値で書きます。
「可用性を意識した運用」ではなく「月間稼働率99.9%のSLOを設定し、エラーバジェット（許容できる障害時間の残量）の消費状況を週次でレビューする体制を構築」のように書くと、判断力が伝わります。
SLOを扱ったことがない場合は、まず自分のチームが運用しているサービスに明文化されたSLOがあるか、社内のダッシュボードや運用ドキュメントを確認するところから始めると良いでしょう。
2. IaCはツール名でなく変更管理の実績で語る
TerraformやPulumiといったIaC（Infrastructure as Code、インフラ構成をコードで管理する仕組み）は、単に「Terraformを使用」と書くのではなく、状態管理やレビュー体制まで書けると差が出ます。
例えば「Terraformで50以上のAWSリソースを管理し、terraform planの差分をPRレビューに組み込み、意図しない変更を防止」のような書き方です。
PulumiのようにTypeScriptやPythonでインフラを記述するツールを使っている場合は、既存のアプリケーションコードのテスト資産を流用できた点も実績になります。
自分の環境を確認する際は、terraform state listでどれだけのリソースをコード管理しているか、git logでインフラ変更のレビュー履歴が残っているかをまず見てみてください。
3. オブザーバビリティは「検知から復旧まで」を書く
「Application monitoring」という単語だけでは、ダッシュボードを眺めていただけなのか、実際に障害検知から原因特定まで担当したのかが分かりません。
オブザーバビリティ（システム内部の状態を外部から観測・推測できる状態にする設計思想。メトリクス・ログ・トレースの3本柱で構成される）を扱った経験があるなら、どのツールでどんな障害を何分で特定できたかを書きます。
例えば「PrometheusのメトリクスとGrafanaのアラートで異常を検知し、分散トレーシングでレイテンシ増加の原因コンポーネントを15分以内に特定」のような表現です。
自分が使っている監視スタックを棚卸しする際は、社内のGrafanaやDatadogのダッシュボード一覧、アラートルールの設定画面を開いて、自分が作成・修正したものがどれかを確認してみてください。
4. コスト最適化の実績は削減率で示す
クラウドコストの最適化は、SREやインフラ担当者ならではの評価軸です。
「AWSの利用経験あり」ではなく「未使用のEBSボリュームとRIの見直しでクラウド費用を月次20%削減」のように、具体的な削減率や対象リソースを書くと説得力が増します。
コスト最適化の経験がまだない場合は、AWSならCost ExplorerやCompute Optimizer、GCPならRecommenderといった標準ツールで、自分のプロジェクトに未使用リソースがないか一度確認するところから始められます。
5. 障害対応は「仕組み化」まで書く
障害対応の経験を書く際は、対応した回数よりも「再発防止をどう仕組みにしたか」が評価されます。
例えば「ポストモーテム（障害後に原因と再発防止策を振り返る文書）のテンプレートを整備し、是正アクションの完了率を追跡する運用を導入」のような書き方です。
これはDevOps（開発と運用を一体で回す文化・手法）の文脈でも重視される観点で、単発の火消し経験より継続的な改善の仕組みを持っているかが問われます。
一般的な技術スキル指南との比較で見える差
一般的なエンジニア向けの職務経歴書指南は、プログラミング言語・フレームワーク・データベース・Git操作・基本的なクラウド知識・テストとデバッグ・セキュリティ基礎・AI活用ツールといった項目を「網羅的に持っているか」で評価します。
これらはSREにとっても土台として必要な項目です。特にLinuxの基礎知識やDockerの操作、CI/CD（継続的インテグレーション・継続的デリバリー）の構築経験は、SRE職の応募要件でもほぼ必ず求められます。
ただしSREの評価軸はそこからもう一段深く、「複数のサービスが絡む障害時に、どのレイヤーで何を確認し、どう仕組みで再発を防いだか」という設計思考まで問われる点が大きな違いです。
>ポイント: 技術名の後ろに「どんな数値・仕組みを作ったか」を一文添えるだけで、職務経歴書の説得力は大きく変わります。
今日から確認できること
手元の職務経歴書やスキルシートを開いて、次の3点をチェックしてみてください。
- 技術名の羅列だけになっている箇所がないか（例:「AWS, Terraform, Docker, Prometheus」のみで終わっている行）
- SLOやコスト削減など、数値で書ける実績が言葉だけの説明になっていないか
- 障害対応の記述が「対応した」で終わり、「その後どう仕組み化したか」まで書けているか
該当する箇所が見つかったら、社内のダッシュボード・Terraformのstate・インシデント管理ツール(PagerDutyやOpsgenieなど)の履歴を見返し、具体的な数値や期間を拾い出すところから始めると書き換えやすくなります。
まとめ
技術名の列挙は「触ったことがある証明」にしかならず、SREの評価では「何を設計し、何を数値で改善したか」が問われます。
SLO設計・IaCの変更管理・オブザーバビリティによる検知時間・コスト削減率・障害対応の仕組み化という5つの観点で、自分の経験を数値と具体例に落とし込んでみてください。
まずは今使っている監視ダッシュボードとTerraformのstate、直近のポストモーテムを1件開いて、そこに書ける数値がないか探すところから始めてみると良いのではないでしょうか。