日本語システム障害報告書作成とインシデント対応コミュニケーション実践ガイド

##コア日本語表現

障害対応で使用する日本語は日常ビジネス日本語よりも専門的で整形化されている。ここでは、障害ライフサイクルの各段階ごとに必ず知るべき表現をまとめる。

### 障害発生報告（障害発生）

|日本語表現|読む|韓国語の意味|使用状況
| -------------------------- | ---------------------------------------- | ----------------------------- | -------------- |
| 障害が発生しました。 しょうがいがはせました|障害が発生しました。最初の報告
| サービスが停止中です。 サービスがあります。サービスが停止しています。サービスダウン時|
| 応答遅延が発生しています。 おうとうちんがハッセイしています |応答遅延が発生しています。性能低下時|
| 警告を検出しました| アラートをけんちました|アラットを検出しました。モニタリングアラット
| 影響範囲を調査中です。 えいきょうんいをちょうさちゅです|影響範囲を調査中です。初期調査フェーズ
| 障害対策本部を設置しました。 しょうがたいさくほんぶをせっちゃいました|障害対策本部を設置しました。重大障害時|

###原因分析(原因分析)

|日本語表現|読む|韓国語の意味|
| ---------------------------- | ---------------------------------------- | ----------------------------------- |
| 原因を特定しました| げんいんをとりました|原因を特定しました。
| 根本原因（RCA）| こんぽんげんいん|根本原因|
| 直接原因| ちょくせつげんいん|直接原因|
| 原因調査を続けています。 げんいちょうさをけいぞくしています|原因調査を続けています。
| 設定ミスが原因と判明しました。 せていミスがげんいんとんめいしました|設定ミスが原因であることが判明しました。
| 想定外の負荷が原因です。 そうていがいのふかがげんいです|予想外の負荷が原因です。

###影響範囲(影響範囲)|日本語表現|読む|韓国語の意味|
| -------------------------------- | ------------------------------------------ | ----------------------------- |
| 影響の範囲は限られています。 えいきょうんいはげんであります|影響の範囲は限られています。
| 全ユーザーに影響があります。 ユーザーにえいきょうがあります|ユーザー全体に影響があります。
| 一部機能が利用できません。 いちぶきのうがりようふふです |一部の機能は利用できません。
| データ損失はありません。 データそんしつはありません。データ損失はありません。
| 約〇〇件の取引に影響 やく〇〇けんのトランザクションにえいきょう｜約OO件の取引に影響

### 復旧作業(復旧作業)

|日本語表現|読む|韓国語の意味|
| ---------------------------- | ---------------------------------------- | ---------------------------- |
| 修復作業を開始しました。 ふっきゅうさぎょうをかいしました|回復作業を開始しました。
| 暫定対応を実施しました| ざんていたいおうをじっとしました |臨時対応を行いました。
| ロールバックを実施します。 ロールバックをじしします。ロールバックを行います。
| サービスが正常に回復しました| サービスがせいじょにふっきゅうしました|サービスが正常に回復しました。
| 経過観察中です。 けいかかんさつちゅうです|経過観察中です。
| 全面復旧を宣言します。 ぜんめんふっきゅうをせんげんします |フロントリカバリを宣言します。

＃＃緊急報告コミュニケーション（Slack / Phone）

障害発生初期には公式レポートよりリアルタイムコミュニケーションが優先だ。 Slackと電話で使用する日本語表現は報告書とはトーンが違うが、正確性と緊急感を同時に伝えなければならない。

### Slack障害報告メッセージテンプレート

