エグゼクティブサマリー

• 成熟した評価フレームワークの多くは、「影響度（Impact）」「緊急度（Urgency）」「範囲（Scope）」など共通の次元で問題の重大度や優先度を評価します。また、一部の手法では頻度（確率）や検出容易性、顧客価値など独自の指標も加味されています (weareitsm.com) (qhubio.com)。
• 各フレームワークは定量的な尺度や具体的基準を定め、評価の再現性を高めています。例えば5段階の定義リスト（「無視できる=1」〜「壊滅的=5」の影響度など） (resources.rework.com)や、数式によるスコア算出（CVSSの0〜10点やRICEの Reach×Impact×Confidence/Effort スコア (pmtoolkit.ai)）によって、一貫した評価が可能です。定義表や数値指標を公開することで、主観に頼らず客観的で説明可能な評点付けをしています。
• 不可逆性（リバーシビリティ）は多くのフレームワークで直接のスコア項目ではありませんが、判断時の考慮要素として質的に扱われます (resources.rework.com)。例えばAmazonでは、一度決めると戻せない「ワンウェイ扉」の決定は慎重に扱い、戻し可能な「ツーウェイ扉」は迅速に行うといった区別があります。同様に、機会コストや遅延のコストはプロダクト優先度の手法で重視され、WSJFでは**「遅延コスト」を数値化**して優先度を計算します (www.prodpad.com)。
• 影響範囲（ブラスト半径）は、ほぼ全てのフレームワークで重要視されています。例えばITILでは「単一ユーザ〜全社」までの範囲で影響度を階層化し (weareitsm.com)、インシデント管理では影響ユーザ数の割合で重大度を区分することが推奨されています (response.pagerduty.com)。一方、本稿のドラフト指標（被害ドメイン・影響範囲・不可逆性）には、緊急度（時間的猶予）や発生可能性の判断軸が含まれておらず、他フレームワークとの比較で不足が見られます。
• テキストから重大度を判定する際の注意点として、評価基準があいまいだと境界のブレやばらつきが生じやすいことが挙げられます。各フレームワークは短い記述からでも判断できるよう定義を明確化し、可能であれば**定量指標（例：影響ユーザX%以上で重大度High）**を用いることを推奨しています (response.pagerduty.com)。証拠に基づく判定には、テキスト中のキーワードや記述内容と評価基準がトレースできる仕組みが必須です。

1. 問題の重大度・価値を評価する指標（Dimensions of Severity/Worth）

各種フレームワーク（エンタープライズのリスクマトリクス、ITIL/ITSMのインシデント優先度、SREの障害SEV1-5区分、セキュリティCVSS、FMEAのリスク優先数RPN、プロダクト優先度のRICE/ICE/WSJF、Kanoモデルなど）では、評価に用いる**次元（評価軸）**として以下のようなものが用いられます：

• 影響度（Impact/Severity） – 事象が発生した場合のビジネスまたは技術的な影響の大きさを示す指標です (weareitsm.com) (weareitsm.com)。多くのフレームワークで中心となる軸で、金銭的損失、サービス中断、顧客への被害、信頼失墜、安全性への影響などを総合した「重大さ」を測ります。例えばリスク評価では「無視できる」から「壊滅的」まで5段階程度の影響度レベルを定義し (resources.rework.com)、インシデント管理でもSEV1（全ユーザ影響の重大障害）〜SEV5（ごく軽微な問題）といったランク分けで影響度を表現します (response.pagerduty.com) (response.pagerduty.com)。CVSSでも機密性・完全性・可用性への影響の程度をBaseスコア計算に含めており、総合的な深刻度を数値化しています（0.0＝影響なし、10.0＝深刻な影響） (nvd.nist.gov)。

• 緊急度・時間的猶予（Urgency/Time Criticality） – 対応の急迫度を示す軸です。ITIL/ITSMでは影響度と組み合わせてチケットの優先度を決定する要素で、*「対応がどれだけ急を要するか」*を測ります (weareitsm.com)。例えばビジネス上の締め切りや法遵守期限に直結する問題は緊急度が高く、逆に放置してもしばらく問題が表面化しないなら低く評価されます (weareitsm.com)。「顧客への影響がいつ現れるか」「重大なイベント（例: セール期間やリリース直前）に差し迫っているか」など時間要因を考慮します。WSJFなどアジャイルの手法では「Time Criticality」として定量評価し、今すぐ着手しないことによる価値損失（コスト）を点数化します (www.prodpad.com)。この軸は問題を先延ばしにすることで失われる機会や被害を評価し、優先度を高める要因となります。

• 規模・範囲（Scope/Blast Radius） – 影響が及ぶ範囲の広さです (weareitsm.com)。どの範囲のユーザやシステムが被害を受けるかを評価軸にします。例えば「個人1名のみ」「チームや部署内」「一つの製品機能全体」「プロダクト全体」「多数の顧客」「全社的/事業継続に関わる規模」などの段階があります。インシデント管理では影響ユーザ数やサービス範囲でSEVレベルを決めるケースが多く、PagerDutyの推奨では「定義を各社のユーザ数割合など定量的指標に落とし込む」ことが挙げられています (response.pagerduty.com)。ITILにおける影響度定義も「単一ユーザ vs 部門 vs 全社」など影響範囲の広がりで区分されます (weareitsm.com)。リスクマトリクスでも影響度レベルを決める際に「プロジェクト全体が失敗する」「一部に遅れが出る」等、影響が及ぶ組織やプロジェクトの範囲で差別化しています (resources.rework.com)。

• 発生確率・頻度（Likelihood/Frequency） – 問題が現実化する見込みの高さです。主にリスク管理の文脈で用いられ、Impactと組み合わせてリスクの深刻度を評価する軸の1つです 。定性的には「ほとんど起こらない（Rare）〜ほぼ確実（Almost Certain）」のように5段階で表し、確率の定義も「10%未満」等の具体値で示されます (resources.rework.com)。FMEAでは「Occurrence（起こりやすさ）」として過去の不具合発生率データなどに基づき1〜10で評価します (qhubio.com)。たとえば「10＝頻発（10%以上の確率）」「1＝極めてまれ（0.001%以下）」と定量的な発生率を基準にします (qhubio.com)。なお、インシデント対応や既知の不具合評価では「既に問題が発生している前提」のため確率の概念は薄れ、主にリスク予測・予防段階で重要な次元となります。

