ミドルSRE/DevOpsエンジニアの友人から職務経歴書レビューを依頼されました。勤務先は基盤/SRE。日常は「サービス所有者とSLO」に深く関与しているのに、冒頭は『サービス所有者とSLOを担当。関係部署を支援』という作業列挙のままでした。
日本の書類選考でも、最初の画面で裁量と成果が見えないと、実力があっても『作業者』に見えます。面接では語れるのに書類に出ていない、というギャップが落ちる原因になっていました。
ミドルSRE/DevOpsエンジニアは、担当レーンの一気通貫とトレードオフ・測定可能な成果を最初のブロックで示してください。
日本の選考で見られるポイント
日本では履歴書（基本情報・写真習慣は企業による）と職務経歴書を分けるのが一般的です。ミドルSRE/DevOpsエンジニアでは、職務経歴書で「担当範囲・工夫・数値化した成果・周囲への影響」を時系列またはプロジェクト単位で示します。自己PRは抽象的な性格論ではなく、再現可能な強み（例：品質を落とさず納期を守る手順を標準化した）に落とします。年齢・通勤・離職理由の書き方は募集要項と企業文化に合わせて過剰な個人情報を出さない慎重さも必要です。
キーワードは求人票の語彙に寄せつつ、丸写しにせず、あなたが実際に担った工程と裁量境界が読める一文にしてください。
ミドルSRE/DevOpsエンジニアが示すべきこと
- サービス所有者とSLO — 制約・判断・検証可能な結果をセットで。
- レーンのインシデント指揮 — 制約・判断・検証可能な結果をセットで。
- デプロイ安全策 — 制約・判断・検証可能な結果をセットで。
- トイル自動化バックログ — 制約・判断・検証可能な結果をセットで。
- 担当フリートのコスト — 制約・判断・検証可能な結果をセットで。
一、サービス所有者とSLO
ミドルSRE/DevOpsエンジニアの『サービス所有者とSLO』は、作業者か裁量者かを見抜く論点です。期限・リスク・顧客・規制など制約を先に書き、何を変えたかを示します。
いまいちな例
サービス所有者とSLOを担当。関係者と連携し、AWS/K8s/Terraformなどの標準ツールを使用。
伝わる例
14日制約下でサービス所有者とSLOを一気通貫で主担当し、手順/チェックを改め3サイクルで手戻り約12%削減。AWS/K8s/Terraformの観点を1枚の意思決定ログに落とし関係者と合意。
AWS/K8s/Terraformは信頼の補助線。主役は制約→判断→測定結果です。
ミドルSRE/DevOpsエンジニアにとって「サービス所有者とSLO」は、制約→判断→検証可能な結果の三点が揃って初めて説得力を持ちます。面接官が次の質問を思いつかない書き方は、まだ作業報告の域を出ていません。
書き方の要点
- サービス所有者とSLOのビジネス/顧客リスクから書き始める
- 『担当』を『主担当/改善/検証/エスカレーション』に置換
- 面接でノートなしで説明できる数字を一つ残す
面接で深掘りされやすい質問
- サービス所有者とSLOのどの工程を具体的に変えましたか？
- 何もしなかった場合のリスクは？
- 数値はどう検証しましたか？
二、レーンのインシデント指揮
ミドルSRE/DevOpsエンジニアの『レーンのインシデント指揮』は、作業者か裁量者かを見抜く論点です。期限・リスク・顧客・規制など制約を先に書き、何を変えたかを示します。
いまいちな例
レーンのインシデント指揮を担当。関係者と連携し、AWS/K8s/Terraformなどの標準ツールを使用。
伝わる例
13日制約下でレーンのインシデント指揮を一気通貫で主担当し、手順/チェックを改め4サイクルで手戻り約15%削減。AWS/K8s/Terraformの観点を1枚の意思決定ログに落とし関係者と合意。
AWS/K8s/Terraformは信頼の補助線。主役は制約→判断→測定結果です。
ミドルSRE/DevOpsエンジニアにとって「レーンのインシデント指揮」は、制約→判断→検証可能な結果の三点が揃って初めて説得力を持ちます。面接官が次の質問を思いつかない書き方は、まだ作業報告の域を出ていません。
書き方の要点
- レーンのインシデント指揮のビジネス/顧客リスクから書き始める
- 『担当』を『主担当/改善/検証/エスカレーション』に置換
- 面接でノートなしで説明できる数字を一つ残す
面接で深掘りされやすい質問
- レーンのインシデント指揮のどの工程を具体的に変えましたか？
- 何もしなかった場合のリスクは？
- 数値はどう検証しましたか？
三、デプロイ安全策
ミドルSRE/DevOpsエンジニアの『デプロイ安全策』は、作業者か裁量者かを見抜く論点です。期限・リスク・顧客・規制など制約を先に書き、何を変えたかを示します。
いまいちな例
デプロイ安全策を担当。関係者と連携し、AWS/K8s/Terraformなどの標準ツールを使用。
伝わる例
12日制約下でデプロイ安全策を一気通貫で主担当し、手順/チェックを改め5サイクルで手戻り約18%削減。AWS/K8s/Terraformの観点を1枚の意思決定ログに落とし関係者と合意。
AWS/K8s/Terraformは信頼の補助線。主役は制約→判断→測定結果です。
ミドルSRE/DevOpsエンジニアにとって「デプロイ安全策」は、制約→判断→検証可能な結果の三点が揃って初めて説得力を持ちます。面接官が次の質問を思いつかない書き方は、まだ作業報告の域を出ていません。
書き方の要点
- デプロイ安全策のビジネス/顧客リスクから書き始める
- 『担当』を『主担当/改善/検証/エスカレーション』に置換
- 面接でノートなしで説明できる数字を一つ残す
面接で深掘りされやすい質問
- デプロイ安全策のどの工程を具体的に変えましたか？
- 何もしなかった場合のリスクは？
- 数値はどう検証しましたか？
四、トイル自動化バックログ
ミドルSRE/DevOpsエンジニアの『トイル自動化バックログ』は、作業者か裁量者かを見抜く論点です。期限・リスク・顧客・規制など制約を先に書き、何を変えたかを示します。
いまいちな例
トイル自動化バックログを担当。関係者と連携し、AWS/K8s/Terraformなどの標準ツールを使用。
伝わる例
11日制約下でトイル自動化バックログを一気通貫で主担当し、手順/チェックを改め6サイクルで手戻り約21%削減。AWS/K8s/Terraformの観点を1枚の意思決定ログに落とし関係者と合意。
AWS/K8s/Terraformは信頼の補助線。主役は制約→判断→測定結果です。
ミドルSRE/DevOpsエンジニアにとって「トイル自動化バックログ」は、制約→判断→検証可能な結果の三点が揃って初めて説得力を持ちます。面接官が次の質問を思いつかない書き方は、まだ作業報告の域を出ていません。
書き方の要点
- トイル自動化バックログのビジネス/顧客リスクから書き始める
- 『担当』を『主担当/改善/検証/エスカレーション』に置換
- 面接でノートなしで説明できる数字を一つ残す
面接で深掘りされやすい質問
- トイル自動化バックログのどの工程を具体的に変えましたか？
- 何もしなかった場合のリスクは？
- 数値はどう検証しましたか？
五、担当フリートのコスト
ミドルSRE/DevOpsエンジニアの『担当フリートのコスト』は、作業者か裁量者かを見抜く論点です。期限・リスク・顧客・規制など制約を先に書き、何を変えたかを示します。
いまいちな例
担当フリートのコストを担当。関係者と連携し、AWS/K8s/Terraformなどの標準ツールを使用。
伝わる例
10日制約下で担当フリートのコストを一気通貫で主担当し、手順/チェックを改め7サイクルで手戻り約24%削減。AWS/K8s/Terraformの観点を1枚の意思決定ログに落とし関係者と合意。
AWS/K8s/Terraformは信頼の補助線。主役は制約→判断→測定結果です。
ミドルSRE/DevOpsエンジニアにとって「担当フリートのコスト」は、制約→判断→検証可能な結果の三点が揃って初めて説得力を持ちます。面接官が次の質問を思いつかない書き方は、まだ作業報告の域を出ていません。
書き方の要点
- 担当フリートのコストのビジネス/顧客リスクから書き始める
- 『担当』を『主担当/改善/検証/エスカレーション』に置換
- 面接でノートなしで説明できる数字を一つ残す
面接で深掘りされやすい質問
- 担当フリートのコストのどの工程を具体的に変えましたか？
- 何もしなかった場合のリスクは？
- 数値はどう検証しましたか？
SRE/DevOpsエンジニアの定量辞書
説明できる数字だけを。4–6個選んでください：
- リードタイム：例「クリティカルパス14→8日」。注意：除去したボトルネック
- 品質：例「手戻り/欠陥20%減」。注意：単位を定義
- 信頼性/満足：例「SLAやCSAT +3pt」。注意：期間と母数
- コスト/ムダ：例「残業やロス15%減」。注意：範囲を明記
数字を書く前に、対象・測定方法・自分の寄与を即答できるように。
ミドルSRE/DevOpsエンジニアあるある落とし穴
落とし穴一：ツール名コスプレ
触ったツール一覧はSRE/DevOpsエンジニアの判断力の証明になりません。
落とし穴二：孤独な％
比較対象・期間・裁量がない割合は追問で崩れます。
落とし穴三：『弊社で』過多
主語が常に集団だと、あなたの寄与が見えません。
落とし穴四：資格の詰め込み
資格は検索用。成果の代わりにはなりません。
落とし穴五：ふわっと自己PR
ミドルSRE/DevOpsエンジニアの冒頭を性格論で埋めるのは損です。
ミドルSRE/DevOpsエンジニアのための補足資料
一次面接後に出せるよう、守秘に配慮した成果サマリー、改善前後の指標、社内向け資料の抜粋を用意しておきましょう。職務経歴書は「面接で深掘りしてもらうための見出し」であるべきで、機密の詳細を詰め込みすぎないことが日本企業でも好印象につながります。
提出前チェックリスト
- サービス所有者とSLOを制約→行動→結果に1行書き直す
- レーンのインシデント指揮の％に比較対象を付ける
- 成果のないツール列を削る
- 履歴書と職務経歴書の職種表記を揃える
- 上位3行それぞれに深掘り質問を3つ用意する
ミドルSRE/DevOpsエンジニアの職務経歴書は、忙しさの伝記ではなく制約下の判断マップです。冒頭の各行が、即答できる深い質問を誘うまで書き直してください。
現場記憶を職務経歴書の言葉に落とす（ミドルSRE/DevOpsエンジニア）
経験不足ではなく、書き方が作業報告のまま、というケースが多いです。以下を自分の事実に置き換えて練習してください。
練習 1
「生の記憶」はこうなりがちです：「サービス所有者とSLOが遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 2
「生の記憶」はこうなりがちです：「サービス所有者とSLOの指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 3
「生の記憶」はこうなりがちです：「レーンのインシデント指揮が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 4
「生の記憶」はこうなりがちです：「レーンのインシデント指揮の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 5
「生の記憶」はこうなりがちです：「デプロイ安全策が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 6
「生の記憶」はこうなりがちです：「デプロイ安全策の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
現場記憶を職務経歴書の言葉に落とす（ミドルSRE/DevOpsエンジニア）
経験不足ではなく、書き方が作業報告のまま、というケースが多いです。以下を自分の事実に置き換えて練習してください。
練習 1
「生の記憶」はこうなりがちです：「サービス所有者とSLOが遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 2
「生の記憶」はこうなりがちです：「サービス所有者とSLOの指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 3
「生の記憶」はこうなりがちです：「レーンのインシデント指揮が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 4
「生の記憶」はこうなりがちです：「レーンのインシデント指揮の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 5
「生の記憶」はこうなりがちです：「デプロイ安全策が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 6
「生の記憶」はこうなりがちです：「デプロイ安全策の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
現場記憶を職務経歴書の言葉に落とす（ミドルSRE/DevOpsエンジニア）
経験不足ではなく、書き方が作業報告のまま、というケースが多いです。以下を自分の事実に置き換えて練習してください。
練習 1
「生の記憶」はこうなりがちです：「サービス所有者とSLOが遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 2
「生の記憶」はこうなりがちです：「サービス所有者とSLOの指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 3
「生の記憶」はこうなりがちです：「レーンのインシデント指揮が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 4
「生の記憶」はこうなりがちです：「レーンのインシデント指揮の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 5
「生の記憶」はこうなりがちです：「デプロイ安全策が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 6
「生の記憶」はこうなりがちです：「デプロイ安全策の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
現場記憶を職務経歴書の言葉に落とす（ミドルSRE/DevOpsエンジニア）
経験不足ではなく、書き方が作業報告のまま、というケースが多いです。以下を自分の事実に置き換えて練習してください。
練習 1
「生の記憶」はこうなりがちです：「サービス所有者とSLOが遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 2
「生の記憶」はこうなりがちです：「サービス所有者とSLOの指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 3
「生の記憶」はこうなりがちです：「レーンのインシデント指揮が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 4
「生の記憶」はこうなりがちです：「レーンのインシデント指揮の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 5
「生の記憶」はこうなりがちです：「デプロイ安全策が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 6
「生の記憶」はこうなりがちです：「デプロイ安全策の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
現場記憶を職務経歴書の言葉に落とす（ミドルSRE/DevOpsエンジニア）
経験不足ではなく、書き方が作業報告のまま、というケースが多いです。以下を自分の事実に置き換えて練習してください。
練習 1
「生の記憶」はこうなりがちです：「サービス所有者とSLOが遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 2
「生の記憶」はこうなりがちです：「サービス所有者とSLOの指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 3
「生の記憶」はこうなりがちです：「レーンのインシデント指揮が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 4
「生の記憶」はこうなりがちです：「レーンのインシデント指揮の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 5
「生の記憶」はこうなりがちです：「デプロイ安全策が遅れそうで何を切るか決めた週」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。
練習 6
「生の記憶」はこうなりがちです：「デプロイ安全策の指摘を再発防止チェックにしたこと」。四段で書き直します。(1)その場の制約や異常、(2)原因経路の仮説、(3)取った具体アクション（道具・関係者）、(4)検証方法。削除テスト：社名と肩書きを隠してもSRE/DevOpsエンジニアの仕事に見えるか。追問テスト：ログを見ずになぜを三つ答えられるか。