日本のIT企業の障害対応Slackチャネル（一般的には＃incidentまたは＃障害対応）では、次の形式が標準的に使用されています。```text
🚨 【障害発生】決済システム応答遅延

@channel 障害が発生しました。

■ 発生日時：2026/03/06 14:23 JST
■ 影響：決済APIのレスポンスタイムが15秒超
■ 影響範囲：EC決済サービス全体
■ ステータス：🔴 調査中
■ 担当：@tanaka @kim
■ 対応チャンネル：#inc-20260306-payment

現在原因調査中です。状況分かり次第、随時更新します。

---

[14:30 更新] @kim
原因の手がかりを掴みました。DBコネクションプールが枯渇している
模様です。詳細調査を続けます。

[14:45 更新] @kim
原因特定しました。バッチ処理の重複実行によるDBコネクション枯渇です。
暫定対応としてバッチ停止＋コネクションプール拡張を実施します。

[15:30 更新] @tanaka
暫定対応完了。レスポンスタイムが正常値に戻りました。
引き続き失敗トランザクションの再処理を行います。

[16:45 更新] @kim
全面復旧しました。失敗トランザクション3,200件の再処理も完了。
ステータスを🟢に変更します。
明日以降、ポストモーテムを実施予定です。
```Slack 메시지의 포인트는 다음과 같다.

- **@channel** 은 전원 통지
- ステータスは絵文字で視覚的に表現する（🔴調査中→🟡対応中→🟢復旧済み）
- 시계열로 업데이트를 추가하고 스레드가 아닌 채널에 직접 게시하는 것이 일본의 많은 현장에서의 관례
- 「模様です」（～のようです）は推定、「判明しました」（判明しました）は確定。 推定段階では断定表現を避ける

### 電話でのエスカレーション表現

일본의 IT 현장에서는 Critical 장애의 경우는 Slack과 병행하여 전화로의 에스컬레이션이 요구되는 경우가 많다.심야의 온 콜 대응에서는 전화가 제일 연락 수단이 되는 경우도 있다.

전화로 사용하는 표현은 Slack 보다 더욱 간결하고 격식 높아진다.

**上長への第一報**

「수고하셨습니다. 개발부의 금입니다. 긴급의 연락입니다. 오늘 14시 23분경부터, 결제 시스템에서 중대한 장해가 발생하고 있습니다.현재, 원인 조사를 개시하고 있어 장해 대책 본부의 설치를 부탁하고 싶고, 연락했습니다.」

（お疲れ様でした。開発部の金です。緊急連絡です。今日14時23分頃から決済システムで重大な障害が発生しています。現在原因調査を開始し、障害対策本部の設置を要請したいと連絡しました。）

**顧客担当者に連絡**

「신세를 지고 있습니다. XYZ테크의 금입니다. 대단히 죄송합니다만, 현재 폐사의 결제 시스템에서 장해가 발생하고 있어, 귀사의 서비스에도 영향이 나와 있는 상황입니다.현재, 전력으로 복구 작업을 진행하고 있으므로, 복구의 목표가 세워지는 대로, 재차 연락하겠습니다.」

（お世話になっております。XYZテックの金です。 大変申し訳ございませんが、現在当社決済システムで障害が発生して貴社のサービスにも影響が発生している状況です。現在電力で復旧作業を進めておりますので、復旧木先が立つとおり再度ご連絡いたします。）

ここで注意すべき点は「復旧の目処（ふっきゅうのめど）」という表現だ。相手が最も知りたがっているのは「いつ回復されるか」なのに、正確な時間を知らない状態で安易に約束してはならない。 「〇時間以内の復旧を目指しています」（O時間以内に復旧を目指しています）のように目標値を提示しますが、確約は避けるのが原則です。

## 経緯書作成法（経緯書の書き方）

経緯書は、障害報告よりも詳細な時間順経過を記録する文書である。障害報告書が「何が起こり、どのように対処したか」に焦点を当てた場合、経緯は「分単位で正確にどのような順序で事件が展開されたか」を記録する。

### 経緯書作成原則

1. **客観的事実のみ記載する**（客観的事実のみ記載する） - 推測や感情を排除して事実だけ書く
2. **時系列で記載する**（時系列で記載する） - 必ず時間順にまとめる
3. **主語を明確にする**（主語を明確にする） - 誰が何をしたのか明確に記録する
4. **根拠となるログやエビデンスを添付する**（根拠となるログや証拠を添付する）

