問題の重大度・影響・「価値」を評価する成熟フレームワーク調査レポート

エグゼクティブサマリー(主要所見)

共通する次元は「Impact × Likelihood」+ α。ほぼ全フレームワークは Impact(深刻度/結果)に加え、Likelihood(発生確率)、Urgency(時間感度)、Scope(波及範囲)、Confidence(根拠の確からしさ)、Effort(コスト)のいずれかを組み合わせる。「リスクは、特定の脅威源が潜在的脆弱性を悪用する可能性と、その悪影響が組織に及ぼす影響との関数である」という二次元構造が、ITIL/NIST/ISO 31000/CVSS など 5 フレームワーク以上の起源にある。
スケールはほぼ「順序尺度 1–5 または 1–10 + アンカー定義」。スコアの再現性を担保する手段は、共通して「数字そのもの」ではなく「各レベルの文章定義(anchor)」と「具体例」である。「ある管理者が"今年中に発生する可能性が高い"と解釈する"Likely"を、別の管理者が"今後5年以内に起こり得る"と解釈してしまえば、マトリクス全体は無意味になる」。
不可逆性(irreversibility)を独立次元として持つのは Amazon の "One-Way/Two-Way Door" のみ。リスク系フレームワークは結果(consequence)の中に間接的に含めるだけで、独立次元として明示化していない。Bezos のフレームでは一方通行のドアの決定は「重大かつ不可逆的な結果をもたらすもの — 物流センターやデータセンターの建設はその例で、多額の資本支出・計画・リソースを要し、それゆえ深く慎重な分析が必要」と明示される。
機会費用(opportunity cost)を直接スコア化するのは Cost of Delay / WSJF のみ。 Cost of Delay は「価値が時間とともにどう漏れていくかを定量化するもの」「もしこれが1ヶ月遅れたらいくらコストがかかるか?」という問いの答え。単位は $/time」。重大度評価系(CVSS/FMEA/ITIL)は時間軸を持たない。
CVSS の「Scope(S)」がブラスト半径の最も精緻な定式化。 CVSS v3.0 は「ある脆弱性が、自らの権限を超えてリソースに影響を及ぼす能力」を Authorization Scope(略して Scope)として捉え、計算機権限の境界(authority)を跨いだ場合にスコアを引き上げる。ユーザのドラフトの「blast radius」次元は CVSS の Scope に概念的に近いが、CVSS は2値(Unchanged/Changed)であり、ユーザの 6 段階の方が粒度は高い。
短文からの判定における最大の失敗モードは「あいまいなアンカー定義」と「証拠を伴わない主観評定」。NIST は「再現性(reproducibility)は異なる専門家が同じデータから同じ結果を生み出す能力を、再現性(repeatability)は将来同じ評価を一貫した形で繰り返し過去の評価と比較できる能力を指す」と明示し、これを公的成果物の品質要件としている。

Q1. 重大度・価値を測る「次元」とは何か

1.1 フレームワーク別の次元一覧

ファミリー	フレームワーク	採用する次元
ITSM	ITIL Priority Matrix	Impact × Urgency
企業リスク	ISO 31000 / 5×5 Risk Matrix	Likelihood × Consequence
情報セキュリティ	NIST SP 800-30	Likelihood × Impact(+ Predisposing Condition)
脆弱性	CVSS v3.x	Exploitability(AV/AC/PR/UI)× Scope × CIA Impact
信頼性工学	FMEA / RPN / AP	Severity × Occurrence × Detection
インシデント	SEV1–SEV5 ladder	Impact(scope/criticality)+ 暗黙の Urgency
プロダクト優先順位	RICE	Reach × Impact × Confidence ÷ Effort
〃	ICE	Impact × Confidence × Ease
〃	WSJF / CD3	(Business Value + Time Criticality + Risk/Opportunity)÷ Job Size
顧客満足	Kano	Must-be / Performance / Attractive / Indifferent / Reverse(カテゴリ分類)
意思決定	Bezos One-Way/Two-Way Door	Reversibility(2値)

1.2 再帰的に現れる次元(共通項)

