地震や台風、サーバーの故障、ランサムウェアの感染。
業務システムが止まる原因は、ある日突然やってきます。
受注も請求も勤怠もシステムで回している会社ほど、止まったときの影響は大きくなります。
この記事では、中小企業が「システムが止まっても業務を続ける」ための計画、つまりシステムのBCPの作り方を解説します。
何を決めればよいか、どこまで備えればよいか、どれくらいの費用がかかるのかを、開発会社の立場から整理しました。
なお、障害が起きた直後の初動対応の手順は、別の記事「システム障害時のトラブル初動対応手順」で詳しく解説しています。
この記事では、その前段となる「平時に決めておく計画」に絞ってお伝えします。
システムのBCPとは？中小企業に必要な理由
システムのBCPとは、業務システムが使えなくなったときに、どの業務を・どの順番で・いつまでに再開するかを決めておく計画です。
BCPは「Business Continuity Plan（事業継続計画）」の略です。
会社全体のBCPのうち、IT部分だけを取り出したものは「IT-BCP」とも呼ばれます。
システムのBCPの目的は「止めないこと」ではなく「止まっても決めた時間内に戻すこと」です。
どれだけ備えても、システムが止まる確率はゼロになりません。
止まる前提で、戻し方を先に決めておくのがBCPの考え方です。
会社全体のBCPとシステムのBCPの違い
会社全体のBCPは、人・建物・設備・取引先まで含めた計画です。
システムのBCPは、その中の「データとシステム」に関する部分を具体化したものです。
両者の違いを表にまとめます。
- 対象
会社全体のBCPは人員・拠点・設備・仕入先まで扱います。システムのBCPは業務システム・データ・ネットワーク・端末が対象です。 - 主な想定
会社全体は地震・水害・感染症が中心です。システムのBCPでは、サーバー故障・サイバー攻撃・担当者不在も同じ重さで扱います。 - 決めること
会社全体は連絡体制や代替拠点を決めます。システムのBCPは、復旧の目標時間・バックアップ・復旧手順を決めます。
会社全体のBCPがすでにある会社でも、システム部分が「サーバーはベンダーに任せている」の一行で終わっていることがよくあります。
その一行の中身を具体化するのが、この記事のテーマです。
中小企業ほど備えが必要な3つの理由
- 担当者が1人しかいない
システムを分かる人が1人だけだと、その人が不在のときに誰も復旧できません。 - 代わりの手段が残っていない
紙やExcelの運用をやめた会社ほど、システムが止まると手作業に戻す方法が分からなくなります。 - 止まった時間がそのまま売上に響く
受注や予約をシステムで受けている場合、停止中の注文はそのまま失われます。
大企業のように専任の部署を置けない分、中小企業は「決めておくこと」で差がつきます。
高価な設備よりも、誰が見ても分かる計画書のほうが役に立つ場面は多いです。
業務システムが止まる5つの原因
システムのBCPを作るときは、まず「何が起きたら止まるのか」を洗い出します。
災害だけを想定していると、実際によく起きる原因を見落とします。
| 原因 | 具体例 | 起きやすさの目安 |
|---|---|---|
| 自然災害 | 地震・台風・水害で事務所やサーバー室が使えない | 頻度は低いが、影響範囲が広い |
| 機器の故障 | 社内サーバーのディスク故障、ネットワーク機器の停止 | 古い機器ほど起きやすい |
| サイバー攻撃 | ランサムウェアでデータが暗号化される、不正アクセス | 規模を問わず被害が報告されている |
| 外部サービスの停止 | クラウド・決済・外部APIなど連携先の障害 | 自社では防げず、発生時期も選べない |
| 人の要因 | 担当者の退職・長期不在、誤操作によるデータ削除 | 中小企業で最も起きやすい |
見落とされやすいのは「人の要因」と「外部サービスの停止」です。
どちらも災害ほど目立ちませんが、日常的に起こり得ます。
特に担当者が1人しかいない会社では、その人の退職が実質的なシステム停止になります。
担当者への依存については「“この人が辞めたら終わり”を解消する｜システムの属人化リスクと対策」で詳しく扱っています。
システムのBCPで決める4つの項目
システムのBCPで決めることは、大きく分けて4つです。
この4つが決まっていれば、計画書としては十分に機能します。
- 優先して復旧する業務とシステム
- 復旧の目標（RTOとRPO）
- バックアップと代替手段
- 体制と連絡先
1. 優先して復旧する業務とシステム
すべてのシステムを同時に戻すことはできません。
止まったときに一番困る業務から順番をつけます。
判断の目安は「止まると売上や信用に直結するか」です。
たとえば、受注・出荷・請求は優先度が高く、社内の掲示板や分析ツールは後回しにできます。
業務ごとに「何日止まると困るか」を経営者と現場で話し合って決めます。
2. 復旧の目標（RTOとRPO）
復旧の目標には、2つの指標を使います。
| 指標 | 意味 | 決め方の例 |
|---|---|---|
| RTO（目標復旧時間） | 止まってから再開するまでに許される時間 | 受注システムは翌営業日まで、勤怠は1週間まで |
| RPO（目標復旧時点） | どの時点のデータまで戻せればよいか | 前日夜の時点まで戻れば、当日分は手入力で補える |
RTOとRPOは短くするほど費用が上がります。
数分で切り替わる仕組みは、待機用のサーバーを常に動かすため費用が膨らみます。
「1日止まっても手作業で回せる」業務なら、日次バックアップで十分なこともあります。
大切なのは、業務ごとに許容できる線を決めることです。
全部を最高水準にそろえる必要はありません。
目安として、業務ごとの決め方の例を挙げます。
自社の業務に置き換えて考えてみてください。
- 受注・予約
止まると注文を取りこぼすため、RTOは数時間から翌営業日までを目安にします。 - 請求・入金
月末に集中するため、月末前後だけは早く戻す運用を決めておきます。 - 勤怠・日報
数日止まっても紙で記録し、後から入力すれば補えることが多い業務です。 - 社内の共有・分析
止まっても業務は回るため、復旧は最後で構いません。
3. バックアップと代替手段
バックアップは「取っている」だけでは不十分です。
次の3点を確認します。
- 保存場所
本番と同じ建物・同じサーバーにしかないと、災害や攻撃で一緒に失われます。 - 世代
最新の1つだけだと、壊れたデータや暗号化されたデータで上書きされる恐れがあります。 - 戻せるかどうか
実際に戻す練習をしていないバックアップは、いざというときに使えないことがあります。
よく使われる考え方に「3-2-1ルール」があります。
データを3つ持ち、2種類の媒体に保存し、1つは別の場所に置くという原則です。
中小企業でも、クラウドの保管サービスを使えば無理なく実現できます。
代替手段は、システムが止まっている間の「つなぎ」です。
紙の受注票、Excelの一時台帳、電話での受付などを決めておき、復旧後にどう取り込むかまで決めます。
4. 体制と連絡先
システムが止まったとき、誰が判断し、誰に連絡するかを決めます。
連絡先の一覧は、システムの中だけに置かないことが重要です。
システムが止まると、その一覧も見られなくなるからです。
- 社内の判断者（経営者・部門長）とその代理
- 開発会社・保守会社・クラウド事業者の窓口と契約番号
- 取引先や顧客への連絡方法とひな形
保守会社との契約で、障害時の対応時間や連絡手段が決まっているかも確認しておきます。
契約の確認ポイントは「システム保守契約の注意点｜外注前に確認すべき5つのSLA」で解説しています。
システムのBCPの作り方｜6ステップ
ここからは、実際に計画を作る手順です。
最初から完璧な計画書を作ろうとせず、A4数枚で回る形を目指します。
- 使っているシステムを書き出す
業務システム・クラウドサービス・社内サーバー・端末を一覧にします。 - 業務との対応をつける
どの業務がどのシステムに依存しているかを線で結びます。 - 優先順位とRTO・RPOを決める
業務ごとに「何日まで止まってよいか」「いつのデータまで戻せばよいか」を決めます。 - 今の備えとの差を確認する
バックアップの場所・世代・復旧手順が、決めた目標を満たしているかを見ます。 - 足りない部分の対策を決める
費用と効果を見ながら、優先度の高いものから対策します。 - 年1回は訓練と見直しをする
実際にバックアップから戻す、代替手段で1日回してみるなどの訓練をします。
一番効果が大きいのは、最後の「戻す訓練」です。
計画書があっても、手順を知っている人がいなければ時間内に戻せません。
訓練で初めて、手順書の抜けや連絡先の古さに気づくことが多いです。
計画書に書く項目のひな形
計画書は、次の項目を埋めるだけでも十分に使えます。
1つの業務につき1ページを目安にまとめると、見る人が迷いません。
- 対象の業務と、使っているシステムの名前
- RTO（何時間・何日で戻すか）とRPO（いつのデータまで戻すか）
- バックアップの保存場所・頻度・保存期間
- システムが止まっている間の代替手段
- 復旧の手順と、作業を依頼する会社の連絡先
- 判断する人とその代理、取引先への連絡方法
印刷して事務所と経営者の自宅など、2か所以上に保管しておくと安心です。
見直しのタイミング
年1回の定期見直しに加えて、次のような変化があったときにも計画を更新します。
- 新しいシステムやクラウドサービスを導入したとき
- サーバーを社内からクラウドへ移したとき
- システム担当者や保守会社が変わったとき
- 拠点の移転や事業の拡大があったとき
クラウドと社内サーバー、BCPではどちらが有利か
システムのBCPを考えると、多くの会社が「サーバーをクラウドに移すべきか」で迷います。
結論から言うと、災害と機器故障への備えはクラウドが有利ですが、クラウドに移しただけではBCPは完成しません。
| 観点 | 社内サーバー | クラウド |
|---|---|---|
| 地震・水害 | 建物が被災すると一緒に停止する | 事業者のデータセンターで保護される |
| 機器の故障 | 自社で交換・修理が必要 | 事業者が機器を管理する |
| ランサムウェア | 社内ネットワーク経由で感染しやすい | 設定次第。バックアップの分離は自社で設計が必要 |
| 外部サービスの停止 | 影響を受けにくい | クラウド事業者の障害で止まることがある |
| 復旧の手間 | 担当者のスキルに依存 | 手順を決めておけば再現しやすい |
クラウドでも、誤操作による削除やアカウントの乗っ取りは防げません。
バックアップを別のアカウントや別の地域に分けて保存するなど、設計の工夫が必要です。
データの置き場所の選び方は「会社のデータを共有したい：クラウドvs社内サーバ」も参考にしてください。
システム開発の段階で組み込むBCP対策
BCPは運用だけの話ではありません。
システムを作る段階で組み込んでおくと、後から足すより安く、確実に備えられます。
開発を依頼するときに、次の点を要件に入れておくことをおすすめします。
| 対策 | 内容 | 効果 |
|---|---|---|
| 自動バックアップ | データベースを毎日自動で別の場所に保存する | RPOを短くできる |
| 復旧手順書の納品 | サーバーを作り直してデータを戻す手順を文書で残す | 担当者が変わっても戻せる |
| 外部連携のエラー処理 | 連携先が止まっても、再試行や後追い処理で業務を止めない | 外部サービス障害の影響を小さくする |
| データの書き出し機能 | CSVなどで主要データをいつでも取り出せる | システム停止中の代替運用に使える |
| 権限の分離 | 管理者権限を限られた人だけに与え、操作履歴を残す | 誤操作や不正の影響を小さくする |
特に重要なのは「外部連携のエラー処理」と「データの書き出し機能」です。
どちらも後から追加すると改修費がかかります。
最初の設計で入れておけば、費用はわずかで済みます。
開発事例：外部APIの障害に備えた設計
当社が開発した災害情報支援サービスでは、天気・地震・雷の3種類の外部APIと連携しています。
外部サービスとの連携には、仕様変更や相手側の障害でデータを取れなくなるリスクがあります。
この開発では、天気APIで起きやすい取得エラーに備えて、リトライ処理（失敗したときに自動で再試行する処理）を設計段階から組み込みました。
その結果、3種類のAPI連携で大きな問題は起きず、安定した運用が続いています。
BCPの観点では、「連携先が止まる」ことを最初から前提にした設計の例です。
この事例の詳細は、以下のページでご覧いただけます。
ランサムウェアに備えるバックアップの注意点
ランサムウェアは、データを暗号化して使えなくし、元に戻す代わりに金銭を要求する攻撃です。
システムのBCPでは、災害と同じくらい重く扱う必要があります。
ランサムウェアの怖さは、ネットワークでつながったバックアップまで一緒に暗号化されることです。
社内サーバーと同じネットワークにある外付けディスクや共有フォルダは、攻撃の対象になり得ます。
- ネットワークから切り離した保存先を持つ
普段は接続しない媒体や、別アカウントで管理するクラウド保管を使います。 - 上書きできない世代を残す
一定期間は削除・変更できない設定ができる保管サービスもあります。 - 管理者のパスワードを分ける
本番とバックアップで同じ管理者アカウントを使わないようにします。 - 戻すのにかかる時間を測っておく
データ量が多いと、戻すだけで1日以上かかることがあります。
戻すのにかかる時間がRTOを超えるなら、バックアップの方法そのものを見直す必要があります。
訓練で一度測っておくと、計画の現実性を確かめられます。
システムのBCP対策にかかる費用の考え方
BCP対策の費用は、決めたRTOとRPOによって大きく変わります。
ここでは、費用が何で決まるかを整理します。
| 対策の水準 | 主な内容 | 費用が増える要因 |
|---|---|---|
| 最低限 | 日次の自動バックアップを別の場所に保存し、復旧手順書を作る | 保存するデータ量、手順書の整備 |
| 標準 | 最低限に加え、世代管理・定期的な復旧訓練・代替運用の準備 | 訓練の工数、保存期間 |
| 高水準 | 待機用のサーバーを用意し、障害時に短時間で切り替える | 待機サーバーの利用料、切り替えの仕組みの構築 |
多くの中小企業では「最低限」から「標準」の水準で十分です。
数分で切り替わる高水準の仕組みは、止まると大きな損失が出る一部の業務に限って検討します。
BCPを放置した場合の損失も比べておくと、判断しやすくなります。
保守を怠った場合のリスクは「システム保守を放置する5つのリスク｜中小企業の損害事例と対策」で事例とあわせて紹介しています。
公的な制度も活用できる
中小企業庁には、中小企業が防災・減災の計画を作って国の認定を受ける「事業継続力強化計画」という制度があります。
認定を受けると、税制措置や金融支援などを受けられる場合があります。
対象や支援内容は年度によって変わるため、最新の情報は中小企業庁の案内で確認してください。
システムのBCPを作る作業は、この計画づくりの土台にもなります。
システムのBCPでよくある失敗
最後に、計画を作ったのに役に立たなかった、というよくある失敗を紹介します。
- バックアップが本番と同じ場所にある
サーバーごと被災したり、ランサムウェアで一緒に暗号化されたりします。 - 戻したことがない
いざ戻そうとしたら手順が分からず、データの形式も合わないことがあります。 - 計画書がシステムの中にしかない
システムが止まると、計画書も連絡先も見られなくなります。 - 担当者1人の頭の中にしかない
その人が不在の日に障害が起きると、誰も動けません。 - 作ってから一度も見直していない
システムや保守会社が変わり、書いてある手順が古くなっています。
どれも、紙に印刷した計画書と年1回の訓練で防げるものです。
高価な仕組みを入れる前に、まずこの5つを確認してください。
よくある質問
Q. 小さな会社でもシステムのBCPは必要ですか？
必要です。
社員が少ない会社ほど、担当者1人の不在やパソコン1台の故障で業務が止まります。
A4数枚の計画書と、バックアップの保存場所の見直しから始めれば負担は大きくありません。
Q. クラウドのサービスを使っていれば、BCPは不要ですか？
不要にはなりません。
クラウド事業者の障害や、誤操作による削除、アカウントの乗っ取りは起こり得ます。
クラウドのデータも、別の場所にバックアップを取っておくことをおすすめします。
Q. RTOとRPOはどう決めればよいですか？
業務ごとに「何日止まると取引先に迷惑がかかるか」「何日分のデータなら手入力で戻せるか」を現場に聞くのが近道です。
最初はおおまかな目安で決め、訓練の結果を見て調整します。
Q. 開発会社にBCPの相談をしてもよいですか？
相談できます。
特に自社で作ったシステムの場合、バックアップの方法や復旧手順は開発会社が一番よく知っています。
既存システムの復旧手順書の作成や、バックアップの見直しだけを依頼することもできます。
まとめ｜システムのBCPは「止まる前提」で今日から始める
システムのBCPは、業務システムが止まっても決めた時間内に業務を戻すための計画です。
決めることは、優先する業務、RTOとRPO、バックアップと代替手段、体制と連絡先の4つです。
最初の一歩は、バックアップの保存場所を確認し、実際に一度戻してみることです。
そこで見つかった課題から順に対策すれば、大きな費用をかけずに備えを固められます。
株式会社みんなシステムズでは、業務システムの開発に加えて、既存システムのバックアップ設計や復旧手順書の整備、クラウドへの移行も支援しています。
「今のシステムが止まったらどうなるか分からない」という段階からでもご相談いただけます。
お気軽にお問い合わせください。
