エンジニア面接で本番障害を聞かれたときの答え方｜ポストモーテムの型

「これまでに本番障害を起こしたことはありますか」と聞かれた瞬間、頭が真っ白になった。面接を終えた候補者から、この種の感想を聞くことは珍しくありません。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、この質問への反応は大きく3つに分かれます。「ありません」と逃げる人、謝罪と反省だけで終わる人、そして時系列で淡々と語って面接官の表情を変える人です。今回は、障害の経験を失敗談ではなく運用設計力の証明として語るための型を、Google SREが公開しているポストモーテムの構成を借りて、実際の言い換え例とあわせてお伝えします。

目次

1. 本番障害を面接で聞かれる理由と、答え方の前提
2. 評価が割れる3つの語り方
3. ポストモーテムの型で組み立てる：影響から学びまで
4. 影響と検知：数字を桁で、きっかけを事実で
5. 切り分けと復旧：判断の理由まで言う
6. 再発防止と学び：動詞と期限で語る
7. 非難の言い方を仕組みの言い方に変える
8. 回答例：2分で話すとこうなる
9. 面接官はどこで深掘りするか：Fさんの例
10. 守秘義務の線引き：何を伏せて何を話すか
11. 担当範囲を盛らない：深掘りで崩れる3つのパターン
12. ケース別の語り方：自分のミス、小さな障害、運用経験が少ない場合
13. 自分のミスが原因だった場合
14. 規模が小さい障害しかない場合
15. 運用・オンコールの経験が少ない場合
16. SES・客先常駐で裁量が小さい場合
17. よくある質問
18. まとめ

本番障害を面接で聞かれる理由と、答え方の前提

まず、なぜこの質問が出るのかを押さえておきます。面接官が知りたいのは、障害を起こしたかどうかではありません。障害は、長く本番を触っていれば誰でも起こします。見ているのは、想定外のことが起きたときに、この人がどういう順番で考え、どう動き、次にどう繋げる人かという点です。

ですから「障害ゼロです」という回答は、安全に見えて実は損をします。本番運用の当事者だった経験が薄いのか、起きたことに気づいていないのか、隠しているのか。面接官はそのどれかを疑います。障害の経験があること自体が不利になるケースを、私はほとんど見たことがありません。不利になるのは、語り方のほうです。

評価が割れる3つの語り方

冒頭で触れた3パターンを、もう少し具体的に書きます。1つ目の「ありません」は先ほどの通りです。2つ目の「私の確認不足でご迷惑をおかけしました。二度と起こさないよう気をつけています」は誠実に聞こえますが、面接官の手元には何も残りません。気をつける、という再発防止は検証できないからです。

3つ目が、影響、検知、切り分け、復旧、再発防止を事実の順に並べる語り方です。話の長さは2分程度で、感情の描写はほとんどありません。それでも面接官が「この人に本番を任せられる」と判断する材料は、この3つ目にしか入っていません。

面接官タイプごとに失敗談のどこを見るかが変わる点は、面接官タイプ別の回答の重心で扱いました。この記事では範囲を本番障害に絞り、話の組み立て方を掘り下げます。

ポストモーテムの型で組み立てる：影響から学びまで

ポストモーテムとは、障害が収まった後に原因と対応を整理して文書にする振り返りのことです。Google SREが公開しているポストモーテムの例は、Summary、Impact、Root Causes、Trigger、Resolution、Detection、Action Items、Lessons Learned、Timelineという見出しで構成されています。Lessons Learnedの中は「うまくいったこと」「うまくいかなかったこと」「運が良かったこと」に分かれています。

面接の2分間にこの全部は入りません。ただ、この骨格は話の順番としてそのまま使えます。私が候補者に勧めているのは、次の6段階です。

影響と検知：数字を桁で、きっかけを事実で

最初に話すのは影響です。「大きな障害でした」という形容ではなく、何がどの範囲で止まり、どれくらい続いたかを一息で言います。数字は正確でなくて構いません。「注文処理が40分ほど止まった」「管理画面の一部が半日見えなかった」程度の粒度で足ります。

