LASSIC Media らしくメディア

2026.07.02 らしくコラム

IT-BCPの考え方と策定ステップ

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

事業継続・システム運用のイメージ

この記事のポイント

  • IT-BCPは情報システム部門だけの技術文書ではなく、事業継続の意思決定として経営層が関与すべき計画です。
  • RTO(目標復旧時間)とRPO(目標復旧時点)は技術指標である前に、事業インパクトから経営が決める判断軸です。
  • 重要業務の特定から訓練・見直しまでの策定ステップと、中小・少人数の情報システム部門での現実的な進め方を整理します。

IT-BCPとは何か — システム停止が事業停止に直結する理由

BCP策定・経営会議のイメージ

IT-BCPとは、情報システムの運用継続計画を指します。災害やシステム障害が発生した際に、重要な業務を支えるITサービスをどこまでの時間・範囲で復旧させるかをあらかじめ定めた計画です。経済産業省の「ITサービス継続ガイドライン」では、ITサービス継続を「事業継続の一部であり、災害・事故等の発生に際し、ITサービスの中断・停止による事業継続に与える影響を、求められるサービスレベルと対策に必要なコストとの関係の中で最適化するための取り組み」と定義しています*1

多くの企業で基幹システム・受発注システム・顧客管理システムなどのITサービスが業務プロセスの土台になっています。同ガイドラインは、IT サービス継続とIT戦略・事業継続の関係を「ITサービス継続はIT戦略の一部ないしIT戦略の次位に整合的に位置づけられるもの」と整理しており*1、ITの中断が業務そのものの停止に直結する構造を前提にしています。

地震などの大規模災害だけでなく、社内サーバーの故障、通信回線の障害、ランサムウェア等のインシデント、感染症の流行による出社制限なども、IT-BCPが想定すべき事象に含まれます。同ガイドラインも、システム本体やインフラの事故のように「より局所的・小規模なリスク」への配慮を全社BCPとは別に求めており*1、経営層が想定すべきリスクの幅は地震のような広域災害に限られません。

IT-BCPの策定が遅れている場合、経営層は「システムが止まったらどこまで許容できるか」を事前に議論しないまま緊急対応を迫られることになります。この判断の遅れそのものが、復旧までの時間を延ばし、取引先や顧客への影響を拡大させる要因になります。

図
IT-BCP策定の流れ(重要業務の特定から訓練・見直しまで)

BCPとIT-BCPの関係 — 全社計画とIT計画の役割分担

内閣府「事業継続ガイドライン」(令和5年3月改定)は、BCP(事業継続計画)を「不測の事態が発生しても、重要な事業を中断させない、または中断しても可能な限り短い期間で復旧させるための方針、体制、手順等を示した計画」と位置づけ、経営レベルで戦略的に取り組むべき事項としています*2。IT-BCPはこの全社BCPのうち、情報システムに関わる部分を切り出して具体化したものと言えるでしょう。

経済産業省のITサービス継続ガイドラインも、この関係を「事業継続マネジメント(BCM)の中からITの要素を取り出して、ITサービスのマネジメント体制を事故前提の考え方に基づいて構築・維持していく」ものと説明しています*1。全社BCPが重要業務の継続方針や人員体制を扱うのに対し、IT-BCPはその業務を支えるシステムをどう復旧させるかに焦点を絞る位置づけです。

両者は別物ではなく一対の関係にあります。全社BCPで「受注業務を3日以内に再開する」と定めた場合、IT-BCPはその業務を支える受発注システムをどの手段でどこまでの時間内に復旧させるかを具体化する役割を担うことになるでしょう。IT-BCP側だけを先に作っても、全社の重要業務の優先順位が定まっていなければ、どのシステムを優先復旧すべきかの判断基準が曖昧になりかねません。

実務上は、全社BCPを主管する部門(経営企画・総務・リスク管理等)と情報システム部門が連携し、重要業務の調査結果とシステム構成の調査結果を突き合わせながら両計画を並行して整備する進め方が現実的です。どちらか一方だけを整備しても、システム復旧が業務再開に結びつかない、あるいは業務再開の前提となるシステムが計画から漏れるといった不整合が生じます。

RTOとRPO — 経営が事業インパクトから決める復旧目標

IT-BCPとは、重要業務を支えるITサービスについて、復旧までの時間と復旧すべきデータの範囲をあらかじめ数値目標として定め、それを実現する体制と対策を整備する計画を指します。この数値目標の中核がRTOとRPOです。

RTO(目標復旧時間。Recovery Time Objective)とは、障害発生後に業務を復旧させるまでの目標期間です*1。RPO(目標復旧時点。Recovery Point Objective)とは、障害発生前のどの時点までデータを復旧できるようにするかの目標時点です*1。あわせてRLO(目標復旧レベル。Recovery Level Objective)という、どのレベルまで業務を復旧・継続させるかの指標もあります*1