• 検出容易性（Detectability） – FMEAに特徴的な次元で、問題が事前に検知・対策できる可能性を示します。1〜10の尺度で「現行管理で発見可能か否か」を評価し、発見が困難な問題ほどリスクが高いと見做します (docs.helpmasterpro.com)。例えば「1＝確実に検出可能（例：自動アラートで直ちに検知）」、逆に「10＝検出ほぼ不可能（ユーザからのクレームでしか発覚しない）」と設定されます。この軸は問題が潜伏して被害を拡大させるリスクを示し、FMEAのRPN算出ではSeverity×Occurrence×Detectionの積で優先度を決める重要要素です (www.proactivanet.com) (wiki.en.it-processmaps.com)。他のフレームワークでは明確な検出性尺度は少ないですが、Confidence（確信度）という形で現れることがあります。例えばRICEスコアリングの「Confidence」は見積もりや予測の信頼度を%で表し、不確実性が高い案件は優先度を下げるよう調整します (pmtoolkit.ai)。これは間接的に、「問題の深刻度が推測に頼っていないか」を評価する次元と言えます。

• 費用対効果・メリット（Value/Benefit） – 解決した際の価値や放置した際の損失を評価する軸です。プロダクトの優先順位付けではImpactを「ユーザ価値・ビジネス価値」に読み替え、解決がもたらす効果の大きさとして扱います。RICEのImpactは「あるユーザに与える効果の大きさ」を定性的ランク（0.25=最小〜3=極大）で示し (pmtoolkit.ai)、ICEやWSJFでもビジネス価値やユーザへの寄与として類似の概念をスコア化します (www.prodpad.com)。Kanoモデルでは価値の次元が独特で、機能や要求をユーザ満足度への寄与類型で分類します。具体的には「必須要素（Must-be）: 無いと激しく不満だが有っても当然と受け取られる基本機能」「一元的要素（Performance）: 充実するほど比例して満足度が上がる機能」「魅力的要素（Delighter）: 無くても気づかれないが有れば大きく満足度が向上する機能」等のカテゴリに分け、各機能の潜在的価値を評価します。このように、問題や要求が提供し得る価値の種類と大きさもフレームワークごとに考慮される重要な次元です。

• コスト・労力（Cost/Effort） – 問題解決に必要なリソースや時間ですが、問題の重大度そのものというより対応の優先度を決める際に組み合わされる軸です。RICEやICEではEffort（労力）を見積もり、例えば「1人が1ヶ月で実装=4週間」のように人月やポイントで定量化します (pmtoolkit.ai)。WSJFでは「Job Size（作業規模）」として処理時間を評価し、Cost of Delay（遅延コスト）との比率で優先度を算出します (www.prodpad.com)。問題の深刻度評価という文脈では直接的な指標ではありませんが、限られたリソース配分の現場では価値（Impact等）と労力（Effort等）のバランスで「割に合うか」が判断されるため、優先度フレームワークでは取り入れられています。ただし質問にある通り、本分析の範囲は「問題が解決に値するか」の価値側であり、コスト側（解決難易度）は別途意思決定プロセスで扱われるものとします。

以上のように、各フレームワークは複数の次元を組み合わせて問題の重大度・優先度・価値を評価しています。共通して頻出するのは「影響の大きさ」「緊急性（時間軸）」「影響範囲」の3点で、それに各ドメイン固有の次元（発生確率、安全検出性、顧客価値など）が付加される傾向があります (weareitsm.com) (qhubio.com)。逆に独自色の強い次元としては、Kanoモデルの満足度類型のようにユーザ心理的な価値を扱うもの、FMEAの検出性のようにプロセス上の管理可能性を扱うものなどが挙げられます。各フレームワークの目的（リスク管理、IT運用、セキュリティ脆弱性評価、品質工学、プロダクト管理など）に応じ、共通項と固有項が組み合わされているのが実情です。

2. 評価スケールと具体的基準（Rating Scales and Criteria）

主要なフレームワークごとに、各指標をどのような尺度で評価し、客観性・再現性を担保しているかを解説します。以下に各枠組みの評価尺度と基準定義の例を示します：

• エンタープライズのリスクマトリクス（確率×影響度）: リスク評価では確率（Likelihood）と影響度（Impact）をそれぞれ3〜5段階の定性的尺度で評価し、その組み合わせ（例えば5×5の25マス）でリスクレベルを算出します (resources.rework.com) (resources.rework.com)。例えばISO 31000に沿った典型的5段階では、確率は「Rare（1）: 10%未満、滅多に起こらない」〜「Almost Certain（5）: 75%以上、高い確度で起こる」 (resources.rework.com)。影響度は「Negligible（1）: 軽微な支障、コスト・納期・品質に影響なし」〜「Catastrophic（5）: 壊滅的、プロジェクト失敗や重大な損失」 (resources.rework.com)。各レベルに定義表や例示が用意されており、評価者はそれに照らして数値を割り当てます。スコアは数値の積 (Probability×Impact) や合計で計算し、閾値により「高リスク（赤）」「中リスク（黄）」のゾーンに分類します (resources.rework.com)。評価者の主観ブレを防ぐため、シナリオに即したアンカーテキスト（定義文）を参照する運用が推奨されます。例: *「プロジェクト目標に大きな支障を及ぼす可能性あり」*と記述されたリスクならImpact=4（Major）に相当する、といった具合です (resources.rework.com)。これにより、同程度のリスクは誰が評価しても同じランクになる再現性を目指しています。

