SRE転職のポートフォリオの作り方｜GitHubで採用担当に刺さる見せ方を解説

SRE転職

SRE転職を検討しているのに、「ポートフォリオに何を載せればいいかわからない」と感じていませんか。

GitHubにとりあえずコードをアップしても、採用担当が「このエンジニアはSREの実務で使えるか」を判断できなければ、書類選考の通過率は上がりません。スキルがあっても、それを可視化できなければ転職市場では存在しないのと同じです。

本記事では、SRE転職において採用担当が実際にポートフォリオを評価するポイントを整理し、GitHubで 「SREとしての実力」 を証明するための具体的な作り方を解説します。評価されるテーマ選び・READMEの書き方・よくある失敗パターンまで網羅しているため、読み終わる頃には今日から取り組む内容が明確になります。

この記事でわかること
– SRE転職でポートフォリオが重要な理由と採用現場の実態
– GitHubで採用担当が実際に確認するポイント（コード・README・コミット履歴）
– SRE転職に効く5つのポートフォリオテーマと具体例
– 採用担当に刺さるREADMEの書き方テンプレート
– やりがちな失敗パターンと対策

この記事の対象読者
インフラ・バックエンド経験があり、SREへの転職を検討しているエンジニア。GitHubアカウントは持っているが、転職向けのポートフォリオをどう構成すべきかわからない方。

SRE engineer job hunting with GitHub portfolio, laptop screen showing GitHub repository with Terrafo

SRE転職でポートフォリオが重要な理由

SRE求人では「証拠」が求められる

SREの採用において、書類選考通過のカギになるのは 「実際に動いているものを見せられるか」 です。

一般的なインフラ・バックエンドエンジニアの転職では、職務経歴書に「〇〇システムの構築・運用を担当」と書けばある程度評価されます。しかしSREの場合、求められるスキルが「信頼性設計」「可観測性の実装」「自動化」といった抽象度の高いものが多く、文章だけでは実力が伝わりにくいのが現実です。

採用担当やエンジニアが面接前に確認したいのは「この人はIaCで本当にインフラを管理できるのか」「SLOをどう設計して運用しているのか」という 証拠 です。GitHubのポートフォリオは、そのまま「証拠」として機能します。

職務経歴書だけでは伝わらないスキルがある

職務経歴書に書ける内容は、基本的に「業務で経験したこと」に限られます。SRE転職を目指す段階では、まだSRE専任として働いていないケースがほとんどです。

その場合、職務経歴書だけでは以下のようなSRE特有のスキルを証明できません。

  • Terraformを使ったインフラのコード管理
  • CloudWatchによるSLI/SLO設計と実装
  • GitHub ActionsでのCI/CDパイプライン構築
  • Kubernetes（EKS）上のアプリケーション監視設定

これらを「個人でも取り組んでいる」という事実をGitHubで示せると、採用担当の評価は大きく変わります。「未経験だが本気でSREを目指している」という姿勢と実力の両方が伝わるからです。

ポートフォリオで差がつく転職市場の実態

SRE転職の競合は、インフラ経験豊富なエンジニアばかりではありません。むしろ 「GitHubにSRE関連のリポジトリが充実しているかどうか」 で合否が分かれるケースが多いです。

実際、転職エージェントのヒアリング事例でも「GitHubのポートフォリオが充実していた候補者は、書類選考で圧倒的に通過率が高い」という声があります。同じスペックなら、証拠を出せる人が優先される。それがSRE転職市場の実態です。

SRE転職に必要なスキルの全体像については、SRE求人票から逆算｜AWSエンジニアがSRE転職に必要なスキルと優先順位でも詳しく解説しています。

recruiter reviewing GitHub profile on computer screen, showing README document, commit history timel

GitHubで採用担当が実際に見るポイント

採用担当やエンジニアがポートフォリオを確認する際、実際に見るのは主に以下の3点です。

READMEの質（目的・構成・使い方）

READMEはポートフォリオの「顔」です。コードを開く前に必ず読まれます。