これらの目標値は、情報システム部門が技術的な可否だけで決めるものではありません。同ガイドラインは、コスト面での制約を考慮せずに要件定義をさせると「RTOとRPOがゼロで、RLOは事象の発生前と同等という要件が当然の結果として出てくる」と指摘し、実際には対策コストと業務への影響度を勘案して目標を決めるべきだとしています*1。復旧を速く・データ欠損を少なくするほど、二重化やバックアップサイトなどの対策コストは増加します。

RTOを決める出発点は、業務が停止した場合に経営へどれだけの影響が及ぶかです。同ガイドラインは、顧客への影響が大きい受発注業務や問い合わせ対応窓口、全社的な影響が大きい電子メールやイントラネットなどは復旧優先順位が高くなりやすいと述べています*1。どの業務にどこまでの停止を許容できるかは事業内容によって異なるため、情報システム部門だけで決めず、経営層と事業部門を交えて合意形成する必要があります。

目標値の検討にあたっては、通常時に想定するRTOと、大規模災害など全社BCPが想定する非日常的な状況でのRTOを区別する視点も欠かせません。同ガイドラインは、大規模災害時は復旧要員の確保やインフラ復旧の遅れなどにより、通常時より目標復旧時間が長くなる傾向があると説明しています*1。平時の障害対応計画と、大規模災害を想定した計画とでは、同じRTOという指標でも前提が異なることを踏まえて検討する必要があります。

重要業務の特定から訓練まで — IT-BCP策定の6ステップ

IT-BCPは、重要業務の特定、影響度分析、復旧目標の設定、対策の実施、体制・連絡網の整備、訓練と見直しという順序で組み立てます。経済産業省のITサービス継続ガイドラインが示す枠組みに沿って、各ステップの要点を整理します。

第一段階は重要業務の特定です。自社の業務のうち、どの業務がどのITサービスにどの程度依存しているかを洗い出します。基幹システムだけでなく、電子メールや入退館システムのような「共通のITサービス」も対象に含める必要があります。同ガイドラインは、これらは事業に直接関係しないため重要度を見誤りやすいと注意を促しています*1

第二段階は影響度分析です。各業務が中断した場合に経営へどのような影響が生じるかを分析します。売上への直接的な影響だけでなく、取引先への信用低下や法令上の対応遅延なども含めて検討する必要があるでしょう。この分析結果が、次の復旧目標を決める根拠になります。

第三段階は前述のRTO・RPOの設定です。影響度分析の結果をもとに、業務ごとに許容できる停止時間とデータ復旧範囲を経営層が承認します。

第四段階は対策の実施です。データのバックアップ、システムやサーバーの冗長化、クラウドサービスの活用など、設定した復旧目標を実現するための技術的対策を選びます。同ガイドラインは、RTO・RPOを短くするほど必要な投資コストが増えるため、対策コストと業務影響のバランスを取ることが重要だとしています*1

第五段階は体制と連絡網の整備です。緊急時に誰が対策本部を設置し、誰が復旧作業を指揮するかという役割分担、従業員や取引先との連絡手段をあらかじめ定めます。同ガイドラインは、対策本部長のような重要な役割を担う要員について代替要員をあらかじめ決めておく必要があるとしています*1

第六段階は訓練と見直しです。策定した計画が実際に機能するかを、机上でのレビューから実機を使った訓練まで段階的に検証します。同ガイドラインも、IT-BCPは策定して終わりではなく、計画・導入訓練・評価・改善のサイクルで運用すべきものだと位置づけています*1。業務内容やシステム構成の変化に応じて、定期的な見直しも欠かせません。

少人数の情報システム部門でも進められる段階的な取り組み方

バックアップ・復旧対策のイメージ

情報システム部門の人員が数名以下の中小企業では、上記6ステップをいきなり全社規模で実行しようとすると、通常業務と並行できずに頓挫しがちです。範囲を絞った段階的な進め方が現実的です。

最初に取り組むべきは、全業務ではなく最重要業務1〜2件に絞った重要業務の特定と影響度分析です。売上への影響が最も大きい業務、あるいは停止した場合に取引先との契約上の問題が生じる業務を優先し、その業務を支えるシステムから検討を始めます。全社を網羅する完全な計画を最初から目指す必要はありません。

対策実施の面では、自社でバックアップサイトを構築するのではなく、クラウドサービスの標準機能として提供されるバックアップ・冗長化機能を活用する選択肢があります。自前でデータセンターを二重化する場合と比べ、初期投資を抑えながら一定水準のRTO・RPOを実現しやすくなります。ただし、クラウド事業者側の障害やサービス終了のリスクも残るため、契約条件やサービスレベルの確認は必要です。

体制面では、専任のBCP担当者を置けない場合でも、緊急時の初動対応者と代替対応者を最低限決めておくことが重要です。情報システム担当者が1名しかいない体制では、その担当者が不在・被災した場合に誰が対応するかという代替要員の検討が抜け落ちやすく、実際に経済産業省のガイドラインも代替要員の確保を明示的な検討項目として挙げています*1

訓練についても、大がかりな総合演習ではなく、計画書の内容を関係者で読み合わせる机上チェックから始めれば、業務への影響を抑えながら実施できます*1。段階を踏んで実効性を高めていく進め方が、少人数体制での現実的な選択肢になります。

