目次
1. なぜ障害対応でPMの関わりが重要なのか
AWSの障害対応は、技術的な復旧だけでなく、
・影響範囲の整理・関係者への共有
・顧客への報告
・判断ポイントの提示
といった「非エンジニア領域」が非常に多く絡んできます。
エンジニアは復旧作業に集中したいので、“状況説明” や “顧客対応” が同時に押し寄せるほど負荷が高まります。
だからこそ PM が
・どれくらいの影響か
・顧客にはどう伝えるか
を整理してくれると、チーム全体の動きが落ち着きます。
PMが主導することで、全員が迷いなく役割に集中できる。
これが障害時における最大の価値です。
2. インシデント発生直後にPMがしたいこと
AWSの障害は、最初の10分がとても大切です。
ただし、やることは難しくありません。
PMが最初に整理したい項目
・どの機能で問題が発生しているか・どの環境（本番／ステージング）で起きているか
・ユーザーにどの程度影響がありそうか
・いつから起きているか
・緊急度の目安
ここでは原因を特定する必要はなく、 「状況を言葉にできる状態をつくる」 ことが目的です。
顧客への一次連絡は早めに
原因が不明でも問題ありません。
「調査中であること」「次の報告タイミング」を伝えるだけで、顧客の不安は大きく減ります。
3. 対応フェーズでPMができること
復旧作業そのものはエンジニアが進めますが、PMには “復旧をスムーズにするための環境づくり” があります。
PMの主な動き
・エンジニアが動きやすいように、情報を整理して共有する・いまの状況を短くまとめて、社内外に共有する
・判断が必要な場合は意思決定をサポートする
・顧客からの質問が来た際に“受け止め役”になる
特に大切なのは、
「エンジニアの仕事を増やさない情報共有」
です。
状況をまとめずに「いまどうなっていますか？」と何度も聞いてしまうと、かえって復旧が遅れてしまいます。
エスカレーションの判断
例えば、次のような状況はエスカレーションのサインになります。
・10分たっても復旧の方向性が見えない・影響範囲が広がってきた
・ユーザーからの問い合わせが増えてきた
こういった場合は、チーム内での報告範囲を広げるタイミングです。
PMは、
「何をどこまで伝えたほうが安心か」
という視点を持てると、とても心強い存在になります。
4. 復旧した後にPMがすること
復旧確認は、PMとエンジニアで一緒に行うことが多いです。
復旧の確認ポイント
・画面／操作が正常に動くか・メトリクスやログが落ち着いているか
・他の機能に影響が出ていないか
5. Post-mortem（事後振り返り）
障害対応の価値は、実は「復旧後」にあります。
ここで PM が主導し、
・改善点の洗い出し
・再発防止策の検討
を進めると、チームは必ず強くなります。
誰かの責任を問うのではなく、 「次にもっと上手くやるための改善」 に意識を向けることが大切です。
PMがその空気をつくってあげられると、チームはとても働きやすくなり、自然とレベルが上がっていきます。
6. まとめ：PMの動きで、障害対応はもっと良くなる
AWSの障害対応で PM に求められるのは、技術を深く理解することではありません。
PMができれば十分な3つのこと
・状況を整理し、みんなが動きやすい状態をつくること・顧客への不安が大きくならないようにコミュニケーションすること
・障害を学びにつなげ、チーム全体の運用を底上げすること
これらができるだけで、 「エンジニアに丸投げしないPM」 として、障害対応に強いチームをつくることができます。
