【非エンジニア編第15回】障害発生時、非エンジニアが状況を整理するために使う

※Claude Codeを使用して記事を作成しています。

前回の記事では、議事録や要件を技術的な言葉に変換する方法を紹介しました。

第4部「実務シーン編」の3回目は、

障害発生時の状況整理

です。

システムに障害が起きたとき、非エンジニアの立場だと、

何をすればいいのかわからず、焦ってしまう
情報が錯綜して、何が事実なのか見えなくなる
上司や顧客への報告を求められ、何を書けばいいのか迷う

といった状況に置かれがちです。

障害の原因を調べて直すのはエンジニアの仕事です。
しかし、周囲の状況を整理し、関係者に伝える役割は、非エンジニアにも求められます。

Claude Codeを使って、障害発生時に状況を整理する方法を紹介します。

最初に:Claude Codeは障害の原因を特定できない

大事な前提を先に共有します。

Claude Codeは、あなたのシステムの中身を見ることができません。
そのため、

障害の原因を特定する
復旧の見込みを判断する
「たぶんこれが原因です」と断定する

といった使い方には向いていません。

原因の調査と復旧の判断は、システムの状況を直接確認できるエンジニアが行うものです。

Claude Codeの役割は、

非エンジニアが持っている情報を整理し、
伝わる形にまとめること

です。

この線引きを意識しておくことで、障害対応の現場を混乱させずに使えます。

非エンジニアが障害時にやるべきこと・やらなくてよいこと

まず、役割を整理しておきます。

【非エンジニアがやるべきこと】
- 何が起きているかを、事実として集める
- いつから、誰に、どんな影響が出ているかを把握する
- お客様や社内の問い合わせ状況を集約する
- 関係者への連絡や報告を担う
- エンジニアが調査に集中できる環境を作る

【やらなくてよいこと】
- 原因を推測して、エンジニアに伝えること
- 復旧方法を提案すること
- 調査中のエンジニアに、頻繁に進捗を聞くこと

特に最後の項目は大切です。

進捗を何度も聞かれると、エンジニアの調査が中断されてしまいます。

そのためにも、

非エンジニア側で情報を整理しておき、
必要なときに一度で伝えられる状態にしておく

ことが重要になります。

障害時の情報整理で意識したい3つの区別

状況を整理する際は、以下の3つを分けて考えます。

事実:実際に確認できていること
推測:確認できていないが、可能性として考えていること
未確認:まだ調べていない、わからないこと

障害時は情報が錯綜しやすく、推測がいつの間にか事実として共有されてしまうことがあります。

Claude Codeに整理してもらうときも、この3つを分けて書いてもらうように依頼します。

実例:問い合わせが急に増えた場面

ここでは、以下のような状況を例にします。
内容は説明のための仮の例です。

【状況のメモ(バラバラの状態)】
- 午後2時ごろから、お客様から「ログインできない」という連絡が来始めた
- サポートに届いた件数は、1時間で10件くらい
- 社内の人間が試したら、自分のスマホでもログインできなかった
- パソコンからは入れた人もいるらしい
- 誰かが「昨日のアップデートのせいでは」と言っていた
- エンジニアのAさんにはチャットで一報を入れた

メモとしては、情報が混ざっていて、何が事実で何が推測なのか判別しにくい状態です。

ステップ1:事実・推測・未確認に分ける

まず、メモをそのまま渡して、分類してもらいます。

【質問例】
システム障害の可能性がある状況について、以下のメモを整理してください。
「確認できた事実」「推測」「未確認」に分類してください。
メモに書かれていないことは補わず、原因の断定もしないでください。

(状況のメモを貼り付ける)

「原因の断定もしないでください」と伝えることがポイントです。

Claude Codeが、以下のように分類してくれます。

【分類例】

■ 確認できた事実
- 午後2時ごろから、ログインできないという連絡が届き始めた
- 1時間で約10件の問い合わせがあった
- 社内でも、スマートフォンからはログインできなかった
- エンジニアのAさんに、チャットで一報を入れている

■ 推測
- 昨日のアップデートが関係している可能性
  （発言者の意見であり、根拠は確認されていない）