• ITIL/ITSMのインシデント優先度（Impact×Urgency）: ITサービス管理では、影響度（Impact）と緊急度（Urgency）の2軸を高・中・低などランク付けし、その組み合わせで優先度（Priority）を決定します (weareitsm.com) (weareitsm.com)。通常は優先度マトリクスを用意し、例えば「影響度：高×緊急度：高」の組み合わせはP1（最優先）、低×低はP4といった具合にマッピングされます (weareitsm.com)。各ランクの定義例として、影響度は 「高: 全社または主要サービスに影響し業務停止」「中: 部門や複数ユーザに影響」「低: 個別ユーザや周辺サービスのみ」 等、影響範囲と重大度が定義されます。また緊急度は 「高: 今すぐ対処しないと重大な法的・営業上の問題になる」「中: 早期に解決すべきだが多少の遅れは許容」「低: 次の定期対応でも問題ない」 など時間的猶予の度合いで定義します。これら基準は社内SLAやビジネス文脈に応じて調整されますが、一度定義すれば誰が判断しても同じ優先度に収束することを狙っています (weareitsm.com)。さらにITILでは技術的重大度（Severity）も概念上区別され、こちらはシステムの機能低下度合いで1〜4など数段階に分類します（例: 「Severity 1: システム全停止」〜「Severity 4: 軽微なUI不具合」 ）。Impact/Severityがビジネスvs技術の視点で分かれる点はありますが、評価基準自体はいずれも定義表に基づく段階評価であり、運用組織はその表現を具体化することで客観性を確保します。

• インシデントの重大度レベル（SEV1〜SEV5など）: サイト信頼性エンジニアリング（SRE）や運用監視の現場では、障害対応の優先度指標としてSEV○レベルを用います。PagerDutyの例ではSEV-1〜SEV-5の5段階が定義され、番号が小さいほど緊急かつ深刻です (syednadeemnaqvi.blogspot.com)。各レベルには共通認識を持つための説明が付されており、例えば SEV-1: 「大多数の顧客に影響するクリティカルな問題。SLAを大幅逸脱、または顧客データ漏洩の恐れなど」 (www.itilxf.com)、SEV-2: 「多くのユーザが主要機能を利用できない重大インシデント」 (docs.octopus-itsm.com)、SEV-3: 「一部機能の部分的障害。放置するとSEV-2に悪化し得る問題」 、SEV-4: 「軽度の性能低下や個別コンポーネント障害（冗長性あり）」 、SEV-5: 「顧客に影響しない UI上の cosmetic な問題やマイナーなバグ」 、といった具合です。さらに各レベルに対して標準的な対応手順（SEV-1なら経営陣アラート・対外公表、SEV-3なら担当チームの即時対応など）も紐づけられており (www.itilxf.com) 、緊急度に応じたエスカレーションフローが明確です。このような定性的区分 + 事例列挙により、オンコール担当者間で「これはSEV-2相当だ」と再現性ある判断を迅速に下せるようにしています。重要なのは、これら定義を各組織の環境に合わせて定期的に見直し、一貫性を保つ運用で (www.splunk.com) (www.splunk.com)、属人的な判断ブレを防ぐことです。

• セキュリティ脆弱性スコア（CVSS）: CVSS (Common Vulnerability Scoring System)は0.0〜10.0の数値スコアで脆弱性の深刻度を表す業界標準です (nvd.nist.gov)。基点となるBaseスコアは8つのメトリクス入力から計算されます。これらは攻撃手法の特性（攻撃元の物理/ネットワーク距離、攻撃の複雑さ、必要な権限レベル、ユーザ操作の要否、影響範囲の変化）と、影響度（該当システムの機密性・完全性・可用性への影響度合い）です。それぞれ定義された選択肢があり例えば攻撃経路 (Attack Vector)はPhysical (直接接触が必要)〜*Network (リモートから可能)*の区別、機密性影響はNone/Low/Highといった形式です。評価者（多くの場合脆弱性公表者）は該当する選択肢を**客観的事実に基づき選びます。CVSSの計算式は公開されており、入力値が同じなら誰が計算しても同一のスコアになります。さらに質的評価として、算出点をLow/Medium/High/Criticalの4段階にマッピングする定義があり（例: v3.1では9.0以上がCritical） (nvd.nist.gov)、非技術の関係者にも分かりやすい区分で伝えられます。CVSSは評価手順と基準が厳密に定義されているため、短文の脆弱性概要からでも再現性高く評価できる点が特徴です (nvd.nist.gov)。例えば「認証なしでネット越しに機密データを読み取れるバグ」という記述から、Attack Vector=Network、Privileges Required=None、Confidentiality Impact=Highなどを明確な規則**で判定でき、スコア計算も自動化可能です。こうした仕組みにより、恣意的な深刻度の過小/過大評価を防いでいます。

• FMEAのリスク優先度数（RPN）: FMEA（Failure Mode and Effects Analysis）では、潜在的不具合の優先度をSeverity（重大度）・Occurrence（頻度）・Detection（検出困難度）の3評価の積で示すRPNとして算出します (www.proactivanet.com)。各評価軸は1〜10の数値で、具体的な評価基準テーブルが用意されています。例えばSeverityは「顧客への影響の深刻さ」を表し、10=「危険（予兆なし）: 最悪の場合、安全事故等に直結」〜1=「影響なし: 機能・用途への影響皆無」のように定義されます (qhubio.com)。Occurrence（発生頻度）は設計や工程上の原因の起こりやすさを表し、10=「10%相当と極めて高頻度」〜1=「0.001%以下の極めて低頻度」と実測データに基づく確率で区分されます (qhubio.com)。Detection（検出性）は現行管理で不具合を事前検出できる可能性の低さを表し、10=「検出手段なし（ほぼ発見不可能）」〜1=「確実に検出できる仕組みあり」の基準です (docs.helpmasterpro.com)。これら数値は出来るだけ客観データ（故障率や検査能力統計）に基づくことが推奨され、評価者間で認識を揃える工夫がなされています (qhubio.com)。例えば自動車業界向けFMEAハンドブックでは 各点数の具体例（「Occurrence=7なら試作品1000個中10個不良」等）が示され (qhubio.com)、組織内で教育・共有されます。RPNは各値を乗じるためスコア範囲が広く（最大1000）なりますが、現在ではAIAG&VDAの新標準でアクションプライオリティ (AP)という非線形な優先度判定に置き換わりつつあります (www.proactivanet.com)。いずれにせよFMEAでは定義に沿った数値評価によって、異なる工程でも一貫したリスク判定ができるよう設計されています。

