【IT業】【防災DX】IT企業の防災BCP|秋の災害前に整える顧客対応と復旧手順
こんにちは、ストラテジーデザインの吉田です。
今日の記事は、台風や豪雨が起こりやすい秋に向けて、中小IT企業が顧客のシステム保守と自社業務を止めないための防災BCPを整える実務を解説します。
9月後半は、台風、豪雨、停電、交通の乱れに備え直す時期です。
受託開発やシステム保守を担うIT企業では、自社の出社可否だけでなく、顧客システムへの影響と問い合わせ集中も考える必要があります。
ただし、従業員数が限られる会社が、大企業と同じ規模のBCPを作る必要はありません。
この記事では、案件と顧客を絞り込み、秋の需要期に入る前に防災対応を実務へ落とし込む手順を解説します。
この記事の要点
IT企業の防災BCPとは、災害や通信障害が起きても、自社の開発・保守業務と顧客への支援を優先順位に沿って継続・復旧するための事業継続計画のことです。
- 中小IT企業の防災BCPは、分厚い計画書ではなく、顧客連絡先・復旧順位・担当代行を一枚にまとめることから始められます。
- 災害時の保守対応は、全顧客を同じ順番で扱わず、社会的影響、契約条件、代替手段の有無で優先順位を事前に決めます。
- クラウドを利用していても、管理者権限、復旧用アカウント、顧客データの保存範囲を確認しなければ復旧準備は不十分です。
- 秋の防災準備は、自社を守る活動であると同時に、顧客へ継続支援を提案する保守契約と内製化支援の機会にもなります。
IT企業の防災BCPは顧客対応の順番から決める

防災BCPで最初に決めるべきことは、災害発生後に誰へ何をするかです。
サーバーや通信の話から始めると、少人数の会社では検討が広がりすぎます。
中小IT企業の防災BCPは、顧客対応の優先順位を決めることが出発点です。
受託開発、SaaS、保守では、停止による影響が顧客ごとに異なります。
緊急時に担当者の経験だけで判断すると、連絡漏れや対応の偏りが起こります。
まず、現在の顧客と運用中システムを一覧にします。
売上規模だけではなく、停止時の影響、連絡の必要性、代替方法を記録します。
たとえば医療、物流、予約、決済に関わるシステムは、一般的な社内ツールより早い状況確認が必要になる場合があります。
- 顧客名、主担当、副担当、緊急連絡先を一つの台帳にまとめる
- 提供中の機能を、停止影響が大きい順にA・B・Cへ仮分類する
- 契約上の受付時間、対応範囲、連絡手段を顧客ごとに確認する
- 自社が被災した場合に、代行連絡できる担当者を一人決める
分類は完璧でなくて構いません。
まずは売上上位の顧客と、24時間運用または生活・事業インフラに近い案件から始めます。
Aランクを10件以内に絞れば、代表者と保守責任者で現実的に確認できます。
顧客への初回連絡も、文章を事前に用意しておくと速くなります。
「自社の稼働状況」「確認中の範囲」「次回連絡の予定時刻」の3点だけを伝える形で十分です。
原因や復旧時刻を推測で断定しないことが、混乱時の信頼を守ります。
防災の日を過ぎたこの時期は、顧客に連絡先確認を依頼しやすい時期でもあります。
年末に向けた繁忙期の保守体制確認として案内すれば、営業色を強めず、実務上の接点をつくれます。
台風・停電に備えるシステム保守の復旧優先順位

台風や豪雨のとき、顧客からの問い合わせは同時に発生しやすくなります。
保守担当が少ない会社ほど、復旧作業と顧客連絡を同じ人が抱え込まない設計が必要です。
障害対応の優先順位は、技術的な難しさではなく、業務停止の影響で決めます。
復旧に時間がかかる案件から着手すると、影響の大きい顧客への一次対応が遅れることがあります。
緊急時には、完全復旧よりも先に被害範囲を切り分けることが重要です。
優先順位は、次の三段階に分けると運用しやすくなります。
案件ごとの細かな手順書を作る前に、共通の判断基準を決めてください。
- 第1優先:顧客の営業、決済、予約、現場運用が止まる機能を確認する
- 第2優先:データ連携や帳票など、当日中の業務に影響する機能を確認する
- 第3優先:表示不具合や改善要望など、代替運用が可能な内容を受け付ける
次に、技術対応と顧客対応を分けます。
技術者が調査に集中し、別の担当者が受付番号、影響範囲、次回連絡時刻を記録するだけでも、対応品質は安定します。
営業や総務が一次連絡を担う場合は、回答してよい範囲を先に決めます。
- 一次受付者は、障害の原因や復旧予定を推測して伝えない
- 技術担当者は、調査開始時刻と判明した事実だけを共有する
- 顧客連絡担当者は、次回連絡時刻を決めて履歴を残す
- 代表者は、複数顧客に影響する障害だけを優先判断する
秋の展示会や年末商戦の準備では、新規開発の納期が詰まりがちです。
しかし、緊急対応の担当者が開発案件に固定されていると、災害時の保守が空洞化します。
10月から12月の主要な納品予定を確認し、緊急連絡を受けられる人を案件ごとに二人置くことをおすすめします。
この整理は、防災だけのためではありません。
通常の障害対応、担当者の休職、急な退職にも使えます。
保守品質を見える化し、単価に見合う運用範囲を顧客と話し合う土台にもなります。
クラウド利用でも確認したいデータ保全と権限管理

