通信が止まっても動くシステムが問いかけるもの
「通信が止まっても回る デジタルで避難所受付はここまで変わる!?」というニュースが話題を呼んでいます。災害時に避難所の受付をデジタル化し、オフラインでも動作するシステムの実証実験が進んでいるという内容です。
一見すると、これは単なる防災DXの事例です。しかし、経営×ITの視点で見ると、ここには多くの企業が抱える根本的な課題が凝縮されています。
それは「本番環境で止まらないIT」が設計されていないという問題です。多くの企業は、平常時の業務効率だけを考えてシステムを導入します。しかし、本当に価値があるのは、トラブルが起きた時にも機能し続けるIT基盤です。
平常時と災害時を分ける発想の危険性
今回の避難所システムの特徴は、通信が途絶してもスタンドアロンで動作する点にあります。クラウドに依存せず、ローカルデータベースで受付を完結させる。これは、経営においても極めて重要な示唆を含んでいます。
多くの企業は「平常時はクラウド、災害時はバックアップ」という二段構えのIT戦略を取っています。しかし、この発想自体が危険です。なぜなら、災害は突然訪れ、システムの切り替えをスムーズに行えるとは限らないからです。
実際、ある中堅製造業の情シス担当者はこう話します。「BCP（事業継続計画）を策定しても、実際にシステムが使えなくなった時のリカバリ手順は紙ベースでしか残っていなかった。肝心な時に動かせる自信はない」と。
これは、ITを「管理IT」としてしか捉えていない典型例です。経営が「事業IT」として、売上や顧客対応に直結するシステムを本番環境で止めない設計をしていれば、この問題は防げたはずです。
経営者が考えるべき「オフライン・ファースト」の設計思想
避難所受付の事例が示すのは、システム設計の思想そのものを変える必要があるということです。
具体的には、以下の3つのポイントを経営者は押さえるべきです。
1. システムの可用性を「平常時」と「障害時」で分けて評価しない
多くの企業は、システムの稼働率を「99.9%」などと評価します。しかし、残りの0.1%の障害時こそが、顧客対応やオペレーションに致命的な影響を与えます。
経営者は、障害時も含めた「フルスペックでの可用性」をシステムに求めるべきです。具体的には、オフラインでも主要機能が動作する「オフライン・ファースト」の設計思想を、SaaS選定の条件に加えることを検討してください。
2. バックアップは「手段」ではなく「目的」として設計する
多くの企業は、データのバックアップを「取っておけば安心」という程度でしか考えていません。しかし、本当に必要なのは「バックアップから復旧できること」であり、その復旧手順が属人的であってはなりません。
たとえば、大手小売チェーンでは、POSシステムがダウンした際に、レジ担当者が手書きで伝票を書き、後日システムに手入力するという運用をしていました。これは、システムが止まった時の「運用」が設計されていない典型例です。経営者は、システムが止まった時の「業務プロセス」まで含めて、IT投資の効果を評価する必要があります。
3. 経営ITとして「再現性」を担保する
災害時はもちろん、日常的なトラブル（サーバーダウン、ネットワーク障害、サイバー攻撃）においても、業務を止めないためには「再現性」が不可欠です。
再現性とは、特定の担当者に依存せず、誰でも同じ手順で業務を継続できる状態を指します。これは、まさに経営ITの核心です。避難所受付のデジタル化が「紙の台帳」から脱却し、誰でも同じように受付を完了できるようにしたように、企業の基幹業務も、障害時に「誰がやっても同じ結果が出せる」状態を目指すべきです。
具体例：ある物流企業の「本番想定」の失敗
過去に、ある物流企業が倉庫管理システム（WMS）を刷新した事例があります。この企業は、クラウド型のWMSを導入し、コスト削減とリアルタイム在庫管理を実現しました。しかし、導入後半年で、データセンターの障害によりシステムが12時間停止する事態が発生しました。
その間、倉庫内のピッキング作業はすべてストップ。出荷が遅れ、取引先から多額の損害賠償請求を受けることになりました。この企業の経営者は、システム導入時に「障害時の代替手段」を全く考慮していなかったのです。
この事例が教えるのは、IT投資の判断基準に「障害時の業務継続性」を必ず含めなければならないということです。ツールの機能や価格だけでなく、「オフラインでも動くか」「障害時に代替プロセスが用意されているか」を評価軸に加えるべきです。
経営者が今すぐやるべき3つのアクション
では、経営者は具体的に何をすれば良いのでしょうか。以下の3つを提案します。
1. 基幹システムの「障害時運用マニュアル」を棚卸しする
情シス部門に任せきりにせず、経営自らが「システムが止まった時に、売上や顧客対応にどの程度の影響が出るか」を定量的に評価してください。その上で、復旧時間の目標（RTO：目標復旧時間）と、その間に実施する代替業務プロセスを定義します。
2. SaaS選定の評価項目に「オフライン機能」を追加する
新しいSaaSを導入する際は、必ず「通信が途絶えた時に、どの機能が使えるのか」をベンダーに確認してください。営業担当者は「99.9%の可用性」を謳いますが、残りの0.1%の時に何が起きるかを尋ねることが経営者の役割です。
3. 「経営IT」としての再現性を強化する
特定の担当者しか知らないシステム設定や運用ルールを、ドキュメント化し、標準化します。これは、災害時だけでなく、担当者の退職や異動による業務停滞を防ぐためにも有効です。具体的には、NotionやConfluenceなどのナレッジ管理ツールを導入し、誰でもアクセスできる状態を作りましょう。
まとめ：ITは「止まらないこと」が最大の価値
避難所受付のデジタル化が示すのは、ITは「便利なもの」である前に「止まらないもの」でなければならないという、当たり前でありながら見落とされがちな事実です。
経営者がIT投資を判断する時、つい「業務効率が何%向上するか」「コストがいくら削減できるか」に目が行きがちです。しかし、本当に問うべきは「そのシステムが止まったら、会社はどうなるのか」という問いです。
この問いに答えられないIT投資は、本番で機能しない「飾りのIT」に過ぎません。災害時でも、トラブル時でも、顧客に価値を提供し続けるためには、経営が直接「本番想定」を設計し、ITに組み込む必要があります。
あなたの会社のITは、本当に「止まらない」設計になっていますか？