続く検知は、見落とされがちですが評価に直結します。Google SREの資料には、ポストモーテムを書くきっかけの例として、ユーザーに見える停止やデータ損失、オンコールの介入やロールバック、解決までの時間超過のほか、監視の失敗によって手動で発見された場合が挙がっています。つまり「監視ではなく問い合わせで気づいた」というのは、それ自体が再発防止の対象になる事実です。検知のきっかけを隠さず話せる人は、再発防止の話にも自然に繋げられます。

切り分けと復旧：判断の理由まで言う

ここが面接官の関心の中心です。何が原因かわからない状態から、どの順番で何を疑ったのか。ログを見たのか、直前のリリースを疑ったのか、依存先を確認したのか。結果として原因が当たっていたかどうかより、仮説を立てて潰していく順番に筋が通っているかを面接官は聞いています。

復旧では、手段そのものよりも「なぜその手段か」を添えます。ロールバックを選んだなら、原因の特定を待たずに戻した理由を言う。設定を直したなら、戻すより直すほうが早いと判断した根拠を言う。ここで「このときの優先順位は、まず影響を止めることでした」と言えると、運用の経験者だという印象が一気に強まります。

再発防止と学び：動詞と期限で語る

再発防止は、面接官が最も細かく見る箇所です。「チェックを強化しました」では、何も語っていないのと同じです。Google SREのワークブックでも、悪い例の問題点として、「Improve」「Make better」のような曖昧な表現のアクションでは成功条件が測れないこと、優先度が全部同じで担当者や追跡用のチケットも欠けていることが挙げられています。

面接では、そこまでの形式は要りません。ただ「リリース前に本番相当のデータ量で負荷試験を行う手順を追加した」「閾値を超えたら通知が飛ぶ監視項目を2つ足した」のように、動詞で終わる具体的な変更を1〜2個言えることが大切です。

学びでは、うまくいったことも言ってください。「切り分けの途中で、直近のデプロイ履歴がすぐ引ける状態だったので助かった」のような一言が入ると、ただ反省している人から、仕組みの良し悪しを評価できる人に見え方が変わります。運が良かった点を正直に挙げられる人も、信頼されます。

非難の言い方を仕組みの言い方に変える

回答がうまくいかない人の多くは、順番ではなく言葉の選び方でつまずいています。自分を責める言い方も、他人を責める言い方も、面接官には同じ結果になります。個人の注意力に原因を置くと、再発防止が「気をつける」になってしまうからです。

Google SREのポストモーテム文化の章は、個人やチームを責めずに、インシデントに寄与した要因を特定することを原則にしています。「人を直すことはできないが、人が正しい選択をしやすいように仕組みや手順は直せる」という趣旨の説明もあります。この考え方を面接の言い回しに置き換えると、次のようになります。

注意してほしいのは、左を右に言い換えただけで責任を逃れる話ではない点です。右の言い方でも「それを確認しなかったのは自分だ」という事実は消えません。担当範囲の話は後の節で扱いますが、事実は正確に語り、原因の置き場所だけを仕組みに移す。これが言い換えの意味です。

回答例：2分で話すとこうなる

実際の話し方を見てみます。ECサイトのバックエンドを担当していた人が、キャンペーン開始時の障害を話す例です。

前職で、キャンペーン開始の直後に注文処理が約40分止まった障害を経験しました。影響は、その間の購入ができなかったことと、一部の注文でメール送信が遅れたことです。検知は、監視ではなくカスタマーサポートからの問い合わせでした。切り分けでは、直前にキャッシュの設定を変えたことと、DBの接続数が上限に張り付いていたことを確認し、設定変更が原因だと判断しました。復旧は、原因の完全な特定より影響を止めることを優先し、設定を元に戻しました。再発防止として、設定変更時に本番相当の負荷でテストする手順と、DB接続数の閾値通知を追加しました。学びは、監視の穴を自分たちで把握できていなかった点です。一方で、設定をすぐ戻せる状態にしてあったことは救いでした。

この回答は400字ほどで、話すと1分半から2分です。感情語はほとんどなく、数字は「40分」だけ。それでも、検知の弱さを隠さず、復旧の優先順位に理由があり、再発防止が具体的です。面接官はここから質問を重ねていきます。

ポイント： 話し終えたら、自分から「詳しくは、切り分けの手順か再発防止の中身のどちらからでもお話しできます」と添えると、深掘りの入口を自分で選べます。準備していない箇所を突かれるのを避ける、実務的な工夫です。

