システム障害対応で経営者がやること。復旧作業には入りません

午前9時、決済画面が開かなくなりました。エンジニアからは「調査中」とだけ届き、営業には顧客からの問い合わせが集まっています。経営者は、復旧見込みを聞くべきか、謝罪文を出すべきか、サービスを止めるべきか迷います。

僕は、システム障害対応で経営者が復旧作業の細部へ入る必要はないと考えます。経営者が担う仕事は、止まっている業務を把握し、戻す順番を決め、社内外へ同じ時点の事実を説明できる状態を作ることです。

障害そのものに加えて、誰も影響範囲を説明できない状態が二次被害を広げます。技術担当者の能力だけを責めても、連絡先、停止を決める人、顧客へ話す人が決まっていない体制は直りません。

システム障害対応で経営者は復旧順と説明を決めます

経営者は原因を当てる人ではなく、事業上の優先順位を決める人です。原因調査と修復は技術責任者へ任せ、経営者は顧客影響、売上や決済への影響、守るべきデータ、代替手段の有無を見ます。

最初に、技術対応を指揮する人、経営判断を引き取る人、社内外の文面を管理する人を決めます。小さな会社では一人が二役を持つ場合もありますが、復旧作業中のエンジニアへ問い合わせ対応まで集中させてはいけません。

役割名だけでは足りません。技術責任者には、関係のない公開作業を止め、問題のある機能を切り離し、保守会社へ緊急連絡するための権限が必要です。追加費用や一時停止の承認が必要なら、経営者がすぐ答えられる連絡経路も要ります。

状況は一つの障害記録へ集めます。発覚した時刻、確認できた症状、影響を受ける機能と顧客、直前の変更、実施した操作、次に判断する時刻を書きます。推測には「未確認」と付け、事実と分けます。

経営者から技術担当者への質問も、一人の窓口へ集めます。役員、営業、カスタマーサポートが別々に「いつ直りますか」と聞くと、同じ説明が何度も必要になります。次回の状況共有時刻を先に決めれば、新しい事実がない時間にも「更新がない」という情報を伝えられます。

システム障害対応の最初の30分で事実を一つにします

最初の30分で原因を確定する必要はありません。必要なのは、対応を始めた事実を全員が認識し、顧客影響を同じ数字で見て、次の判断時刻までに誰が何を確認するか決めることです。

0〜10分は責任者と記録場所を決めます

異常を見つけた人は、技術責任者と経営者へ連絡します。技術責任者は障害対応の開始を宣言し、時系列を残す文書か専用チャンネルを開きます。関係のない公開作業や設定変更は止め、調査中の状態をむやみに変えません。

サイバー攻撃の可能性を否定できない場合は、慌てて機器の電源を切る前に専門家へ確認します。2026年3月のIPA「中小企業のためのセキュリティインシデント対応の手引き」も、役割分担、ネットワークからの隔離、記録を消さない初動を示しています。

同資料は主にセキュリティ事故向けの手引きであり、一般的な障害の復旧時間や個別環境での操作を保証する資料ではありません。原因が分からない段階でログを失わないための確認に使います。

10〜20分は顧客影響を数字で見ます

サーバーが動いているかだけでは、経営判断に足りません。決済の失敗件数、受注の未処理件数、ログインできない利用者の範囲、処理待ちのデータ量、最後に成功した取引時刻を開きます。地域、契約プラン、端末などで影響が分かれる場合は、確認できた範囲も書きます。

売上損失を精密に計算する時間ではありません。顧客が商品を買えないのか、買えても二重請求の危険があるのか、社内だけが使えないのかを分けます。人数が少なくてもデータを壊す症状なら、表示だけの不具合より先に止める判断が必要です。

20〜30分は戻す順番を決めます

復旧順は、声の大きい部門ではなく、顧客と事業への影響で決めます。人の安全、取り返せないデータ、支払い済みの取引、法令や契約上の期限、代替手段の有無を確認します。全部を同時に戻すのではなく、顧客が重要な操作を最後まで完了できる一本の経路を選びます。

画面が表示された時点を復旧完了にしてはいけません。注文が保存され、決済結果が一致し、確認メールが届き、後続処理へ渡ったところまで確かめます。未処理データが残る場合は、再実行する担当者と重複を防ぐ確認方法も決めます。

顧客への第一報は原因確定を待ちません