### 経緯書タイムライン形式テンプレート```text
経緯書

件名：決済システム応答遅延障害に関する経緯書
作成日：2026年3月7日
作成者：開発部 金 英柱
承認者：開発部部長 田中 太郎

1. 障害発生前の状況
  2026年3月6日（金）は通常の営業日であり、特別なリリースや
  メンテナンスは予定されていなかった。
  14:00より、月次集計バッチ処理が自動実行される設定となっていた。

2. 障害発生から復旧までの経緯

  時刻      | 担当者 | 対応内容
  ----------|--------|--------------------------------------------------
  14:00     | (自動) | 月次集計バッチ処理が自動実行開始
  14:15     | (自動) | 日次レポートバッチ処理が自動実行開始（重複実行）
  14:23     | (自動) | Datadogアラート発報（API応答時間 > 5秒）
  14:23     | 金     | PagerDutyよりオンコール通知受信
  14:25     | 金     | Datadogダッシュボード確認、障害認定
  14:26     | 金     | #incident Slackチャンネルに障害発生を投稿
  14:28     | 金     | 田中部長に電話でエスカレーション
  14:30     | 田中   | 障害対策本部設置を指示
  14:30     | 金     | DBメトリクス確認開始
  14:35     | 金     | コネクションプール使用率100%を確認
  14:40     | 金     | バッチ処理の重複実行をCloudWatchログで確認
  14:45     | 金     | 原因特定：バッチ重複実行によるDB接続枯渇
  14:50     | 田中   | 暫定対応方針を承認
  14:55     | 金     | 月次集計バッチ処理を手動停止
  15:00     | 金     | コネクションプール上限を200→500に変更、デプロイ
  15:10     | 金     | API応答時間の改善を確認（15秒→0.8秒）
  15:15     | 金     | Slackにて暫定対応完了を報告
  15:20     | 佐藤   | 失敗トランザクションの抽出開始（SQL実行）
  15:45     | 佐藤   | 失敗トランザクション3,200件を特定
  16:00     | 佐藤   | 再処理バッチ実行、全件正常完了確認
  16:30     | 金     | 経過観察（30分間異常なし）
  16:45     | 田中   | 全面復旧宣言

3. 障害の原因
  （省略：障害報告書と同内容を詳細に記載）

4. 再発防止策
  （省略：後述の再発防止策セクションと同内容）

5. 添付資料
  ・別紙1：Datadogアラート画面キャプチャ
  ・別紙2：CloudWatchログ抜粋
  ・別紙3：DBコネクション数推移グラフ

