事業継続計画のためのアプリケーション重要度スコアリング

事業継続計画が失敗するのは、危機発生時ではなく、危機発生前の評価段階であることが最も多い。組織は事業影響度分析を実施し、復旧目標時間（RTO）を文書化し、包括的な復旧手順書を作成する。そして最悪のタイミングで、一見重要でないと思われていた従来の認証サービスが、eコマースプラットフォーム全体の単一障害点であること、優先度が低いと誰もが考えていたCOBOLバッチプログラムがリアルタイム決済検証サービスにデータを提供していること、あるいは同じ復旧階層に割り当てられた2つのアプリケーション間に、文書化されていない依存関係があり、順次復旧が不可能になっていることに気づくのだ。リスク評価は済​​んでいたが、依存関係は考慮されていなかった。

アプリケーションの重要度スコアリングとは、組織のポートフォリオ内の各アプリケーションに、重要度を定量的または段階的に評価するプロセスです。この評価によって、アプリケーションの復旧優先度、冗長化への投資レベル、変更管理要件、および災害復旧シーケンスにおける位置が決定されます。このスコアリングがビジネス影響度調査とアプリケーション所有者へのインタビューのみに基づいている場合、それは人々がアプリケーションについてどのように考えているかを反映しているにすぎません。一方、アプリケーションが実際に何をしているのか、誰が誰に電話をかけているのか、どのデータがどのプログラムを通過するのか、どの共有コンポーネントが複数の優先度の高いシステムのクリティカルパス上にあるのかといった構造分析に基づいている場合、それは運用上の現実を反映しています。

事業継続計画が失敗する原因は、信念と現実の間のギャップにある。

アプリケーションの重要度スコアリングが実際に測定するもの

重要度は単一の要素で表せるものではありません。エンタープライズアプリケーションの重要度スコアを決定するには、戦略的なビジネスニーズへの影響、ビジネスパートナーへの影響、顧客とのやり取り、他のエンタープライズアプリケーションへの影響など、エンタープライズアプリケーションの重要度や重要性を評価するためのユーザー入力を考慮に入れることができます。これらの各要素は、「重要」の意味の異なる側面を捉えています。

ビジネスへの影響とは、システムがダウンタイム1時間あたりに失う損失のことです。最も分かりやすいのは収益損失です。例えば、1時間あたり1,000万ドルを処理する決済処理システムの場合、停止1分あたりのコストは定量化できます。しかし、ビジネスへの影響は収益だけにとどまらず、規制上のリスク（システム停止によってどのようなコンプライアンス義務が発生するか）、評判の低下（顧客に直接的な影響があるか）、契約上のペナルティ（SLAによってペナルティ条項が発動されるか）などにも及びます。

運用上の依存関係とは、このアプリケーションに依存している他のシステムやプロセスの数を指します。直接的なビジネスへの影響が低いアプリケーションでも、直接的な影響が大きいアプリケーションの依存関係パスにある場合、重要度が高くなることがあります。他のすべての顧客向けアプリケーションを有効にする認証サービスは、その機能自体が示唆する以上に重要です。

復旧の複雑さとは、アプリケーションの復旧がどれほど困難で時間がかかるかを示す指標です。ビジネスへの影響が中程度で復旧に48時間かかるアプリケーションは、ビジネスへの影響が大きく復旧に2時間かかるアプリケーションよりも、冗長性への投資額が多くなる可能性があります。これは、後者の方がダウンタイム全体のリスクが大きいためです。

規制上の義務とは、どのアプリケーションが規制上の継続性要件の対象となるかを示すものです。DORAの対象となる金融機関は、重要または不可欠な機能が特定の障害シナリオに耐えられることを証明しなければなりません。HIPAAの対象となる医療機関は、保護対象医療情報を含むシステムの可用性を保護しなければなりません。規制上の側面は、特定のアプリケーションに対するビジネス影響評価よりも優先される場合があります。

重要度スコアは、組織の具体的なリスク許容度、規制環境、およびビジネスモデルに基づいて重み付けされた、4つの側面すべてを総合的に評価したものです。

標準重要度階層

