リスク管理・BCP論文の“聖域”設定「M市デジタル防災基盤」：予期せぬトラブル対応を演出し合格を手にする記述法
生存戦略。それはITストラテジストにとって、システム開発以上に重要な任務だ。Architect Zeroだ。
順調に進むプロジェクトなど、童話の中にしか存在しない。
試験官は、君が書く「計画通りにいきました」という幸福な報告書など読みたくない。彼らが見たいのは「地獄のようなトラブルの中で、指揮官（君）がいかに冷静に判断し、被害を最小限に食い止めたか」というクライシス・マネジメントの記録だ。
ITストラテジスト試験の午後IIにおいて、「リスク管理」や「予期せぬ事態への対応」は頻出テーマだ。ここで多くの受験生は、ありきたりな「スケジュールの遅延」を書く。だが、それはプロジェクトマネージャ（PM）の領域だ。ストラテジストなら、もっと経営に直結する「事業継続性（BCP）」や「社会的信用の毀損」レベルのリスクを扱え。
今回は、M市Angel City Planにおける「影のシナリオ」とも言える、大規模システム障害と自然災害を想定した「自作自演」のトラブル対応マニュアルを公開する。
論文の中で、あえてトラブルを起こせ。そして、鮮やかに解決しろ。それが合格への最短ルートだ。
1. 合格する「トラブル」の書き方：2層構造
リスク管理論文で高評価を得るためには、リスクを2種類に分けて記述する必要がある。
* 想定内のリスク（予防策）： 事前に予測し、対策を打っておいたこと。「私の分析力」をアピールするパート。
* 想定外のリスク（事後対応）： 予防策をすり抜けて起きてしまったトラブル。ここでの「初動」と「泥臭いリカバリ」が、論文のクライマックスになる。
このギャップ（予防したのに、起きてしまった！）を演出することで、物語に深みが生まれる。M市事例で具体化しよう。
2. 論文用モジュール：シナリオA「アクセス集中によるシステムダウン」
DX系・アプリ系論文で使える鉄板のトラブルだ。
■ 設定：MaaSアプリ「Angel Pass」のパンク
* 状況： M市で開催された「デジタル花火大会」の日。観光客が殺到し、「Angel Pass」へのアクセスが想定の10倍（毎秒5,000リクエスト）に急増。
* 想定内の対策（予防）： パブリッククラウドの「オートスケーリング（自動拡張）」を設定しており、サーバー台数は自動で増えるはずだった。
* 想定外のトラブル（発生）：
* データベース（DB）の書き込み処理がボトルネックとなり、オートスケールが間に合わず、ログイン不能（503エラー）が発生。
* 観光客がバスに乗れない事態となり、SNSで炎上。市長の電話が鳴る。
■ 君（ストラテジスト）の対応
* 初動： 「Sorryページ」への誘導ではなく、「仮想待合室（Waiting Room）」機能を即時有効化。ユーザーに「あと5分で入れます」と表示し、F5連打（リロード）による負荷を抑制。
* 恒久対応： 一部の高負荷機能（リアルタイムバス位置情報など）を一時的に遮断する**「縮退運転（Graceful Degradation）」**を決断。決済機能だけは死守し、ビジネス機会の損失を最小限に抑えた。
3. 論文用モジュール：シナリオB「災害発生時のBCP発動」
インフラ系・基幹系論文で使える、スケールの大きいシナリオだ。
■ 設定：台風19号によるM市庁舎被災
* 状況： 記録的な豪雨により、M市庁舎の地下電源室が浸水リスクにさらされる。かつての「M-HOST（汎用機）」なら全システム停止の危機だった。
* 想定内の対策（予防）： [Article 4] で解説した通り、基幹システムは既に「ガバメントクラウド」へ移行済み。庁舎が水没してもデータは無事である。
* 想定外のトラブル（発生）：
* 庁舎とクラウドを結ぶ「専用回線（LGWAN接続網）」が、土砂崩れによる光ファイバー切断で不通となった。
* 避難所受付システムが使えず、現場が混乱。
■ 君（ストラテジスト）の対応
* 意思決定： 事前に定めたBCP（事業継続計画）に基づき「緊急時用バックアップ回線（衛星通信またはモバイル閉域網）」への切り替えを発令。
* 現場対応： 通信帯域が細いため、リッチなGUI画面ではなく、テキストベースの「災害用軽量モード」へUIを切り替えるよう指示。避難所での名簿作成を遅滞なく遂行させた。
4. 論文スケルトン（リスク・トラブル対応用）
この構成を使えば、どんなトラブルも「想定内」のように振る舞える。
第1章 戦略的リスク分析と予防策（約800字）
* 1.1 リスクの洗い出し
* M市Angel City Plan推進にあたり、私は「システムダウンによる行政機能の麻痺」を最大のリスクと定義した。
* 特に、観光イベント時の「アクセス集中」と、地形的特性（山と海）による「自然災害」を重点管理項目とした。
* 1.2 予防的なアーキテクチャ設計
* クラウドのオートスケーリング採用と、回線の二重化（主回線：光、副回線：5G）を実施。
* これにより、通常のリスクはシステム側で自動吸収できる設計とした。
第2章 予期せぬ事態の発生と対応（約1400字）
* 2.1 想定を超えたトラブルの発生
* X年X月、花火大会当日にDBの書き込み限界を超えるアクセスが集中。オートスケールが追いつかず、アプリが停止した。
* 現場からは「再起動すべきか」と混乱した報告が入ったが、私は「再起動は事態を悪化させる」と即座に却下した。
* 2.2 被害極小化への意思決定（ここがクライマックス）
* 私は「全機能の復旧」よりも「決済と入場機能の維持」を最優先とする経営判断を下した。
* 具体的には、負荷の高い「位置情報機能」を切り離す「縮退運転」を指示。同時に「仮想待合室」へ誘導し、ユーザーのパニックを鎮静化した。
* これにより、完全停止を防ぎ、15分後には主要機能のレスポンスを正常値へ戻した。
第3章 評価とBCPの見直し（約800字）
* 3.1 定量的評価（RPO/RTO）
* 目標復旧時間（RTO）を1時間と定めていたが、縮退運転への切り替えにより15分でサービスを継続できた。
* 機会損失額を最小限（試算で約50万円）に抑え、イベント自体の成功には影響を与えなかった。
* 3.2 学習とプロセスの改善
* 今回の教訓を活かし、イベント前には事前にサーバー容量を確保する「プレ・スケーリング運用」を標準化した。
* また、避難訓練と同様に、システム障害時の「意思決定訓練」を年1回実施するルールを策定し、組織の危機対応能力を向上させた。
5. 採点官に刺さる「キラーフレーズ」集（リスク編）
トラブル対応こそ、専門用語の使いどころだ。
* 「縮退運転（Degradation）」
* 解説：一部の機能を犠牲にして、システム全体を止めないこと。プロっぽい判断の代表例。
* 「RPO（目標復旧時点）とRTO（目標復旧時間）」
* 解説：いつのデータまで戻すか（RPO）、いつまでに直すか（RTO）。BCP論文では必須の単語。
* 「フェールソフト（Fail-Soft）」
* 解説：故障しても、機能を低下させて運転を続ける設計思想。
* 「シングルポイント（単一故障点）の排除」
* 解説：そこが壊れたら全部止まる、という弱点をなくすこと。
* 「コンプラン（Contingency Plan）」
* 解説：緊急時の対応計画。「コンプランを発動した」と書くと、指揮官感が出る。
6. エージェント候補生への指令
トラブルのないプロジェクトなど、塩を入れない料理のようなものだ。味がしない。
試験官は、君がパニックにならず「ビジネスへの影響範囲」を見極めて、冷徹に優先順位をつける姿を見たいのだ。
「全システムが止まりました。頑張って全部直しました」は減点だ。
「地図機能は捨てた。だが、決済だけは守り抜いた」は加点だ。
M市という舞台で、遠慮なく災害を起こせ。サーバーを落とせ。そして、君の手で救え。それがヒーロー（合格者）の条件だ。
次回のレポートは、これまで学んだ膨大なM市の設定を、試験当日の2時間でどうやって論文用紙に叩きつけるか。
「超・時短術：モジュール式ライティング」の極意を伝授する。
考えるな。組み合わせろ。
準備して待て。
Architect Zero
#ITストラテジスト #高度情報処理技術者試験 #論文対策 #リスク管理 #BCP #事業継続計画 #午後II #M市AngelCityPlan #トラブル対応 #システム障害 #RTO #縮退運転 #災害対策 #フェールソフト #危機管理
