障害対応ばかりのエンジニアは損？火消し経験を市場価値に変える
深夜にアラートで起こされ、原因を切り分け、朝までに復旧させた。次の日は通常業務。半期が終わってみると、障害対応に追われていた記憶しかなく、評価シートに書ける「開発成果」が薄い。
火消し役は、現場では確実に頼られているのに、評価制度の上では不利になりやすい立場です。一方で、採用市場では本番運用の経験を持つ人が明確に不足しています。この差をどう埋めるかを整理します。
- 障害対応が社内評価で不利になる3つの理由
- 火消し経験を裏づける数字の取り方
- 採用側が障害対応の話から読み取っていること
- 面接で使える伝え方
障害対応が社内評価で不利になる理由
1. 計画外の仕事なので、目標に入っていない
期初に立てた目標に「障害対応」は入りません。突発で発生し、その分だけ計画していた開発が遅れます。結果として、評価シート上は「目標未達」に見えます。実際には最も価値のある時間を使っているのに、制度が拾えません。
2. 復旧は評価されても、再発防止は評価されない
障害が起きた直後は注目が集まります。しかし、根本原因を潰す作業は数週間後に地味に行われ、誰も見ていません。そして再発しなくなると、その障害自体が忘れられます。火を消した人より、火が出ない仕組みを作った人のほうが評価されにくいという逆転が起きます。
3. 対応できる人に集中する
一度うまく対応すると、次も呼ばれます。詳しい人に寄っていくので、特定の個人に負荷が集中します。これは便利屋化の典型的な入口です。構造はエンジニアが便利屋扱いされる会社で起きていることで詳しく扱っています。
火消し経験を裏づける数字を取る
障害対応の価値は、感覚ではなく数字で語れます。障害チケットやSlackのログから拾える範囲で構いません。
| 取れる数字 | 拾い方 | 語れること |
|---|---|---|
| 検知から一次対応までの時間 | アラート時刻と最初の投稿時刻の差 | 初動の速さ |
| 復旧までの時間（MTTR） | 検知から復旧宣言まで | 切り分けの精度 |
| 同一原因の再発回数 | 障害チケットを原因別に分類 | 再発防止が効いたか |
| 月あたりのアラート件数 | 監視ツールの通知数 | ノイズ削減の成果 |
| 影響ユーザー数・停止時間 | 障害報告書の記載 | 障害の規模感 |
特に効くのは同一原因の再発回数です。「同じ原因の障害が月3件起きていたが、監視条件と復旧手順を見直して半年でゼロになった」と言えれば、それは運用改善の実績になります。
採用側は障害対応の話から何を見ているか
面接で障害の話をすると、採用側は技術的な難易度より判断のプロセスを見ています。
- 限られた情報で、どこから切り分けたか
- 復旧優先と原因究明のどちらを先に置いたか。その判断理由は何か
- 誰にいつエスカレーションしたか
- 事後に何を変えたか。変えた結果どうなったか
本番環境を触った経験があり、落ちたときに動ける人は、どの会社でも必要とされます。特に自社サービスを運営している会社では、SREや運用基盤のポジションで明確な需要があります。「障害対応ばかりで開発をしていない」は、市場では「本番運用の実務経験がある」と読み替えられます。
ただし、語り方が「大変でした」で止まると伝わりません。次の言い換えが役立ちます。
- 「夜間対応をしていた」→ オンコール体制の一次対応を担当し、検知から復旧までを主導した
- 「原因を調べた」→ ログとメトリクスから影響範囲を特定し、切り分け手順を確立した
- 「暫定対応した」→ 復旧を優先しつつ、恒久対応との切り分けを判断した
- 「手順書を作った」→ 対応を属人化から外し、チームの誰でも初動できる状態にした
消耗しないための線引き
市場価値になるとはいえ、割り振られ続けると消耗します。社内で手を打てることもあります。
当番制にする
特定の人に寄っている状態は、会社にとってもリスクです。「私が倒れたら誰も対応できません」という事実を、属人化リスクとして上司に伝えると話が通りやすくなります。感情ではなく、事業リスクとして提示するのがポイントです。
再発防止を目標に入れる
期初の目標に「同一原因の障害をゼロにする」を入れておけば、地味な恒久対応が評価対象になります。目標に入っていない仕事は評価されないという原則は、地味な貢献が評価されないエンジニアへ｜ドキュメント整備を例にでも書いた通りです。
アラートのノイズを削る
対応件数そのものを減らす動きは、数字で示しやすい改善です。不要なアラートを整理して件数を半分にすれば、それ自体が成果になります。
IT転職エージェント＠PRO人
ITエンジニアの転職に特化したエージェント「PRO人」。専任のキャリアアドバイザーが、経歴やスキルを踏まえた具体的な求人・条件面を提示してくれます。
- IT・Web業界の転職支援に特化
- 経歴・スキルに合わせた求人を紹介
- 年収交渉や条件面のすり合わせも相談できる
- TechGoとは別の視点で市場価値を確認できる
よくある質問
Q. 障害対応しかしていないと、開発スキルが落ちませんか A. 落ちる面はあります。ただ、障害対応は既存コードを深く読む作業でもあるので、読解力と設計の勘所は鍛えられます。心配なら、恒久対応の実装を自分で持つようにすると、開発の実績も残せます。
Q. 障害を起こした側の経験は、面接で話さないほうがいいですか A. 話して構いません。起こしたこと自体より、その後どう変えたかを見られます。原因を構造で説明し、再発防止まで語れる人は、むしろ信頼されます。隠すと質問が深掘りされたときに答えられなくなります。
Q. 数字が残っていない場合はどうすればいいですか A. 今日から取り始めれば、半年後には材料になります。障害チケットを原因別に分類するだけでも傾向が見えます。過去分は「月に数件あったものが、ほぼなくなった」という粒度でも伝わります。
まとめ
障害対応は、社内評価では不利に働きやすく、市場では明確に需要がある経験です。
- 計画外の仕事なので目標に入らず、評価シートに乗りにくい
- 復旧より再発防止のほうが評価されにくいという逆転が起きる
- 同一原因の再発回数は、運用改善の実績として最も語りやすい数字
- 採用側は技術難易度より、切り分けと判断のプロセスを見ている
まずは直近の障害チケットを原因別に分類してみてください。同じ原因が並んでいれば、そこが次の改善対象であり、同時に次の面談で語れる材料になります。