ほとんどのエンタープライズアプリケーションポートフォリオは、4段階の重要度モデルを採用しています。アプリケーションの重要度マトリックスにおける重要度のカテゴリは、ミッションクリティカル、ビジネスクリティカル、ビジネスオペレーション、および管理です。以下の定義は、ISO 22301（事業継続マネジメントシステム）および事業継続協会（BCI）の優良事例ガイドラインに準拠した、現在の業界慣行を反映しています。

ティア1：基幹業務に不可欠なアプリケーション。障害が発生すると、基幹業務が即座に停止するか、許容できない規制リスクまたは安全リスクが生じる。目標復旧時間（RTO）：通常0～4時間。目標復旧時点（RPO）：通常0～1時間。例：基幹銀行取引処理、リアルタイム取引システム、緊急指令システム、産業制御インターフェース、決済承認システム。これらのアプリケーションには、アクティブ/アクティブ冗長構成、RPOゼロのレプリケーション、自動フェイルオーバー、最も厳格な変更管理など、最高レベルのインフラ投資が正当化される。

ティア2：業務上重要なアプリケーション。障害が発生すると業務運営に重大な支障をきたすが、直ちに停止するわけではない。目標復旧時間（RTO）：通常4～24時間。目標復旧ポイント（RPO）：通常1～4時間。例：CRMシステム、ERPモジュール、受注管理システム、給与計算期間中の人事システム、規制当局への提出期間中の報告システム。これらのアプリケーションは、高可用性インフラストラクチャ、定期的なフェイルオーバーテスト、および優先順位付けされた復旧シーケンスを必要とします。

ティア3：業務運営を支える業務アプリケーション。一時的な利用不能状態は手動による回避策で対処可能。復旧時間目標：通常24～72時間。復旧ポイント目標：通常4～24時間。例：社内コラボレーションツール、顧客向けではないレポート作成ツール、管理ポータル、トレーニングプラットフォーム。標準的なバックアップおよび復旧手順が適切。

ティア4：管理機能をサポートする管理アプリケーション。運用に直接的な影響はありません。復旧時間目標：通常72時間以上。復旧ポイント目標：24時間以上または最後のバックアップ。例：社内ドキュメントWiki、重要度の低い開発ツール、履歴レポート。バックアップからの復元は、必要に応じて行います。

ティアの割り当ては永続的なものではありません。年間を通してほとんどの期間ティア3に分類されているアプリケーションでも、月末の決算処理期間、規制報告期間、または繁忙期にはティア2になる場合があります。運用カレンダーに基づいてティアの割り当てが変化する動的な重要度は、成熟したBCPプログラムを持つ組織が、基本となるティア構造を確立した後に導入する改良点です。

採点方法：次元を数値に変換する

構造化されたスコアリング手法では、4つの重要度次元を数値スコアに変換し、組織内の政治的な思惑ではなく、客観的に階層分けを決定します。以下の手法では、加重基準を用いて0～100の複合スコアを算出します。

次元1：ビジネスへの影響（比重：35％）

ダウンタイム1時間あたりの収益への影響	スコア
時給1万ドル以上	35
時給1万ドル～100万ドル	28
時給10ドル～100ドル	21
時給1ドル～10ドル	14
時給1ドル未満	7
直接的な収益への影響なし	0

規制上の影響（DORA、HIPAA、PCI-DSS、SOXコンプライアンス義務など、停電によって発生するもの）は、この項目に最大10ポイント加算されます。

次元2：運用上の依存性（重み：30％）

ファンイン：このアプリケーションに依存するアプリケーション	スコア
20を超える依存アプリケーション	30
10～20件の依存アプリケーション	24
5～9件の依存アプリケーション	18
2～4件の依存アプリケーション	12
1つの依存アプリケーション	6
扶養家族なし（単独）	0

ここでいうファンインカウントとは、構造的な依存関係を示すカウント、つまりこのアプリケーションを呼び出す、その出力を読み取る、またはそのデータに依存するアプリケーションの数を指し、ユーザー数や認識されている重要度を指すものではありません。この指標は、アプリケーションの所有者が下流のすべての利用者を把握していないため、調査において最も頻繁に誤算されるものです。

次元3：復旧の複雑さ（重み：20％）