Impact / Consequence / Severity:全フレームワーク共通。 ITIL では「impact は事業混乱の範囲を測り、課題が組織にどれほど広く影響するかを反映する」「影響を受けるユーザ数、重要事業サービスが利用不能か、収益・規制遵守・組織評判へのリスクがあるか」を評価。
Likelihood / Probability:リスク系(ISO 31000, NIST, FMEA)で必須。製品優先度系(RICE/ICE)では「Confidence」として裏返しに登場。
Urgency / Time-criticality:ITIL の中核次元、WSJF の Cost of Delay 構成要素、インシデント ladder にも暗黙存在。
Scope / Blast radius:CVSS の Scope、ITIL の影響範囲、インシデントの affected user count として登場。

1.3 各ファミリーに固有の次元

Detection:FMEA のみ。「Detection は故障モードが発見される確率を 1-10 で評価」「Severity × Occurrence × Detection で RPN を算出」。
Effort / Job Size / Ease:RICE, ICE, WSJF にのみ存在(分母)。リスク系には登場しない。
Confidence(根拠の確からしさ):RICE, ICE に固有。「プロジェクトが大きなインパクトを生むと思うがデータがない場合、confidence でその不確実性を制御できる。Confidence は %で、100%=高い、80%=中、50%=低、それ以下は"moonshot"」。
Reversibility:Bezos の One-Way/Two-Way Door のみが独立次元化。
Kano カテゴリ:数値ではなく「Must-be / Performance / Attractive」のカテゴリ分類。 Kano モデルは「顧客の好みを 5 つのカテゴリ(delighter/satisfier/dissatisfier 等)に分類し、それぞれが顧客満足に異なる影響を与える」。

Q2. 評価尺度と客観性・再現性の担保

2.1 ITIL Impact × Urgency

Impact:組織のリーチで定義(個別ユーザ→部門→全社)。 Carlos Helpdesk の典型例:「Low impact: 単一または小規模ユーザ群。Medium impact: 50% 以上の影響を受けるユーザ群または VIP。High impact: 80% 以上のユーザ群」。
Urgency:時間感度。「High: 中核業務サービス(取引アプリのように財務・ブランド・セキュリティに直接影響するもの)、Medium: 中核業務を支えるサポートサービス(印刷など)、Low: 非緊急サービス(社内ポータルなど)」。
再現性の担保: 「インパクト定義は事業に合わせて始めよ。汎用カテゴリは失敗する。インシデント分類は現実の事業影響を反映しなければならない」「実シナリオでマトリクスをテストせよ」。

2.2 CVSS(セキュリティ脆弱性)

構成: 「CVSS は Base, Temporal, Environmental の 3 メトリックグループからなる。Base は脆弱性の本質的特性、Temporal は時間で変わる特性、Environmental はユーザ環境固有の特性。Base は 0–10 のスコアを出力」。
質的レーティング: 「スコアは severity ラベルへマップ:Info (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), Critical (9.0–10.0)」。
再現性の担保:Vector string により全評定が明示化される。「CVSS スコアとベクタは、環境横断で脅威レベルに基づき脆弱性を一貫的・客観的に優先順位付けできる」。「v3.1 では Roundup の単純実装が言語間で結果が違う問題に対応した」ほど、再現性に厳格。
重要な明示: 「CVSS はリスクの尺度ではない。CVSS v2.0 と v3.x は 3 つのメトリックグループからなる」 (severity ≠ risk)。
CVSS v4.0 では専門家評定を集約: 「1500万件の CVSS-BTE ベクタを 270 個の同値類に集め、専門家による比較データから最重要度の高い順に並び替え、後方互換性のある質的境界を決定」 (専門家コンセンサスベース)。

2.3 FMEA(RPN / AP)

3次元 × 1–10 アンカー: 「Severity 10 は警告なく安全に影響する故障(致命/負傷の可能性、安全関連の規制違反)。9 は警告ありの安全故障。7-8 は主要機能損失。4-6 は機能低下と顧客不満。1-3 は顧客が気づかないかもしれない軽微な影響」。
Severity の独立性: 「FMEA の重要原則は、Severity は detection や occurrence の制御では下げられないこと。電子部品が過熱して発火する故障 (severity 10) に温度センサを追加しても severity は下がらない」。
客観性の担保: 「Severity ランキングは 1–10 の相対尺度。組織固有の例を追加することで一貫性が向上する。各列を顧客満足、環境衛生・安全のように分けて記述するのが有効」。
RPN の限界と Action Priority への移行: 「RPN=120 でも S=10,O=4,D=3 と S=4,O=5,D=6 ではリスクプロファイルが全く異なる。2019 AIAG/VDA ハンドブックは厳密な RPN 閾値から離れ、Action Priority(High/Medium/Low)に移行し、Severity の高い項目に特別な重みを与える」。
再現性のための定石: 「Severity と Occurrence の混同を避ける」「最悪ケースを常に考える」「業界ガイド(AIAG & VDA)に従い標準化された評定表を使う」「各評定の理由を文書化する」「過去の現場故障と保証データをレビューする」。