クラウドサービスを使っているため、災害対策は不要だと考えるのは危険です。
クラウド事業者側の設備が守られていても、自社の管理者が連絡できない、認証情報に入れない、設定を戻せない問題は起こり得ます。
クラウド時代の防災対策は、データの保存先より復旧できる権限を確認することが重要です。
特に代表者や一人のエンジニアだけが管理者権限を持つ状態は、少人数のIT企業で起こりやすいリスクです。
確認は、サービスごとではなく、顧客案件ごとに行うと漏れが減ります。
たとえばソースコード、顧客データ、DNS、クラウド基盤、ドメイン、メール、監視ツールを一つの案件単位で並べます。
- 管理者権限を持つ人と、緊急時に代理で入れる人を確認する
- 二要素認証の端末や認証方法を、担当者一人に依存させない
- バックアップの保存場所、保存世代、復元担当者を確認する
- ドメインやクラウド契約の名義、更新通知先、支払方法を確認する
- 退職者や協力会社の不要なアカウントを停止または棚卸しする
すべての顧客データを自社で複製する必要はありません。
むしろ、契約や個人情報保護の観点から、保存範囲を広げすぎない方がよい場合があります。
何を誰が保管し、どの条件で復元するかを、契約内容と照らして整理してください。
バックアップは「存在すること」と「復元できること」が別です。
月に一度でも、テスト用環境または限定データで復元手順を試します。
手順に迷った箇所は、画面の説明ではなく、担当者、権限、確認順を簡潔に追記します。
AIを活用する場合は、障害連絡文の下書き、手順書の検索、問い合わせ内容の分類などに用途を絞るとよいでしょう。
一方で、顧客の機密情報や認証情報を、利用条件が不明な生成AIへ入力してはいけません。
利用するツールの設定と社内ルールを確認したうえで使います。
少人数でも回る在宅対応と顧客連絡の訓練方法

防災BCPは、文書を作っただけでは機能しません。
実際には、担当者が自宅にいる、電話がつながりにくい、社内チャットの通知に気づかないといった小さな問題が重なります。
中小IT企業の防災訓練は、30分の連絡テストから始めるのが現実的です。
大規模な避難訓練を企画しなくても、平日の朝や月例会議の前に、限定した想定で動作確認できます。
最初の訓練では、「平日午前に大雨警報が出て、全員が出社できない」という想定がおすすめです。
開発、保守、営業、管理の各担当が、どの連絡手段を使い、誰へ状況を報告するかを試します。
- 緊急連絡用のグループチャットに、全員が入れているか確認する
- 担当者不在を想定し、副担当が顧客情報へアクセスできるか試す
- 自宅から業務用システムへ安全に接続できるか確認する
- 顧客向け連絡文を作成し、承認者が不在でも送れる条件を決める
- 訓練後10分で、詰まった箇所を三つだけ記録する
連絡手段は一つに依存しない方が安全です。
社内チャットが利用できない場合に備え、電話、メール、携帯電話の連絡網など、第二手段を決めます。
ただし、複数の連絡網を日常的に更新する負担もあります。
まずは役員、保守責任者、主要顧客担当の範囲から整えるのが現実的です。
顧客への連絡では、個別メールだけに頼らず、障害情報を掲載するページや案内窓口を準備する方法もあります。
SaaS事業者は公開範囲を慎重に判断する必要がありますが、情報が錯綜しにくい窓口を一つ用意しておく価値はあります。
訓練結果は、反省会の資料に終わらせないでください。
「連絡先が古い」「VPN接続の案内がない」など、直せる問題を担当と期限に分けます。
こうした小さな改善を月次で続ける方が、年に一度だけ大きな計画を見直すより定着しやすくなります。
10月から進める防災BCPの実行計画と提案機会

