第6部 面接の実践・第16章
国内Web系では最も比重が大きい。知識の説明のあとに「実際にやったこと」を数字つきで話せると評価が大きく変わる。各エピソードは STAR（状況・課題・行動・結果）で準備する。
| 要素 | 書く内容 | 分量の目安 | よくある失敗 |
|---|---|---|---|
| Situation（状況） | サービスの規模、チーム構成、時期 | 2〜3文 | 前置きが長すぎる |
| Task（課題） | 何が問題で、自分の役割は何だったか | 1〜2文 | 課題の大きさが伝わらない |
| Action（行動） | 自分が判断・実行したこと。なぜその選択をしたか | 最も厚く | 「チームで」ばかりで自分が見えない |
| Result（結果） | 数字での成果、学び、その後の仕組み化 | 2〜3文 | 数字がない、学びがない |
状況説明は短く、自分の判断と行動を中心に話す。
| 要素 | 例 |
|---|---|
| Situation | 月間〇〇万ユーザーのサービスで、平日昼にAPIのエラー率が急上昇した |
| Task | オンコール担当として初動を任され、影響の把握と復旧を主導する必要があった |
| Action | 直前のデプロイを確認したが無関係と判断。APMでDB待ちが増えていることを特定し、新規追加されたバッチのクエリがロックを長時間保持していると突き止めた。バッチを停止して緩和し、開発チームとクエリを修正した |
| Result | 検知から〇分で復旧。ポストモーテムでバッチの実行時間帯の見直しとロック待ちのアラートを追加し、同種の障害は再発していない |
| 質問 | 見られているポイント |
|---|---|
| 今までで一番大きな障害対応は？ | 冷静な切り分け、緩和の判断、関係者への連絡、再発防止 |
| 自分が原因で起きた障害はあるか？ | 責任の取り方、学びを仕組みに変えたか |
| 現在のデプロイパイプラインの課題は？ | 現状を分析し、改善の優先順位をつけられるか |
| 開発チームとの意見対立をどう解決した？ | データ（SLO、エラーバジェット）で合意を作れるか |
| 一番成果を出した改善は？ | 課題設定力、定量的な成果、巻き込み方 |
| トイルをどう減らしたか？ | 計測、自動化、効果の測定 |
| コスト削減の経験は？ | 削減額と、信頼性とのトレードオフの判断 |
| 技術選定で迷ったときどう決めた？ | 比較軸の設定、PoC、意思決定の記録 |
| オンコール体制をどう改善した？ | アラートの質、負荷の偏り、手順書の整備 |
| 次の会社でやりたいことは？ | キャリアの一貫性、応募先の課題への理解 |
面接官は1つのエピソードを何段階も掘り下げる。次の問いに答えられるか確認しておく。
| 深掘りの方向 | 質問の例 |
|---|---|
| 判断の根拠 | なぜその方法を選んだのか。他にどんな選択肢を検討したか |
| 自分の貢献 | あなた自身は具体的に何をしたのか |
| 困難 | 一番難しかったところはどこか、どう乗り越えたか |
| 反対意見 | 反対した人はいたか、どう説得したか |
| 振り返り | 今やり直すなら何を変えるか |
| 再現性 | 同じ状況が別の会社で起きたらどう進めるか |
| カテゴリ | よく聞かれる質問 | アピールしたいこと |
|---|---|---|
| 障害対応 | 一番大変だった障害は？検知はどうだった？ | 冷静さ、復旧優先の判断、再発防止の仕組み化 |
| 信頼性向上 | SLOを導入した経験は？アラートをどう改善した？ | 計測に基づく改善、開発チームの巻き込み |
| 移行・更新 | 大きなマイグレーションの経験は？無停止でできたか？ | 計画、リスク評価、段階的な切り替え、ロールバック計画 |
| 自動化 | どんな作業を自動化した？どれだけ時間が減った？ | トイルの計測と削減効果 |
| コスト | どうやって削減対象を見つけた？ | 可視化、優先順位づけ、信頼性とのバランス |
| セキュリティ | 脆弱性やインシデントへの対応は？ | リスク評価、優先順位、仕組みでの防止 |
| 協業 | 開発チームと対立したときは？ | データに基づく合意形成、相手の立場の理解 |
| 育成・マネジメント | メンバーをどう育てた？業務委託の方とどう連携した？ | 任せ方、期待値のすり合わせ、成果の出し方 |
| 技術選定 | ツールやベンダーをどう選んだ？ | 比較軸、PoC、意思決定の記録と説明 |
各カテゴリに1つずつ用意する。数字（時間、金額、件数、割合）を必ず入れる。
| カテゴリ | 状況・課題 | 自分の行動 | 結果（数字） | 関連する技術論点 |
|---|---|---|---|---|
| 障害対応 | Linux、DB、インシデント対応 | |||
| 信頼性向上 | SLO、監視、アラート設計 | |||
| インフラ移行・更新 | IaC、デプロイ戦略、DB運用 | |||
| 自動化・トイル削減 | CI/CD、スクリプト | |||
| コスト最適化 | AWS料金体系、可視化 | |||
| セキュリティ | IAM、脆弱性管理 | |||
| チーム間の協業・合意形成 | エラーバジェット、ポストモーテム | |||
| 失敗から学んだこと | 再発防止の仕組み化 |
| 項目 | 良い伝え方 | 避けたい伝え方 |
|---|---|---|
| 退職理由 | 「〇〇に挑戦したいが、現職では機会が限られる」と前向きに | 現職の不満や人間関係の話を中心にする |
| 志望動機 | 応募先の課題（規模、技術、事業）と自分の経験・やりたいことを結びつける | 「成長したい」「勉強したい」だけ |
| キャリアの方向 | スペシャリスト / マネジメントのどちらに進みたいかを具体的に | 「何でもやります」 |
| 目的 | 質問 |
|---|---|
| SREの成熟度を知る | SLOはどのサービスに設定されていて、どう運用されていますか |
| 働き方を知る | オンコールの体制と、1人あたりの頻度はどれくらいですか |
| 役割の範囲を知る | SREチームと開発チームの責任分担はどうなっていますか |
| 課題を知る | 今いちばん解決したい信頼性・インフラの課題は何ですか |
| 文化を知る | 最近の大きな障害と、そのポストモーテムでどんな改善をしましたか |
| 期待値を知る | 入社後半年で期待される成果は何ですか |
| 技術の方向性を知る | 今後1〜2年でインフラに大きな変更の予定はありますか |
| 場面 | 注意点 |
|---|---|
| わからない質問 | 正直に「わからない」と言い、知っている範囲から推測を述べる。知ったかぶりは深掘りで必ず見抜かれる |
| 質問が曖昧 | 前提を確認してから答える（「〇〇という理解でよいですか」） |
| 長くなりそう | 結論を先に言い、「詳しく話しましょうか」と相手に選ばせる |
| オンライン面接 | 図を描く場面に備えて、ホワイトボードツールや紙を用意しておく |
| 社外秘の情報 | 現職の具体的な数値や構成は、話してよい範囲に抽象化する |
各カテゴリのエピソードを STAR で書き出した
「URL入力から表示まで」を 5 分で説明できる
インデックスと分離レベルを図なしで説明できる
Linux トラブルシューティングを 5 ステップで話す練習をした
システム設計のお題を 2〜3 個、時間を計って練習した
応募先の技術ブログ・構成・障害報告を読んだ
逆質問を用意した（SLO運用、オンコール体制、SREチームの役割範囲など）
まず答えを見ずに声に出して答え、そのあと開いて比べる。
模範回答
STARで話します。状況（規模、時間帯、影響）を2〜3文で述べ、自分の役割を明確にします。行動では、何を見てどう判断したかを時系列で話し、特に「原因が分かる前にどう影響を止めたか」を入れます。結果は復旧までの時間と影響を数字で示し、ポストモーテムで何を仕組み化したかで締めます。
深掘りされたら
見られているポイント冷静さ、判断、再発防止
模範回答
対立の内容を具体的に述べ、相手の立場（リリースを急ぐ理由など）をどう理解したかを話します。そのうえで、SLOやエラーバジェット、障害件数などのデータを使って共通の判断基準を作り、合意した経緯を説明します。結果として関係がどう良くなったかまで伝えます。
深掘りされたら
見られているポイントデータにもとづく合意形成
模範回答
現職への不満ではなく、挑戦したいことを中心に話します。これまでに積んだ経験（基盤構築、セキュリティ、自動化など）を述べたうえで、より大きな規模や新しい領域に挑戦したい、という方向性を示し、応募先でそれが実現できる理由を具体的に結びつけます。
深掘りされたら
見られているポイント一貫性と前向きさ
模範回答
必ず用意しておきます。SLOがどう運用されているか、オンコールの体制と頻度、SREチームと開発チームの責任分担、直近の大きな障害と改善、入社後半年で期待される成果などを聞くと、相手の成熟度が分かり、自分の関心の高さも伝わります。
見られているポイント相手を見極める姿勢