• プロダクト機能優先度: RICE/ICE: RICEはIntercom社が提唱したスコアリングで、Reach（影響人数）・Impact（1人当たり効果）・Confidence（確信度）・Effort（工数）の4要素から機能や施策の総合スコアを算出します (pmtoolkit.ai)。計算式は RICE = (Reach × Impact × Confidence) / Effort で、スコアが高いほど「少ない労力で大きな価値が見込める」ことを意味します (pmtoolkit.ai)。各要素の評価尺度は次の通りです: Reachは「一定期間に影響を与えるユーザ数」（例: 四半期あたり500人など）で具体的な数値を入れます (pmtoolkit.ai)。Impactは「ユーザ1人あたりのインパクト」を5段階の係数（3=大、2=高、1=中、0.5=低、0.25=最小）で見積もります (pmtoolkit.ai)。Confidenceは見積もりの信頼性を%で表し、80%以上=高信頼、50〜80%=中、50%未満=低といったガイドがあります (pmtoolkit.ai)。Effortは開発に必要な時間を人月やストーリーポイントで見積もり（例: 4人週）ます (pmtoolkit.ai)。ICEスコアはRICEからReachを除いた簡易版で、Impact×Confidence/Effortで算出されます。RICE/ICEの基準策定では、特にImpactとConfidenceの定義づけが重要です。Impactの数値は属人的に盛られがちなので (pmtoolkit.ai)、過去類似プロジェクトの効果測定など根拠を示して「これは高=3に値する」など判断します。またConfidenceも闇雲に100%とせず、データ不足時は50%とする等のルール化で客観性を保ちます (pmtoolkit.ai)。RICEは数式であるため再現性が高い反面、元となる見積もりが恣意的だと無意味なので、評価基準の明文化と複数人での相互チェックが推奨されています (pmtoolkit.ai)。

• WSJF（Weighted Shortest Job First）: Scaled Agile Framework (SAFe) で推奨されるWSJFは、Cost of Delay（遅延による価値損失）をジョブの所要時間で割って優先度を決める手法です (www.prodpad.com)。Cost of Delayはさらに3つの要因に分解されます: ユーザ/ビジネス価値 (User-Business Value)、時間的価値減衰 (Time Criticality)、リスク低減・機会獲得 (Risk Reduction & Opportunity Enablement) (www.prodpad.com)。各要因をチームで1〜10点など相対評価し、その合計がCost of Delayとなります (www.prodpad.com)。例えば 「ユーザ価値=8, 時間緊急度=7, リスク低減=5」ならCoD=20です。この評価には経済的価値（売上やコスト削減額）を定量的に見積もるアプローチもありますが、困難な場合は相対的な比較基準で十分とされます 。Job Size（ジョブ規模）は例えば見積ポイントや工数で算定し、WSJFスコア = CoD / Job Sizeを計算します (www.prodpad.com)。この値が高い項目ほど「1時間あたりの経済価値」が高いため優先すべきという判断になります (www.pureconsultant.de)。WSJFでは各因子のスケールと採点基準を予め合意しておくことが重要です 。例えばユーザ価値10点の基準を「最重要顧客群全体に影響する」等と決め、チーム全員が同じ物差しで点数付けするようにします 。遅延コストという概念を明示的に数値化する点がWSJFの特徴であり、機会コストを定量評価する枠組みとして有用です【20†L105-L1 (www.prodpad.com)（価値）/（時間）をシンプルな比率で示すことで、異なる種類の仕事を客観基準で比較可能にしています。

• Kanoモデル: Kanoモデルは上記の他と毛色が異なり、スコアリングではなくカテゴリ分類によって要求の重要度を評価します。具体的にはアンケートでユーザの反応を解析し、各要求を「当たり前品質（Must-be）」「一元的品質（Performance）」「魅力的品質（Attractive）」「無関心品質（Indifferent）」「逆品質（Reverse）」のいずれかに仕分けます。数値尺度こそありませんが、Must-beに分類された項目は「欠如すると致命的」な必須要件として扱い、まず満たすべきものになります。一方Attractiveは「あれば嬉しいが無くても構わない」機能で、競合差別化要素にはなるが優先度は状況次第です。このようにKanoモデルはユーザ満足度への寄与タイプを重視するため、判断基準も「ユーザが感じる満足/不満の変化」という定性的指標になります。分析結果はグラフ上で各機能がどのカテゴリか視覚化され、ロードマップ上の優先順位付け（例えばMust-be要件は最優先投入すべき、など）に活かされます。Kanoモデルの場合、スコアではなく二次元座標（満足-実装度）で評価するため、他のフレームワークと直接の数値比較はできません。しかし、そのカテゴリ分け手法自体には厳密な調査プロセスが定められており（ペア質問票による分析など）、主観ではなく顧客データに基づき分類することで客観性を担保します。

以上、各フレームワークの評価尺度と具体的基準例を示しました。共通しているのは、ランク定義や計算式を公開・共有することで人による判断のブレを抑えている点です。特に数値スコア型の手法（CVSS, RPN, RICE, WSJFなど）は入力値と算出方法が明確なので再現性が高く、一方マトリクス型やカテゴリ型の手法（リスク評価, ITIL, インシデント, Kano）は定義リストと事例によって共通理解を作り上げることで客観性を得ています (resources.rework.com) (response.pagerduty.com)。評価の説明責任も重視され、なぜそのスコアになったかを基準定義と照合して説明できる仕組みをとっています。例えば「このリスクはImpact=5（壊滅的）と評価したのは、定義上『プロジェクト失敗に繋がる可能性』があるため」 (resources.rework.com)のように、評価根拠を文書化できるようにしています。以上の取り組みにより、フレームワークは再現性と客観性を確保しています。