事前構築済みの災害復旧（DR）なしの場合の推定復旧時間	スコア
> 72時間	20
24-72時間	16
8-24時間	12
2-8時間	8
<2時間	4
自動フェイルオーバー（15分未満）	0

次元4：データの機密性と規制上の義務（重み：15％）

データ分類と規制要件	スコア
明確な復旧時間義務を伴う規制対象の個人情報（PII）／保護医療情報（PHI）／CHD	15
特定の復旧時間義務のない規制対象データ	12
機密性の高い社内データ（企業秘密、財務記録）	9
内部運用データ	6
機密性の低い内部データ	3
データは保存されていません	0

総合スコアとティアのマッピング：

複合スコア	階層割り当て
75-100	ティア1、ミッションクリティカル
50-74	ティア2、ビジネス上重要な
25-49	ティア3、ビジネスオペレーション
0-24	ティア4、管理部門

依存関係の問題：アンケートに基づくスコアリングがなぜ間違っているのか

運用上の依存関係という側面は、最も誤算されやすく、また誤算した場合の影響も最も大きい。一見重要でないように見える従来の認証サービスが、eコマースプラットフォーム全体の単一障害点となり、その障害によってすべての収益を生み出す取引が停止してしまう可能性がある。このプロセスは、抽象的な脅威から、サービスレベル契約に対する具体的で測定可能な影響へと移行する。

アプリケーションの所有者は、自身が呼び出すシステム、つまり直接の上流依存関係を把握しています。しかし、それらを呼び出すシステム、つまり下流依存関係全体を把握していることは稀です。例えば、内部ユーザー認証サービスは、所有者からは重要度の低いサービス（収益を生み出さない、シンプルな、めったに障害が発生しない）と見なされるかもしれませんが、実際には、すべてティア1に分類される12個の顧客向けアプリケーションから依存されています。認証サービスの実際の重要度はティア1ですが、それは認証サービス自体の機能によるものではなく、上位ティアシステムの依存関係グラフにおける位置によるものです。

アンケートに基づく重要度評価では、このようなエラーが体系的に発生します。アプリケーション所有者へのアンケートで「このアプリケーションの重要度はどのくらいですか？」と尋ねます。認証サービスの所有者は、サービス自体の機能に基づいて「低～中」と回答します。一方、依存する12のアプリケーション所有者は、認証サービスに関するアンケートには回答せず、自身のアプリケーションに関するアンケートに回答します。そのため、依存関係が正確に把握されることはありません。

その結果は復旧順序に現れます。BCPは調査結果に基づく重要度スコアに基づいて復旧順序を定義し、認証サービスはティア3の復旧対象としてスケジュールされます。しかし、実際のインシデント発生時には、最初に復旧すべきティア1アプリケーションは、依存する認証サービスが復旧していないため復旧できません。復旧シーケンスは、最も重要な依存関係の段階で失敗します。

調査で見落とされがちな3つの依存関係の種類：

隠れた共有コンポーネント。調査ではコンポーネントを共有しているとは特定されなかったものの、3つの異なる業務プロセスで通貨換算を処理する内部COBOLプログラムは、3つすべての業務プロセスの復旧に影響を与える隠れた依存関係です。通貨換算プログラムがティア3で、3つの業務プロセスのいずれかがティア1の場合、通貨換算プログラムの実質的な重要度はティア1となります。

データパイプラインの依存関係。他のアプリケーションからバッチ処理されたデータを利用するアプリケーションは、リアルタイムではなく時間的な依存関係を持ちます。リスクは同時障害ではなく逐次障害です。下流のアプリケーションは復旧しますが、データソースが同じ復旧ポイントに復元されていないため、古いデータに対して正しく動作しているように見えます。この種の依存関係は、データフロー自体をトレースしない限り、ネットワークトポロジーマップやコールグラフ分析には表示されません。

構成とスキーマの依存関係の共有。データベーススキーマ、構成サービス、またはIDプロバイダを共有するアプリケーションは、直接呼び出しを行わない場合でも、暗黙的な依存関係を持ちます。共有データベースのスキーマ変更は、複数のアプリケーションに影響を与える可能性があります。スキーマ破損後に1つのアプリケーションのみを復旧し、そのスキーマを共有するすべてのアプリケーションを復旧しない場合、アプリケーションポートフォリオ全体で一貫性のない状態が発生します。

