SREのスキルシートの書き方｜面談で評価される実績の見せ方

SREのスキルシートは、監視やコンテナの道具の名前より、障害対応でどの役割を担ったか、オンコールにどう関わったか、改善の前と後で何が変わったかを書くのが基本です。SREの案件は、同じ名前でも中身が運用の改善から基盤の構築まで幅広く、読み手は「本番の障害の場に立ったことがあるか」「仕組みを変えた経験があるか」をシートから判断しようとします。数字は、社外に出せない値を避け、割合や傾向で書きます。

全体の構成はスキルシートの基本をご覧ください。案件で求められるスキルの中身はSREの案件で求められるスキル、経験の棚卸しと独立の準備はSREがフリーランスになるにはで扱っています。ここでは、シートへの書き方と見せ方に絞って説明します。

肩書きより「担った仕事」で書く

SREの案件に応募する方には、インフラの運用担当やバックエンドの開発者として、SREに近い仕事をしてきた方が多くいます。肩書きがSREでなかったことは、隠す必要も、書き換える必要もありません。

プロジェクト欄の「立場」には実際の肩書きを書き、そのうえで担当内容にSREの仕事として読める部分を書き出します。

• 運用担当として：監視の見直し、障害の振り返りの主催、手作業の自動化
• 開発者として：リリースの仕組みの改善、性能の調査、障害時のコードの調査
• インフラ構築の担当として：構成のコード化、復旧の手順の整備、容量の見積もり

肩書きをSREに書き換えると、面談で当時の体制を聞かれたときに話がずれます。「肩書きは運用担当。SLOの設定と振り返りの仕組みづくりを主導」のように、肩書きと中身を並べて書くほうが、経験は正しく伝わります。

障害対応は「役割」と「その後」を書く

SREのシートで最も差が出るのが、障害対応の書き方です。「障害対応を担当」の一言では、アラートを受けて連絡しただけなのか、原因を突き止めて仕組みを変えたのかが分かりません。

障害対応での役割を、次のように書き分けます。

これは書き方を示すための例です。大切なのは、障害の「その後」まで書くことです。振り返りで決めた対策を、監視の追加やリリースの手順の変更として実際に入れたところまで書けると、障害対応を仕組みに変えられる人だと伝わります。

個別の障害の内容（どのサービスが、いつ、どのくらい止まったか）は、参画先にとって外に出したくない情報です。シートでは「決済の処理が遅くなる障害」のように種類でぼかし、日付や影響の大きさは書かないようにします。

オンコールの関わり方を1行で書く

オンコールの経験は、案件によって求められることも、求められないこともあります。どちらの案件にも判断材料になるよう、関わり方を1行で書いておきます。

• 「数名の交代制で、週ごとにオンコールを担当（夜間の一次対応を含む）」
• 「オンコールには入らず、日中の二次対応と振り返りを担当」
• 「オンコールの体制と呼び出しの基準を設計。不要な呼び出しを減らす見直しを実施」

3つ目のように、オンコールの体制そのものを見直した経験は、SREの案件で特に目に留まりやすい項目です。オンコールに入れるかどうかは働き方の条件でもあるので、基本情報の「働き方」の欄にも、対応できる範囲を書いておきましょう。

改善の成果は「前と後」を割合で書く

SREの仕事の成果は、数字で書くと伝わりやすい一方で、そのまま書くと参画先の内部の情報になる値が多くあります。たとえば、SLOの目標値や、実際の稼働率、障害の件数などです。

成果は、前と後の変化を割合や傾向で書きます。

• 「デプロイにかかる時間を半分程度に短縮」
• 「夜間の呼び出しの回数が大きく減った」
• 「手作業だった証明書の更新をなくし、関連する問い合わせがなくなった」
• 「障害の原因の特定にかかる時間が短くなった（トレースの導入後）」

SLOについては、目標の値そのものより、何をSLIにして、SLOを何の判断に使ったかを書くほうが、経験の中身が伝わります。「応答の成功率をSLIにし、残りのエラーバジェットを見てリリースを止める運用を作った」のような書き方です。

トイルの削減は、前と後の作業の流れを1行ずつ書くと伝わります。「申請を受けて手作業で権限を付与 → 申請のフォームから自動で付与し、記録が残る形に」のように書けば、金額や時間の正確な値がなくても、何を変えたかが分かります。

道具は「何のために使ったか」と組み合わせる

SREのスキル一覧は、監視・コンテナ・IaC・CI/CDの道具が並びやすい欄です。名前だけを並べるのではなく、使い道を添えます。

これは書き方を示すための例です。プログラミングの行は、SREの案件で見られることが多い部分です。運用の自動化のために書いたコードがあれば、規模が小さくても書いておきましょう。

Kubernetesの知識を示す資格として、CKA（Certified Kubernetes Administrator）があります。2026年10月時点のLinux Foundationの案内では、コマンドラインで課題を解く実技の試験で、認定の有効期間は2年とされています。シートには取得年月と有効期限を書き、期限が切れたものは「取得歴」として分けます。

プロジェクト欄の記入例

ここでは、Webサービスの運用改善を担当した場合を想定しています。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年半程度）
案件概要：サービス業向け 一般の利用者が使うWebサービスの信頼性の改善
規模・立場：基盤チーム数名（肩書きはインフラ担当。SLOの導入と振り返りの仕組みづくりを主導）
担当工程：運用、改善の企画と実装
使用技術：Kubernetes、Terraform、OpenTelemetry、CI/CD、Go
オンコール：数名の交代制で担当。後半は呼び出しの基準の見直しを担当
障害対応での役割：原因の調査と、振り返りの主催。対策として監視の追加とリリース手順の変更を実施
工夫・成果：応答の成功率をSLIにし、エラーバジェットの残りでリリースを判断する運用を開発チームと合意した。不要なアラートを整理し、夜間の呼び出しが大きく減った

この例では、肩書きと中身を並べ、オンコールと障害対応での役割を独立した行にしています。面談では、SLOを開発チームとどう合意したかを聞かれることがあります。答えられる深さで書くことが大切です。

よくある質問

SLOを導入した経験がありません。SREの案件に向けてどう書けばよいですか？

監視のアラートの見直し、障害の振り返り、手作業の自動化など、信頼性に関わる仕事を拾い出して書きます。SLOの経験がなくても、何を測り、何を判断に使っていたかを書けば、SREの考え方に近い経験として読まれます。上流の仕事へ広げる考え方は上流工程の案件に入るために必要な経験も参考になります。

障害の件数や稼働率などの数字は書かないほうがよいですか？

参画先の実際の値は、社外に出せない情報であることが多いため、そのまま書かないほうが無難です。前と後の変化を「半分程度に」「大きく減った」のように割合や傾向で書けば、成果は伝わります。判断に迷う場合は、参画先との秘密保持の取り決めを確かめてください。

オンコールに入れない場合、スキルシートで不利になりますか？

オンコールのない案件もあるため、入れないこと自体を隠す必要はありません。基本情報の働き方の欄に対応できる範囲を書き、プロジェクト欄では日中の二次対応や振り返り、仕組みの改善など、担ってきた仕事を厚く書きましょう。