3. 不可逆性と機会コストの扱い（Irreversibility & Opportunity Cost）

不可逆性（Irreversibility）と機会コスト/遅延コスト（Opportunity Cost / Cost of Delay）は、フレームワークによって扱いが異なりますが、多くの場合間接的に考慮されています。それぞれについて、主要な枠組みでの取り入れ方を解説します：

• 不可逆性（リバーシブルか否か）: 問題や決定事項が後戻り可能かどうかは、ビジネス上のリスク判断で重要な視点です。しかし伝統的な評価マトリクスでは、不可逆性それ自体を数値化するケースは多くありません。代わりに、対処戦略やガバナンスで区別されます。例えば【Jeff Bezos/Amazonの「ワンウェイドア vs ツーウェイドア」決定モデル】は、不可逆な一方向の決定（Type1）は極めて慎重に行い、可逆な決定（Type2）は迅速に実行することを提唱しています。この原則は形式的なスコアリングではないものの、重大度評価の区分として機能します。同じ効果範囲の問題でも「取り返しがつかない損失を招く可能性」があれば事実上より高優先度で扱われます (resources.rework.com)。例えば先述のリスクマトリクス文脈でも、同一スコアのリスクが複数ある場合「将来修正困難なもの」から対処する、といった意思決定に不可逆性が影響します (resources.rework.com)。またビジネス継続計画（BCP）や災害対策の領域では、人命やブランド毀損など不可逆的損失を伴うリスクは、発生確率が低くとも高い優先度が与えられます。この意味で、不可逆性はリスクの影響度を実質的に上方補正するファクターといえます。
  一部のフレームワークでは不可逆性に類する概念を取り込んでいます。例えばFMEAではSeverityの定義で「危険レベル」を細分し、警告なしに致命的な故障（不可逆な大事故）を最高点としています (qhubio.com)。重大インシデント対応でも、データロスやセキュリティ侵害など元に戻せない被害はSEVレベルを引き上げる要因となります。総じて、不可逆性はスコアリング軸というより判断上のしきい値として使われ、「不可逆的な影響があるなら強制的にCritical扱い」等のルールで組み込まれることが多いです。これは定量化が難しい要素ではありますが、ガイドライン化することで再現性に配慮しています（例: 「お客様データの永続的損失を発生させうる場合は、一律Impactを5（Catastrophic）とする」 等）。このように不可逆性は質的ルールや分類で評価プロセスに織り込まれ、モデルの境界を守る役割を果たしています。

• 機会コスト・遅延コスト: 機会損失とも呼ばれ、問題を放置した場合に逸失する利益や増大する損失を指します。これは主にプロダクト開発やビジネス投資の優先度判断で明示的に扱われます。代表例が前述のWSJFで、Cost of Delayとして定量化されます (www.prodpad.com)。Cost of Delayは、例えば機能リリースが遅れることによる日次売上機会の損失額や、脆弱性対応が遅れた場合の潜在被害額など、本来得られたはずの価値が得られないコストとして算出されます。これを金額換算したり、またはポイントスコア（重要度10＝非常に時価総額へ影響等）で表し、優先度スコアに組み込みます。Lean開発の指標では**「1週間遅れるとXXドル損する」といった試算を行うことも推奨されています (www.pureconsultant.de)。一方、ITILのインシデント優先度では機会コストはUrgency（放置した際の影響時間要素）に内包されています。緊急度高=「解決を遅らせられない」状況であり、その裏には遅延した場合の損失が暗に考慮されています。リスクマネジメントでは機会損失よりも顕在損失に注目しがちですが、定性的リスク評価でも「対応の遅れによりリスクが増大するか」という観点で高Urgencyとするケースがあります。【プロジェクト管理】の優先順位づけではCoD (Cost of Delay)を直接会議で検討し、例えば「機能Aは月次100万円の収益増が見込めるので遅延コスト高」といった議論を通じ、数値に基づく順位決定が行われます (www.prodpad.com)。
  コストオブディレイの定量化は難しい場合も多いですが、その場合は相対評価**（例えば3段階: 大/中/小）でも良いので取り入れると良いとされています 。機会コストの概念を入れることで、短期的な影響が小さくても将来的損失が大きい問題（技術的負債の蓄積など）に光を当てることができます。ただし、客観性を担保するには数値モデルやエコノミック分析が必要となるため、組織の成熟度によりバラツキがある領域です。先進的な企業ではROIシミュレーションやユーザあたりLT（ライフタイムバリュー）の損失といった計算まで行いますが、それを簡易化したのがWSJF等の手法です (www.prodpad.com)。要するに、機会コストは**「やらなかった場合の痛み」**として優先度計算に組み込まれ、時間経過による価値変化を定量的に扱う点に特徴があります。

以上、不可逆性と機会コストの扱いについてまとめると、不可逆性は多くのフレームワークで質的に考慮され、スコア評価を超えて最優先で扱うべき問題かを判断する軸となっています。一方、機会コストはLean/Agile系のフレームワークで直接数値化され、緊急度や重要度に反映されています。両者とも、適切に組み込むことで「見落とされがちな要素」を補正し、優先度判断の抜け漏れや誤判断を防ぐ効果があります。特に不可逆なリスクや放置による損失拡大を無視しないよう、評価プロセスにルールや計算式として組み込むのが成熟した組織のプラクティスと言えます。

4. 影響範囲と草案との比較: スコープ定義と不足次元（Scope/Blast Radius & Gaps vs Draft Framework）

本章では、各フレームワークが定義する影響範囲（スコープ）の階層と、質問者様のドラフト3次元モデル（被害ドメイン・影響範囲・不可逆性）に照らして不足している次元・尺度を分析します。また、短文テキストから重大度を判断する際の課題についても言及します。

各フレームワークの影響範囲（スコープ）定義

複数の枠組みで観察される共通パターンとして、影響範囲（Blast Radius）の階層化があります。例えば:

• ITIL/インシデント管理: 「単一ユーザ or 小規模チーム」、「部門や多数の内部ユーザ」、*「全社または顧客全体」*といった粒度で影響範囲を区切り、それを影響度ランクに反映します (weareitsm.com)。具体的には、社内ヘルプデスクのインシデント分類では「1ユーザ影響=Low Impact」「部署全体=Medium Impact」「会社全体や顧客サービス影響=High Impact」など段階的定義が一般的です。

• 重大障害のSEV基準: PagerDutyのガイドでは、各SEVレベルの説明に影響範囲の指標が含まれます。SEV-1は*「大多数の顧客に影響」、SEV-2は「多くの顧客または全ユーザに主要機能の障害」、SEV-3は「一部機能の障害（多数には影響せず）」*といったように、影響を受けるユーザ/機能の広がりで序列化しています (www.itilxf.com) 。このようにインシデント系では人数割合や主要サービスか否かがスコープ定義のキモです。PagerDutyは自社向けを一般化した定義を公開しており、「自社状況に合わせユーザ数や割合で具体化するのが望ましい」としています (response.pagerduty.com)。

• リスクマトリクス: プロジェクトリスクの影響度定義にはスコープ軸の要素が入ります。引用例ではImpact=5（Catastrophic）の定義に「プロジェクト失敗、甚大な財務・安全規制上の損害」とあり (resources.rework.com)、組織全体やプロジェクト全体に及ぶレベルを示唆します。Impact=3（Moderate）では「顕著だが管理可能な影響、管理者の注意喚起が必要」とあり (resources.rework.com)、局所的影響に留まることを示すなど、暗に影響範囲の広さが盛り込まれています。

• セキュリティCVSS: 厳密には「影響範囲」という軸はありませんが、Scope (スコープ)というメトリクスがあり、脆弱性が及ぼすセキュリティ権限範囲の変化を評価します（例えば脆弱性を突くことで別システムにまで影響が及ぶか否か）。またCVSSのBase指標のAttack Vectorは、攻撃に必要な物理的/ネットワーク的距離を示し、その到達範囲の広さ（ネット経由ならより広範囲への影響可能）を評価軸にしています。これらは厳密には「被害対象の人数」ではないですが、問題が影響を及ぼしうる範囲を測る指標と言えます。CVSS環境値では組織固有に「該当システムが社外公開か内部か」などで調整するため、間接的に組織内外のスコープが考慮されます。

以上から、**影響範囲（スコープ）の概念は各フレームワークに共通して存在し、表現は違えど「どれだけ広い範囲に影響が波及するか」**をランク付けに使っていることが分かります。質問者様草案の第二軸「blast radius (影響範囲)」は、この観点を押さえており、広く採用される次元と一致しています。

ドラフト案との比較: 不足次元と推奨スケール

質問者様のドラフト評価軸は以下の3つでした:

1. Harm domain（被害ドメイン）: compliance / revenue / internal efficiency / continuity / info-asset & trust のように**問題の種類（影響を受ける価値領域）**を分類する軸。
2. Blast radius（影響範囲）: individual -> team -> product-feature -> whole-product -> customers -> whole-company のように影響が及ぶスケールを段階づけた軸。
3. Irreversibility class（不可逆性クラス）: A: fatal-irreversible / B: chronic-compounding / C: minor の3段階で不可逆性や影響持続性を評価する軸。

このモデルに対して、前述の他フレームワークとの比較から浮かび上がる不足次元や改善点を整理します。

• Must-have（ぜひ追加すべき）:

  • 緊急度・時間軸の要素: 機会損失や解決の緊急性を判定する軸が無い点は見逃せません。他フレームワークではUrgency/Time Criticalityが頻出しており (weareitsm.com) (www.prodpad.com)、問題を放置した際の時間的悪化度合いを評価に入れることで優先度精度が上がります。短文テキストから抽出する場合でも、「期限」「目前のイベント」「成長阻害」「競合状況」などの記述から緊急度を類推できます。具体的提案: 「Time Criticality」軸を追加し、高=「時間猶予なし」、中=「待つと損失増」、低=「遅れても影響小」等の3段階で評価 (www.prodpad.com)。これはCost of Delayの簡易表現としても機能し、価値の時間依存性を捉えられます。
  • 頻度・再現性の要素: ドラフト案は起きている問題の現在価値にフォーカスした構成ですが、もし予防的な判断も含めるなら発生確率や頻度を加味すべきです。他フレームワークのRisk系では常にProbabilityとImpactのセットになっています 。再現頻度が高い問題（しばしば起こる障害、不定期だが必ず来るイベント等）は、一回の影響が小さくても累積影響が大となるため重要度を上げる必要があります。短文テキストでも「週次で発生」「頻繁に問い合わせが来る」等の記載から頻度を推定可能です。具体的提案: 「Frequency」軸を追加し、高=「常態的に発生/既に起きている」、中=「時々発生しうる」、低=「可能性低い」程度に3段階評価。これによりリスクと現象の両面から妥当性チェックができます（例えばハームドメイン上は深刻でも頻度が極低なら優先度見直し、といった判断が可能）。