第一報に詳しい原因説明は要りません。発覚時刻、利用できない機能、確認できた顧客影響、利用できる代替手段、次回の更新時刻を伝えます。影響範囲が分からなければ、分からない範囲と調査中の項目を分けて書きます。

「現在は復旧しています」と書く前に、顧客と同じ操作を最後まで試します。「情報漏えいはありません」といった否定も、ログと調査範囲を確認する前には書きません。原因候補や復旧予定を早く断定すると、後から説明を直す回数が増えます。

更新時刻になったら、新しい事実が少なくても発信します。前回から変わった点、現在行っている作業、残る影響、次回の更新時刻を同じ順番で書けば、営業とカスタマーサポートも同じ説明を使えます。問い合わせ窓口を一本化すると、技術担当者へ個別連絡が流れ込む状況も減らせます。

個人データの漏えい、消失、または発生する可能性がある場合は、通常の障害告知と法令上の報告を分けて確認します。個人情報保護委員会の「漏えい等の対応とお役立ち資料」では、報告対象となる事態について、速報は発覚から3〜5日以内、確報は原則30日以内、不正目的が疑われる場合は60日以内と案内しています。

全てのシステム停止へ一律に適用される期限ではなく、業種ごとの制度や顧客との契約で別の連絡が必要な場合もあります。該当性と通知内容は、事故の前から法務担当者や弁護士などの専門家へ確認してください。

システム障害対応の体制を平時に一枚へ落とします

障害時に分厚い手順書を最初から読む余裕はありません。止まると困る業務ごとに、一枚の対応表を作ります。業務名、停止を許容できる時間、最初に開く管理画面、顧客影響を示す数字、技術責任者と副担当、保守会社の緊急窓口、顧客向け文面の保管場所を同じ行へ置きます。

管理画面のURLだけでなく、会社のアカウントで副担当が入れるか確かめます。担当者が休んだ日に緊急窓口へ到達できない会社は、システム開発の社内体制を作る方法から手を付けてください。パスワードを表へ直接書かず、会社が管理する保管先を記載します。

外部の開発会社や保守会社には、通常の問い合わせ先とは別に、障害時の受付時間と連絡方法を確認します。誰がサービス停止を承認できるか、ログをどこまで取得できるか、事故を何時間以内に報告する取り決めか、担当者不在時に代替要員がいるかを契約書と運用資料で照合します。

サイバー攻撃の疑いがある場合は、一般障害と同じ再起動手順を急がず、中小企業が最初に行うセキュリティ対策も確認してください。コード、クラウド、監視、公開手順を一人だけが知っている場合は、システム内製化で情報と権限を引き取る方法と同じように、副担当が実際に管理画面を開きます。

平時の訓練では、復旧の操作だけでなく、経営判断と説明の流れも確かめます。対応表を読んだことと、緊急時に使えることは別です。自社の取引、顧客、委託先を含む想定で、連絡先、判断者、記録場所が機能するかを試します。

訓練では、実際に起きた過去の障害か、売上へ直結する機能の停止を一件選びます。技術責任者が不在という条件も加え、副担当が監視画面を開き、経営者が復旧順を決め、営業が第一報を書くところまで机上で進めます。大きな構成変更や担当交代の後にも同じ流れを試します。

復旧後の振り返りでは、誰が失敗したかではなく、発覚が遅れた場所、判断に足りなかった数字、届かなかった連絡先、復旧を妨げた承認待ちを時系列で見ます。改善作業には担当者と期限を付け、通常の開発予定へ入れます。障害を早く報告した人が不利になる評価では、次の発見が遅れます。

翌営業日に一つの管理画面を開きます

次の営業日に、決済、予約、出荷、会員ログインなど、止まると顧客が困る業務を一つ選んでください。経営者と技術担当者で監視画面を開き、通常の成功件数、最後に成功した処理、失敗時に増える数字を確認します。

次に、停止を何時間まで許容するか、誰が復旧順を決めるか、技術責任者が不在なら誰が代わるか、顧客へ何を使って知らせるかを一枚へ書きます。保守契約の緊急窓口にも実際にたどり着けるか確かめます。

四つの質問へ答えられない場合、担当者の説明力だけが問題ではありません。会社として障害対応の入口を用意できていない状態です。最初の一枚と一回の机上訓練から、復旧作業を邪魔せずに経営判断を進められる体制へ変えてください。