１．想定外は必ず起きる

近年、サイバー被害はもはや例外ではない。ミュトス、ランサムウェア、ソフトウェア不具合、クラウド障害、など、情報システムが「突然止まる」ことは、現実の前提となった。しかし、こうした前提に対する向き合い方には、大きな差がある。

私自身、外資系の証券会社との共同プロジェクトでシステム開発を担当していた際、その違いに強い戸惑いを覚えたことがある。サービスインを最終決定する会議で、先方からこう言われた。
「システムが停止した場合のビジネスプランを作りましょう」。
正直に言えば、驚いた。「止まること」を前提に議論すること自体が、日本企業の感覚ではどこか「縁起でもないこと」のように感じられるからだ。

また、別の機会に外国企業の方からゴルフに誘われたときのことも印象的だった。
その際、こう確認された。「前日12時のゴルフ場の天気予報で、降水確率70％以上、雨量2ミリ以上であれば中止ということでいいですか」。
あらかじめ条件を決めておくことに、これもまた驚いた。どちらも些細な話に見えるかもしれない。しかし、ここには決定的な違いがある。

欧米企業は、明確な前提に立っている。それは、「想定外は必ず起きる」という前提だ。だから彼らは、起きるかどうかを議論しない。起きたときにどう判断するかを決めておく。この思考様式を持っている。
サイバー攻撃に対しても同様である。彼らの出発点は、止まるかどうか、ではない。止まったときに、顧客へのサービスをどう継続するかにある。つまり、ITの可用性と、事業の継続性を別物として考えているのだ。
ここに、日本企業との大きな差がある。

もっとも、日本企業の考え方が、単純に間違っていたわけではない。高度成長期では、日本企業は「止めない品質」を徹底的に追求してきた。現場改善、品質管理、障害の未然防止を積み重ね、高い安定運用を実現したことは、日本企業の大きな競争力だった。
しかし現在は、クラウド化、サプライチェーンの複雑化、そしてサイバー攻撃の常態化によって、「完全に止めない」こと自体が現実的ではなくなっている。だからこそ今求められているのは、「止めないこと」だけではなく、「止まった時にどう意思決定するか」を設計することなのだ。

２．BCPは「IT計画」ではない

この前提に立つと、BCPの意味は大きく変わる。欧米企業ではBCPは、顧客成果を守るための意思決定体系として定義される。単なる復旧計画ではない。何を守り、どう判断するかという「経営の構造」そのものなのだ。
この考え方は、ITサービスマネジメントの国際的フレームワークである「ITIL 4」が示している。ITIL4では、ITの目的はシステムの安定稼働ではなく、顧客との価値共創と定義されている。すなわち、守るべきはITそのものではなく、顧客価値なのだ。
さらに、ITIL4のサービス継続性管理においても、重大障害は起きる前提に立ち、その際に事業への影響をいかに最小化するかが重視される。また、従来の手順中心のプロセスから、状況に応じて判断する「プラクティス」への転換が提唱されている。
つまり、BCPとは手順ではなく、価値を守るための意思決定構造だと考えることが求められている。

この設計には、3つの特徴がある。

1. 「何を守るか」が明確（顧客起点）
   まず定義されるのはシステムではない。どの顧客に、どの価値を、どのレベルで、どの時間内に、提供し続けるのかを定義する。
   例えば、決済は止めない、医療データは30分以内に復旧する、ECは注文受付だけは維持する、など。
   ここで初めて、BCPの目的が定まる。
2. 業務プロセス単位で設計される
   次に、それを実現する業務が分解される。受注・決済・出荷・カスタマーサポートといったビジネスプロセス単位で設計される。
   その結果、ITが止まっても手動代替が可能になり、どの業務を優先すべきか即時に判断できる。ここでも単位はITではない。あくまで「価値を生むプロセス」だ。
3. 意思決定権限が事前に設計されている
   そして最も重要なのが、意思決定構造だ。システム障害時に、誰がサービス停止を判断するのか、誰が代替手段への切替を決断するのか、誰が顧客に説明するのかが、あらかじめ決められている。
   ここにおいてBCPは、意思決定のOSとして機能する。

３．実際の危機対応

実際の事例を見れば、その差は明確だ。
例えば、物流大手のA.P. Moller-Maerskは、大規模なサイバー攻撃により全システムが停止した。それでも同社は、紙と電話による手動オペレーションへ即時切替、港湾業務を縮退運転で継続、グローバルで意思決定を一元化、という対応を取り、「完全停止」を回避したようだ。ここで重要なのは、ITの強さではない。意思決定が止まらなかったことだ。
重要なのは、現場が「全部を復旧するまで待つ」という発想を取らなかったことだ。どの港湾業務を優先するか、どの顧客対応を継続するか、誰がその判断を下すかが、事前に設計されていた。だから、システムが止まっても、意思決定は止まらなかった。 逆に言えば、日本企業ではここが曖昧なまま運用されていることが多い。
「誰が止めるのか」「誰が優先順位を決めるのか」が平時から定義されていないため、非常時には、現場が上位判断待ちとなり、結果として、システム停止以上に「意思決定停止」が発生しやすい。

４．BCPの本質は何か

以上を踏まえると、結論は明確だ。
BCPとは、復旧の手順ではなく、システムの設計でもなく、「顧客価値を守るために、誰がどう判断するか」を定義した経営の仕組みなのだ。
どの価値を守り、どのサービスを止めるかは、本来、事業責任を持つ経営の判断だ。それはIT部門の役割ではない。IT部門の役割は、その判断を可能にする選択肢と情報を提示することにある。ここまで設計されて初めて、BCPは機能する。

５．BCP作成を契機に、マネジメントOSへの転換をドライブ

「正しいBCPを作成すること」を一つの現実的な契機として、会社のOSを顧客価値を起点とする「マネジメントOS」に転換することを始められないだろうか。
このBCPの設計は、単なるリスク対策にとどまらない。むしろ、企業がこれまで曖昧にしてきた問いを、避けずに引き受けることを要求する。
「どの顧客価値を最優先とするのか。」「すべてを守れないとき、何を切り捨てるのか。」「その判断を、誰が責任を持って行うのか。」
これらは本来、経営が答えるべき問いだ。しかし平時においては、こうした問いが真正面から議論されることは少ない。結果として、意思決定は設計されないまま、先送りされている。

サイバー災害という現実は、その先送りを許さない。正しいBCPを作るという行為は、必然として、マネジメントOSを問い直すプロセスそのものになると思う。