2.4 インシデント Severity ladder (SEV1–SEV5)

5段階の典型定義: 「SEV2 は major disruption だが完全停止ではない。SEV3 は中核利用は妨げない機能影響、性能低下や非中核機能の不具合。SEV4 は美的バグ、エッジケース、少数ユーザ影響。SEV5 は対応不要の事象、可視性・トレンド分析のために追跡」。
客観性のための定義要件: 「良い定義:"SEV1: コア機能がアクティブユーザの10%超で停止/著しく劣化、または API エラー率が連続5分で10%超、または確認されたデータ損失、または決済処理が20%超劣化"。良い定義は2人のエンジニアが同じ監視データから独立に同じ severity 分類に到達できるかをテストできる」。
Severity と Priority の分離: 「Google SRE Workbook はこれを"severity はインシデントの属性、priority は応答者の決定"と定式化している」。「ステージング環境の sev1 は critical severity, low priority。環境は完全停止しているが顧客影響なし。契約期限をブロックする sev3 は minor severity, high priority」。
失敗モード: 「Severity インフレ:全てが SEV1 なら何も SEV1 でない。レベル数が多すぎる:6-7 個は判別不能で分類麻痺を生む。3-5 個がスイートスポット。曖昧な定義:午前2時に"重大な影響"は人により意味が違う。各レベルを具体例でアンカーせよ。Severity と effort の混同:修正困難なバグが自動的に高 severity ではない、severity は impact について」。

2.5 RICE / ICE(プロダクト優先度)

RICE 公式: 「Reach: 何人に影響するか(時間枠内の人数)。Impact: 1人あたりどれだけ影響するか(Massive=3x, High=2x, Medium=1x, Low=0.5x, Minimal=0.25x)。Confidence: 推定にどれだけ自信があるか(High=100%, Medium=80%, Low=50%)。Effort: 何 person-months か。スコア = Reach × Impact × Confidence ÷ Effort」。
ICE 公式: 「ICE は Impact, Confidence, Ease の 3 パラメータを 1–10 で評定し、掛け合わせる。例:Item One が Impact 7 × Confidence 6 × Ease 5 = 210, Item Two が 9 × 7 × 2 = 126。Item Two は Ease の低さに引き下げられる」。
客観性の弱点: 「ICE の弱点:主観性(同じアイデアでも人により大きく異なる)、Reach 不在(高トラフィックページと低トラフィックページが同点になる)、Ease の曖昧さ(時間か、コストか、複雑さか)、アンカリングバイアス(最初の人のスコアに集約)」。
対策: 「最初のセッション前に、各因子の 1 と 10 の意味をチームで合意し書き出せ。各人が独立にスコアしてから議論」。

2.6 WSJF / Cost of Delay

公式: 「WSJF = Cost of Delay ÷ Job Size。Cost of Delay は SAFe の 3 入力の合計 — Business Value + Time Criticality + Risk Reduction/Opportunity Enablement。各入力は修正 Fibonacci 尺度(1, 2, 3, 5, 8, 13, 20)で評定」。
CD3(本家): 「CD3 — Cost of Delay Divided by Duration — は WSJF の元になった経済的優先順位の元祖。Reinertsen の CD3 は Cost of Delay($/単位時間)を期間(時間)で割る。SAFe の WSJF は両方を相対 Fibonacci スコアに置き換え、精度を速度と引き換えにした」。
数値例: 「規制遵守タスク:Business Value 3、Time Criticality 20(罰則付き期限)、Risk Reduction 13(停止防止)、Job Size 8 → WSJF = (3+20+13)/8 = 4.5。モバイル新規ローンチ:13+8+5/13 = 2.0。compliance が先」。
再現性の制約: 「相対推定は複数ステークホルダーがいる場合に役立たない。ある人の相対スコア 2 は別の人の 8。3-4 人のステークホルダーを管理するなら、相対推定は HiPPO への escalation か horse-trading になる」。