採用担当が確認するのは「このリポジトリが何をするものか」「なぜ作ったか」「どう使うか」の3点です。この3点が1分以内に理解できるREADMEであれば、コードを読む前から好印象を与えられます。

逆に、READMEがない・内容が「TODO」のままのリポジトリは、「このエンジニアはドキュメントを書かない人だ」という印象を与えます。SREの仕事ではRunbookやPlaybookなどのドキュメント作成が必須スキルなので、ここで脱落するのは非常にもったいないです。

コミット履歴の量・頻度・メッセージ

採用エンジニアはGitHubのコミット履歴から「このエンジニアがどう考えながら実装しているか」を読み取ります。

評価されるコミット履歴のポイントは以下の通りです。

ポイント 良い例 悪い例
メッセージの質 feat: CloudWatchアラームにSLO閾値を追加 update fix 修正
コミット粒度 機能単位・変更理由が明確 first commit で全ファイル一括
頻度 週1〜複数回コンスタントに更新 数ヶ月前に一度だけ

特に「first commit」で全ファイルを一括アップしているリポジトリは、「勉強のためにコードをコピーして上げただけ」という印象を与えます。作業の過程をコミットで残すことが重要です。

コードの品質とIaC設計

SRE領域では、Terraformなどの IaC（Infrastructure as Code） の質が重要視されます。採用エンジニアが見るのは次の3点です。

  1. モジュール化・再利用性: 変数・モジュールを適切に使っているか
  2. 命名規則・コメント: リソースの命名が統一されているか、なぜその設定にしたかのコメントがあるか
  3. セキュリティ意識: ハードコードされたシークレットがないか、IAMポリシーが最小権限になっているか

特に3つ目のセキュリティ意識は、本番環境を扱うSREにとって必須の感覚です。.env ファイルや認証情報が誤ってGitHubにプッシュされているリポジトリは、どんなに内容が良くても評価を大きく下げます。

five portfolio themes for SRE career, icons for Terraform infrastructure, CloudWatch monitoring, Git

SRE転職に効く5つのポートフォリオテーマ

どんなポートフォリオを作ればいいかわからない方向けに、SRE採用で評価されやすい5つのテーマを紹介します。