■ 未確認
- パソコンからは入れた、という情報の正確性
  （伝聞のため、確認が必要）
- 障害の影響を受けている範囲（全員か、一部か）
- 問い合わせの正確な件数と、最初の連絡があった時刻

「昨日のアップデートのせい」という発言が、
推測として切り分けられました。

ここを事実として共有してしまうと、調査の方向を誤らせるおそれがあります。

ステップ2:時系列で整理する

次に、出来事を時間順に並べます。

【質問例】
以下の情報を、時系列の表にまとめてください。
時刻が不明なものは「時刻不明」と書いてください。

(時刻付きの情報を貼り付ける)

Claude Codeが、以下のように整理してくれます。

【時系列の例】

| 時刻 | 出来事 | 情報源 |
|---|---|---|
| 14:00ごろ | ログインできないという連絡が届き始める | サポート窓口 |
| 15:00ごろ | 累計で約10件の問い合わせ | サポート窓口 |
| 時刻不明 | 社内でスマートフォンからのログインを試し、失敗 | 社内メンバー |
| 時刻不明 | エンジニアのAさんにチャットで一報 | 自分 |

時系列にしておくと、

「いつから起きているのか」
「いつ誰に連絡したのか」

が一目でわかります。

後から振り返りをする際にも、この記録が役立ちます。

時刻は、わかった時点で、その場で記録しておく習慣が大切です。

ステップ3:エンジニアに伝える情報をまとめる

調査中のエンジニアに、簡潔に状況を伝えるための文章を作ります。

【質問例】
調査中のエンジニアに共有するための、状況のまとめ文を作成してください。
事実と推測を分けて、短く書いてください。

Claude Codeが、以下のように作成してくれます。

【共有文の例】

お疲れ様です。現時点で把握している状況を共有します。

【確認できている事実】
- 14時ごろから、ログインできないというお問い合わせが届いています
- 15時時点で、約10件の問い合わせがあります
- 社内のスマートフォンからも、ログインできませんでした

【推測(未確認)】
- 昨日のアップデートとの関連を指摘する声がありますが、
  根拠は確認できていません

【未確認】
- パソコンからは入れたという情報がありますが、伝聞です
- 影響範囲（全ユーザーか一部か）

お客様からの問い合わせ件数は、増えた時点で追記してお知らせします。

「推測」と「未確認」を明記しておくことで、エンジニアが情報の確度を判断しやすくなります。

ステップ4:社内の関係者への報告文を作る

次に、上司や他部署への報告文を整えます。

【質問例】
上司への第一報として、以下の状況を報告する文章を作成してください。
技術的な専門用語は使わず、現時点でわかっていることと、
わかっていないことを分けて書いてください。
復旧の見込みは、わからないものとして断定しないでください。

（状況を貼り付ける）

Claude Codeが、以下のように作成してくれます。

【第一報の例】

件名:【第一報】ログインできない事象について

お疲れ様です。
現在、ログインに関する不具合の可能性があり、第一報をお送りします。

【現在の状況】
- 14時ごろから、ログインできないというお問い合わせが届いています
- 15時時点で約10件のご連絡があります
- 社内の確認でも、スマートフォンからはログインできませんでした

【対応状況】
- 開発担当(Aさん)に連絡済みで、調査を依頼しています

【現時点で不明なこと】
- 原因
- 影響を受けているお客様の範囲
- 復旧の見込み

状況が変わり次第、追ってご報告します。
次回の報告は、16時を目安に行います。

ここで重要なのは、

次回の報告時刻を決めて伝えておく

ことです。

報告を待つ側にとって、次の連絡がいつ来るのかがわかるだけで、問い合わせが減り、エンジニアも調査に集中できます。

ステップ5:お客様向けの案内文を整える

お客様への案内も、非エンジニアが担うことの多い業務です。

【質問例】
お客様向けのお知らせ文を作成してください。
以下の条件でお願いします。

- 原因や復旧の見込みは、確認できていないため書かない
- 不具合の可能性があることと、確認中であることを伝える
- お客様に不安を与えすぎない、丁寧な表現にする
- 専門用語は使わない

