企業活動を取り巻くリスクは、地震や台風などの自然災害だけではありません。サイバー攻撃、システム障害、設備故障、通信障害、サプライチェーンの寸断など、事業を停止させる要因は多岐にわたります。
特に注意したいのが、企業の業務を支えているITシステムです。
受発注、生産管理、在庫管理、物流、会計などの業務がシステムに依存する現在では、基幹システムが停止すると、システム部門だけの問題では済みません。製造業であれば生産や出荷が止まり、取引先や顧客にも影響が広がる可能性があります。そのため事業継続を考える際には、「災害が発生したらどうするか」というBCP（事業継続計画）だけではなく、日常的なシステム障害や老朽化、セキュリティリスクまで含めて、重要業務を止めない仕組みを整えることが重要です。
本記事では、事業継続の基本的な考え方から、BCPとの関係、ITシステムにおける具体的な対策、導入・整備の進め方まで解説します。後半では、長年利用され複雑化した生産管理システムを刷新し、安定した生産活動を支えるIT基盤と運用体制を整備した製造業の事例も紹介します。
INDEX
事業継続とは
事業継続とは、災害や事故、システム障害などの予期せぬ事態が発生した場合でも、企業にとって重要な業務を継続する、または許容できる時間内に復旧させるための取り組みです。すべての業務やシステムを絶対に停止させないことが事業継続の目的ではありません。重要なのは、事業に大きな影響を与える業務を特定し、「どの程度まで停止を許容できるのか」「どの順番で復旧するのか」「復旧するために何が必要なのか」をあらかじめ整理しておくことです。
事業継続とBCPの違い
事業継続とあわせて使われる言葉に「BCP」があります。BCPはBusiness Continuity Planの略で、日本語では「事業継続計画」と呼ばれます。自然災害や事故などによって通常どおりの事業活動が困難になった場合に、重要業務を継続・早期復旧するための計画です。
つまり、事業継続が企業として実現したい状態や取り組み全体を示すのに対し、BCPはそのための具体的な計画と位置付けることができます。例えば製造業であれば、「主要工場の生産を一定時間以内に再開する」という目標に対して、代替拠点、要員、設備、調達先、ITシステム、データ復旧、連絡体制などを事前に定めます。
ここで重要なのが、ITシステムだけを切り離して考えないことです。生産管理システムが復旧しても、ネットワークや認証基盤が停止していれば利用できない場合があります。反対にITシステムが正常でも、必要な人員や設備が確保できなければ業務を再開できません。
事業継続では、業務・人・設備・IT・データなどを一つのつながりとして捉える必要があります。
BCPとIT-BCPの関係
企業全体のBCPのうち、ITシステムやデータ、ネットワークなどの継続・復旧に焦点を当てた取り組みは「IT-BCP」と呼ばれることがあります。IT-BCPでは、重要システムの優先順位やバックアップ方法、代替環境、障害発生時の対応手順などを具体化します。
特に企業活動のデジタル化が進む現在では、IT-BCPは事業継続を支える重要な要素です。例えば、生産計画から製造指示、実績収集、在庫管理までがシステム化されている工場では、生産設備そのものが稼働できても、生産管理システムが停止すれば正常な生産を継続できないことがあります。そのため、「システムの復旧」はIT部門だけの目標ではなく、「事業をどの時間内に再開するか」という経営・業務側の目標から逆算して設計することが重要です。
なぜ今、事業継続対策が求められているのか
事業継続対策が必要な理由は、企業の業務がITシステムや外部サービスに依存するようになり、一つの障害が事業全体へ波及しやすくなっているためです。事業継続というと大規模災害への備えが注目されがちですが、実務ではより幅広いリスクを考える必要があります。
ITシステムへの依存度が高まっている
企業ではERPや生産管理、販売管理、物流、会計、CRMなど、多くの業務がITシステムによって支えられています。さらに、一つの業務が一つのシステムだけで完結するとは限りません。例えば製造業では、受注情報を基幹システムから生産管理システムへ連携し、製造実績をMESなどから取得し、その情報を在庫や出荷、会計システムへ反映するといった構成も考えられます。
このような環境では、一つのシステムが停止しただけでも、連携先を含む複数業務に影響が及ぶ可能性があります。そのため事業継続対策では、個々のシステムだけではなく、業務とシステムの依存関係を把握することが重要です。
レガシーシステムの老朽化が事業リスクになる
長年利用している基幹システムや生産管理システムも、事業継続上のリスクになる可能性があります。例えば、OSやミドルウェアのサポート終了、古い開発言語への依存、保守担当者の退職、設計書の不足などが重なると、障害が発生しても原因を迅速に特定できなくなる可能性があります。
さらに、長期間にわたり機能追加や個別カスタマイズを繰り返している場合、システム間の依存関係が複雑になり、一つの改修が別の機能へ影響することもあります。この状態では「現在動いているから問題ない」とは言えません。
事業継続の観点では、障害が発生する確率だけでなく、発生した場合に復旧できるかどうかまで評価する必要があります。
サイバー攻撃など想定すべきリスクが広がっている
事業停止につながる要因は、ハードウェア障害や自然災害だけではありません。ランサムウェアなどのサイバー攻撃を受けた場合、業務システムだけでなくバックアップデータまで影響を受ける可能性があります。また、クラウドサービスやネットワークなど外部サービスへの依存が高まれば、自社設備が正常でも業務が継続できないケースも考えられます。
したがって事業継続対策では、「災害対策」「システム障害対策」「サイバーセキュリティ」を別々に検討するのではなく、事業停止につながるリスクとして横断的に整理することが求められます。
ITによる事業継続対策で実現できること
ITにおける事業継続対策の目的は、障害を完全になくすことではなく、障害が起きても重要業務への影響を抑え、必要な時間内に復旧できる状態をつくることです。そのためには「止めない仕組み」と「止まった後に戻す仕組み」の両方が必要になります。
システム停止リスクを低減する
サーバーやネットワークなどを冗長化することで、一部の機器に障害が発生しても別の機器へ切り替え、システム停止のリスクを抑えられます。ただし、冗長化すれば事業継続対策が完成するわけではありません。
アプリケーション、データベース、ネットワーク、認証、外部サービスなど、業務を構成する要素のどこに単一障害点が残っているかを確認する必要があります。「サーバーだけ二重化されているがネットワークは単一構成」といった状態では、想定した可用性を確保できない可能性があります。
障害発生時の復旧を迅速化する
事業継続では、障害を防ぐ対策と同じくらい、発生後の復旧設計が重要です。その際に検討したいのが、RTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧時点）です。RTOは「障害発生からどの程度の時間で復旧させる必要があるか」、RPOは「どの時点までデータを戻せれば事業上許容できるか」を示します。
重要なのは、IT部門だけで数値を決めないことです。例えば「1時間以内に復旧する」という高い目標を設定すれば、冗長化やバックアップ、待機系環境などへの投資も大きくなります。反対に復旧まで数日かかっても問題ない業務に高可用性構成を導入すると、過剰投資になる可能性があります。
業務影響を確認し、必要なサービスレベルを決め、その要件を満たすシステム構成へ落とし込むことが重要です。
障害を早期に検知し、初動を迅速化する
システム障害への対応時間は、実際の復旧作業だけで決まるわけではありません。「障害に気付くまでの時間」と「原因を切り分けるまでの時間」も大きく影響します。そのため、監視によって異常を早期に検知するとともに、障害発生後に誰が確認し、どこまで一次切り分けを行い、どの担当者へエスカレーションするのかを決めておく必要があります。
24時間365日の監視・一次対応が必要なのか、業務時間内の対応でよいのかについても、対象システムの重要度から判断します。障害発生時の事後対応だけでなく、近年はAIを活用した稼働監視ツールなどを導入することで、サーバーの異常な負荷やリソースの枯渇といった「障害の予兆」を自動で検知できるようになっています。これにより、システムが完全に停止してしまう前に対処を行い、ダウンタイムそのものを未然に防ぐプロアクティブな事業継続対策が可能となります。
システムを継続的に維持できる状態にする
見落とされやすいのが「平常時の保守性」です。災害対策としてバックアップや冗長化を整備していても、システム自体がブラックボックス化していれば、障害時に迅速な復旧ができない可能性があります。設計書を整備する、システム構成を簡素化する、古い技術への依存を減らす、変更管理のルールを定めるといった取り組みも、事業継続対策の一部です。
つまりITによる事業継続では、非常時だけではなく、平常時から「壊れにくい・把握できる・直せる」システムを維持することが重要になります。
事業継続対策の進め方
事業継続対策は、最初からバックアップ製品や冗長化構成を決めるのではなく、事業影響を把握し、重要業務と復旧目標を定めてからIT対策へ落とし込むことが基本です。特に複数の業務システムが連携している企業では、システム単位ではなく業務単位で考える必要があります。
STEP1．重要業務を特定する
最初に「止まった場合に事業への影響が大きい業務」を整理します。売上、生産、顧客対応、法令対応、社会的信用などへの影響を確認し、業務ごとの重要度を評価します。例えば製造業であれば、生産計画、製造指示、在庫管理、出荷などが候補になります。ただし、企業や製品によって影響度は異なるため、自社の事業構造に基づいて判断する必要があります。
STEP2．業務とITシステムの依存関係を可視化する
次に、重要業務がどのシステムやインフラによって支えられているかを整理します。ここでは、アプリケーションだけでなく、データベース、サーバー、ネットワーク、認証基盤、クラウドサービス、外部システムとの連携なども確認します。特に長期間利用しているシステムでは、担当者が認識していない連携処理やバッチ処理が存在する場合があります。
そのため、設計書だけで判断せず、現行環境や実際のデータフロー、運用担当者へのヒアリングなどを通じて現状を把握することが重要です。
STEP3．RTO・RPOなどの復旧要件を決める
業務影響を踏まえ、システムごとに復旧の優先順位を設定します。「何時間以内に復旧する必要があるのか」「どの程度のデータ損失まで許容できるのか」を明確にすることで、必要なバックアップ頻度や冗長化レベルを判断しやすくなります。
すべてのシステムを同じレベルで保護するのではなく、事業への影響に応じて優先順位を付けることがポイントです。
STEP4．システム・インフラ・運用の対策を設計する
復旧要件が決まったら、具体的な対策へ落とし込みます。代表的な対策としては、サーバーやネットワークの冗長化、データバックアップ、遠隔地へのデータ保管、クラウド活用、DR（Disaster Recovery：災害復旧）環境、監視、セキュリティ対策などがあります。
対策を設計する際は、バックアップやサーバー冗長化といった障害発生後の復旧策（事後対応）に加えて、前述したAI等による「予兆検知の仕組み」を運用設計に組み込むことも重要です。人手では気づきにくいわずかなシステムの異常を早期に察知する仕組みがあれば、システム停止の発生リスクを大幅に引き下げることができます。
ただし、技術的な仕組みだけでは十分ではありません。障害発生時の連絡先、一次切り分け、エスカレーション先、復旧判断を行う責任者など、運用面まで設計して初めて実際に機能する対策になります。
STEP5．テストと見直しを継続する
BCPやIT-BCPは、一度策定して終わりではありません。システム構成や業務プロセスは変化するため、策定当時の復旧手順が数年後にも機能するとは限らないからです。バックアップから実際にデータを復元できるか、代替環境へ切り替えられるか、担当者不在でも手順を実行できるかなどを定期的に確認します。
また、システム更改や組織変更、新拠点の追加、クラウドサービス導入などがあった場合には、BCP・IT-BCPもあわせて更新する必要があります。
当社が支援した製造業の事業継続を支える生産管理システム刷新事例
ここまで、全社的な視点から事業継続 (BCP) におけるIT・システムの重要性とその進め方について解説してきました。では、実際の現場において、特定のシステムインフラを見直すことが、どのように全社の事業継続に直結するのでしょうか。
ここでは、「なぜ今、事業継続対策が求められているのか」でも触れた「レガシーシステムの老朽化」という事業継続リスクに対し、長年利用され複雑化した生産管理システムを刷新し、リスク回避と安定した生産活動を実現した事例をご紹介します。
導入前の課題
ある大手製造業の生産拠点では、20年近くにわたってシステムの構築・改修が続けられてきました。その結果、社内で開発されたものと外部ベンダーが構築したものを含めて約60のシステムが混在。長年の個別カスタマイズによって機能数も約4,000まで増加していました。さらに、一部では25年以上利用しているVB6などの古い技術も残っていました。
問題は、単にシステムが古いことだけではありません。長年の改修によってシステムやデータベース間の連携が複雑になっている一方、設計書などのドキュメントが十分に残っておらず、現行仕様を把握すること自体に時間がかかる状況でした。国内・海外拠点との連携もあり、一つの変更がどこへ影響するのかを確認することも容易ではありません。こうした状態で障害が発生すると、原因特定や復旧に時間を要し、生産活動へ影響する可能性があります。
そこで、単なるハードウェアやソフトウェアの更新ではなく、複雑化・肥大化したシステム全体を整理し、継続的に維持管理できる基盤へ刷新することになりました。
導入内容
刷新では、大きく「簡素化」「スリム化」「最新化・堅牢化」の3つの方向からシステムを見直しました。まず、複数に分散していたアプリケーションとデータベースの構成を整理し、統合できるものを集約しました。同時に約4,000の機能を棚卸しし、現在も必要な機能、類似する機能、廃止可能な機能を整理。既存機能をそのまま新環境へ移植するのではなく、必要性を確認しながら仕様の統廃合を進めました。
特に難しかったのが、現行仕様の把握です。ドキュメントが十分に残っていないため、既存アプリケーションやデータベース、システム間のデータ連携を確認し、実際の業務と照らし合わせながら仕様を整理しました。
また、一つの仕組みを複数の事業部が利用する一方、製造する製品や生産方法には違いがありました。そのため、すべてを画一的に標準化するのではなく、共通化できる業務と個別対応が必要な業務を切り分けながら要件を定義しました。
技術的・運用的ポイント
今回の刷新で重視したのは、アプリケーションだけを新しくするのではなく、事業継続に必要なインフラと運用まで一体で設計することでした。例えば、求められる目標復旧時間などのサービスレベルを踏まえて、サーバーの冗長化や検証環境を整備しています。
一方で、インフラを強化する際には、設置スペースや電力など物理的な制約も考慮する必要がありました。また、複数のシステムやデータベースが連携し、国内外の拠点とも接続されていたため、刷新対象だけを見るのではなく、周辺システムへの影響を確認しながら設計を進めました。
運用面では、稼働後の24時間365日の一次切り分け対応も開始しています。障害発生時に「誰が最初に確認するのか」が曖昧な状態では、技術的に復旧可能であっても初動が遅れる可能性があります。そこで、障害を検知した後の一次切り分けから必要な対応へつなぐ体制を整備し、復旧対応の迅速化を図りました。
このように、事業継続を目的としたシステム刷新では、要件定義、アプリケーション、データベース、システム連携、インフラ、セキュリティ、運用設計を分断せずに考えることが重要です。
導入効果
刷新によって、古い技術に依存した環境を見直し、継続的に維持管理できるシステム基盤への移行が進みました。特に、セキュリティ面の不安が軽減されたことに加え、24時間365日の一次切り分け体制を整えたことで、障害発生時の初動から復旧対応までを迅速に進められる環境が整っています。また、サーバーの冗長化や検証環境なども含めて基盤を強化したことで、今後の安定した生産活動を支える環境を構築できました。
今回の事例が示しているのは、事業継続対策が災害時だけの取り組みではないという点です。長期間利用したシステムの老朽化やブラックボックス化を解消し、障害発生時にも対応できるシステムと運用体制へ変えていくことも、重要な事業継続対策です。
さらに、安定して維持できる基盤を整備したことで、今後はシステムやデータを「守る」だけでなく、蓄積されたデータの活用やさらなる業務改善へ取り組むための土台にもつながっています。
事業継続対策で失敗しないためのポイント
事業継続対策で失敗しないためには、BCPを文書化すること自体を目的にせず、実際の障害時に「誰が、何を、どの順番で復旧するのか」まで具体化することが重要です。特にIT領域では、技術的な対策だけを先行させないよう注意が必要です。
「とりあえず冗長化」から始めない
よくある失敗の一つが、事業への影響を整理しないまま、サーバー二重化やバックアップ製品の導入を進めることです。冗長化は重要な手段ですが、それ自体が目的ではありません。まず重要業務を特定し、停止した場合の影響と許容停止時間を確認します。そのうえでRTO・RPOを定め、必要な可用性やバックアップ方式を選択することが重要です。
この順序を逆にすると、必要以上の設備投資になる一方、本当に重要なシステムに十分な対策ができていないという状況が起こり得ます。
システム単体ではなく依存関係を見る
二つ目のポイントは、システムを単体で評価しないことです。例えば生産管理システム自体を冗長化していても、認証基盤やネットワーク、連携するデータベースが停止すれば業務を継続できない場合があります。そのため、業務プロセスを起点として「この業務を実行するには何が必要か」をたどり、システム、データ、ネットワーク、外部サービスまで含めて依存関係を可視化する必要があります。
レガシーシステムを放置しない
正常稼働している古いシステムは、刷新の優先順位が下がりがちです。しかし、サポートが終了したOSや開発環境、特定担当者しか理解できないプログラム、設計書のないシステムなどは、障害が起きた際の復旧リスクを高めます。「まだ動いているか」だけではなく、「壊れた場合に直せるか」「担当者が変わっても維持できるか」という観点から評価することが必要です。
すぐに全面刷新できない場合でも、システム構成や連携関係の可視化、ドキュメント整備、保守期限の管理などから段階的に取り組むことができます。
運用設計をシステム稼働後に回さない
システム構築を優先し、運用設計を稼働直前に始めることも避けたい進め方です。監視対象、障害の判断基準、連絡先、一次対応の範囲、エスカレーション条件、復旧後の確認方法などは、システム設計と並行して検討する必要があります。特に24時間稼働するシステムでは、深夜や休日に障害が起きた場合も想定しなければなりません。
「システムとして復旧できる設計」と「組織として復旧を実行できる体制」の両方を整えることが重要です。
定期的に訓練・見直しを行う
事業継続対策は、作成時点では正しくても、時間が経過すれば実態と合わなくなります。システム追加やクラウド移行、組織変更、担当者変更などによって、障害対応の手順や連絡先が変わるためです。
そのため定期的に復旧訓練や手順確認を行い、「実際にバックアップから戻せるか」「目標時間内に復旧できるか」「担当者不在時にも対応できるか」を確認する必要があります。テストで発見した課題をBCPや運用手順へ反映し、継続的に改善することが、実効性のある事業継続につながります。
まとめ
事業継続の目的は、あらゆる障害を防ぐことではなく、予期せぬ事態が発生しても重要業務への影響を最小限に抑え、必要な時間内に事業を継続・復旧できる状態をつくることです。そのためには、BCPを策定するだけではなく、実際の業務を支えているITシステムまで掘り下げて考える必要があります。
特に、長期間利用している基幹システムや生産管理システムでは、老朽化、複雑化、ブラックボックス化そのものが事業継続リスクになる可能性があります。まず重要業務とシステムの依存関係を整理し、RTO・RPOなどの復旧要件を設定する。その要件に基づいて、システム刷新、冗長化、バックアップ、セキュリティ、監視、障害対応などを設計し、定期的に見直すことが重要です。
また、大規模なシステムではアプリケーション、データベース、インフラ、ネットワーク、周辺システムが複雑に関係しています。そのため、事業継続を目的としたIT基盤の見直しでは、個々の技術を部分最適で導入するのではなく、業務要件から要件定義、システム連携、インフラ、セキュリティ、運用設計までを一つの仕組みとして設計することが、継続的に事業を支えられるIT環境につながります。