9月後半に棚卸しを始めれば、10月以降は確認、訓練、顧客提案へ段階的に進められます。
年末の納品や保守繁忙が本格化する前に、最低限の運用を固めることが狙いです。
防災BCPは、秋に一度完成させる仕事ではなく、日常の保守設計へ組み込む仕事です。
担当変更、顧客追加、クラウド構成の変更があれば、連絡先と復旧手順も更新します。
実行計画は、次のように4週間単位で置くと進めやすくなります。
代表者が全作業を抱えず、営業、保守、開発、管理に小さく分担してください。
- 9月後半:主要顧客と運用中サービスを棚卸しし、優先順位を決める
- 10月前半:連絡先、管理者権限、バックアップ、契約上の対応範囲を確認する
- 10月後半:在宅対応と顧客連絡のミニ訓練を30分実施する
- 11月以降:訓練で見つけた課題を修正し、月次の保守会議で更新する
この取り組みは、顧客支援の提案にもつながります。
顧客側でも、担当者しか分からないシステム、連絡先が不明な外部サービス、紙に残った緊急手順が課題になりがちです。
自社の防災BCPを整えた経験をもとに、顧客の連絡網整理、権限棚卸し、業務継続手順の可視化を支援できます。
ただし、防災を理由に不要なツール導入を急がせる必要はありません。
顧客の現状を聞き、既存のクラウド、チャット、ファイル共有で改善できる範囲を先に示します。
必要に応じて、バックアップ環境や監視体制の見直しを段階的に提案します。
防災や事業継続に関する支援制度が公募されることもありますが、対象経費や申請条件は年度や制度ごとに異なります。
補助金の活用を検討する場合は、必ず最新の公募要領で確認してください。
秋の準備で得るべき成果は、立派な冊子ではありません。
誰が不在でも、主要顧客へ状況を伝え、重要なシステムの復旧に着手できる状態です。
この状態をつくることが、年末の繁忙期を安心して迎える土台になります。
よくある質問
Q. IT企業の防災BCPは何から作ればよいですか?
最初に作るべきものは、主要顧客の連絡先と対応優先順位の一覧です。
全社向けの詳細な計画書より先に、停止影響の大きい顧客、主担当と副担当、緊急連絡手段、契約上の対応範囲を一枚にまとめてください。
Q. クラウド利用ならバックアップは不要ですか?
クラウド利用でも、自社の復旧手順と権限確認は必要です。
事業者側の設備対策と、自社が誤操作やアカウント停止から復旧できるかは別の問題です。
保存範囲、復元方法、管理者権限、認証手段を案件ごとに確認します。
Q. 少人数のシステム保守会社でも訓練は必要ですか?
少人数のシステム保守会社ほど、短時間の訓練が必要です。
一人の担当者に連絡先や管理権限が集中すると、不在時に対応が止まります。
30分の連絡テストで、副担当のアクセス権と在宅接続を確認するだけでも効果があります。
Q. 災害時に顧客へ最初に伝えるべき内容は?
最初の連絡では、自社の稼働状況、確認中の範囲、次回連絡時刻を伝えます。
原因や復旧時刻を推測で断定しないことが重要です。
事実が分かるたびに連絡するより、次回の報告時刻を明示する方が顧客も状況を把握しやすくなります。
Q. 防災BCPを顧客への提案に生かす方法は?
自社で実施した連絡先・権限・復旧手順の棚卸しを、顧客向けの点検支援として提案できます。
まずは既存環境で改善できる連絡網整備や管理者権限の確認から始めます。
ツール販売を目的にせず、顧客の停止リスクを具体化することが大切です。
中小企業が明日から取り組めること
- 売上上位と停止影響が大きい顧客を合わせて10件以内に絞り、主担当・副担当・緊急連絡先を確認します。
- 顧客ごとに、止まると困る機能、代替運用の可否、契約上の対応時間を一行ずつ記録します。
- クラウド、ドメイン、メール、ソースコードの管理者権限を棚卸しし、代理担当者を一人決めます。
- 平日午前の大雨を想定し、全社員が在宅で連絡・業務接続できるか30分だけ試します。
- 障害時の初回連絡文を用意し、自社の稼働状況、確認範囲、次回連絡時刻だけを書けるようにします。
あわせて読みたい
- IT企業のOKRとは|単価・採用・AI活用をつなぐ目標管理 — 防災対応を日常目標へ組み込む参考です
- 学習塾・スクールの防災対策|秋に整える休講・連絡・オンライン授業 — 連絡設計と継続運営の考え方が共通します
- IT企業の展示会商談を年末受注につなぐ9月の実務 — 秋の商談活動と並行する計画に役立ちます
ストラテジーデザインにご相談ください
自社の場合はどこから手をつけるべきか、30分の無料相談で整理します。
- SD補助金|補助金活用支援 — 使える補助金の診断から申請サポートまで。自己負担を抑えて投資できます。
- SD CLOUD — 中小企業のための業務クラウド。スモールスタートで現場から変えられます。
この記事を書いた人
吉田 光広 / 代表取締役CEO ストラテジーデザイン株式会社
1997年からITの最前線に立ち、ゲーム開発を経てWeb・システム開発の会社経営を20年以上継続。 現在はAIコンサルタントとして上場企業への講師登壇や高校生向けAI教育を担当し、 ITプロ育成スクール「PROCLASS」代表も兼務。中小企業のAI・DX導入を現場で支援している。
著書:泥臭いAI ― リアルビジネスをAIでハックする/AIを雇う技術 ― 100人の天才を部下にする仕事術/AI×教育の実践ガイド ― 問いを立てる力を育てる