• Should-have（可能なら追加を検討）:

  • 顧客価値・ビジネス価値の軸: Harm domainで分野は特定できますが、価値の大きさ（特にポジティブな機会の大きさ）は直接表現されていません。例えば同じ「revenue」ドメインでも、増収額100万円 vs 1億円では緊急度が異なるはずです。これはBlast radiusやIrreversibilityでは表現しきれない価値規模の次元です。他のプロダクト優先度手法ではImpactを「ユーザ/売上へのインパクト規模」で数値化しています (pmtoolkit.ai)。具体的提案: Harm domainごとに「想定インパクト額またはスコア」を設定し、別途ポイント付与する（例えば「compliance問題: 発生すれば罰金Max¥1M=Impactスコア3」など）。もしくは全ドメイン横断でImpact magnitude軸を追加し、定性5段階（無視できる〜壊滅的）の評価を取り入れても良いです (resources.rework.com)。後者は汎用的ですが、すでにIrreversibilityクラスA/B/Cがあるため、定義重複に注意しつつ調整します。
  • 検出性・信頼度の軸: モデルのハード制約として「ドラフト文から得られる証拠で判断する」ことがあります。この条件下では、テキストに書かれていない推測は避ける必要があります。しかし判定に迷うケース（情報不足）が出た場合、Confidence（確信度）の軸でエスカレーションする選択も考えられます。他フレームワークのRICEでは、確信度を%で評価し低い場合はスコアを下げます (pmtoolkit.ai)。同様に、本モデルでもAIによる評価の不確実性を軸に持ち、例えば「関連知識データベースにない新規問題なのでConfidence低＝減点」等とすれば、誤判定リスクを低減できます。これは純粋な問題の重大度ではなく判定の信頼性評価ですが、実務上は発生しうるブレ要因として考慮を推奨します。

• Nice-to-have（余裕があれば検討）:

  • 解決コスト/難易度: 問題の「割に合う度」を見るため、解決にかかるリソース量も本来は重要です。ただ、質問文にある通り意思決定プロセスで別途扱う領域であり、先行して入れるとかえって評価が主観化・複雑化する恐れがあります。従って無理に追加は勧めませんが、優先度付け最終判断では別シートでEffortポイントを管理し、本モデルのスコアと組み合わせて判断する形が望ましいでしょう。
  • 定量スコア換算: 現状A/B/Cや段階をクラス分けしていますが、最終的に総合スコアがあると閾値設定や自動判定が容易になります。各軸を例えば0〜4点で数値化し合計スコアを出す、あるいは重み付け平均する等です。これ自体は次元追加ではありませんが、モデルをシステマチックに運用する上で将来的に検討すると良いでしょう。

短文テキストから評価する際の課題と留意点

最後に、ドラフト文からの自動/半自動評価に関して、**想定される課題（pitfalls）**と対策を明示します。

• 曖昧な表現による評価の揺らぎ: テキスト内に評価に必要な要素が十分明示されていない場合、評価者（やモデル）が推測に頼ることになり、再現性が損なわれます。例えば「システムに障害が起きた可能性がある」という表現のみでは、影響範囲も深刻度も不明瞭です。この場合、人間なら状況を補完できますがモデルでは一貫しない判断を下す危険があります。対策: 可能な限り明確な言葉の定義またはキーワード辞書を設け、テキストにその語があるかで判断するようにします（例: “顧客”という単語があれば影響範囲は最低でも「customers」以上、といったルール）。

• 境界ドリフト（Boundary drift）: 明確な基準がなかったりモデルの学習が偏ったりすると、時間経過で判断基準がずれてしまう現象です。例えば最初は厳格にC（軽微）判定していたケースでも、類似の別ケースでBにしてしまう等が起こりえます。対策: 各クラス/A・B・Cのアンカーとなる具体例を用意し、それと比較して判定するアルゴリズムにします。また定期的なキャリブレーション（過去の判定との比較検証）を行い、基準が守られているかチェックします。これは人手評価でも重要で、FMEAでは定期的にチームで評価結果をレビューしてスケール感を共有します (qhubio.com)。同様にADR運用でも、時折過去の決定を見直し評価軸の解釈がズレていないか確認するのが望ましいです。

• 証拠の要求水準: ハード制約として「テキスト上の verbatim evidence で説明可能」があるため、モデルが勝手に背景知識を補完してはいけないことになります。これにより、たとえば**「売上損失額」のような数字が書いていない限りRevenueインパクトを高と断定できない、といった制約が発生します。対策: 評価基準を作る際、「テキスト中に◯◯と記述があればImpact高」と具体的なトリガー条件**を定義します (response.pagerduty.com)。例えば「重大」「致命的」「全ユーザ」など強いワードは高スコア、逆に「一部」「一時的」などのワードは低スコアに紐づける形です。また、欠落情報への対処としては、保守的評価の原則を採用します (docs.helpmasterpro.com)。PagerDutyが「疑わしきは高く見積もれ」としているように (docs.helpmasterpro.com)、不明な場合は一段上の深刻度で扱い、後から人間が引き下げる方針が安全策となります。

• モデルの説明性: AIモデルが評価する場合、その理由を説明できないと現場では受け入れられません。そこで、評価根拠をテキストのどの部分から得たかを明示する必要があります。これには自然言語処理の根拠抽出手法を用い、各スコア項目ごとに「○○と書かれているのでImpactスコア=高」といった説明文を生成させると良いでしょう。説明文テンプレートを用意しておき、該当箇所を抜き出して埋め込む形でも実現できます。このように、説明可能AIの考え方を取り入れることで、モデルの判断への利用者の納得感と信頼性が向上します。

以上のような課題を踏まえ、ドラフトの評価フレームワークを完成させる際には、他の成熟フレームワークでの知見（定義表の整備、基準の明確化、定期レビュー等）を積極的に取り入れることを推奨します (response.pagerduty.com)。特に短文からの推定は不確実性が高いため、曖昧な場合にどう処理するか（保守的に扱う、低確信度としてフラグする等）のポリシーを決めておくことが重要です。既存フレームワークのエッセンスを取り入れつつ、ADRの文脈に合った実践的で再現性のある評価スキームを構築してください。

比較マトリックス: フレームワーク別の評価軸と尺度

各フレームワークについて、使用する評価次元、評価尺度、不可逆性・機会コストの扱い、影響範囲（スコープ）区分の有無をまとめます。

※上記は一般的な内容をまとめたもので、実際の運用では各社・各組織で定義の細部が調整されています。例えばリスクマトリクスの尺度は組織目標に合わせてカスタマイズされますし、RICEの数値もチームにより若干解釈が異なります。そのため基準表の明示と教育が不可欠であり (response.pagerduty.com)、本マトリックスは全体像の比較としての参考にしてください。

ドラフト三次元モデルへのギャップ分析