Claude Codeが、以下のように提案してくれます。

【お知らせ文の例】

ただいま、一部のお客様において、ログインしづらい状況が確認されております。
現在、原因を調査しております。

ご不便をおかけし、申し訳ございません。
状況が分かり次第、あらためてお知らせいたします。

ここでは、確認できていないことを書かないことが大切です。

「まもなく復旧します」のような一文は、根拠がなければ書くべきではありません。

もし復旧が長引いた場合、かえって信頼を損ねてしまいます。

外部に出す文章は必ず確認を挟む

お客様向けのお知らせなど、社外に出す文章は、

内容が事実と合っているか
社内の広報や責任者の確認を経ているか

を確認してから公開してください。

Claude Codeが作った文章を、そのまま公開することは避けましょう。

ステップ6:障害が落ち着いた後の振り返りに使う

障害が収束した後には、振り返りを行うことが一般的です。

ステップ2で作った時系列は、ここで活きてきます。

【質問例】
以下の時系列をもとに、
障害対応の振り返りで確認すべき観点を整理してください。
「検知」「初動」「連絡」「情報共有」の4つの観点で、
良かった点と改善できそうな点を考えるための質問を出してください。

（時系列を貼り付ける）

Claude Codeが、以下のような質問を返してくれます。

【振り返りの質問例】

■ 検知
- 最初の問い合わせから、エンジニアへの連絡まで
  どのくらいの時間がかかったか
- もっと早く気づける方法はなかったか

■ 初動
- 最初に集めた情報で、不足していたものは何か
- 連絡先や連絡手段は、迷わずに選べたか

■ 連絡
- 社内外への連絡は、適切なタイミングで行えたか
- 報告のたびに、同じ情報を何度も書き直していなかったか

■ 情報共有
- 事実と推測が混ざって伝わった場面はなかったか

これらの質問に答えていくことで、

「次に同じことが起きたら、どう動くか」

を具体的に考えられます。

この振り返りの進め方は、第2部で紹介したふりかえりの考え方とも通じます。

障害時にやってはいけないこと

原因をClaude Codeに聞いて、それを共有する

障害の最中に、

【避けたい使い方】
ログインできない原因は何ですか?

とClaude Codeに聞いても、あなたのシステムの状況を知らない以上、一般論しか返ってきません。

その内容を原因として関係者に共有してしまうと、混乱を招くおそれがあります。

原因の話は、エンジニアに任せる

という姿勢を守ってください。

焦って未確認の情報を共有する

情報が欲しい場面ほど、未確認の情報が出回りやすくなります。

共有するときは、

確認できたこと
伝聞や推測であること

を、必ず分けて伝えてください。

個人情報や機密情報をそのまま入力する

障害の最中は、お客様のお名前、メールアドレス、問い合わせの内容などを扱うことがあります。

Claude Codeに入力する際は、

個人が特定できる情報は伏せる、または置き換える
社内のAI利用ルールに従う

ことを守ってください。

状況整理には、「お客様A」「お客様B」のような表記で十分です。

障害時の状況整理テンプレート

いざというときに慌てないよう、あらかじめテンプレートを手元に置いておくと便利です。

【障害時の状況整理テンプレート】

1. 以下のメモを、
   「確認できた事実」「推測」「未確認」に分類してください。
   メモに書かれていないことは補わず、原因の断定もしないでください。
   （状況のメモを貼り付ける）

2. 以下の情報を、時系列の表にまとめてください。
   時刻が不明なものは「時刻不明」と書いてください。
   （時刻付きの情報を貼り付ける）

3. 調査中のエンジニアに共有するための、状況のまとめ文を作成してください。
   事実と推測を分けて、短く書いてください。

4. 上司への第一報の文章を作成してください。
   専門用語は使わず、わかっていることとわかっていないことを
   分けて書いてください。
   復旧の見込みは断定しないでください。

5. 障害が収束した後の振り返りで確認すべき観点を、
   「検知」「初動」「連絡」「情報共有」の観点で質問の形で出してください。
   （時系列を貼り付ける）