システムが突然停止すると、多くの現場では「復旧するまで待つしかない」と考えがちです。しかし、受注や顧客対応を止めてしまうと、信頼の喪失や売上の減少に直結します。まず取り組むべきは、システムが使えない時間帯に「どの業務を、どの手段で、どう記録するか」という代替手順を決めることです。復旧した瞬間に元の状態に戻れるとは限らないため、止まっている間の「手書き」や「別のツール」による記録方法を整理しておくことが、事業を守る第一歩となります。
システム停止時に業務を止めないための準備とは?
どの業務を優先して継続させるべきか
システムが止まった際、すべての業務を同時に継続させるのは困難です。まずは、会社にとって「今、これを止めると致命的な損害が出るもの」を特定しましょう。例えば、注文の受付や緊急の問い合わせ対応は優先度が高くなりますが、月次の集計作業や社内向けの報告書作成は、システム復旧後でも構いません。あらかじめ「停止した際、どの業務を紙や電話で継続するか」という優先順位を組織として定めておきます。単に業務名を挙げるだけでなく、「期限がいつまでのものか」「どの顧客への対応か」といった判断基準を明確にしておくことで、現場の混乱を防げます。
止まっている間の依頼をどう記録するか
システムが使えない間、電話やFAX、あるいは個人のメールなどで受けた依頼を、どのように記録するかが鍵となります。ここで重要なのは、復旧後に「システムへ入力し直す」作業が発生することを前提にすることです。例えば、メモ帳に書き留める場合でも、後でシステム上のデータと照合できるように、「受付日時」「顧客名」「注文内容」「担当者名」といった項目を統一したフォーマットで残すルールを作ります。記録の管理体制(誰が記録し、誰が内容を確認するか)を定めておかないと、復旧後のデータ入力漏れや、二重入力といったミスを招く原因になります。
代替手段で扱う情報の安全性をどう守るか
システム停止を機に、普段は使っていない個人のクラウドストレージや、暗号化されていない共有フォルダに機密情報を移して作業を進めるのは避けてください。これは、システム停止というトラブルに、情報の流出という別のトラブルを重ねてしまうことになりかねません。代替手段として使うツールや紙の管理方法についても、「いつまで使うのか」「復旧後にそのデータはどう破棄・整理するのか」という終了条件をあらかじめ定めておきます。代替手段を利用する際のルールとして、情報の利用範囲や保存先を明確に定め、組織の運用規定として周知しておく必要があります。
復旧をスムーズに進めるための優先順位の決め方
システム同士のつながり(依存関係)を把握する
システムを復旧させる際、どの順番で直していくべきかは、システム同士の「つながり」で決まります。例えば、販売管理システムを直そうとしても、その基盤となる顧客データベースが動いていなければ、販売管理システムは正しく機能しません。このように、あるシステムが動くために別のシステムが必要な状態を「依存関係」と呼びます。「このシステムを動かすには、どのシステムが先に稼働している必要があるか」という依存関係を整理し、復旧のロードマップを作成します。このつながりを無視して個別に復旧を進めると、作業のやり直しが発生し、復旧がさらに遅れる原因となります。
関連する部署や取引先への連絡タイミングを決める
システムの復旧には時間がかかる場合があり、復旧の目処が立たないまま業務を続けるのは限界があります。そのため、「いつ、誰に対して、どのような状況を伝えるか」という連絡のルールも決めておきましょう。自社の従業員だけでなく、システムを利用している取引先や、配送を依頼している物流業者など、業務のつながりがある外部組織への連絡も重要です。例えば、「停止から2時間経過しても復旧の目処が立たない場合は、取引先に電話で状況を伝える」といった具体的な基準を作っておきます。これにより、現場の判断迷いを減らし、外部とのトラブルを最小限に抑えることができます。
段階的な再開プロセスを設計する
システムが復旧したからといって、すぐに全業務を元通りに再開するのはリスクがあります。まずは「読み取り専用(データの確認だけができる状態)」で動作を確認し、次に「一部の限定的な機能」から動かし、最後に「すべての機能」を解放するという、段階的なステップを踏むのが安全です。例えば、まずは受注データの確認ができる状態にし、次に新規受注の入力、最後に在庫の更新といった流れです。この手順をあらかじめ決めておくことで、復旧直後のシステム負荷による再停止や、データの不整合による混乱を防ぐことができます。各段階でどのような動作確認を行うべきか、確認項目をあらかじめリスト化しておきましょう。
復旧後に発生する「データのズレ」を防ぐ手順
システムと手書き記録の照合作業を行う
システムが復旧した際、最も注意すべきは「停止中に手作業で行った業務」と「システム内のデータ」が一致しているかを確認することです。停止中に紙や別のツールで受け付けた注文をシステムへ入力し直した際、入力漏れや打ち間違いが必ずと言っていいほど発生します。これを防ぐために、復旧直後には「暫定的な受付リスト」と「システム上のデータ」を突き合わせる照合作業を工程に組み込みます。例えば、受付番号を付与して管理していれば、「番号が飛んでいないか」「内容が一致しているか」を効率的にチェックできます。この照合作業を誰がいつ行うかを、復旧計画の一部として明記してください。
二重処理と未処理を切り分ける管理術
復旧作業が慌ただしく進むと、すでにシステムに入力済みのデータを、手書きのメモを見て再度入力してしまう「二重処理」が起こりやすくなります。また、逆に「入力したつもりで漏れていた」という「未処理」も深刻な問題です。これらを防ぐには、作業中のデータに「暫定入力済み」といった印を付ける、あるいは入力済みの紙メモには大きくチェックを入れるといった、物理的な区別が有効です。「入力が終わったメモは、すぐに別の箱に移す」といった、視覚的に作業状況が判別できる運用ルールを定めることが、ミスを減らすための現実的な対策となります。
暫定資料の整理と最終的な整合性の確認
すべての入力と照合が終わったら、最後に「暫定的に使っていた資料」をどう処理するかを決めます。紙のメモや、一時的に作成したExcelファイルなどが残っていると、後日「どちらが正しいデータか」という混乱を招く原因になります。照合が完了し、システム上のデータが正しいことが確認できたら、暫定資料は「システムデータとの照合済み」と区別して管理し、会社の保存ルールや調査・契約上の必要性を確認してから保管または廃棄します。この最終確認のプロセスを完了して初めて、システム停止に伴う業務を再開・継続できるかの判断材料が整います。業務の再開にあたっては、使用した暫定資料の処理結果まで含めて、完了報告を行うフローを確立しておきましょう。
業務継続計画を形にするための判断基準
自社の規模とリソースに合わせた範囲設定
BCP(事業継続計画)を策定する際、大企業のような完璧な計画を目指す必要はありません。中小企業においては、限られた人員と予算の中で「何を守り、何を諦めるか」を明確にすることが重要です。例えば、すべてのシステムを即時に復旧させることは難しくても、「受注だけは止まらない」という一点に絞って対策を固める方が、実効性は高まります。計画を立てる際は、「もし明日システムが止まったら、どの作業が一番困るか?」「その時、自社のリソースだけで何ができるか?」といった現場の実態をヒアリングし、無理のない範囲から計画を組み上げてください。
専門家へ相談すべきタイミングと確認事項
システム停止への備えは、ITの専門知識が必要な場面が多くあります。自社だけで判断が難しいと感じたら、早めに情報システム部門や外部のITコンサルタント、保守ベンダーへ相談しましょう。相談する際は、「現在の業務フロー(誰が、いつ、どのシステムを使って、何をしているか)」をまとめた資料を用意しておくと、スムーズに話が進みます。また、「復旧の優先順位はこれで正しいか」「データのバックアップから復旧する際、どの程度の作業時間がかかる見込みか」といった、具体的な作業時間や依存関係について専門家の意見を仰ぐことが、計画の精度を高めるポイントです。
計画の有効性を確かめる机上訓練の実施
計画を作っただけで満足せず、定期的に「もしもの場面」を想定した訓練を行いましょう。本格的なシステム停止をシミュレーションするのは難しいため、まずは会議室に集まり、「システムが止まったと仮定して、今の手順書通りに動けるか?」を話し合う「机上訓練」から始めます。例えば、「受注システムが止まり、電話での受付が集中した場合、今のメモの書き方で後から入力できるか?」といった具体的なシナリオを提示します。訓練を通じて、「この手順では時間が足りない」「この記録方法では後で困る」といった課題が見つかれば、それを計画に反映させて改善していくことが、真に役立つ備えへとつながります。
現在の自社の業務フローにおいて、システムが止まった際に「これだけは止められない」という業務はどれでしょうか。また、その業務を止めた場合に、どのような代替手段が考えられるでしょうか。まずは、主要な業務を書き出し、その記録方法と復旧後の手順を整理することから始めてみてください。もし、具体的な手順の作り方や、優先順位の付け方に迷う場合は、専門家への相談を検討しましょう。
参照情報・確認日
以下の公式情報を背景に、本文の手順・判断例はAX labsの提案として整理しています。料金や効果の保証は扱っていません。
- IPA:中小企業のためのセキュリティインシデント対応の手引き ↗
確認日:2026-10-15