2.7 ISO 31000 / 5×5 マトリクス

2軸 × 5レベル: 「ISO 31010 と PMI 指針下の2つの主要尺度は 3×3 と 5×5。5×5(25 組合せ)は ERM・規制業界・中レベル間の差別化が必要な場合に望ましい」。
数値化: 「Risk スコアは通常 Likelihood × Impact。5×5 マトリクスではスコアは 1–25、典型的閾値は 1-6(low/green)、7-14(moderate/yellow)、15-25(high/red)。データ侵害 L=3, I=4 なら 12 で高リスク帯」。
Likelihood の客観化: 「Likelihood には検証可能な頻度を使え — 20年に1回未満、深刻シナリオは10年に1回、5年内に複数回 — そうすればオーナーはインシデントや外部データと比較できる」。
Consequence の多次元化: 「組織に関連する影響次元(財務、運用、評判、安全、規制)を 5 段階で定義。各レベルには単なるラベルではなく具体的閾値が必要」。
再現性の核: 「順序尺度は金額ではない。Impact の "4" は "2" の 2 倍ではない。落とし穴は、2 つのリスクが同じセルを共有しても、片方が管理可能な罰金、もう片方がフランチャイズレベルの損害を意味する場合がある — 財務・非財務帯が書き出されていない限り」。

2.8 NIST SP 800-30(情報セキュリティ)

2軸: 「リスクは、特定の脅威源が潜在的脆弱性を悪用する尤度と、その悪事象の組織への影響との関数」「Impact は脅威が脆弱性を悪用することで引き起こされる可能性のある損害の規模を指す」。
再現性の明示要件: 「再現性(reproducibility)は異なる専門家が同じデータから同じ結果を生み出す能力。再現性(repeatability)は将来の評価を過去と一貫的に繰り返せる能力 — 組織がトレンドを特定できるようにする」。
3 階層化: 「Level 1: 組織(戦略フォーカス)、Level 2: ミッション/業務プロセス、Level 3: システム(運用環境) — より広範な視点からより詳細・粒度の高いリスク視点へ」。
質的 vs 半定量: 「成熟した NIST 評価は半定量に落ち着く。0–100 尺度は十分な粒度と管理可能性を両立。NIST は階層により異なるアプローチを許容 — Tier 3 低影響システムには質的、Tier 1 全社リスクには半定量」。

2.9 Kano モデル(顧客満足)

5 カテゴリ分類: 「Must-haves: 提供されないと不満を生むが、あっても効果なし。Delighters: 顧客が期待しないが提供されれば良い影響。Satisfiers: 充足で満足/未充足で不満、"多ければ良い"の原則。Indifferent: 良くも悪くもない要素」。
アンケート式評定: 「Kano は標準化されたアンケートで参加者の意見を暗黙的に測定する。各製品特徴について、機能的(肯定形)と非機能的(否定形)の2問」。
時間変化: 「Wow は Want になり、Must になる(時間とともに陳腐化)。自動車のセルフスターターやオートマがその例」。

Q3. 不可逆性と機会費用(opportunity cost)の取り扱い

3.1 不可逆性(irreversibility)

フレームワーク	不可逆性の扱い方
Bezos One-Way/Two-Way Door	独立 2 値の次元として明示化
FMEA	Severity の中に間接的に(致命的故障=10)
CVSS	直接の次元なし。Confidentiality の取消不能性は暗黙的
ITIL/インシデント	明示扱いなし(SEV1 の影響として暗黙的)
RICE/ICE/WSJF	扱いなし
ISO 31000 5×5	Consequence の最高レベル(Catastrophic)に丸める

Bezos の定義: 「one-way door 決定は significant かつしばしば不可逆的な結果を持つもの(物流センターやデータセンター建設など、巨額の資本支出・計画・リソース・深い分析を要する)。two-way door 決定は限定的かつ可逆的(サイト詳細ページや mobile app の A/B テストが典型例)」。

