台風・停電に備える中小企業のBCPチェックリスト｜連絡手段・テレワーク判断・データアクセスの整理術

想定読者

台風シーズンを控え、停電や交通機関の運行停止が起きても業務を止めない体制を整えたいと考えている中小企業の経営者、総務担当者、情報システム担当者を想定読者とします。

要点

• 台風・停電などの自然災害への備えは、サイバー攻撃対策とは目的も手順も異なるため、分けて整理することが重要です
• 連絡手段・重要書類やデータへのアクセス・テレワーク切り替えの判断基準を、具体的な手順とチェックリストで示します
• 一度作った備えは定期的な見直しと簡易訓練によって、実際に機能する体制として定着させる必要があります

なぜ台風・停電への備えが中小企業に必要か

台風や大雨による停電、交通機関の運行停止は、毎年どこかの地域で必ず起こる自然現象です。こうした事態が起きても重要な業務を止めず、あるいは早期に再開できるようあらかじめ備えておく計画をBCP（事業継続計画）と呼びます。

大企業では専任部署がBCPを策定することも多い一方、中小企業では人手や予算の制約から後回しにされがちです。

しかし従業員数が少ない組織ほど、連絡が一人途絶えるだけで全体の判断が止まってしまうリスクが高く、むしろ簡潔で実行可能な備えを優先して整えておく価値があります。

自然災害への備えとサイバー攻撃対策は分けて考える

BCPというと、ランサムウェアや不正アクセスといったサイバー攻撃への対策を思い浮かべる方も多いかもしれません。

しかし台風や停電への備えは、攻撃者への対抗策ではなく、電力・通信・交通というインフラが一時的に使えなくなる状況にどう対応するかという、まったく別の課題です。対策すべき相手が「悪意のある第三者」ではなく「自然現象によるインフラの停止」である点を意識すると、何を優先して準備すべきかが整理しやすくなります。本記事ではサイバー攻撃対策には触れず、停電・交通機能停止・通信障害といった自然災害由来の業務停止リスクに絞って解説します。

BCPが整っていない場合に起きる具体的な困りごと

備えがないまま台風や停電に見舞われると、現場では次のような混乱が起こりがちです。

• 誰が出社可能で誰が出社できないか把握できず、業務の割り振りが決められない
• 社内サーバーに保管された見積書や契約書に、停電中や担当者の不在時にアクセスできない
• 取引先や顧客への連絡が遅れ、信用を損なう
• テレワークに切り替える判断が遅れ、無理な出社を強いてしまう、あるいは判断が属人化して現場が混乱する

これらの多くは、特別な設備投資をしなくても、事前の整理と合意形成だけで大きく軽減できます。

本記事で扱う範囲（自然災害・運用面に限定）

本記事では、台風・大雨による停電、交通機関の運行停止、通信障害といった自然災害由来の事象を想定し、連絡手段の確保、重要書類・データへのアクセス確保、テレワーク切り替えの判断基準という運用面の備えに絞って解説します。

サーバーの耐震対策や非常用電源の導入といった設備投資、サイバー攻撃への防御については対象外とします。

事前準備チェックリスト①連絡手段の確保

停電・通信障害を想定した複数手段の用意

携帯電話の基地局が停波したり、固定電話が使えなくなったりすることは、大規模な停電時には珍しくありません。

特定の一つの手段に頼ると、その手段が使えなくなった瞬間に組織内の連絡が完全に途絶えてしまいます。複数の連絡手段をあらかじめ用意し、優先順位を決めておくことが重要です。

固定電話はアナログ回線であれば停電中も通話できる機種がありますが、ビル内線や集合住宅の設備によっては使えないこともあります。

社用携帯電話についてはモバイルバッテリーを常備しておく、チャットツールと安否確認サービスは同じ通信回線に依存しない組み合わせにしておく、といった工夫で、どれか一つに障害が起きても連絡を取り合える状態を保てます。

安否確認と指示系統（誰が誰に連絡するか）の整理

連絡手段を複数用意しても、「誰が誰に連絡するか」が決まっていなければ混乱します。特に中小企業では、代表者や特定の管理職に連絡が集中し、本人が被災して連絡が取れないと指示系統全体が止まってしまうケースが見られます。

あらかじめ一次連絡先と代理の連絡先を決めておき、表にして全従業員に共有しておくと安心です。

この表は年に一度、人事異動のタイミングで見直すことをおすすめします。

取引先・顧客への事前周知テンプレート

台風接近時は、取引先や顧客にも「対応が遅れる可能性がある」ことを事前に伝えておくと、問い合わせの集中や不信感を防げます。

メールやウェブサイトのお知らせ欄で、次のような内容を簡潔に伝えるテンプレートを用意しておくと、当日慌てずに発信できます。