以上
```経緯書でよく使われる表現として「〇〇を確認」（OOを確認）、「〇〇を実施」（OOを実施）、「〇〇を指示」（OOを指示）、「〇〇を報告」（OOを見て）などがある。いずれも漢字語名詞＋するという形で、簡潔で客観的な技術に適した表現だ。

##再発防止策の作成(再発防止策)

再発防止策（再発防止策、さいはつぼうしさく）は障害報告の核心の中核である。日本のIT業界では障害自体よりも**再発防止策の質**でチームの能力を評価する傾向が強い。 「同じ障害を二度と起こさない」（同じ障害を二度と起こさない）という意志を具体的なアクションアイテムとして見せなければならない。

###再発防止策の3段階構造

日本のIT現場で効果的な再発防止策は、次の3つの視点に分類して作成する。

|分類日本語説明例
| -------- | ------------------ | -------------------------------- | --------------------------------- |
| 発生防止| はせせぼうし|同じ原因が発生しないようにする排他制御の実装、設定検証の自動化
| 早期検出 そうきけんち|発生してもすぐに検出監視強化、アラットしきい値調整|
| 影響を軽減 えいきょうけいげん|検出後の影響を最小限に抑える自動フェイルオーバー、サーキットブレーカーの導入

＃＃＃再発防止策を作成するときに避けるべき表現と正しい表現

|悪い表現（NG）|問題良い表現（OK）|
| ------------------------------ | ------------------ | ------------------------------------------------------ |
| 注意する具体的ではありません。 チェックリストを作成し、ダブルチェックシステムを導入する
| 気をつける人の意志に依存 自動検証を実装する
| 再発しないように確認する行動は不明です。 CIパイプラインに一括排他制御のテストケースを追加する
| 今後は問題ありません。根拠のない断言 負荷テストシナリオを追加し、月次で実施する
| ヒューマンエラーなので仕方ない|責任回避| 人間のエラーを防ぐための自動化を実装する

この表からわかるように、日本のIT現場での再発防止策は、「人の注意力ではなく、システムとプロセスの改善」に焦点を当てるべきです。 「注意する」（注意する）は再発防止策として認められず、必ず技術的またはプロセス的対策を具体的に記述しなければならない。

＃＃ポストモテム文化（ポストモテム）

日本の先進IT企業（メルカリ、LINE、楽天など）では、グーグルSREの影響を受けてポストモテム文化が定着している。ポストモテムは障害報告書や経緯書と異なり、**非難排除（ブレームレス、Blameless）**原則の下の技術的学習に焦点を当てた文書である。

＃＃＃ポストモデルと既存のレポートの違い障害報告書と経緯書が「誰が何をした」（誰が何をした）に集中すれば、ポストモテは「なぜそれが起きたのか、システムとして何が足りなかったのか」（なぜそれが起きたのか、システムとして何が不足したのか）を深く掘り下げる。

###ポストテンプレートテンプレート```text
ポストモーテム報告書

タイトル：決済システム応答遅延障害（INC-2026-0307-001）
作成日：2026年3月13日
ファシリテーター：金 英柱
参加者：田中太郎、佐藤花子、鈴木一郎

■ サマリー
2026年3月6日14:23〜16:45（2時間22分）にわたり、
決済システムの応答遅延が発生。約3,200件の決済処理が失敗した。
直接原因はバッチ処理の重複実行によるDBコネクション枯渇。
根本原因はバッチスケジューラーの排他制御の欠如。

■ インパクト
・影響期間：2時間22分
・影響ユーザー数：約50,000名
・失敗トランザクション：3,200件（全件再処理完了）
・推定売上影響：約480万円（遅延による離脱を含む）
・SLA違反：あり（月次稼働率99.95%目標に対し影響あり）

■ タイムライン
（経緯書のタイムラインを転記）

■ 根本原因分析（5 Whys）
1. なぜ決済APIが遅延したか？
   → DBコネクションプールが枯渇したため
2. なぜコネクションプールが枯渇したか？
   → 2つのバッチ処理が同時に大量のDB接続を使用したため
3. なぜバッチ処理が同時実行されたか？
   → スケジューラーに排他制御が未実装だったため
4. なぜ排他制御が未実装だったか？
   → 初期設計時にバッチ処理の同時実行シナリオが考慮されていなかったため
5. なぜ設計レビューで検知できなかったか？
   → バッチ処理の負荷試験シナリオが不十分だったため

■ うまくいったこと（What went well）
・アラート検知から2分以内にオンコール担当が対応を開始した
・原因特定まで22分と迅速だった
・関係者間の情報共有がSlackで適切に行われた
・失敗トランザクションの再処理手順が整備されていた

■ うまくいかなかったこと（What didn't go well）
・バッチ排他制御が設計段階で考慮されていなかった
・コネクションプールの監視アラートの閾値が高すぎた（80%→実質的に検知不能）
・顧客への第一報に35分を要した（目標は15分以内）

■ 幸運だったこと（Where we got lucky）
・障害発生がピーク時間帯（12:00〜13:00）を過ぎていた
・データ損失が発生しなかった

