災害時の従業員安否確認と事業継続判断を連動させ初動対応の遅れを防ぐ方法

災害が発生したとき、多くの企業では安否確認の集計、業務システムの稼働確認、復旧手順の判断がそれぞれバラバラに進みます。総務部門が安否確認の回答を待っている間に、情シス部門はサーバーの状態を個別に確認し、経営層はどの業務から復旧すべきか判断材料がそろわないまま時間だけが過ぎていきます。この初動の遅れが事業停止期間を長引かせ、顧客離反や売上損失に直結する深刻な問題です。

この記事は、従業員50〜500名規模の企業で、総務・人事部門やBCP担当を兼務している管理部門の方を想定しています。読み終えると、安否確認の回答状況とシステム稼働状況を1か所に集約し、復旧優先順位の判断を迅速に行うための実務ワークフローを自社に導入できるようになります。なお、数千名規模のグローバル企業向けの全社BCP体制構築や、各ツールの網羅的な機能比較は扱いません。

本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、災害発生から60分以内に安否集計・システム稼働状況・復旧優先順位を1つのチャットチャンネルに集約し、経営判断を下せる体制の設計図が手に入ります。

Workflow at a glance: 災害時の従業員安否確認と事業継続判断を連動させ初動対応の遅れを防ぐ方法

• Step 1: 安否確認を自動送信し回答状況をチャットに集約する (安否確認サービス2) (安否確認システム)
• Step 2: 業務システムの稼働状況をチャットに自動通知する (Mackerel) (インフラ・セキュリティ関連)
• Step 3: 復旧優先順位に沿ってタスクを起動し進捗を共有する (Questetra BPM Suite) (ワークフローシステム)

なぜ安否確認と事業継続判断がバラバラになるのか

情報の発生源が3つに分かれている

災害時に必要な情報は大きく3種類あります。1つ目は従業員の安否情報、2つ目は業務システムの稼働状況、3つ目はBCP上の復旧優先順位です。これらはそれぞれ安否確認システム、サーバー監視ツール、紙やPDFの復旧手順書という別々の場所に存在しています。平常時にはそれぞれ独立していても問題ありませんが、災害時にはこの3つを突き合わせて初めて正しい判断ができます。

突き合わせ作業が人力に依存している

安否確認の集計結果を見て出社可能な人数を把握し、サーバー監視画面を開いて止まっているシステムを確認し、手順書を引っ張り出して復旧順序を確認する。この突き合わせ作業を災害直後の混乱の中で人力で行うのは現実的ではありません。担当者自身が被災している可能性もあります。結果として、情報がそろうまでに数時間かかり、その間に事業停止が長引きます。

判断者に情報が届かない

仮に各担当者が情報を集められたとしても、それを経営層やBCP責任者に伝える手段が電話やメールでは、情報の鮮度が落ちます。電話はつながりにくく、メールは埋もれます。判断者が必要な情報をリアルタイムで見られる仕組みがなければ、初動判断は遅れ続けます。

重要な考え方：3つの情報を1つの場所に自動で集め、判断者がすぐ見られる状態をつくる

災害対応で最も重要なのは、情報を集める時間を限りなくゼロに近づけることです。安否確認の回答率、システムの稼働・停止状況、復旧優先順位の3つが1つの画面に自動的に集まっていれば、判断者は画面を開くだけで意思決定に入れます。

自動集約のために必要な設計原則

この仕組みを実現するには、3つの原則を守る必要があります。

1つ目は、各ツールからの通知をビジネスチャットの専用チャンネルに集約することです。安否確認システムの集計結果もサーバー監視の障害アラートも、同じチャンネルに流れるようにします。

2つ目は、通知の形式を統一することです。安否確認なら回答率と未回答者数、サーバー監視なら停止中のシステム名と影響範囲を、決まったフォーマットで投稿します。フォーマットが統一されていれば、判断者は一目で状況を把握できます。

3つ目は、復旧優先順位をあらかじめデジタル化しておくことです。紙やPDFの手順書では災害時に参照できません。ワークフローシステム上にチェックリストとして登録しておけば、状況に応じて即座に起動できます。

平常時の準備が9割

この仕組みは災害が起きてから構築するものではありません。平常時に通知連携の設定、チャンネルの作成、復旧チェックリストの登録を済ませておくことが前提です。年に1〜2回の訓練で動作確認を行い、担当者の異動があれば設定を更新する運用サイクルを回すことが成功の鍵です。