graph TD

  A["SRE転職
ポートフォリオ"] --> B["① Terraform × AWS
インフラ構築"]

  A --> C["② CloudWatch
監視設計・SLO実装"]

  A --> D["③ GitHub Actions
CI/CDパイプライン"]

  A --> E["④ インシデント対応
ドキュメント"]

  A --> F["⑤ EKS上の
アプリ監視構成"]

① Terraform × AWSインフラ構築

SRE求人でほぼ必須となっているのがTerraformです。「VPC・EC2・RDSをTerraformで構築したリポジトリ」は最も王道なポートフォリオテーマのひとつです。

推奨する構成例:

terraform-aws-infra/
├── README.md
├── environments/
│   ├── dev/
│   └── stg/
├── modules/
│   ├── vpc/
│   ├── ec2/
│   └── rds/
├── variables.tf
└── outputs.tf

ポイントは「dev/stg環境を分けてモジュールで管理している」という設計を見せることです。terraform init → terraform plan → terraform apply の流れをREADMEに記載し、実際に動作することを示せると説得力が増します。

S3をバックエンドにした tfstate 管理も合わせて実装しておくと、より実務に近い構成として評価されます。

② CloudWatch監視設計・SLO実装

SREの根幹である「信頼性の可視化」を示せるテーマです。CloudWatchでSLI（サービスレベル指標）を設定し、SLO（サービスレベル目標）の閾値を超えたときにアラームで通知する構成を実装します。

実装例:

# Terraformでの CloudWatch アラーム設定例
resource "aws_cloudwatch_metric_alarm" "error_rate_slo" {
  alarm_name          = "error-rate-slo-breach"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "5"
  metric_name         = "5XXError"
  namespace           = "AWS/ApplicationELB"
  period              = "60"
  statistic           = "Average"
  threshold           = "0.01"  # SLO: エラー率1%以下
  alarm_description   = "SLO breach: error rate exceeded 1%"
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

このような実装をGitHubに上げ、READMEに「SLOの目標値をどう設定したか・その根拠」を書いておくと、採用担当に「SREの考え方を理解している」という印象を与えられます。

CloudWatchの具体的な設定方法については、CloudWatchアラートの設定方法 – 閾値・通知先の設計指針も参考にしてください。

③ GitHub ActionsによるCI/CDパイプライン

「コードをプッシュしたら自動でテスト・デプロイが走る」構成は、SREが日常的に扱う自動化の典型例です。

シンプルなCI/CDパイプラインの例:

# .github/workflows/deploy.yml
name: Deploy to AWS

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1
      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service api --force-new-deployment

「シークレットをGitHub Secretsで管理している」「テストが通らないとデプロイしない」という設計を明示することが重要です。これだけで「セキュリティ意識と自動化のセンスがある」と判断してもらえます。

④ インシデント対応ドキュメント（Runbook・ポストモーテム）

コードだけがポートフォリオではありません。SREの重要な仕事である ドキュメント文化 を体現した成果物も高く評価されます。

GitHubに以下のようなディレクトリを作り、Runbookやポストモーテムのサンプルを公開している候補者は「実際の運用まで考えられるエンジニア」として差別化できます。

runbooks/
├── README.md
├── incident-response/
│   ├── alert-investigation.md    # アラートが鳴ったときの初動フロー
│   └── rollback-procedure.md    # デプロイ切り戻し手順
└── postmortem/
    └── 2026-03-sample.md         # ポストモーテムサンプル

ポストモーテムは「実際に起きた障害」でなくても構いません。「仮想的な障害シナリオに対してどう対応し、再発防止策を立てたか」を書くだけでも十分な評価材料になります。

⑤ Kubernetes（EKS）上のアプリ監視構成

Kubernetesを使ったポートフォリオは難易度が高いですが、その分評価も高くなります。EKS上にシンプルなアプリをデプロイし、CloudWatchやPrometheus+Grafanaで監視する構成を実装します。

最小構成の例:

# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sample-api
  template:
    metadata:
      labels:
        app: sample-api
    spec:
      containers:
        - name: sample-api
          image: nginx:alpine
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

resourcesの requests と limits を設定しているだけでも「Kubernetesのリソース管理を理解している」という印象を与えられます。

採用担当に刺さるREADMEの書き方

採用担当が一番最初に見る場所

採用担当がGitHubのリポジトリを開いて最初に目にするのがREADMEです。コードを見る前に「このリポジトリが何をするものか」を把握しようとするため、READMEの質がポートフォリオ全体の印象を左右します。

採用担当がREADMEで知りたいのは次の3点です。
1. このリポジトリは何をするものか（概要）
2. なぜ作ったか（目的・学習したこと）
3. どうやって動かすか（手順）

READMEに必ず含める5つの要素

要素 内容 重要度
概要 このリポジトリが何をするものか1〜2文で ★★★
目的・背景 なぜ作ったか・何を学んだか ★★★
構成図 アーキテクチャ図（Mermaid or 画像） ★★☆
セットアップ手順 git clone から動くまでのコマンド ★★★
改善点・今後の課題 現状の課題と今後やりたいこと ★☆☆

特に「改善点・今後の課題」を書いておくと、「自分の実装の限界を把握していて、継続的に改善しようとしている」という姿勢が伝わります。

実際のREADMEサンプル

# terraform-aws-sre-infra

AWS上にSREの視点でインフラを構築するTerraformサンプルリポジトリです。

## 概要

SRE転職に向けて、本番環境を意識したAWSインフラをTerraformで構築しました。
VPC・EC2・RDS・ALBの基本構成をdev/stg環境で分離して管理しています。

## 学んだこと

- Terraformのモジュール設計と変数管理
- S3 + DynamoDBを使ったtfstateのリモート管理
- IAMポリシーの最小権限設計

## アーキテクチャ

[アーキテクチャ図を挿入]

## セットアップ

\`\`\`bash
git clone https://github.com/yourname/terraform-aws-sre-infra
cd terraform-aws-sre-infra/environments/dev
cp terraform.tfvars.example terraform.tfvars
# terraform.tfvarsにAWSアカウント情報を記載
terraform init
terraform plan
terraform apply
\`\`\`

## 今後の課題

- CloudWatchによるリソース監視の追加
- GitHub ActionsでのCI/CD自動化
- EKS対応
comparison of bad vs good GitHub portfolio practices, left side showing empty README and single comm

よくある失敗パターンと対策

コードだけ上げてREADMEがない

最もよくある失敗が「コードをアップしたがREADMEが空」または「Hello Worldレベルの内容しかない」ケースです。

コードの中身がどれだけ優れていても、採用担当がリポジトリの概要を掴めなければ評価の土台に乗りません。「READMEを書く = ドキュメントを書く」という意識を持ち、コードを書く前にREADMEのアウトラインから作り始める習慣をつけることをおすすめします。

「試してみた」止まりで本番運用視点がない

「チュートリアルをそのままやってみた」という内容のポートフォリオは、採用担当にはすぐにわかります。

SREが評価されるのは 「本番環境でも使える設計になっているか」 です。たとえば以下のような「本番運用を意識した一手間」を加えるだけで、印象は大きく変わります。

  • ハードコードしていた値を変数化する
  • シークレットをGitHub Secretsや環境変数で管理する
  • terraform plan の結果をPRのコメントに自動投稿するCIを追加する
  • リソース名に環境名（dev/stg/prod）のプレフィックスをつける

コミットが「first commit」だけ

コードを一括で first commit にまとめているリポジトリは、「作業の過程が見えない」という問題があります。採用エンジニアはコミット履歴から「このエンジニアがどう考えながら実装したか」を読み取ろうとします。

対策は簡単で、「機能ごとにコミットを分ける」習慣をつけるだけです。例えば以下のような粒度が理想的です。

git commit -m "init: Terraformプロジェクト初期化"
git commit -m "feat: VPCモジュール追加（パブリック・プライベートサブネット分離）"
git commit -m "feat: EC2モジュール追加"
git commit -m "feat: RDSモジュール追加（マルチAZ構成）"
git commit -m "fix: セキュリティグループのインバウンドルールを最小権限に修正"
git commit -m "docs: READMEにアーキテクチャ図とセットアップ手順を追加"

まとめ

SRE転職でポートフォリオを評価してもらうためのポイントをまとめます。

  • 採用担当はREADMEを最初に見る: 概要・目的・手順が1分で理解できる構成にする
  • コミット履歴は「思考の痕跡」: 機能単位でコミットし、メッセージに変更理由を書く
  • 本番運用視点を一手間入れる: 変数化・シークレット管理・環境分離で「チュートリアル写経」から抜け出す
  • 5つのテーマから着手: Terraform × AWS / CloudWatch監視 / CI/CD / Runbook / EKS監視

SRE転職においては、スキルを「証拠」に変換できるかどうかが勝負を分けます。まずは1つのリポジトリを丁寧に作り込み、READMEまで仕上げることから始めてください。

ポートフォリオが完成したら、次は職務経歴書・面接の準備が必要です。転職エージェントを使って選考対策を進めたい方には、SREエンジニア転職に強い レバテックダイレクト がおすすめです。企業との直接スカウト型なので、ポートフォリオURLを登録しておくだけで採用担当の目に触れる機会が増えます。

レバテックダイレクトで求人を見てみる

SRE転職に必要なスキルをまだ整理できていない方は、SREエンジニアのスキルセット｜必須・推奨・差別化の3段階で解説もあわせて参考にしてください。

バックエンドエンジニアからSREを目指している方は、バックエンドエンジニアがSREに転向するために補うべきスキルも参照してください。

コメント

タイトルとURLをコピーしました