■ アクションアイテム
| No. | アクション | 担当者 | 期限 | ステータス |
|-----|-----------|--------|------|-----------|
| 1   | バッチスケジューラー排他制御実装 | 金 | 3/14 | 対応中 |
| 2   | コネクションプール監視強化 | 佐藤 | 3/10 | 完了 |
| 3   | 負荷試験シナリオ追加 | 鈴木 | 3/21 | 未着手 |
| 4   | 顧客通知フロー見直し | 田中 | 3/17 | 未着手 |
| 5   | 障害訓練（ゲームデー）実施 | 金 | 4/末 | 未着手 |

■ 学んだこと（Lessons Learned）
・バッチ処理の設計時には、同時実行・リソース競合を必ず考慮する
・「起きないだろう」という前提でなく、「起きたらどうなるか」で設計する
・監視アラートの閾値は、障害に至る前に検知できる値に設定する

以上
```포스트모템의 회의에서는 다음과 같은 진행 문구가 사용된다.

- 「このポストモテムはブレームレスで行います。個人の責任を追及する場ではありません。」
- 「システムの改善点にフォーカスしましょう。」（システムの改善点にフォーカスしましょう。）
- 「なぜそうなったのか、5回掘り下げてみましょう。」

##本番会話シミュレーション

実際の障害対応状況で発生する会話をシミュレーションで見てみましょう。障害発生から復旧までの各段階別コミュニケーションを通じて実戦感覚を身につけることができる。

＃＃＃シナリオ：金曜日の午後の決済システムの障害

**シーン1：障害検出直後にSlackを報告**

김(엔지니어): "@channel 긴급입니다. 결제 API의 응답 시간이 15초를 넘고 있습니다. Datadog의 경고를 14:23에 탐지했습니다. 조사를 시작합니다."

（緊急です。支払いAPIの応答時間が15秒を超えています。Datadogアラットを14:23に検出しました。調査を開始します。）

**シーン2：上司に電話をエスカレーション**

金：「田中部長、お疲れ様です。金です。緊急の連絡です。」

田中：「はい、何かありましたか。」

金：「決済システムに重大な障害が発生しています。14時23分にDatadogアラートを検出し、現在APIの応答時間が通常の30倍に達しています。障害対策本部の設置をお願いしたいのですが。」

田中：「わかりました。すぐに設置します。影響範囲は把握できていますか。」

金：「現時点ではEC決済サービス全体に影響が出ていると見ています。詳細な影響範囲は調査中です。」

田中：「了解。お客様への連絡は私の方で対応します。原因調査を最優先でお願いします。」

金：「承知しました。状況が分かる度に、Slackで随時報告します。」

**シーン3：原因特定後の対応方針の確認**

김(Slack에서): 「@tanaka_bucho 원인을 특정했습니다. 월간 집계 배치와 일차 리포트 배치가 동시 실행되어, DB 커넥션 풀이 고갈하고 있습니다. 잠정 대응으로서, (1) 배치 처리의 수동 정지, (2) 커넥션 풀 상한의 확장을 제안합니다.」

田中：「了解です。その方針で進めてください。本番環境への変更なので、変更内容をSlackに記録した上で実施してください。」

金：「承知しました。変更内容を記録してから実施します。」

**シーン4：回復後の報告**

김(Slack에서): 「전면 복구했습니다.16:45를 가지고 복구 선언으로 하겠습니다. 실패 트랜잭션 3,200건의 재처리도 완료하고 있습니다.장애 보고서는 내일 중에 작성하겠습니다. 포스트 모템은 다음주 실시 예정입니다. 바쁜 중 대응해 주셔서 감사합니다.

このシミュレーションで注目すべき点は、キムエンジニアがすべての段階で「判断を求める」コミュニケーションをしているということだ。日本のIT現場では技術的判断が当たっても、上司の承認（承認）を得た後に実行することが重要だ。特に本番環境（本番環境）への変更は必ず事前承認を受けなければならない。

＃＃注意事項とよくある間違い

韓国人エンジニアが日本のＩＴ現場で障害対応時によく犯すミスとその対処法をまとめる。

### ミス 1: 推測を単定で表現

**NG**: 「原因はDBの負荷です。」(原因はDB負荷です。)
**OK**: 「原因はDBの負荷であると考えられます。調査を続けています。」（原因はDB負荷だと思われます。調査を続けています。）確定されていない情報を断定的に言うと、後で原因が異なることが判明したときに信頼を失います。日本語には推定表現が豊富なので積極的に活用しなければならない。

- 「〇〇と思われます」（OOと思われます）
- 「〇〇の可能性があります」（OOの可能性があります）
- 「〇〇と見ています」（OOと見ています）
- 「〇〇の模様です」（OOのようです）

＃＃＃ミス2：報告なしで一人で判断して対応

韓国のIT現場では、エンジニアが自律的に判断して迅速に対応することが美徳であることが多い。しかし、日本では**報告・連絡・相談（ほうれんそう、報告・連絡・相談）**が基本だ。特に本番環境に対する変更は、いくら緊急しても上司の承認を先に受けなければならない。

**NG**: (Slack に報告せずにすぐにサーバーを再起動)
**OK**: 「サーバの再起動を実施したいのですが、よろしいでしょうか。」（サーバ再起動を行いたいのですが、大丈夫でしょうか？）

＃＃＃ミス3：リンゴ表現の欠如または過剰

障害報告でリンゴが抜ければ反省がないとされ、逆に過度のリンゴは不安感を与える。

**過小**: 「障害が発生しました。復旧済みです。」(障害が発生しました。修復完了です。) - 謝罪なし
**過剰**: 「大変申し訳ありません、本当に申し訳ありません、誠に...」 - 過度の繰り返し
**適切**: 「この度はご迷惑をおかけし、深くお詫び申し上げます。」（今回ご迷惑をおかけして深くお詫び申し上げます。）

＃＃＃ミス4：再発防止策の精神論

先に取り上げたがもう一度強調するほど重要なポイントだ。 「気をつけます」（注意します）、「今後注意します」（これから注意します）は、日本のIT業界で再発防止策として絶対に認められない。具体的な技術的対策やプロセスの変更を明示しなければならない。

### ミス 5: 時間の不正確な記載

「14時ごろ」（14時ごろ）ではなく「14時23分」（14時23分）と正確に記載しなければならない。障害報告と経緯の時間の正確さは、文書の信頼性を決定する重要な要素です。監視ツールのログに基づいて分単位で正確に記録することが原則です。

## 失敗事例で学ぶ

実際の現場で発生する可能性のある障害報告失敗事例を通じて教訓を得てみよう。

＃＃＃ケース1：報告の遅れによる信頼の喪失

ある韓国人エンジニアが夜間オンコール中に障害を感知した。技術的に素早く原因を把握して30分で回復したが、回復後のみSlackに報告した。翌日上司から「なぜすぐに報告しなかったのですか」（なぜすぐに報告しなかったのか）という指摘を受けた。

**教訓**: 日本では復旧より報告が先だ。 「まず報告、それから対応」（まず報告、その後対応）が原則である。障害を感知した直ちに、調査を開始すると同時に、最初の報告を上げなければならない。内容が不完全でも大丈夫です。 「障害の可能性があります。確認中です」（障害の可能性があります。確認中です）が1行で十分です。

＃＃＃ケース2：再発防止策が受け入れられていない場合

障害報告書に再発防止策として「担当者が配布前の確認を徹底する」と作成した。上司から「それは対策ではなく心がけです。技術的な対策を書いてください」（それは対策ではなく心構えです。技術的な対策を書いてください）というフィードバックを受けた。**教訓**: 再発防止策は必ず**検証可能(検証可能)および自動化可能(自動化可能)**したものでなければならない。 「CI/CDパイプラインに〇〇チェックを追加する」(CI/CDパイプラインにOOチェックを追加する)、「〇〇のアラート閾値を変更する」(OOのアラットしきい値を変更する)のように具体的な技術アクションで記述する。

＃＃＃ケース3：顧客レポートの過度の技術用語

顧客に送る障害報告書に「DBコネクションプールの枯渇によりスレッドプールがブロックされる…」と技術的詳細をそのまま使った。お客様担当者から「もう少し分かりやすく書いていただけますか」（もっとわかりやすく書いていただけますか）という要請を受けた。

**レッスン**：顧客向けレポートでは技術用語を最小限に抑え、影響と対応に焦点を当てる必要があります。 「システム内部の処理能力の上限に達したため、一時的にサービスの応答が遅くなりました」（システム内部の処理能力の上限に達して一時的にサービス応答が遅くなりました）のように非技術的な表現に置き換えます。

## 障害対応メールテンプレート

障害の状況で顧客や関係者に送信する電子メールは、タイミングと内容の両方にとって重要です。以下は、障害発生時に送信する第1報と復旧完了報告のEメールテンプレートである。```text
件名：【緊急・障害報告】決済システム障害発生のお知らせ