災害発生から60分で事業継続判断を下すワークフロー

ステップ 1：安否確認を自動送信し回答状況をチャットに集約する（安否確認サービス2）

災害発生時、安否確認サービス2が地震情報などと連動して従業員へ安否確認メッセージを自動送信します。従業員はスマートフォンからワンタップで回答します。回答状況は安否確認サービス2の管理画面にリアルタイムで集計されますが、これだけでは判断者が別画面を開く必要があります。

そこで、安否確認サービス2のWebhook機能を使い、回答率が一定の閾値（たとえば50%、80%、100%）に達したタイミングでMicrosoft Teamsの災害対策専用チャンネルに自動投稿する設定を行います。投稿内容は、回答率、未回答者数、出社可能人数の3項目に絞ります。これにより、判断者はMicrosoft Teamsを開くだけで安否状況の概要を把握できます。

担当者は総務部門のBCP担当者です。平常時にWebhookの設定と投稿フォーマットのテンプレートを作成しておきます。未回答者へのリマインド送信は安否確認サービス2の自動リマインド機能に任せ、BCP担当者は集計結果の確認に集中します。

ステップ 2：業務システムの稼働状況をチャットに自動通知する（Mackerel）

災害発生と同時に、サーバー監視ツールであるMackerelが各業務システムの稼働状況を自動的に検知します。Mackerelにはあらかじめ、基幹システム、受注管理、メールサーバーなど事業継続に不可欠なシステムを監視対象として登録しておきます。

システムの異常や停止を検知すると、MackerelからMicrosoft Teamsの同じ災害対策チャンネルにアラートが自動投稿されます。MackerelはMicrosoft Teams向けの通知チャンネル設定を標準機能として備えているため、Webhook URLを登録するだけで連携が完了します。

投稿フォーマットは、停止中のシステム名、検知時刻、影響を受ける業務の3項目を含むように設定します。これにより、判断者はステップ1の安否情報と並べて、どのシステムが止まっていて、それを復旧できる人員がいるかどうかを同時に確認できます。

担当者は情シス部門です。平常時にMackerelの監視対象とアラート条件を設定し、四半期に1回はテストアラートを送信して通知が正しく届くことを確認します。

ステップ 3：復旧優先順位に沿ってタスクを起動し進捗を共有する（Questetra BPM Suite）

ステップ1とステップ2の情報がMicrosoft Teamsのチャンネルに集まった時点で、BCP責任者は事業継続判断を行います。どの業務から復旧するかの優先順位は、あらかじめQuestetra BPM Suiteにワークフローとして登録しておきます。

Questetra BPM Suiteには、BCP上の復旧対象業務ごとにプロセスを定義しておきます。たとえば、優先度1は受注管理システムの復旧、優先度2はメールサーバーの復旧、優先度3は社内ポータルの復旧、といった具合です。各プロセスには、担当者、作業手順、完了条件、代替担当者をあらかじめ設定しておきます。

BCP責任者がMicrosoft Teamsの情報をもとに復旧開始を判断したら、Questetra BPM Suite上で該当するプロセスを起動します。担当者にはQuestetra BPM Suiteから自動的にタスクが割り当てられ、進捗状況はQuestetra BPM Suiteの画面で一覧できます。主要な進捗の節目（着手、完了など）はMicrosoft Teamsのチャンネルにも通知されるよう設定しておくことで、経営層を含む関係者全員が復旧の進み具合をリアルタイムで把握できます。

担当者はBCP責任者と各復旧作業の実行担当者です。平常時にQuestetra BPM Suite上のプロセス定義を完了させ、年1回の防災訓練で実際にプロセスを起動して手順の抜け漏れを確認します。

この組み合わせが機能する理由

安否確認サービス2：災害連動の自動送信で初動ゼロ秒を実現

安否確認サービス2は気象庁の地震情報と連動し、設定した震度以上の地震が発生すると自動的に安否確認メッセージを送信します。管理者が手動で送信ボタンを押す必要がないため、管理者自身が被災していても安否確認が開始されます。回答方法もスマートフォンからのワンタップで完了するため、従業員側の負担も最小限です。

一方で、安否確認サービス2単体では出社可能人数とシステム稼働状況を突き合わせることはできません。あくまで人の安否に特化したツールであり、事業継続判断に必要な情報の1ピースを担う位置づけです。Webhook連携の設定には情シス部門の協力が必要になる場合がありますが、設定自体は1時間程度で完了します。