• 台風接近に伴い、営業時間や対応に遅延が生じる可能性がある旨
• 緊急連絡先として代替の電話番号やメールアドレス
• 復旧見込みが立った時点で改めて案内する旨

テンプレートは文面を固定しすぎず、日付や固有の状況を書き換えるだけで使える形にしておくと、実際の発信がスムーズです。

事前準備チェックリスト②重要書類・データへのアクセス確保

クラウド化状況の確認とオフライン時の代替手段

見積書、契約書、顧客情報などの重要書類がクラウドサービス上に保管されていれば、社内サーバーが停電で止まっていても、インターネット経由で別の場所からアクセスできます。

まずは自社の重要書類がどこまでクラウド化されているかを棚卸しし、社内サーバーにしか存在しないデータがあれば、バックアップの方法を検討しておきましょう。

あわせて、インターネット回線自体が使えなくなった場合に備え、最低限必要な書類だけは紙やUSBメモリなど物理媒体でも持ち出せるようにしておくと安心です。

紙の重要書類の保管・持ち出しルール

契約書の原本や印鑑など、電子化が難しい重要書類については、保管場所と持ち出しルールをあらかじめ決めておきます。

浸水や停電で建物に立ち入れなくなる事態も想定し、最低限どの書類を優先して持ち出すかを決めておくと、いざという時の判断が早くなります。

アクセス権限の整理（誰が社外から何に触れるか）

テレワークに切り替える際、誰が社外から何のデータにアクセスできるかが整理されていないと、必要な担当者が業務に必要なシステムに入れず、作業が滞ってしまいます。

逆に、普段は社外からのアクセスを想定していない重要なシステムまで無計画に開放してしまうと、意図しないアクセスのリスクも高まります。平常時から、役割ごとに社外アクセスが必要なシステムとその範囲を整理しておきましょう。

この整理は、平常時のテレワーク運用ルールと重なる部分が多いため、既にテレワーク規程がある場合はそちらと整合性を取っておくとよいでしょう。

テレワーク切り替えの判断基準と当日の対応フロー

切り替えを判断するトリガーの決め方（警報・交通情報の基準）

テレワークへの切り替えが遅れる最大の原因は、「誰が、何を基準に判断するか」が決まっていないことです。

台風が接近してから慌てて判断するのではなく、気象庁が発表する警報や公共交通機関の運行情報など、客観的に確認できる基準をあらかじめ決めておくことで、判断のスピードと一貫性が高まります。

具体的には、次のような基準を自社の実情に合わせて決めておくと、当日の判断がぶれません。

• 暴風警報が発表された時点で、翌日のテレワーク切り替えを前日のうちに判断する
• 主要な通勤経路の鉄道が計画運休を発表した時点で、即日テレワークに切り替える
• 大雨特別警報が発表された地域の従業員は、出社の可否を本人の判断に委ねる

基準は「〇〇警報が出たら」のように誰が見ても同じ判断に至る形で言語化しておくことが重要です。

誰がいつ判断・指示するかの明確化

基準を決めても、実際に判断し指示を出す人が不在では機能しません。台風は接近のタイミングがある程度予測できるため、前日のうちに判断者・判断のタイミング・連絡手段を決めておきます。

判断者が出張や休暇で不在の場合に備え、代理の判断者もあわせて決めておきましょう。

台風接近前〜停電発生時〜復旧後の初動チェックリスト

実際に台風が接近し、停電や交通機能の停止が発生した場合の初動対応をフェーズごとに整理しておくと、当日の混乱を抑えられます。

それぞれのフェーズで「誰が確認するか」を事前の連絡体制表（本記事内の指示系統の表）と紐づけておくと、当日は表を見るだけで次の行動がわかる状態になります。

チェックリストの定期更新と簡易訓練

ここまで紹介したチェックリストや連絡体制表は、一度作成して終わりにすると、人事異動や組織変更によってすぐに実態と合わなくなってしまいます。

年に1〜2回、台風シーズンが始まる前後のタイミングで、連絡先・判断者・アクセス権限の一覧を見直す機会を設けることをおすすめします。

あわせて、実際に機能するかどうかを確認するために、簡易的な訓練を行うことも有効です。大掛かりな訓練でなくても、次のような簡単な取り組みから始められます。

• 安否確認サービスやチャットツールで、実際に全従業員へテスト送信してみる
• テレワーク切り替えの判断者が、実際に基準に沿って模擬的な判断を下してみる
• 重要書類のクラウド上の保管場所に、関係者全員が実際にアクセスできるか確認する

訓練を通じて見つかった不備は、その都度チェックリストに反映していくことで、実際の台風シーズンに機能する体制へと少しずつ育てていくことができます。

備えは一度整えて終わりではなく、見直しと訓練を繰り返すことで初めて、いざという時に機能する運用になります。