株式会社ABCコマース
システム管理部
佐々木 様

いつもお世話になっております。
株式会社XYZテック 開発部の金 英柱でございます。

大変申し訳ございませんが、弊社が運用しております
決済システムにおいて、下記の通り障害が発生しております。

■ 障害概要
・発生日時：2026年3月6日（金）14:23頃
・影響内容：決済処理の応答遅延
・影響範囲：決済サービスをご利用の全てのお客様
・現在のステータス：原因調査中

■ 現在の対応状況
現在、原因の特定および復旧作業を最優先で進めております。
復旧の目処が立ち次第、改めてご連絡いたします。

ご利用のお客様にはご不便をおかけしておりますこと、
深くお詫び申し上げます。

取り急ぎ、第一報としてご連絡申し上げます。

何卒よろしくお願い申し上げます。

──────────────────────────
株式会社XYZテック 開発部
金 英柱（キム・ヨンジュ）
TEL：03-XXXX-XXXX
Email：kim@xyztech.co.jp
──────────────────────────
```この電子メールで注目すべき表現は次のとおりです。

- 「取り急ぎ、第一報としてご連絡申し上げます」（急いで、第一報としてご連絡致します） - まだ完全な情報ではないことをお知らせ
- 「復旧の目処が立ち次第」（復旧の見込みが立つとおり） - 具体的な時間を約束しないが、後続の連絡を予告
- 「深くお詫び申し上げます」（深くお詫び申し上げます） - 格式あるりんご

## チェックリスト

障害発生時に欠けやすい項目をチェックリストにまとめる。このチェックリストをチーム内で共有しておけば、実際の障害時に不足なく対応できる。

### 障害発生直後(発生直後)

- モニタリングアラット確認および障害認定（監視アラート確認・障害認定）
- Slack #incidentチャンネルに第1報投稿 (Slack第一報投稿)
- 上司にエスカレーション (上長へのエスカレーション)
- 障害対策本部設置要請（障害対策本部設置依頼） ※Criticalの場合
- 影響範囲の初期把握（影響範囲の初期把握）

###調査/対応中(調査・対応中)

- 原因調査状況を15分ごとにSlackにアップデート（15分おきに状況更新）
- 対応方針を上司に承認を受ける（対応方針の承認取得）
- 本番環境変更時の変更内容を記録（本番変更内容の記録）
- 顧客担当者に第一報メール送信（顧客への第一報メール送信）

### 復旧後(復旧後)

- 経過観察実施（30分以上以上ない確認）（経過観察実施）
- 全面復旧宣言(全面復旧宣言)
- お客様に復旧完了報告メール送信（復旧完了報告メール送信）
- 失敗トランザクションなど残余対応処理（残対応の実施）

###事後対応(事後対応)

- 障害報告書作成（24～48時間以内）（障害報告書作成）
- 経緯書作成（1週間以内）（経緯書作成）
- ポストモテ実施（1～2週間以内）（ポストモテム実施）
- 再発防止策の実行および追跡（再発防止策の実行・追跡）
- 再発防止策完了報告（再発防止策完了報告）

## 障害対応でよく使われる日本語の略語と専門用語

日本のIT現場のSlackや口頭コミュニケーションでは、略語と専門用語が頻繁に使われる。これを知らないと会話速度を追いにくい。|略語/用語|正式名称|意味|
| ---------------- | ---------------------------- | --------------------------------------- |
| 障害票| 障害管理票|障害管理チケット|
| 一次切り分け| 一次切り分け調査一次分類調査
| 暫定/恒久| 暫定対応/恒久対応|一時的な対応/恒久的な対応|
| 横展開| 横展開|類似システムの水平展開チェック
| 水平展開| 水平展開確認|同じ原因が他の場所にも存在することを確認する
| 切り返し| 切り返し（きりもどし）|ロールバック|
| 縮退運転| 縮退運転（しゅくたいうんてん）|機能を縮小して操作する（Degraded mode）
| 冗長化 冗長化（じょうちょうか）|冗長/冗長|
| フェイルオーバー| フェイルオーバー|フェイルオーバー|
| ゲームデー| ゲームデー|障害対応訓練（Game Day）|

特に「横展開(よこてんかい)」は韓国でよく使わない概念だが、日本のIT現場では非常に重要に扱われる。一つの障害が発生した場合、「他のシステムでも同様の問題がないか横展開で確認してください」（他のシステムでも同じ問題がないか水平展開で確認してください）という要求が必ずついてくる。

＃＃障害対応レベル別コミュニケーションの整理

障害の重大度（Severity）によって必要なコミュニケーションの範囲と格式が変わる。下表で各レベル別対応を一目で把握することができる。|アイテム| Critical（P1）| Major（P2）| Minor（P3）| Low（P4）|
| ----------------- | --------------- | --------------- | ---------- | ----------- |
|日本語 緊急 重大| 軽微 低
| Slack通知| @channel | @here |チャンネル投稿|スレッド|
|電話エスカレーション|必須|状況に応じて不要不要
|顧客連絡|即時| 1時間以内必要に応じて事後報告|
|障害報告|必須（24時間以内）|必須（48時間以内）|簡易報告|チケット記録のみ|
|ポストモデル|必須|推奨|ランダム不要
|経営陣の報告即時|当日|週間報告|不要

##参考資料

障害報告書の作成とインシデント対応のより深い学習のために、以下の資料を参考にしてください。

- [障害報告書の書き方 - Qiita](https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda) - 障害報告書作成の基本原則と実践例を扱った記事
- [障害レポートテンプレート - NotePM](https://notepm.jp/template/failure-report) - すぐに使用できる障害レポートテンプレートのコレクション
- [システム障害報告書の書き方 - SHIFT](https://service.shiftinc.jp/column/5344/) - 品質保証の観点から見た障害報告書作成ガイド
- [障害報告書テンプレートと書き方 - Qbook](https://www.qbook.jp/column/1793.html) - テスト観点からの障害報告方法論
- [ポストモテムの書き方 - Qiita](https://qiita.com/Ping/items/7cc93bcae87583184121) - Google SREスタイルポストモテ
- [Google SRE Book - Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) - ポストモテム文化の原発
- [PagerDuty Incident Response Guide](https://response.pagerduty.com/) - インシデント対応プロセスガイド

この記事で取り上げた内容を実戦で活用するためには、普段日本語障害報告書をたくさん読むことが重要だ。自社の過去障害報告書を閲覧したり、上記の参考資料でテンプレートを学習しながら日本語障害対応コミュニケーションに慣れてほしい。障害はいつでも発生する可能性がありますが、準備されたエンジニアは障害をチームの学習機会に変えることができます。