運用ルール: 「決定が可逆なら、速度を上げよ。最大のリスクはぐずぐずすること。決定が不可逆なら、速度を落とせ。最大のリスクは間違った決定をすること」。

実務的判別基準: 「不可逆である可能性が高いのは、回収不能なコストを大きく伴う、法的義務を生む、アイデンティティ/軌道を根本的に変える、他人の生活に大きく影響を与える場合。30 日以内に大きな結果なく元に戻せないなら、one-way door として扱え」。

注意点: 「組織が大きくなるにつれ、heavy-weight Type 1 意思決定プロセスを Type 2 決定を含む大半に適用する傾向 — 多くの 2-way door を 1-way door と扱う過剰見積もり」。

3.2 機会費用 / Cost of Delay

最も精緻な定式化は Reinertsen の Cost of Delay: 「Cost of Delay は"時間が結果に与える影響を伝える方法"。formally には総期待価値の時間に関する偏微分。価値が時間とともにどう漏れていくかを定量化。問い:"これが1ヶ月遅れたらいくらかかるか?"単位は $/time」。

実証データ: 「同じチーム内でも直感的な Cost of Delay 推定は 50:1 で変動する。Maersk Line は 38 週間キューに留まった機能に CD3 を適用、Cost of Delay は週 $200,000 超、遅延総額は約 $800 万ドル」。

WSJF の限界: 「Cost of Delay は Value と Urgency の組合せ。どちらかが 0 なら CoD は 0。"Time Criticality"を"Business Value"に加算するのは経済的に意味をなさない — ビジネス価値ゼロで時間感度の高いものがスコアを得てしまう」。本家 Reinertsen 自身は SAFe の単純加算を批判している。

短文評価への適用可能性:CoD のドル建て見積もりは情報不足の draft 段階では困難。「ソフトウェア会社時代は不可能に思えた。"ユーザビリティ問題で週いくら失っているか?"セキュリティパッチの Cost of Delay は?」とプロでも難航する。

3.3 重要な区別

概念	CVSS/FMEA/SEV ladder	WSJF/CoD	One-Way Door
取り扱い対象	発生時の severity	遅延の経済コスト	意思決定の取り消しコスト
時間軸	静的(時点)	動的($/time)	静的(2 値)
必要情報	影響範囲・確度	経済モデル	コスト構造

Q4. ブラスト半径(Scope)とユーザのドラフトに対するギャップ分析

4.1 各フレームワークの Scope 定義

CVSS Scope:最も精緻。「Scope は、ある計算機権限機関(アプリ、OS、サンドボックス環境)が計算機リソース(ファイル、CPU、メモリ等)へのアクセスを認可する際に定義される権限の集合を指す」。「Authority A(VM)と Authority B(ホスト OS)の 2 つの機関が脆弱性悪用に関与するとき、CVSS は scope change が発生したとみなす」 (2値 Unchanged/Changed)。
ITIL Impact: 「Impact はインシデントの程度と、解決前に引き起こされる可能性のある損害の尺度」。粒度は組織内のユーザ範囲(個別/部門/全社)。
インシデント Severity:典型例は「サービス完全停止? → SEV1 / 50%超ユーザ影響 + 中核業務影響 → SEV1 / 50%超 + 非中核 → SEV2 / 10%超 + 回避策なし → SEV2 / 10%超 + 回避策あり → SEV3 / ユーザ影響あり → SEV4 / なし → SEV5」。
ISO 31000 Consequence: 「組織に関連する影響次元(財務、運用、評判、安全、規制)を 5 段階で定義」。複数ドメイン横断。

4.2 ユーザのドラフトとのマッピング

ユーザのドラフトは 3 次元:harm domain × blast radius × irreversibility class。これを既存フレームワークの次元に対応付けると:

ユーザのドラフト次元	直接対応する成熟フレーム	カバレッジ
harm domain(compliance/revenue/...)	ISO 31000 の Consequence 次元(複数ドメイン定義)	◎
blast radius(個人→全社)	CVSS Scope, ITIL Impact, SEV ladder	◎
irreversibility class(A/B/C)	Bezos One-Way/Two-Way Door, FMEA Severity 9-10	△(成熟フレームでは独立次元化が稀)

4.3 ドラフトに不足している可能性のある次元