BCP統合：重要度スコアが復旧決定にどのように影響するか

重要度スコアは、6つの具体的なBCP設計上の決定事項への入力となる。

1. 復旧順序の定義。アプリケーションは重要度順に復旧します。ティア1がティア2より先に復旧し、ティア3より先に復旧しますが、ティア内では依存関係グラフによって順序が決定されます。インバウンド依存関係のないアプリケーション（他のアプリケーションが依存していないアプリケーション）は、ティア内で任意の順序で復旧できます。ファンインの高いアプリケーションは、ティア内での相対的なスコアに関係なく、依存するアプリケーションより先に復旧する必要があります。したがって、復旧順序は、各ティア内の依存関係制約付きサブシーケンスにティア順序を適用したものです。

2. RTOとRPOの目標設定。重要度スコアによってRTOとRPOの目標が調整されます。各本番アプリケーションの最大許容ダウンタイム（MTD）とリカバリポイント目標（RPO）は、継続性戦略全体の技術的な基盤となります。MTDは、アプリケーションが利用できない状態をビジネスが許容できる最大時間です。RTOはMTDよりも短くなければなりません。RTOとMTDの差は安全バッファです。ダウンタイム1時間あたりのビジネスへの影響が大きいティア1アプリケーションは、MTD/RTOの差が小さく、高速な自動復旧に対応したインフラストラクチャが必要です。

3. インフラストラクチャ投資の調整。重要度スコアは、DRインフラストラクチャ投資の意思決定に直接影響します。ティア1アプリケーションは、アクティブ/アクティブのマルチリージョン冗長構成が正当化されます。ティア2アプリケーションは、テスト済みのフェイルオーバーを備えたアクティブ/パッシブ構成が正当化されます。ティア3アプ​​リケーションは、文書化された復元手順を備えた定期的なバックアップが正当化されます。ティア4アプリケーションは、標準的なバックアップポリシーに依存できます。重要度スコアがない場合、インフラストラクチャ投資の意思決定は、一律の過剰投資（高コスト）または一律の過少投資（リスク）のいずれかに陥ります。

4. 変更管理要件。重要度スコアの高いアプリケーションには、より厳格な変更管理が必要です。具体的には、変更凍結期間の延長、承認者の増加、変更前のテストの徹底、ロールバック手順の厳格化などが挙げられます。ティア1の変更管理をティア4のアプリケーションに適用すると、エンジニアリング時間の無駄になります。ティア4の変更管理をティア1のアプリケーションに適用すると、許容できないリスクが生じます。

5. テストと検証の頻度。BCPでは、復旧手順の定期的なテスト、机上演習、コンポーネントレベルのフェイルオーバーテスト、および完全な災害復旧シミュレーションが求められます。テストの頻度は重要度スコアによって決まります。ティア1アプリケーションは四半期ごとのDRテスト、ティア4アプリケーションは年1回のテストが必要です。すべてのアプリケーションを同じ頻度でテストすることは、現実的でも必要でもありません。

6. ベンダーSLA要件。サードパーティサービスに依存するアプリケーションの場合、重要度スコアによって、ベンダー契約に含めるべきSLA要件が決まります。RTOが4時間のティア1アプリケーションでは、そのRTOに沿った可用性を保証するサードパーティSLAが必要です。ティア4アプリケーションでは必要ありません。

レガシーシステムの複雑さ

レガシーシステムは、最新のアプリケーションポートフォリオ管理フレームワークでは十分に対応できない方法で、重要度評価を複雑化させます。標準的な重要度評価では、アプリケーションの所有者が、アプリケーションの動作と、誰がアプリケーションに依存しているかを把握していることを前提としています。しかし、レガシーシステム、つまり複数の世代の開発者によって保守されてきたCOBOLプログラム、依存関係が最後に文書化されたのが2008年のJCLジョブストリーム、組織内で現在働いている誰も作成していないプロセスによって使用される出力ファイルを生成するRPGプログラムなどでは、この前提は成り立ちません。

