障害が起きたときのPMの動き方
本番稼働後に障害が起きた。あるいはテスト中に、業務が止まるほどの不具合が出た。こういうとき、PMは何をすべきでしょうか。
答えは「直す人」ではなく「回す人」になることです。原因の調査と修正は技術者に任せ、PMは情報を整理し、判断し、外に伝える役割に専念します。
■ 最初の30分：止血と体制
事実だけを集める
最初に知るべきは「何が起きているか」であって、「なぜ起きたか」ではありません。原因の議論は後です。
いつから起きているか
どの機能・どの業務が使えないか
何人が、どの業務で困っているか
データが壊れている可能性はあるか
とくに4つ目は早く確認します。データの不整合は、時間が経つほど範囲が広がります。
指揮者を1人決める
技術対応の指揮を誰が執るかを、その場で決めます。PMがやる必要はありません。むしろ、PMが技術調査に入り込むと、全体の指揮が止まります。
PMは、対外の窓口と情報の集約に回ります。
連絡の場を1本にする
複数のチャットや電話で情報が散ると、状況が分からなくなります。「この件はこのチャンネルで」と決めて、そこに集約します。
第一報を出す
原因が分からなくても、第一報は出します。伝えるのは次の4つです。
いま何が起きているか（分かっている範囲で）
業務への影響
いま何をしているか
次にいつ報告するか
「原因を調べています。1時間後にあらためてご報告します」。これだけで、相手の不安はかなり収まります。沈黙がいちばん不安にさせます。
■ 当日中：暂定対応と情報整理
暂定の回避策を決める
根本原因の修正には時間がかかります。まず、業務を回す方法を決めます。「この画面は使わず、手作業で伝票を起こしてください」「受付は一時的に電話で」。
回避策は、業務側に具体的な手順として伝えます。「代替手段をご検討ください」では現場は動けません。
時系列のログを書き続ける
何時に何が分かり、何を決めたかを、1か所に書き続けます。これは後の報告書の材料になりますし、途中から人が加わったときの共有にもなります。
記憶で後から書くと、必ず抜けます。その場で書きます。
定期報告の時刻を決める
「1時間ごとに、状況が変わらなくても報告します」と決めておきます。変化がなければ「変化ありません」と伝えます。
報告の時刻を決めておくと、関係者からの問い合わせが減り、対応者が作業に集中できます。
交代要員を手配する
長期化に備えます。徹夜対応は、翌日の判断力を確実に落とします。PMは、対応者の休憩と交代を手配する役です。
復旧の判断基準を決める
「何が確認できたら復旧とするか」を、収束の前に決めます。決めずに進めると、「まだ不安だ」と言われて終われません。
■ 翌日以降：恒久対応と再発防止
原因を分析し、恒久対応の計画を立てる
影響を受けたデータや業務の是正を行う
経緯・原因・対応・再発防止策をまとめて報告する
検知が遅れた理由も振り返る（気づくのが遅れたこと自体が課題です）
他の箇所に同じ弱点がないか点検する
報告書は、犯人探しの文書ではありません。次に同じことが起きないようにするための文書です。書き方でチームの雰囲気が変わります。
■ PMがやってはいけないこと
自分で原因調査に入り込む 指揮者が不在になり、対外対応も止まります
原因が分かる前に断定して報告する 後で訂正すると、信頼を失います。「調査中」と言い切る勇気が要ります
対応中の担当者に何度も状況を聞きに行く 手が止まります。報告の時刻を決めて、それまで待ちます
その場で責任の所在を問う 対応が終わってからにします
■ まとめ
障害対応でのPMの仕事は、技術対応の環境を整えることです。情報を集約し、外に伝え、交代を手配し、判断の場を作る。
そして、最も効くのは「次にいつ報告するか」を毎回伝えることです。これだけで、対応中の余計な問い合わせが減り、現場が落ち着きます。