第23話｜本番障害｜東央ソリューションズ―― 実務統合型PM論・連載小説

午後十一時五十分。

東和物流。

本番移行が始まった。

大会議室には、東央ソリューションズと東和物流のメンバーが集まっていた。

ホワイトボードには本番移行タイムチャート。

大型モニターには監視画面。

時計だけが静かに時を刻んでいる。

「バックアップ完了。」

「システム停止確認。」

「データ移行開始します。」

高梨は一つひとつ報告を受けながら、タイムチャートにチェックを入れていく。

ここまでは予定どおりだった。

午前一時四十分。

「ジョブ有効化します。」

担当者がエンターキーを押す。

数秒後。

監視画面の一部が赤く変わった。

「……あれ？」

担当者の声が止まる。

「システム間連携ジョブ、異常終了です。」

会議室の空気が一瞬で変わった。

「ログ確認します！」

「リトライしてください！」

「変わりません！」

「原因は？」

誰も答えられない。

高梨は画面を見つめた。

焦ってはいけない。

まず状況を整理する。

「全員、一度止まってください。」

部屋が静かになる。

「このままだと情報が散ります。」

高梨は壁際の大きなホワイトボードへ歩いた。

マーカーを手に取る。

大きく書く。

【障害対策本部】

さらに線を引く。

■ 発生時刻

■ 現象

■ 影響範囲

■ 原因調査

■ 暫定対応

■ 恒久対応

■ 担当

■ 次回報告時刻

「以降、このホワイトボードを唯一の正とします。」

「Slackだけで情報を流さない。」

「口頭だけでも進めない。」

「新しい情報は必ずここへ集約してください。」

「五分ごとに状況更新します。」

慌ただしかった部屋が少し静かになる。

黒田が頷いた。

「いい。」

「開発は原因調査。」

「インフラは設定確認。」

「運用は影響範囲確認。」

「担当を固定する。」

白石もすぐに動いた。

「顧客への状況説明は私が引き受けます。」

「十分ごとに経営へ報告します。」

田辺は業務部門へ電話を掛け始める。

「朝の業務開始に影響が出る可能性があります。」

「現時点では調査中です。」

誰も責任論を口にしなかった。

今は原因を探す時間だった。

午前二時十五分。

「分かりました！」

インフラ担当が声を上げた。

「ジョブサーバの接続先設定が旧環境のままです！」

会議室が静まり返る。

高梨が確認する。

「修正時間は？」

「五分です！」

「影響は？」

「他にはありません！」

黒田が即座に判断する。

「修正。」

「ダブルチェック。」

「終わったら報告。」

午前二時二十七分。

「設定変更完了。」

「ジョブ再実行します。」

全員がモニターを見る。

数秒。

赤かったジョブが、

緑へ変わった。

SUCCESS

誰も歓声を上げなかった。

まだ終わっていない。

高梨が静かに言う。

「業務確認をお願いします。」

電話が鳴る。

田辺が受話器を取る。

数十秒後。

「……正常に動いています。」

その一言で、

大会議室の空気がようやく少しだけ緩んだ。

朝五時。

東の空が少し明るくなり始めていた。

ホワイトボードは文字で埋め尽くされている。

発生時刻。

原因。

対応内容。

担当者。

判断時刻。

すべてが時系列で残っていた。

高梨はそのボードを静かに見つめる。

障害は起きた。

しかし、

情報は混乱しなかった。

誰が何をしているのか。

何が分かっていて、

何が分かっていないのか。

全員が同じ景色を見ながら動けた。

それだけが、

あの夜、唯一の救いだった。

ケーススタディ

第23話では、リリース後に本番障害が発生しました。

しかし、このプロジェクトは「炎上」しませんでした。

その理由は、障害が起きなかったからではありません。

障害が起きた後の動き方が変わったからです。

実際のシステム開発では、本番障害を100％防ぐことは困難です。

だからこそ重要なのは、