レガシーシステムの実際の依存関係構造は、コード自体の中にしか見えません。12個の下流プログラムが読み込むデータセットに書き込むCOBOLプログラムには、12個の下流依存関係がありますが、この事実はCOBOLプログラムの所有者には知られていない可能性があります。所有者はプログラムの機能（日々のトランザクションを処理する）しか認識しておらず、その構造的な役割（他の12個のプロセスを可能にするデータセットを生成する）には気づいていないからです。

レガシーシステムの場合、重要度スコアリングにおける依存関係の次元は、所有者へのアンケート調査ではなく、コード分析によって評価する必要があります。COBOLプログラムのファンイン数は、環境内の他のすべてのプログラムを調べ、最初のプログラムの出力データセット、呼び出し規約、または共有コピーブックを参照しているプログラムを特定することによってのみ算出できます。このような分析は構造化コード分析プラットフォームが提供するものであり、これがなければ、レガシープログラムに割り当てられた重要度スコアの依存関係の次元は、せいぜい推測に過ぎません。

レガシーアプリケーションの重要度を誤って判断した場合の影響は特に深刻です。なぜなら、レガシーシステムは、非常に重要である（多くの場合、数十年にわたって蓄積されたコアビジネスロジックが含まれている）一方で、評価が低い（所有者が何が依存しているかを明確に説明できないため、保守的なスコアを割り当ててしまう）傾向があるからです。その結果、実際にはティア1のビジネスプロセスのクリティカルパス上にあるレガシープログラムがティア3に分類され、実際のインシデント発生時の復旧シーケンスの障害モードと全く同じ状況が生じます。

認定条件 SMART TS XL 重要度スコアリングのための依存関係の証拠を提供する

SMART TS XL 本製品は、調査に基づくアプローチの信頼性が最も低いアプリケーション群において、アプリケーションの重要度評価における依存性という側面を直接的に扱っています。

アプリケーション依存関係マッピング機能は、環境内のすべての言語にわたる完全な依存関係グラフを構築します。つまり、他のすべてのプログラムを呼び出すすべての COBOL プログラム、下流プログラムで使用されるデータを生成するすべての JCL ジョブ ステップ、直接呼び出し合わないプログラム間に暗黙的な依存関係を作成するすべての共有コピーブック、プロデューサー プログラムとコンシューマー プログラム間を流れるすべてのデータセットが含まれます。このグラフは、重要度スコアリングの依存関係次元、ファンイン数、共有コンポーネントの識別、および調査では確実に把握できない隠れたデータ パイプラインの依存関係の構造的な根拠となります。

影響分析機能により、BCP計画のために依存関係グラフを照会できるようになります。ポートフォリオ内の任意のアプリケーションについて、直接的または間接的に依存し、したがって可用性要件を継承する他のすべてのアプリケーションを列挙します。直接依存するプログラムが3つ、間接的依存するプログラム（直接依存するプログラムに依存するプログラム）が20個あるCOBOLプログラムの場合、そのプログラムのクリティカルパスに含まれる23個のプログラムを反映した有効なクリティカル度を持つことになります。

静的コード解析機能は、リカバリの複雑性を示す構造的複雑性指標（循環的複雑性、結合度指標、デッドコード率、技術的負債指標など）を明らかにし、各アプリケーションのリカバリにかかる時間とリスクを予測します。複雑性が高く結合度が高いアプリケーションは、クリーンなアーキテクチャを持つ同等の機能を持つアプリケーションよりも復旧コストが高く、ディメンション3のリカバリ複雑性スコアも高くなります。

エンタープライズ検索機能により、BCPライフサイクル全体を通して依存関係インベントリ全体をクエリできます。特定のデータセットにアクセスするすべてのプログラム（その可用性に依存するすべてのプログラムを特定）、特定のコピーブックを共有するすべてのプログラム（その可用性の影響を受けるすべてのプログラムを特定）、特定のバッチウィンドウで実行されるすべてのJCLジョブ（ウィンドウ開始前にリカバリする必要のあるすべてのプログラムを特定）を検索できます。この検索機能は、アプリケーションポートフォリオの進化に合わせてスコアを最新の状態に保つための更新プロセスである、年次の重要度スコアレビューをサポートします。