面接官はどこで深掘りするか：Fさんの例

ここからは、私が支援した方の話です。32歳・経験9年のバックエンドエンジニアのFさんは、チケット販売サービスを運営する自社開発企業に在籍していて、別の自社開発企業への転職を考えていました。

Fさんが話した障害は、セール開始直後の購入不可でした。キャッシュの設定変更をきっかけに、DBの接続数が枯渇して約40分購入できなくなった、というものです。一次面接では、先ほどの型で整理した回答がよく通りました。ところが二次面接で、現場のリードエンジニアにこう聞かれたそうです。

「その設定変更は、誰がどういう理由で判断したんですか」

Fさんは「チームで判断しました」と答えました。事実としてはそうだったのですが、リードは続けて「あなた自身は、何を判断しましたか」と重ねました。Fさんは設定の値を決めたのはインフラ担当で、自分は変更の申請をしただけだったため、答えに詰まったそうです。本人の中では「チームの話」として語るつもりが、面接官には「この人は判断の現場にいなかったのかもしれない」と映りました。

Fさんの回答は、障害の型としては正しかったのです。足りなかったのは、自分が判断した部分と、他の人がやった部分の線引きでした。後日、Fさんと一緒に回答を組み直し、「設定値の決定は別の担当でした。私は変更の影響範囲の確認を依頼され、負荷の確認が漏れていました。復旧の判断は私が行い、再発防止の手順整備は私が主導しました」と、担当の境界を先に宣言する形に変えました。

その後に受けた別の企業の面接では、同じ質問に詰まらずに答えられ、最終面接まで進みました。結果は、年収条件が合わずに不合格です。内容が評価されたかどうかと、条件が合うかどうかは別の話だと、あらためて感じた例でした。

守秘義務の線引き：何を伏せて何を話すか

障害の話は、機密情報の宝庫です。社名、顧客名、売上への影響額、脆弱性の詳細。ここで迷って話を丸ごと薄めてしまう人もいれば、逆に話しすぎて「この人は前職の情報も同じように話すのでは」と警戒される人もいます。私が候補者と整理するときの線引きは次の通りです。

ポイントは、面接官が評価したい中身（判断と手順）が、機密にあたる部分とほとんど重ならないことです。顧客名や金額を伏せても、切り分けの順番や再発防止の設計は話せます。「守秘義務があるので詳しくは話せません」の一言で終わらせるのは、必要以上の防御です。

数字を「桁」で示す方法は、契約や案件の守秘が厳しい働き方でも使えます。複数の守秘契約を抱えた職務経歴書の書き方は、フリーランスが複数NDAの案件を職務経歴書にまとめる方法で詳しく扱っています。

話せる範囲に自信がないときは、面接の冒頭で「守秘の関係で、固有名詞と金額は伏せてお話しします」と一言断っておくと、その後の曖昧さが誠実さとして受け取られます。断らずにぼかすと、ただ話が薄い人に見えるのです。

担当範囲を盛らない：深掘りで崩れる3つのパターン

Fさんの例のように、障害の質問は担当範囲の深掘りに直結します。ここで「自分がやったこと」を実際より大きく語ると、技術面接では数分で崩れます。私が見てきた崩れ方は、大きく3つです。

1つ目は、主語が「私たちは」のまま最後まで行くパターンです。何をしたのかを聞かれて、チームの話にしか答えられません。2つ目は、復旧の判断を自分のものとして語ったが、実際はリーダーの指示を実行しただけで、「別の選択肢は考えましたか」に答えられないパターンです。3つ目は、再発防止を「導入しました」と言い切ったが、運用実態を聞かれると、提案しただけで採用されていなかったと露呈するパターンです。

対策は単純で、語る前に自分の関与を3段階に仕分けておくことです。

話すときは、1番目を中心にしつつ、2番目と3番目も「ここは別の担当でした」と正直に言います。盛らなくても、自分の判断の部分だけで十分に評価されることが多いのです。むしろ「ここまでは私の仕事、ここからは別の人」と言える人のほうが、役割の境界を理解している人に見えます。

運用の現場にいた経験をどう職務経歴書に落とすかは、運用保守5年の経験を書類で伝える方法に書きました。書類で書いた内容は、面接でそのまま深掘りされます。両方を同じ粒度でそろえておくと、話がぶれません。