「障害発生後に、どのように情報を整理し、組織として対応するか」

という視点です。

それでは、このケースから学んでいきましょう。

ケーススタディ

Q1

本番障害が発生した直後、PMが最初にやるべきことは何でしょうか。

A1｜解答例

最初に行うべきことは、

原因究明ではなく、情報を整理する場をつくることです。

障害発生直後は、

• 開発はログを確認する

• インフラは設定を確認する

• 顧客は影響範囲を知りたい

• 管理職は復旧見込みを聞きたい

と、それぞれが別々に動き始めます。

この状態では、

同じ調査を複数人が実施したり、

古い情報が伝わったり、

誰も全体像を把握できなくなったりします。

そこで重要なのが、

「情報の集約場所（War Room）」を作ることです。

今回、高梨はホワイトボードを用意し、

• 発生時刻

• 現象

• 影響範囲

• 原因調査

• 暫定対応

• 恒久対応

• 担当者

• 次回報告時刻

を一元管理しました。

これにより、

「誰が何をしているのか」

「何が分かっていて、何が分かっていないのか」

を全員が共有できるようになりました。

障害対応では、

情報を集約すること自体が最初の仕事なのです。

Q2

障害対応中に、責任論を始めてはいけない理由は何でしょうか。

A2｜解答例

障害対応の最優先事項は、

サービスを復旧させることです。

ところが、

「誰が悪いのか」

「開発の責任か」

「インフラの責任か」

という議論を始めると、

本来原因調査に使うべき時間が失われます。

さらに、

担当者が責任を恐れて情報を出さなくなり、

問題解決が遅れるケースも少なくありません。

責任の整理は重要です。

しかし、それは復旧後に行うべき活動です。

障害発生直後は、

「誰の責任か」ではなく、

「何が起きているのか」

に集中することが重要です。

高梨がホワイトボードを立ち上げたことで、

関係者全員の視線が責任論ではなく、

事実の整理へ向かったことは、

PMとして非常に重要な判断でした。

Q3

今回の障害対応で、高梨が最も評価されるべき点は何でしょうか。

A3｜解答例

高梨が評価されるべき点は、

障害をすぐに解決したことではありません。

混乱を管理したことです。

インシデント対応では、

障害そのものより、

情報の混乱が被害を拡大させることがあります。

例えば、

• 最新情報が共有されない

• 同じ調査を複数人が行う

• 顧客への説明内容が担当者ごとに異なる

• 復旧見込みが二転三転する

こうした状況は、

障害そのもの以上に、顧客の信頼を失わせます。

今回、高梨は

「ホワイトボードを唯一の正とする」

というルールを作りました。

その結果、

全員が同じ情報を見ながら行動でき、

調査・報告・意思決定が一本化されました。

PMの役割は、

自分で障害を直すことではありません。

チーム全体が最も効率よく問題を解決できる環境を整えることです。

このケースで本当に学んでほしかったこと

本番障害が発生すると、

「なぜこんな障害を防げなかったのか」

という議論になりがちです。

もちろん、再発防止は重要です。

しかし、

障害発生直後にPMが最優先で考えるべきことは、

原因分析ではありません。

「混乱を制御すること」です。

そのためには、

情報を一か所へ集約し、

役割を明確にし、

事実と推測を分け、

一定間隔で状況を更新し続けることが欠かせません。

今回、高梨はホワイトボードを中心に情報を整理することで、

関係者全員が同じ状況認識を持ちながら対応できる体制を作りました。

だからこそ、

障害は発生しても、

プロジェクト全体が混乱へ陥ることはありませんでした。

優れたPMとは、

障害を一度も起こさない人ではありません。

障害が起きても、組織を混乱させず、冷静に復旧へ導ける人です。

それこそが、本番障害対応におけるPMの最も重要な役割なのです。

連載にこれまでお付き合いいただきありがとうございます。
次回は最終回、第24話となります。