Mackerel：国産サーバー監視で日本語運用と柔軟な通知設定

Mackerelは株式会社はてなが提供する国産のサーバー監視サービスです。管理画面やドキュメントが日本語で提供されており、情シス部門の運用負荷が低い点が強みです。監視対象の追加やアラート条件の変更もブラウザ上で完結します。

Microsoft Teamsへの通知連携は標準機能として用意されているため、外部の連携ツールを追加する必要がありません。監視対象のサーバーにエージェントをインストールする必要がありますが、主要なOSに対応しており、導入の技術的ハードルは低めです。

注意点として、Mackerelはインフラの死活監視やメトリクス監視が中心であり、アプリケーション層の細かなエラー監視には別途設定が必要です。BCP用途では、サーバーが応答しているかどうかの死活監視を中心に設定すれば十分です。

Microsoft Teams：情報集約のハブとして全員がアクセスできる

Microsoft Teamsを情報集約のハブに選ぶ理由は、多くの日本企業ですでに導入済みであり、新たにツールを追加する必要がない点です。災害対策専用のチャンネルを1つ作成し、安否確認とサーバー監視の通知をそこに集めるだけで、判断者は1つの画面で状況を把握できます。

スマートフォンアプリからもアクセスできるため、出社できない状況でも経営層が判断に参加できます。ただし、Microsoft Teamsは通知が多い環境では重要な情報が埋もれるリスクがあります。災害対策チャンネルは平常時の投稿を禁止し、災害時の自動通知と判断者の投稿のみに限定するルールを設けることが重要です。

Questetra BPM Suite：復旧手順をデジタル化し属人化を排除

Questetra BPM Suiteは国産のクラウド型ワークフローシステムです。BCP上の復旧手順をプロセスとして定義しておくことで、紙の手順書に頼らない復旧対応が可能になります。担当者が被災して対応できない場合も、代替担当者への自動エスカレーションが設定できます。

クラウドサービスであるため、自社のサーバーが停止していてもQuestetra BPM Suite自体は利用可能です。これはBCPツールとして重要な特性です。ノーコードでプロセスを定義できるため、情シス部門でなくても総務部門のBCP担当者がプロセスの作成・修正を行えます。

トレードオフとして、プロセス定義の初期設計には一定の工数がかかります。復旧対象業務が10件程度であれば、1〜2週間で初期設定が完了する見込みです。また、年1回の訓練でプロセスの内容を見直し、組織変更や担当者異動を反映する運用が欠かせません。

Recommended tool list

結論：情報集約の仕組みを平常時に構築し、災害時は判断だけに集中する

災害時の初動対応が遅れる根本原因は、安否情報・システム稼働状況・復旧手順が別々の場所にあり、それを突き合わせる作業に時間がかかることです。安否確認サービス2、Mackerel、Questetra BPM Suite、Microsoft Teamsを組み合わせ、災害発生時に必要な情報がMicrosoft Teamsの1つのチャンネルに自動的に集まる仕組みを構築すれば、判断者は情報収集ではなく意思決定に集中できます。

最初の一歩として、Microsoft Teamsに災害対策専用チャンネルを作成し、安否確認サービス2のWebhook通知をそのチャンネルに接続するところから始めてください。この設定は1時間で完了します。動作確認ができたら、Mackerelの通知連携、Questetra BPM Suiteの復旧プロセス定義へと順に進めていくことで、無理なく体制を整えられます。

Mentioned apps: 安否確認サービス2, Mackerel, Microsoft Teams, Questetra BPM Suite

Related categories: Web会議システム, インフラ・セキュリティ関連, ワークフローシステム, 安否確認システム

Related stack guides: 輸出管理教育の受講完了と実務権限を自動連動させ未受講者による誤申請を防ぐ方法, 該非判定の根拠資料が散逸して再現できない問題を解消し監査対応を万全にする方法, 補助金の変更申請と実績報告の整合性を保ち事後監査での指摘と返還リスクを防ぐ方法, パートナーへの変更依頼が社内承認後に正しく伝わらない問題を解消し手戻りとプロジェクト遅延を防ぐ方法, 付議基準の属人判断による上程漏れをなくし取締役会のガバナンスと議論の質を守る方法