組織が実施する場合 レガシーの近代化 BCP開発と並行するプログラム、 SMART TS XLの分析は、両方の目的を同時に果たします。重要度スコアリングの基準となる依存関係マップは、移行の順序も決定し、復旧の複雑性スコアリングの基準となる複雑性指標は、近代化の作業量の見積もりも決定します。

スコアを最新の状態に保つ：年次レビューサイクル

事業継続性成熟度評価は、現状把握、最も重要なギャップの特定、そして現実的な改善計画の策定という3つの点で役立ちます。これこそが、成熟度評価をより効果的なプログラムへと変える鍵となります。

組織の変化に伴い、アプリケーションの重要度スコアは現実から乖離していく。新しいアプリケーションが追加され、古いアプリケーションは廃止されるものの、完全には停止されない。これまで依存関係のなかったアプリケーション間で統合が構築される。ビジネスプロセスが変化し、それに伴い依存するアプリケーションも変化する。規制要件が進化し、新たな復旧義務が課される。

重要度スコアの年次レビューサイクルには、以下が含まれるべきである。

構造的な再分析。依存関係マッピングを再実行し、前回のレビュー以降に導入された新たな依存関係を特定します。スタンドアロンだったアプリケーションは、依存関係によって重要度が上昇している可能性があります。一方、依存度が高かったアプリケーションは、利用者が新しいシステムに移行したことで重要度が低下している可能性があります。

事業への影響の再評価。事業の成長とアプリケーションポートフォリオの進化に伴い、収益と運用への影響に関する数値は変化します。3年前には1時間あたり1,000ドルの事業価値を扱っていたアプリケーションが、事業の成長に伴い、現在ではその10倍の価値を扱っている可能性があります。

復旧テスト結果の組み込み。DRテストでは、想定される復旧の複雑さと実際の復旧の複雑さとの間にギャップがあることが明らかになります。初期評価で復旧の複雑さのスコアが低かったアプリケーションは、机上演習で性能が悪かった可能性があり、スコアの上方修正が示唆されます。

規制変更の見直し。新たな規制、または既存の規制の変更により、特定のアプリケーションに対して新たな復旧時間義務が課される場合があります。例えば、DORA規制におけるEU金融機関向けの運用回復力要件は、「重要または不可欠な機能」に対して特定のRTO義務を課しており、これはDORA施行前の重要度スコアには反映されていない可能性があります。

成熟したBCPプログラムを持つ組織は、重要度スコアリングを一度限りの作業ではなく、継続的なプロセスとして捉えています。アプリケーションの依存関係、ビジネスへの影響、または規制上の義務に重大な変更が生じた場合、スコアは更新され、構造化されたレビューを通じて毎年検証されます。

スコアは、その依存関係を示す証拠の質によってのみ評価される。

アプリケーションの重要度評価は、依存関係の側面がアンケート調査ではなく構造的な証拠に基づいている場合に最も価値を発揮します。ビジネスへの影響と規制上の義務の側面は、インタビューやビジネスプロセス分析を通じて確実に評価できます。しかし、運用上の依存関係の側面は、各アプリケーションが何に依存しているかを把握する必要があるため、評価できません。アプリケーション所有者は、下流の利用者を体系的に過小評価する傾向があるからです。

障害モードは予測可能です。調査から得られた重要度スコアに基づいて構築された復旧シーケンスが、隠れた依存関係で失敗します。レガシー認証サービスは復旧が遅れます。COBOL通貨換算プログラムは、それに依存するアプリケーションが復旧を試みる際にオフラインになっています。共有データベーススキーマは、そこから読み取るアプリケーションとは異なる復旧ポイントにあります。これらの障害は、構造分析によって得られる依存関係の証拠によってそれぞれ防止できますが、机上演習ではなく実際のインシデントで発生すると、それぞれが多大なコストを伴います。

採点方法は確立されている。枠組みも存在する。多くの組織が抱えるギャップは、採点枠組みそのものではなく、最も重要な側面に関するエビデンス基盤にある。次のインシデントで事業継続計画（BCP）の運用が必要になる前に、構造分析によってそのギャップを埋めるべきだ。