次元	採用フレームワーク	短文評定の容易さ	優先度
Likelihood / 発生確度	ISO 31000, NIST, FMEA Occurrence	△(draft では未確定が多い)	Should-have
Urgency / Time-criticality	ITIL, WSJF	○(draft 中の時間語彙から抽出可)	Must-have
Confidence / 証拠強度	RICE, ICE	○(draft の引用・データ参照量から推定可)	Must-have
Effort / 実装コスト	RICE, ICE, WSJF Job Size	△(draft では未確定)	Nice-to-have
Detection / 検知可能性	FMEA	△(運用次元、draft 段階では希薄)	Nice-to-have
Reversibility(独立次元化)	Bezos	○(draft の語彙から判定可能)	既にあり(irreversibility class)

4.4 短文評価で起こる落とし穴(共通)

アンカー不在による評定者間ばらつき: 「"Likely"を"今年中に発生"と解釈する管理者と"今後5年以内に起こり得る"と解釈する管理者がいれば、マトリクス全体は無意味になる」
証拠なし主観評定: 「FMEA の大半は事後ドキュメント作業として、時間圧力下で 1-2 人のエンジニアが楽観的評定を付け、RPN を快適に保つように作成されている。それは設計に何の影響も与えない、コンプライアンス演劇であってエンジニアリングではない」
ドメイン依存の影響定義の欠如: 「Severity 評定に組織固有の例を加えるとチームは尺度を使いやすくなる。各列で customer satisfaction failures、環境衛生・安全のトピックを分けて記述」
Severity と Priority の混同: 「Severity = どれくらい影響が悪いか(客観・顧客向け)。Priority = どの順で取り組むか(severity + effort + 依存関係 + タイミング)」
Severity インフレと尺度数の多さ: 「全てが SEV1 なら何も SEV1 でない。6-7 個のレベルは判別できず分類麻痺を生む。3-5 個がスイートスポット」
境界が動く問題: 「Delighters は時間とともに satisfier → mandatory に変わる」。Kano に限らず重大度の境界は環境変化で再評価が必要。

4.5 再現性を保つための原則(NIST 由来)

「NIST のゴールは完璧な数字ではなく、一貫し弁明可能で繰り返し可能なプロセス — 意思決定者が行動でき、時間を超えて比較できる結果を生み出すもの」

フレームワーク比較マトリクス

Framework	採用次元	評定尺度	不可逆性	機会費用	Scope 階層	再現性メカニズム
ITIL Priority Matrix	Impact × Urgency	通常 3×3 か 5×5 順序尺度	×	△(Urgency に内在)	個人/VIP/部門/全社	各レベルの文章定義 + ITSM ツール統合
CVSS v3.x	Exploitability(AV/AC/PR/UI)× Scope × CIA	0.0–10.0 連続 + 5 段ラベル	×	×	2 値 (Unchanged/Changed)	Vector string で全評定明示化、Roundup 標準化
FMEA RPN / AP	Severity × Occurrence × Detection	1–10 順序尺度(積)	△(S=10 へ吸収)	×	顧客/ユーザ視点のみ	AIAG/VDA 標準アンカー、各社例追加
SEV1–SEV5 ladder	Impact(scope+criticality)+ 暗黙 Urgency	カテゴリ(SEV1–5)	×	×	50%/10%/個別ユーザ等	具体例+測定可能基準 + Sev/Priority 分離
RICE	Reach × Impact × Confidence ÷ Effort	数値+カテゴリ(3,2,1,0.5,0.25)+ %+ person-months	×	△(Effort)	Reach の数値で表現	Confidence で証拠強度を明示
ICE	Impact × Confidence × Ease	1–10 順序尺度	×	△(Ease)	なし(批判点)	スコア定義の事前合意
WSJF / CD3	(BV + TC + RR/OE) ÷ Job Size	Fibonacci 1,2,3,5,8,13,20(WSJF)/ $/time(CD3)	△(Risk Reduction に内在)	◎(Time Criticality + CoD)	なし	CD3 では金額化、WSJF は相対基準
Kano	カテゴリ分類	機能/非機能 2 問アンケート × 5 段階	×	×	顧客満足ベース	標準化アンケート + 顧客検証
One-Way/Two-Way Door	Reversibility	2 値	◎(中核次元)	×	なし	「30日以内に元に戻せるか」基準
ISO 31000 5×5	Likelihood × Consequence(多ドメイン)	5×5 順序尺度、Score 1–25	×	×	多ドメイン(財務/運用/評判/安全/規制)各 5 段階	各レベルに頻度+金額閾値、固有/残余の二重評価
NIST SP 800-30	Likelihood × Impact	Very Low–Very High または 0–100 半定量	×	×	組織/業務/システムの 3 階層	reproducibility/repeatability を明示要件化