上記比較と質問3での考察を踏まえ、**現行ドラフト（被害ドメイン・影響範囲・不可逆性）**に対するギャップを整理します。

• 不足している主な次元:

  • 時間・緊急度要素: ほぼ全ての既存手法に共通する「Urgency/Time」の視点が欠落しています。Must-haveレベルの見直しポイントです。
  • 頻度・発生可能性要素: リスク性を扱うなら重要です。今後ADRで予防的決定も扱うならShould-haveとして検討すべきです。
  • 価値規模（ビジネスインパクト）: ドメイン区分のみではインパクト量が不明確なため、収益額や影響人数など定量インパクトの概念を入れると精度が上がります。重要度はShould-haveです。
  • 確信度・情報量: モデル出力の信頼性管理のための補助軸です。Should-have程度に留め、スコアリング計算からは除外してもフラグ的に使えます。

• 現在の次元における懸念:

  • 被害ドメイン: 他にあまり見られない軸ですが、問題の種類別に重み付けを変える意図と思われます。これは社内戦略に沿って調整すべきところです。ただ、モデルへの入力としてテキストからドメインを判定させるのは難度が高く、曖昧なケースも多そうです（例: 「顧客の信頼低下」はRevenueかTrustか？）。Pitfall: 一文中に複数ドメイン要素が混在する場合の扱い。→ 対策: 主要キーワードで重み付けする、複数該当時は最高のものを採用するなどルール化。
  • 影響範囲: これは多くの枠組みで核なので、定義をより精緻にしておきたいです (response.pagerduty.com)。例えば「team」と「product-feature」の違いが分かりづらければ、該当例（「○○の場合はteamレベル」）を設けます。Pitfall: テキストに範囲が明記されていない場合の推定。→ 対策: デフォルトは狭いとみなす、ただし特定ワード（「顧客」「全社」等）で上書き昇格するルールにする。
  • 不可逆性クラス: A/B/Cの3段階ですが、説明を見るとAは「致命的で元に戻せない」、B「慢性的にじわじわ悪化」、C「小さい」。これと影響度との違いがユーザに直感的に伝わりにくい懸念があります。例えば「慢性的に悪化」は時間軸にも読めるためUrgencyとの混同に注意が必要です。Pitfall: 評価者によってAとBの線引きが揺れる。→ 対策: 「不可逆的＝永続的被害（データ消失など）」など具体事象例をAに挙げ、Bは「放置すれば被害累積（技術的負債など）」と定義する等、判定基準を強化します。

• 再現性確保のポイント:

  • 基準テキストの整備: 各評価軸につき、簡潔なランク定義表を作りましょう。既存フレームワークから引用した定義文を参考に、日本語で「高=... 低=...」を明文化し、それを評価時に参照するしくみにします (resources.rework.com)。
  • 評価ルールの自動チェック: モデル or ツールが出した評価を、人間がその定義と照らして説明できるか検証します。説明できなければ「境界がブレている」ので基準やモデルを修正します (response.pagerduty.com)。
  • 定期的な基準の見直し: フレームワーク導入当初は特に、判定結果の分布やフィードバックを集め、必要なら定義や重み付けをチューニングします。これはITILやインシデント運用でも継続的に行われていることです (www.splunk.com)。

以上より、ドラフト案には時間的緊急度と発生頻度という重要次元が不足しており、それらを追加検討すべき（Must/Should）と判断しました。また既存3軸についても定義の明確化とルール設定で補強が必要です。短文からの自動評価は難度が高いですが、既存フレームワークの客観基準策定ノウハウを活用することで、十分再現性・説明性のある仕組みが構築できるでしょう。

参考文献・情報源

1. Risk Matrix: How to Score Probability and Impact (Template) – Re:Work (Project Management). リスク評価マトリクスの確率・影響度の定義とスコアリング手法【引用: 【4†L65-L73】 (resources.rework.com)】.
   (URL: https://resources.rework.com/libraries/project-management/risk-matrix)

2. Understanding the Relationship Between Impact, Urgency, Priority, and Severity – We are ITSM (Blog). ITILにおける影響度・緊急度と優先度の関係、および定義例【引用: 【5†L21-L28】 (weareitsm.com)】.
   (URL: https://weareitsm.com/impact-urgency-priority-and-severity/)

3. Severity Levels – PagerDuty Incident Response Documentation – PagerDuty Docs. インシデント重大度（SEV）レベルの定義と対応フロー【引用: 【0†L29-L37】 】.
   (URL: https://response.pagerduty.com/before/severity_levels/)

4. Incident Severity Levels 1-5 Explained – Splunk Blog. インシデント重大度レベルの解説（SEVとPriorityの違い等）【引用: 【8†L21-L28】 (www.splunk.com)】.
   (URL: https://www.splunk.com/en-us/blog/learn/incident-severity-levels.html)

5. NVD – Vulnerability Metrics (CVSS) – NIST National Vulnerability Database. CVSSのスコアリング方式と定性的ランク【引用: 【13†L3-L11】 (nvd.nist.gov)】.
   (URL: https://nvd.nist.gov/vuln-metrics/cvss)

6. FMEA Severity, Occurrence & Detection: Complete Rating Guide – Qhubio (Blog). FMEAにおけるSeverity・Occurrence・Detectionの1〜10評価基準【引用: 【22†L25-L33】 (qhubio.com)】.
   (URL: https://qhubio.com/fmea-severity-occurrence-detection)

7. What is RICE (RICE Scoring)? Definition, Formula & Benchmarks – PM Toolkit. プロダクト優先度づけ手法RICEの定義・算出方法と各要素の基準【引用: 【16†L17-L25】 (pmtoolkit.ai)】.
   (URL: https://pmtoolkit.ai/glossary/rice)

8. Weighted Shortest Job First (WSJF) – ProdPad Glossary. WSJFの解説とCost of Delay計算、各要素のスケール設定方法【引用: 【20†L105-L113】 】.
   (URL: https://www.prodpad.com/glossary/weighted-shortest-job-first-wsjf/)