シリーズについて：「職場の暗号辞典」は、エンジニアが職場で使う言葉の「本当の意味」を翻訳するシリーズです。
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編（本記事）
- Vol.4：スプリント・スクラムイベント編（近日公開）
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編
- Vol.8：技術選定編
はじめに
障害対応は、エンジニアリングの中で最もストレスが高い時間帯です。
サービスが落ちている。ユーザーからの問い合わせが殺到している。Slackに「状況は？」というメッセージが3分に1回飛んでくる。そんな状況下で、人は不思議と同じ言葉を使います。
「影響範囲を確認します」「暫定対応を入れました」「確認中です」——これらは現場の混乱を整然と見せるための言葉であり、同時に、本当のことを直接言えない状況を包む表現でもあります。
この記事では、障害対応と振り返り（ポストモーテム）の場に登場するフレーズを素直な日本語に翻訳します。
翻訳辞典：障害対応・振り返り編
「影響範囲を確認します」
翻訳： まだよくわかっていません。正直に言うとかなり怖いです。
障害発生直後に最もよく使われるフレーズです。「確認します」という能動的な言い方をすることで、「把握していない」という事実を一時的にカバーします。
状況が本当にわかっているときは「〇〇機能が〇〇時から使えない状態です、影響ユーザーは推定〇〇人です」と言えます。「影響範囲を確認します」としか言えないときは、まだ何もわかっていないサインです。
焦りは禁物ですが、何もわかっていないまま時間が経つのも問題です。ログ・モニタリング・エラーレートの確認を並行して進めながら、5分ごとに「現状これだけわかった」を共有するのが理想的な障害対応のコミュニケーションです。
対処法： 上司や関係者への共有は「わかっていないこと」も含めて正直に言う。「影響範囲は現在調査中です。わかっている事実は〇〇です」という構造で話すと、信頼感を保ちながら正直に状況を伝えられます。
「暫定対応を入れました」
翻訳： サービスは復旧しましたが、原因はまだわかっていません
障害対応における最も重要な分岐点に差し掛かったことを意味します。「暫定」というのは「根本原因を修正した恒久対応ではない」という意味であり、「また起きる可能性がある」という宣言でもあります。
よくある暫定対応の例：
- 問題のあるバッチ処理を一時停止した
- 特定の機能へのアクセスをフラグでオフにした
- サーバーを再起動して症状を消した（原因は不明）
「暫定対応で復旧した」の後に「根本原因の調査と恒久対応は〇〇までに行います」がセットでないと、技術的負債が1つ積み上がったことになります。
対処法： 「暫定対応を入れた」と言った瞬間にIssueを起票する。「根本原因の調査」「恒久対応の実装」の2つのタスクを作り、担当者と期限を決める。このIssueが起票されない暫定対応は、永遠に暫定のまま終わります。
「確認中です」
翻訳： ① 文字通り確認中、または ② 詰んでいます、誰か助けてください
障害対応のSlackチャンネルで繰り返される「確認中です」は、2種類あります。
1つは本当に確認中で、5分後に「わかりました、〇〇でした」と続くケース。もう1つは、何を確認すれば良いかもわからないまま、「何かやっている感」を出すために言っているケースです。
後者は「確認中」が10分以上続いたときに疑い始めると良い。同じ担当者が同じフレーズを繰り返しているなら、助けが必要なサインです。
対処法： 「確認中」が続いている人には「今何を見ていますか？一緒に確認しましょう」と声をかける。責めるためではなく、一緒に詰める状況から抜け出すために。障害対応は1人でやらない方が早いことが多いです。
「再発防止策を検討します」
翻訳： 今は何も思いついていませんが、そのうち考えます（考えないかもしれません）
ポストモーテムや振り返りの場で、原因分析の後によく出てくる言葉です。
「検討します」という言葉は未来の行動を約束しているように聞こえますが、主語が不明確で、期限がなく、具体的な手段も決まっていない場合、この約束が履行される確率は低い。
本当に実行される再発防止策は「〇〇さんが担当で、次のスプリントまでに〇〇を実装します」という形をしています。「検討します」で終わった再発防止策は、次の同じ障害が起きるまで再び議題に上がりません。
対処法： 振り返りの場では「再発防止策を検討します」と言った人に「誰が・いつまでに・何をしますか？」の3点を確認する。答えられない場合は「次回の定例で具体案を持ち寄りましょう」と期限を設定する。
「人為的なミスでした」
翻訳： 個人を責めることで、構造的な問題から目をそらしています
障害の原因を「人為的なミス」で終わらせることは、一見シンプルな結論に見えて、実は最も危険な結論の出し方です。
「Aさんが誤った操作をした」は事実かもしれません。しかしなぜAさんが誤操作できる状態になっていたのか、なぜ誤操作を防ぐ仕組みがなかったのか、なぜ誤操作が検知できなかったのか——こちらの方が本質的な問いです。
人間はミスをします。それを前提として、ミスが障害につながらない仕組みを作るのがエンジニアリングの仕事です。「人為的なミスでした」で終わる振り返りは、次の障害の種をそのままにしています。
対処法： 「なぜ人間がミスできる状態になっていたのか？」を必ず問いかける。操作ミスが原因なら「誤操作を防ぐUIの改善」「本番環境への操作に承認フローを追加」など、人間以外が変わる形での再発防止策を探す。
「ポストモーテムを書きます」
翻訳： 書くかもしれないし、書かないかもしれません
障害が復旧した直後に「ポストモーテム書きますね」と言う人は多いですが、実際に書かれる確率は決して高くありません。
障害が復旧した瞬間に安堵感が来る。その後に別のタスクが積み上がる。「まあ今回は軽微だったし……」という判断が入る。気づいたらドキュメントが生まれていない。このフローが発生しやすいのが障害後のチームの現実です。
ポストモーテムが書かれないことで失われるのは「同じ障害を未来の自分たちに防ぐ機会」です。チームの学習資産が積み上がらない。
対処法： 「ポストモーテムを書きます」と言った人に、翌営業日に「書きましたか？」と確認する（これだけで完成率が大きく上がります）。あるいは「障害対応後48時間以内にドラフトを書く」をチームルールにする。テンプレートを用意しておくと書き始めのコストが下がります。
「今回は特殊なケースでした」
翻訳： 次も同じことが起きたとき、また同じことを言う準備ができています
「特殊なケース」は再発防止をしなくていい理由として使われることがあります。「これは滅多に起きないケースだから」「本番環境で特定のデータが重なったときだけ発生するから」——本当に特殊なこともありますが、そう結論づけることで思考停止が起きることもあります。
「特殊なケース」と判断するなら、「どのくらいの頻度で起こりうるか」「次に起きたときに素早く対応できるか」をセットで議論するべきです。
対処法： 「特殊なケース」と結論した場合でも「再発した場合のRunbookを整備する」という対応は常にできます。ゼロイチではなく、「対応コストを下げる」という選択肢を持つ。
「次回に活かします」
翻訳： 振り返りが終わったので、元の生活に戻ります
振り返りの締めくくりとして最も使われる言葉です。温かみがあり、前向きに聞こえます。しかし「何を・どう活かすか」が決まっていない場合、次回の振り返りも同じ言葉で終わります。
「次回に活かす」ためには、「活かす内容」が具体的な行動に落とされていなければなりません。「情報共有を密にする」より「障害発生から5分以内にSlackの#incidentチャンネルに状況を投稿するルールを作る」の方が活かされます。
対処法： 振り返りの最後に「今日の振り返りで決まった具体的なアクションは何か」を全員で確認する。アクションの主語・期限・完了条件が決まっていれば、「次回に活かします」は本物になります。
なぜ障害対応の言葉は暗号になるのか
障害対応はプレッシャーと不確実性が同時にピークに達する場面です。
わからないことを「わかりません」と言うと、「何やってるんだ」と思われるかもしれない。失敗の原因を「私がミスしました」と言うと、評価が下がるかもしれない。こういった恐れが、言葉を柔らかく・曖昧にする方向に働きます。
また、振り返りの場も似た構造があります。「なぜそうなったのか」を正直に話すためには、「正直に話しても責められない」という心理的安全性が必要です。それがないチームでは、振り返りが「言い訳の場」か「誰も本音を言わない場」になりやすい。
障害対応の暗号を減らすために
障害対応中：
- 「わかっていること」と「わかっていないこと」を分けて共有する習慣をつける
- 「確認中」が10分以上続いたら、自分から「助けを求める」を選択できる文化を作る
- 誰かが詰まっていたら、責めるより「一緒に見ましょう」と声をかける
振り返りの場で：
- 「人為的なミス」で終わらず「なぜそのミスが起きる状況になったか」を掘る
- 再発防止策は「誰が・いつまでに・何をするか」まで決めてから終わる
- 「次回に活かします」の前に、具体的なアクションアイテムを全員で確認する
おわりに
障害対応の言葉を翻訳すると、ほとんどが不確実性への対処と、失敗を責められることへの恐れから来ていることがわかります。
これは個人の問題ではなく、チームと文化の問題です。「正直に言える場」を作ることが、長期的には障害の頻度を下げる最も確実な方法かもしれません。
次回はVol.4：スプリント・スクラムイベント編。「スプリントに入れられそうです」「ベロシティが低い」「次のスプリントに持ち越します」——スクラムの場に積み上がった暗号を翻訳します。
シリーズ一覧：職場の暗号辞典
- Vol.1：設計レビュー編
- Vol.2：コードレビュー編
- Vol.3：障害対応・振り返り編（本記事）
- Vol.4：スプリント・スクラムイベント編
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。