ユーザのドラフトに対する明示的ギャップ分析

Must-have(必須・追加すべき)

Confidence(証拠強度)次元の追加

理由:ユーザのハード制約「verbatim evidence からの説明可能性」を直接担保する。RICE/ICE の Confidence と同じ構造で、draft 中の引用・データ言及・「未確定」表現の量で機械的に評定可能。
推奨スケール:RICE 流の 100%/80%/50%/<50%(High/Medium/Low/Moonshot)。「Confidence は %、100%=高、80%=中、50%=低、それ以下は moonshot」
短文での運用:draft に定量データへの参照があれば High、定性的根拠のみなら Medium、根拠なし主張なら Low。

各次元レベルの「verbatim trigger 語彙」のアンカー化

理由: 「良い定義のテスト:2人のエンジニアが同じデータから独立に同じ severity 分類に到達できるか」
実装:blast radius "team" = draft 中に「self / my workstation / personal」のみ出現する場合、等の Trigger-based ルール。
これは NIST が明示する「再現性 = 異なる専門家が同じデータから同じ結果を生み出す」要件を満たす唯一の現実的手段。

Urgency / Time-criticality の最小限の取り込み

理由:ITIL の核次元かつ、blast radius 単独では「現在影響中」と「将来発生する可能性」を区別できない。「ITIL では impact と urgency を分けることが核」「同じ少数ユーザ影響でも、給与処理直前の payroll 問題は high urgency」
推奨実装:irreversibility class A/B/C の中の B(chronic-compounding)に時間軸を内在化させているなら、明示的に「猶予時間」次元として切り出すと再現性が上がる。

Should-have(あれば望ましい)

Likelihood / Probability の質的注記

理由:現状の 3 次元は「もし発生したらどうなるか」(後果)のみで、「どのくらいの確からしさで起こるか」が欠落。NIST/ISO 31000 では Likelihood × Impact が標準。
draft 段階の制約:発生確度は draft 中に書かれていない場合が多いため、ハード必須にはせず「該当語彙があるとき昇格」のオプトイン採用が現実的。

harm domain 内の影響金額帯の文書化

理由: 「同じセルを共有しても、片方は管理可能な罰金、もう片方はフランチャイズレベルの損害 — 財務・非財務帯が書き出されていない限り」
実装:compliance / revenue / 業務効率の各ドメインに対し、「軽微 / 中度 / 重大」の典型金額帯を 1 行で明示。

blast radius と harm domain の組合せでの「致命セル」明示

理由:FMEA の Action Priority、ISO 31000 のレッドゾーンに対応。「Severity 9-10 はどんな RPN でも自動的にアクション必要」のような「lookup-table 型」ルール。
実装:irreversibility A × blast radius "whole-product 以上" は常に「solving worth = High」、など。

Nice-to-have(オプション)

CVSS v4.0 のような専門家コンセンサスベースの境界補正

- 「専門家比較データを使い、ベクタを最重要度の高い順に並び替え、後方互換性のある質的境界を決定」

solo operator では実装不可だが、自分自身の過去判定のリプレイで境界をキャリブレートできる。

Severity vs Priority の明示分離

- 「severity はインシデントの属性、priority は応答者の決定」

ユーザのパイプラインでは「solving worth(severity 系)」と「実際にいつ着手するか(priority 系)」を分離すべき。前者だけが本フレームワークの対象。

採用しない方が良いもの

Effort 次元(WSJF 分母):draft 段階では実装規模が判明していない。「Denominator gaming through feature slicing: チームはエピックを小さな部分に分割すれば Job Size が減ることを学ぶ」のように、評定の歪みを生む。
Detection 次元(FMEA):意思決定の「価値」評価には情報運用次元として遠い。
CD3 ドル建て: 「ソフトウェア会社では不可能に思えた」のとおり、draft の verbatim から数値化困難。

参考文献(URL付き)