外部委託の活用 — 策定と運用を専門パートナーと分担する考え方

IT-BCPの策定・運用を内製だけで完結させるには、リスク評価の知見、システムアーキテクチャの設計力、平時の運用保守体制という複数の専門性が必要になります。これらをすべて自社に確保するのは容易ではありません。

内製で対応する場合に必要となる知識は、リスク評価の手法、システム構成ごとのデータ複製方式の選定、バックアップサイトの設計、緊急時対応手順の整備など多岐にわたります。経済産業省のガイドラインも、データレプリケーション方式だけで完全同期型・遅延同期型・一括同期型といった複数の選択肢を挙げ、システム構成に応じた検討が必要だとしています*1。これらを情報システム部門の担当者が独学で判断するには、相応の学習期間と実務経験が求められます。

専門パートナーに相談する場合との違いは、リスク評価から対策設計、運用後の見直しまでを一貫した知見に基づいて進められる点にあるのではないでしょうか。内製で進める場合は、担当者の異動や退職によって蓄積した知見が失われるリスクも避けられません。運用保守を外部委託していれば、平時の監視・保守と緊急時対応の両方を継続的な体制で担保しやすくなります。

IT-BCPの策定支援や、復旧目標を実現するためのシステム構成の設計、日常の運用保守までを外部パートナーと分担することで、限られた人員でも継続的にIT-BCPを維持できる体制を組みやすくなります。委託する場合も、緊急時対応の役割分担や連絡体制は契約条件として明確にしておく必要があります。

LASSICに相談するメリット

LASSICは元請(プライムベンダー)として、システムの保守・運用を受託する体制を整えています。重要業務の洗い出しからRTO・RPOの設定、バックアップ・冗長化構成の設計、日常の運用保守までを一貫して相談できる点が特徴です。情報システム部門が少人数の企業でも、段階的にIT-BCPを整備していく進め方についてご相談いただけます。

まとめ:IT-BCP策定で経営が握るべき3つの判断軸

本稿では、IT-BCPの考え方と策定ステップを経営視点で整理しました。要点を3つに集約すると次の通りです。第一に、IT-BCPは情報システムの技術文書ではなく、システム停止が事業停止に直結するという前提に立った経営の意思決定であり、全社BCPと連携させて策定する必要があります。第二に、RTO・RPOは技術的な理想値ではなく、業務停止が経営に与える影響と対策コストのバランスから経営層が決める判断軸であり、重要業務の特定から訓練・見直しまでの手順を踏んで具体化するものです。第三に、少人数の情報システム部門であっても最重要業務から段階的に着手する進め方が現実的であり、専門知見を要する領域は外部パートナーとの分担も選択肢になります。

よくある質問

IT-BCPとディザスターリカバリー(DR)は同じものですか。

同じではありません。DR(ディザスターリカバリー)は主にシステムやデータの技術的な復旧手段を指す概念であり、IT-BCPはその技術的対策に加えて、復旧目標の設定・体制整備・訓練・見直しまでを含む計画全体を指すものです。DRはIT-BCPを実現するための技術的対策の一部という位置づけになります。

RTOとRPOはどちらから先に決めればよいですか。

決まった順序はありませんが、まず業務が停止した場合の経営インパクトを分析したうえで、その業務にどこまでの停止時間(RTO)とデータ損失(RPO)を許容できるかを併せて検討する進め方が実務的です。どちらか一方だけを厳しく設定しても、もう一方が緩ければ復旧後の業務に支障が出る可能性があります。

IT-BCPの策定にはどの部門が関わるべきですか。

情報システム部門だけでなく、経営層、事業部門、全社BCPを主管する部門(経営企画・総務・リスク管理等)が関わる必要があります。重要業務の優先順位や復旧目標の承認は経営層の役割であり、情報システム部門はその目標を実現する技術的対策の検討を担います。

クラウドサービスを使えばIT-BCPは不要になりますか。

不要にはなりません。クラウドサービスの利用はバックアップや冗長化の選択肢を広げますが、クラウド事業者側の障害やサービス終了のリスクは残ります。どのサービスをどう使い、復旧目標をどう設定するかという計画自体は、クラウド利用の有無にかかわらず必要です。

IT-BCPは一度策定すれば見直しは不要ですか。

見直しは必要です。業務内容やシステム構成、組織体制は時間とともに変化するため、策定時の前提が古くなります。訓練の実施結果をふまえたフィードバックや、システム変更時の計画反映など、継続的な維持改善のプロセスをあらかじめ組み込んでおく必要があります。

著者:テレリモ総研編集部 鈴木 亮佑


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:経済産業省「ITサービス継続ガイドライン」(2008年)https://www.bousai.go.jp/kyoiku/kigyou/keizoku/pdf/itsc_gl.pdf
  2. *2 出典:内閣府「事業継続ガイドライン-あらゆる危機的事象を乗り越えるための戦略と対応-」(令和5年3月改定)https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf


View