ケース別の語り方：自分のミス、小さな障害、運用経験が少ない場合

型は共通でも、状況によって気をつける点が変わります。よく受ける相談を3つ挙げます。

自分のミスが原因だった場合

正直に話して構いませんし、話したほうが良いです。ただし「ミスをした」で止めず、なぜそのミスが本番に届いたのかまで掘ります。手順書がなかった、レビューが形骸化していた、検証環境と本番の差が大きかった。こうした背景を、先ほどの言い換え表の要領で仕組みとして語ります。同時に「この確認をしなかったのは私でした」と、事実を自分の言葉で言うことも忘れないでください。事実は自分、構造は仕組み。この両立が、面接官の信頼につながります。

規模が小さい障害しかない場合

規模は問われません。評価されるのは型の中身であって、止まった時間や件数の大きさではないからです。「社内ツールが半日使えなかった」「管理画面の集計が一晩ずれた」程度でも、検知から再発防止までを語れれば成立します。むしろ、小さな障害で再発防止まで実行している人のほうが、大きな障害を一度経験しただけの人より、日常の運用習慣が見えて評価されることもあります。

運用・オンコールの経験が少ない場合

本番障害そのものがない場合は、近い経験で型を使います。検証環境で起きた不具合、リリース手順のミスで直前に気づいて止めた経験、手動オペレーションの誤りなどです。「本番ではありませんが」と先に断ったうえで、同じ6段階で話します。面接官が見ているのは、障害を扱う思考の型だからです。

夜勤の監視業務からインフラ構築を目指す方の事例は、夜勤監視オペレーターの職務経歴書の書き方にあります。一次対応の経験は、検知と切り分けの材料として十分に使えます。

SES・客先常駐で裁量が小さい場合

復旧の判断や再発防止の最終決定が客先にあったとしても、型は使えます。「判断は客先の責任者でしたが、私は切り分けの材料を整理して提案しました」と、自分の関与を正確に言うだけです。再発防止が採用されなかった場合も、「手順書の改訂案を作ったが、運用ルールの変更までは行われなかった」と正直に話し、それでも自分の担当範囲の中でできた小さな改善（自分が作る手順書の確認項目を増やした、など）を添えてください。

よくある質問

障害を起こした経験は、転職で不利になりますか。 語り方次第です。障害の有無よりも、その後の動きを説明できるかどうかが見られます。逆に「経験がない」と答えるほうが、本番運用の当事者だったかを疑われる場合があります。

自分のミスが原因の障害は、どこまで正直に話すべきですか。 事実としては正直に話してください。そのうえで、ミスが本番に届いた背景（手順、レビュー、環境差など）と、変えた仕組みまで話します。ミスを隠すと、深掘りで必ず矛盾が出ます。

守秘義務が心配で、何も話せません。 顧客名、金額、ホスト名、脆弱性の詳細を伏せれば、判断と手順は話せます。数字は桁や比率でぼかし、最初に「固有名詞は伏せます」と断っておくと安全です。

STAR法で話すのと、何が違いますか。 STAR法は状況、課題、行動、結果で話す一般的な型です。障害の話はこの型にも当てはまりますが、本記事の6段階は、検知や切り分け、再発防止といった運用の観点を明示している分、技術面接で見られる箇所を取りこぼしにくくなります。どちらかに決める必要はなく、面接官の質問の形に合わせて使い分けて構いません。

まとめ

本番障害の質問は、失敗を問う質問ではなく、運用の設計力を見る質問だというのが、この記事で一番伝えたかったことです。影響、検知、切り分け、復旧、再発防止、学びの順に事実で並べ、原因の置き場所を個人ではなく仕組みに移す。それだけで、同じ障害が全く違う評価の材料になります。

一方で、型を整えるだけでは足りない場面があります。守秘の線引きを決めておくこと、自分の判断した部分とそうでない部分を分けておくこと。この2つを準備していれば、深掘りされても崩れません。面接の前に、自分の障害経験を6段階で書き出し、関与を3段階に仕分けてみてください。そこで語れる自分の判断が、あなたの強みです。

障害対応の実績を「運用していました」で終わらせず、設計の判断として語り直す話は、データエンジニアのオファー面談の事例にまとめています。面接前の整理とあわせて読んでみてください。