この記事のポイント
BCP規程の整備は内容が重複する複数の既存規程を整理する作業から始まりました。
既存規程の統合に加えて管理者研修で管理監督者が検討した内容を反映しました。文書の本数を減らしてMECEに近づけても「何をどこまで書くか」という別の粒度のMECE課題が残ります。わかりやすさを取ると重複が増えます。MECEを取ると参照が増えて使いづらくなります。どこまでBCP規程に書くかは有事の初動で開くかどうかで決めました。実用性を重視し、あえてMECEを崩した箇所もあります。
MECEは絶対の目標ではなく、実用性も含めて設計する事が必要です。
要点サマリ
ISMS規程と重複する内容をBCP規程にどこまで書くかを「有事の初動で開くかどうか」で線引きしました。
きっかけはISMS側のBCP関連規程と地震対応・災害復旧を扱う複数の既存文書が併存しており、内容の重複も生じていました。これらを整理し、あわせて管理者研修で検討した内容を反映して現行のBCP規程にまとめました。
ただし文書が2本ある以上、完全に重複を無くす事は避けられません。MECEを重視すれば参照だらけで使いにくくなり、わかりやすさを重視すれば二重管理が多くなります。
そこである一定のルールとその目的を設けて、部分的な二重管理は許容する事にしました。
用語解説
- BCP(事業継続計画): 地震・システム障害等の緊急事態が起きても、重要業務を止めない、または早期に復旧させるための計画・規程。
- ISMS: 情報セキュリティマネジメントシステム。情報資産の管理・保護に関する社内規程・運用の枠組み。
- MECE: Mutually Exclusive, Collectively Exhaustive(相互に排他的、かつ全体として網羅的)の略。重複がなく、かつ抜け漏れがない分類・整理の考え方。
- 相互排他性: MECEの前半部分。同じ内容を複数箇所に重複して書かないこと。
- 網羅性: MECEの後半部分。想定すべき事態や項目に抜け漏れがないこと。
- 発動基準: BCPを発動するかどうかを判断するための条件。「震度がいくつ以上」のように、誰が読んでも同じ判断になる形で定めるもの。
- 南海トラフ地震臨時情報: 南海トラフ地震の発生可能性が普段より高まったと評価された場合に気象庁が発表する情報。地震が起きる前の段階で警戒を促す仕組み。
規程を何本にまとめたか
もともと社内にはISMS側のBCP関連規程(緊急時対応規程等)に加えて地震対応の出社基準や災害復旧対応を個別に定めた複数の既存文書も存在し、一部はISMSと内容が重複していました。
一本化に踏み切ったきっかけは2026年5月15日に開催した危機管理対応管理者研修会です。
管理監督者を3班に分け、大地震による本社被災・サーバ室発火によるデータ消失・感染症のまん延という危機シナリオを設定し、参加者は取締役や営業部長といった役割を担当してロールプレイング形式で対応を検討しました。実際のシナリオに沿って動いてみると既存の文書のままでは有事に使いにくいという課題が具体的に見えてきました。
出典: 「危機管理対応管理者研修会」を開催しました。 – アサミ情報システム株式会社｜GIS/3D/CityGML
整理の対象にした既存文書と研修で得られた検討結果は次のとおりです。
| 規程名 | 内容 |
|---|---|
| ISMS関連規程(緊急時対応規程、情報システム管理規程ほか) | 緊急時の指揮命令系統と連絡体制、情報システム管理と情報セキュリティ全般 |
| 地震災害対応の出社規定(2021年制定) | 地震発生時に誰がどの基準で出社するかの判断基準 |
| 災害復旧支援マニュアル(2018年制定) | 被災後の復旧作業の進め方と支援体制 |
| 管理者研修検討結果(2026年5月) | 大地震による本社被災・サーバ室発火によるデータ消失・感染症のまん延の3シナリオについて管理監督者が検討した対応内容 |
これらを整理して最終的にISMS規程とBCP規程の2本構成に集約しました。
想定リスク・発動基準・部門別の対応チェックリストのようにBCP規程の該当章とほぼ同じ内容を書いていた文書は統合して廃止し、ISMS規程側の内容は基本的には参照する形にしました。
研修結果の章立てへの反映
研修はリスク別に班を分けて実施し、研修の検討結果を規程に反映する際にシナリオをそのまま章にはしませんでした。しかし検討内容を並べてみると複数のシナリオに共通して出てくる対策がありました。
研修班と規程の反映箇所の対応は次のとおりです。
| 研修の班(シナリオ) | 検討で出てきた主な対策 | 規程での置き場所 |
|---|---|---|
| 大地震による本社被災 | 部門ごとの動き方 | 部門別の対応チェックリスト |
| サーバ室発火によるデータ消失 | 復旧の優先順位 | 部門別の対応チェックリスト |
| 感染症のまん延 | リモートワークへの移行 | 独立した章(発動事由に紐づけない) |
例えばリモートワークへの移行は感染症の班が検討した内容でしたが、地震で出社できない場合にもサーバー障害で執務環境が使えない場合にも同じように必要になります。感染症の章に書き込むと他のシナリオで発動したときに読まれません。
そこで発動事由に紐づけずリモートワーク自体を独立した章として切り出しました。
このように研修でリスク別に検討した内容を規程では機能ごとの章に組み替えています。
リスク別の章立てだけで規程を作ると共通する対策が複数の章に重複し、すでに相互排他性をどう確保するかという問題に直面していました。
MECEとわかりやすさの綱引き
文書の本数を2本に減らした後に出てきたのが、ISMSが既に定めている内容をBCP規程側でどこまで書くかという問題です。
わかりやすさを重視するとISMS規程に書いてある内容と同じことをBCP規程にも書くことになります。
読み手はBCP規程だけ開けば完結します。有事にISMS規程を探しに行く手間もありませんが、これは二重管理になります。ISMS規程を改定するたびにBCP規程側の記載とズレていないか確認する手間が発生します。
MECEを重視しすぎるとBCP規程はISMS規程への参照だらけになります。重複はなくなります。
しかし有事に複数の文書を行き来する必要が生じて使いづらい規程になります。
| 選択 | メリット | デメリット |
|---|---|---|
| MECEを重視(参照に留める) | 二重管理を避けられる。ISMS規程を改定してもBCP規程側の記載とズレない | 有事にISMS規程を別途開く必要がありBCP規程だけでは完結しない |
| わかりやすさを重視(重複して書く) | BCP規程だけで有事の対応が完結し読み手が別文書を探す手間がない | ISMS規程を改定するたびにBCP規程側の記載とズレていないか確認する手間が発生する |
BCP規程は平常時の管理文書ではありません。非常時に手元に置いて見ながら動くための文書です。
ISMS規程は緊急対策本部の設置基準や指揮命令系統を定めた危機管理体制の正本であり、BCP規程はその体制のもとで現場が実際に動くための手順書にあたります。
役割が異なるため、一刻を争う場面で現場が手を動かす内容は両方に必要になります。
そこで、発動基準や初動対応手順はISMS規程と重複してもBCP規程本体に書き、改定手続きや管理責任の所在は参照に切り分けました。ISMS規程を改定する際は、BCP規程側に転記した該当箇所も突き合わせて更新する運用とし、二重管理のズレが放置されない仕組みにしました。
あえてMECEを崩した実例
MECEを絶対視しなかった実例もあります。
BCP規程にはどういう事態が起きたらBCPを発動して誰がどう動くかをリスク別に定めた部分があります。
地震については観測された震度が一定以上になった場合に発動するという基準を置くことで、地震のリスクは一通りカバーできているはずでした。
ところが南海トラフ巨大地震は同じ地震でも想定される事態が質的に違います。
津波・数日以上に及ぶ停電・長時間の通信制限・鉄道のほぼ全線停止。震度で発動して参集を判断する通常の地震対応をそのまま当てはめると津波警報が出ている最中に従業員を移動させかねません。
さらに南海トラフ地震には気象庁が発生前に「臨時情報」として警戒を呼びかける仕組みがあります。まだ揺れていない段階での事前準備が必要になる点も震度を基準にする限り条文にできませんでした。
出典: 「南海トラフ地震に関連する情報」について | 気象庁
そこで南海トラフ巨大地震だけを独立した対応手順として切り出しました。
発災直後から津波警報の解除まで・解除後72時間まで・72時間以降という段階ごとに行動を定めています。
結果として地震というひとつのカテゴリの中に「震度を基準にした通常の対応」と「南海トラフ専用の段階的な対応」が併存する構造になりました。
これは厳密にはMECEが崩れた状態です。
想定漏れをなくす網羅性を優先するとカテゴリの相互排他性を犠牲にせざるを得ない場面があります。
崩したうえで手当てしたのはどちらを適用するかを条文に書いたことです。南海トラフ地震に起因する場合は通常の地震対応ではなく専用の手順を優先するという一行を入れました。
重複を残すなら重なった箇所で読み手にどちらに従うか迷わせない手当てがセットになります。
前段では「有事の初動で開くか」を軸にわかりやすさとMECEを使い分けました。ここでは同じ「地震」というカテゴリの中で網羅性を優先して相互排他性そのものを崩しています。
判断軸は一つに固定せず章ごとに何を優先するかを都度決めています。
BCP規程の全体構成
これまで述べた判断の結果、現行のBCP規程は次の構成になっています。
事業継続計画(BCP)規程
├─ 第I部 総則
│ ├─ 1. 目的
│ ├─ 2. 適用範囲
│ ├─ 3. 他規程との関係
│ └─ 4. 用語の定義
├─ 第II部 共通事項
│ ├─ 5. 緊急連絡体制と安否確認
│ ├─ 6. 緊急対策本部の設置と運営
│ └─ 7. リモートワーク体制の確立
├─ 第III部 リスク別対応(発動基準→対応手順)
│ └─ 8. リスク別対応
│ ├─ 8.1 南海トラフ巨大地震
│ ├─ 8.2 地震
│ ├─ 8.3 感染症まん延
│ ├─ 8.4 個人情報・機密情報漏洩
│ └─ 8.5 サーバー・システム障害
├─ 第IV部 組織別対応
│ └─ 9. 各部門の役割と行動チェックリスト
│ └─ 管理部 / 営業部 / 情報技術部
└─ 第V部 運用
├─ 10. 訓練・定期見直し
└─ 11. 廃止規程リモートワーク体制(7)を第II部の共通事項に置いたのが、研修のシナリオ別検討を機能ごとに組み替えた結果です。南海トラフ巨大地震(8.1)と地震(8.2)が同じリスク別対応の中に並んでいるのが、網羅性を優先して相互排他性を崩した箇所にあたります。
FAQ
Q. MECEを完全に守ることは目指すべきですか。
目指す価値はありますが、絶対視すると使いにくい規程になります。
どちらを優先するかはその規程が有事にどう扱われるかを考える必要があります。
Q. この基準だと、BCP規程の大部分をISMS規程と重複させることになりませんか。
なりません。重複を許容するのは発動基準や初動対応手順のように有事の初動で実際に開く章だけです。
改定手続きや管理責任の所在といった管理的な条項はこれまで通りISMS規程側に一本化しています。線引きを「初動で開くかどうか」に絞ることで際限のない重複を避けています。
Q. 統合したBCP規程で、廃止した旧文書の記載漏れをどう防ぎましたか。
旧文書の想定リスク・発動基準・対応チェックリストは要約して圧縮しませんでした。
項目単位を保ったままBCP規程の該当章に書き写しています。要約すると細部が落ちやすいため統合時は圧縮よりも移し替えを優先しました。
まとめ
今回のBCP規程は、内容が重複していた既存規程の整理と、管理者研修で管理監督者が検討した内容を元に作成しました。既存規程だけを組み替えても文書の整理で終わります。研修の検討結果だけを条文にすれば既存規程との重複が残ります。
文書の本数をまとめた後もBCP規程にISMSの内容をどこまで書くかという課題が残りました。
わかりやすさを取れば重複が増えます。MECEを取れば参照が増えます。
重複を許容する判断軸は「有事の初動で開くかどうか」としました。南海トラフ地震のように網羅性を優先してあえて相互排他性を崩した箇所もあります。MECEは絶対の目標ではありません。
どこで崩すかという判断まで含めて設計する事が必要です。
お問い合わせ
本記事に関するお問い合わせは、下記よりご連絡ください。