主：この判断モデルは思想を元に判断モデルを作成した一例であり、絶対の正ではない。
フレームワーク連携前提の“判断ロジック＋契約”。具体の数値・儀式・ボード構成はFrameworkが担う。
役割（この文書の目的）
- 思想に沿って“どう判断するか”の抽象ロジックと不変条件、Framework が実装すべき契約（Policy/Artifacts フック）を定義する正典。
- 具体の数値・儀式・ボード構成は持たない（Framework の責務）。
0. スコープ
- 問題モデル（PM）の型と状態遷移（抽象）
- 意思決定単位（DU）スキーマ
- 目的関数（制約優越）の原則と ROI 序数の定義
- 粒度規則（候補生成ガード／Blocking Frontier／並列化）
- タイブレーク順序（正典）
- 不変条件（Invariant）
- 契約インターフェイス（Policy/Artifacts）
- 抽象アルゴリズム（擬似コード）
- 計測の概念枠
1. 問題モデル（Problem Model）
- 定義: PM = { T: 定義済みタスク群, H: 未定義変数=仮説（=マイクロ課題）群, X: 未特定要因 }
- 目的: 行動リストではなく“意思決定のコンテキスト”。ここからDUを切り出す。
状態遷移（抽象）
- X → H（発見）→ 実験中 → 解像 → T（実装タスクへ分解）
- 逆遷移: TのDoR未達/前提崩壊 → Hに昇格（再検証）
2. 意思決定単位（Decision Unit, DU）
スキーマ（最小）
- id, title, type: Task（実装タスク）/ Hypothesis（仮説=マイクロ課題）/ Sub‑Problem（構造化の器）
- deps_in / deps_out
- readiness: DoR（score or Ready/Not）
- reversibility: Two‑way / One‑way
- blast_radius: Small / Medium / Large
- cod: Cost of Delay（High / Med / Low）
- cost_switch: Context Switch Cost（Low / Med / High）
- roi_explore: 1–5（根拠一行）
- roi_deliver: 1–5（根拠一行）
- action: Explore / Deliver（決定後のPlan/PackageはFW側で生成）
- owner（任意）
定義補足
- Sub‑Problem: 出力は分割案/依存図/優先案。実験/実装は子のHypothesis/Taskが担う。
3タイプの違い（要点）
- Task（実装タスク）
- 目的: 解像済みの価値を実装して出荷する（Deliver）
- いつ使う: DoRを満たし、手順・依存・品質基準が明確なとき
- 必須: DoR/DoD、Rollback（必要に応じて）
- 出力: 動く成果物（コード、設定、資産）
- 完了条件: DoD達成・レビュー/テスト/リリース完了
- 例: 「通知APIを実装」「LP文案を公開」
- Hypothesis（仮説＝マイクロ課題）
- 目的: 不確実性を小さな実験で燃やし、意思決定の確度を上げる（Explore）
- いつ使う: 前提や効果が未検証／タスクのDoR未達のとき
- 必須: Experiment Plan（方法・TB・Exit・倫理リスク）
- 出力: 学習結果（Yes/No/条件付き）と更新された問題モデル、必要なら新たなTask
- 完了条件: Exit基準を満たす学習が得られた
- 例: 「SNS広告のCPAが目標以内に収まるかを検証」
- Sub‑Problem（構造化の器）
- 目的: 大きな課題を“良い切り口”で分割し、依存と優先順位を決める
- いつ使う: 選択肢が多い／複数の仮説やタスクがぶら下がる論点があるとき
- 必須: 分割案・依存図・優先案（アウトプットは“構造化”）
- 出力: 子のHypothesis/Taskの一覧、順序、探索エピックの束ね
- 完了条件: 分解図と優先案が合意され、子アイテムがReady
- 例: 「ユーザー獲得チャネルの設計」「課金方式の選択肢の絞り込み」
即判定フローチャート
- もうやり方が見えているか？
- Yes → Task（Deliverへ）
- No → その“分からなさ”は検証できる仮説か？
- Yes → Hypothesis（Experiment Plan必須）
- No（切り口や範囲の設計が先）→ Sub‑Problem（構造化して子を出す）
型の遷移ルール（昇格/降格）
- TaskがDoR未達/前提崩壊 → Hypothesisへ昇格（Exploreに戻す）
- Hypothesisが解像 → 必要なTaskへ分解してDeliverへ
- 大課題で子が散らばる → Sub‑Problemを立てて束ね、分割と優先を確定
アンチパターン（避けるべき）
- Hypothesisに実装タスクを直接ぶら下げる（実験と実装の混在）
- Sub‑Problemに「実装の完了」を完了条件として持たせる（器が作業を食う）
- 大きな未定義をTaskのまま進める（DoR未達の放置）
- 直線中にJDIを逸脱させる（JDIの禁止領域に触れる変更）
要するに
- Sub‑Problem＝分け方と順番を決める“設計の箱”
- Hypothesis＝分からないことを燃やす“学習の単位”
- Task＝決まったことをやる“実装の単位”
3. 目的関数と ROI（序数）
- 制約優越: 倫理・規制・安全・ブランド等の下限はROI比較に優越（Constraint NGは即却下 or Explore‑Legalへ）。
- 目的関数（概念）: 価値獲得 + 情報価値 − リスク影響 − CoD を最大化。
- 近似スコア（1–5、数値＋短いナラティブ併用）
- ROI_Explore ≈ 失敗確率低減幅 × 失敗時損失 ÷ 探査コスト
- ROI_Deliver ≈ 期待価値 ÷ 実行コスト − 機会費用
- 序数化ガイド（ばらつき低減）
- 各ロールが Low/Med/High（三値）で入力 → 加重平均 → 1–5に写像
- 0未満は1にクリップ、突出は5にクリップ
- 評点は短い根拠文（1行）を必須とし、再評価で上書き可
4. 粒度規則（Blocking Frontier）
- IsBlocking の定義: 当該アイテム未解決により他DUの開始/完了が阻まれる状態（依存/承認/共通資源）。
- 候補生成ガード
- DoR未達のTask→Hypothesisへ昇格（候補化）
- Readyかつ非JDIのTask → 候補化（Deliver側のDUとしてスケジューリングに載せる）
- 依存でブロックするH/サブ課題を候補化
- risk: One‑way×Large または 依存クリティカルは常時候補化（前倒し燃焼）
- JDI適合Taskは候補化せず直行（判定はFrameworkのPolicy.JDI）
- Blocking Frontier フィルタ
- “今の前進を止める最小のDU”＝必須DU、他＝任意DU
- 並列化基準
- 依存グラフで独立な成分は並列可
- ExploreはWIP絞り目、Deliverは共通ボトルネック能力に従う（数値はFramework）
- 飢餓（starvation）回避
- CoD=Highかつ非ブロッキングが連続2バッチ未着手なら、次バッチで割当優先（SLA）
- Prioritizeにaging（滞留週数）を加点要素として反映
スケジューリングヒューリスティック（cost_switchの扱い）
- cost_switch=High のDUは同一ドメインでバッチ化、または実効WIPを−1扱い（FitCapacityで調整）。Decide（選択）には用いない。
5. タイブレーク（正典）
- 規則: ROI差が2以上 → 高い方で即断。差が1以内 → 次の順に判定
1) 可逆性（Two‑way→Deliver寄り／One‑way→Explore寄り）
2) 被害半径（Large→Explore寄り）
3) Cost of Delay（High→Deliver寄り）
4) 依存クリティカリティ（強→Explore寄り）
5) 最短学習時間（time‑to‑knowledge）が短い方
6) 後戻りコスト（rework cost）が小さい方
6. 不変条件（Invariant）
- I1. Hypothesisは必ず“実験計画（ExperimentPlan）”を持ち、実装タスクと混在しない
- I2. TaskのDoR未達はHypothesisへ昇格し、Exploreで扱う
- I3. ADR（意思決定ログ）を1行以上残す（選択/理由/前提/見直し条件）。JDIはADR不要（JDIログで代替）
- I4. JDI は“可逆・小半径・短時間”の領域に限定（禁止領域と閾値はFrameworkが定義）
- I5. One‑way×Largeの決定は、段階コミット/可逆化/逸脱検知の設計を伴う
- I6. Constraint GateはDecideの前段で必ず評価される（制約NGは即却下 or Explore‑Legalへ）
（Frameworkは上記を弱めてはならない。強化は可）
7. 契約インターフェイス（Frameworkが実装すべきフック）
- Policy.DoR(item) -> {score: 0–9, ready: bool}
- Policy.JDI(task, context) -> bool
- Policy.CoD(item, context) -> High/Med/Low
- Policy.WIP(team, context) -> {explore_wip: int, deliver_wip: int}
- Policy.BottleneckCapacity(context) -> W
- Policy.ReevaluationTriggers(context, metrics, events) -> bool
- Policy.Consent(signers, objections) -> proceed: bool
- Policy.RollbackRequired(action, context) -> bool
- Policy.MetricsConfig() -> 指標セット定義
- Policy.ConstraintCheck(item, context) -> {ok: bool, route: Reject|Explore‑Legal|Proceed}
- Policy.IsAgingRescue(item, context) -> bool # 例: CoD=High かつ AgeWeeks≥2
- Artifacts.MakeExperimentPlan(DU) -> ExperimentPlan(min_fields)
- Artifacts.MakeDeliverPackage(DU) -> DeliverPackage(min_fields)
- Artifacts.MakeStructurePlan(DU) -> StructurePlan
- Artifacts.MakeADR(DU, decision, meta) -> ADR(min_fields)
8. 抽象アルゴリズム（擬似コード：改訂版）
loop:
PM = UpdateProblemModel()
candidates = set()
for item in PM:
// 1) JDI（直行）。Policy.JDI は禁止領域/軽量Constraintを内包して判定
if item.type == Task and Policy.JDI(item, ctx):
ExecuteDeliver(item) // 直行（JDIログのみ）
continue
// 2) Task の扱い（Ready判定→候補化 or 昇格）
if item.type == Task:
dor = Policy.DoR(item)
if !dor.ready:
candidates.add(UpgradeToHypothesis(item)) // DoR未達は昇格（Exploreへ）
else:
candidates.add(item) // Ready非JDI Taskは候補化（Deliver側）
continue
// 3) Hypothesis / Sub-Problem の候補生成
// - ブロッカー/大リスク/依存クリティカルは常時候補化
// - 非ブロッキングでも CoD 高 or aging 救済対象は候補化（飢餓回避）
if IsBlocking(item) or IsRiskOneWayLarge(item) or IsDepsCritical(item)
or Policy.CoD(item, ctx) == High
or Policy.IsAgingRescue(item, ctx):
candidates.add(item)
// 4) Blocking Frontier（必須 vs 任意）
must = FilterBlockingFrontier(candidates) // 最小阻害単位
maybe = candidates - must
// 5) スケジューリング（WIP/ボトルネック/切替コスト/aging/CoD）
queue = Prioritize(must, cod_boost=true, consider_aging=true)
+ FitCapacity(
Prioritize(maybe, cod_boost=true, consider_aging=true),
Policy.WIP(team, ctx),
consider_cost_switch=true
)
// 6) 意思決定と実行
for DU in queue:
// Sub-Problem は先に“構造化Explore”として処理し、子へ分解して戻す
if DU.type == Sub-Problem:
plan = Artifacts.MakeStructurePlan(DU) // 分割案/依存図/優先案
ExecuteExplore(plan) // 短時間ワークショップ等
PM = UpdateProblemModelFrom(DU) // 子Hypothesis/Task生成
continue
// 制約ゲートは意思決定前段で必ず評価
gate = Policy.ConstraintCheck(DU, ctx)
if !gate.ok:
if gate.route == Reject:
Log(Artifacts.MakeADR(DU, "Reject", {reasons:"Constraint NG"}))
continue
if gate.route == Explore‑Legal:
DU = EnsureHypothesis(DU) // リーガル/セキュ検証へ
scores = ScoreROI(DU) // ROI_E, ROI_D in 1–5（序数）
choice = Decide(scores, tie_breakers=[
reversibility, blast_radius, Policy.CoD(DU, ctx),
deps_criticality, time_to_knowledge, rework_cost
])
if choice == Explore:
plan = Artifacts.MakeExperimentPlan(DU) // TB＋Exit必須
ExecuteExplore(plan)
else:
pack = Artifacts.MakeDeliverPackage(DU) // DoR/DoD/Rollback等
if Policy.RollbackRequired(pack.action, ctx): AttachRollback(pack)
ExecuteDeliver(pack)
Log(Artifacts.MakeADR(DU, choice, {reasons, assumptions, revisit, signers:Policy.Consent(...)}))
PM = UpdateProblemModelFrom(DU) // 実行結果でモデル即時更新（必要なら）
// 7) 再評価トリガー（緊急は即リループ）
if Policy.ReevaluationTriggers(ctx, metrics, events): continue
EndOfCycle()補足:
- IsAgingRescue は Framework の SLA/aging ルールを参照（例: CoD=High 且つ Age≥2バッチ）
- Artifacts.MakeStructurePlan は Framework が提供（短時間の構造化/分割セッション）
9. 計測（概念）
- フロー: リードタイム、手戻り率、意思決定遅延、Deliver完了率
- 学習: Explore比率、仮説的中率、情報価値の獲得件数（EVSI+）
- 健全性: 重大事故率、ロールバック成功率
- ポートフォリオ: CoD高案件の滞留（aging）とSLA逸脱件数
補足: Metrics の定義・ダッシュボード実装は Framework の責務。
対応マッピング（簡潔）
- 問題モデル更新（T/H/X棚卸し）
- Model §8 loop先頭、Framework ミニバッチ手順(2)
- 候補DUの限定生成（生成ガード）
- DoR未満のTask→Hypothesisへ: Model §4 候補生成ガード、I2
- Readyかつ非JDIのTask→候補化: Model §4、Framework ミニバッチ手順(2)
- 依存でブロック中H/サブ課題→候補化: Model §4
- JDI（≤2h・可逆・被害小）→DU化せず即Deliver: Model §4/§6、Algorithmの直行、Framework 1-3
- One-way×Large/依存クリティカルの常時候補化: Model §4
- 非ブロッキングでもCoD=High/aging救済→候補化（SLA）: Model §4、Framework 1-10/ラベル運用
- Blocking Frontierフィルタ（必須と任意）
- Model §4、Framework チェックリスト
- ROI比較（ROI_Explore vs ROI_Deliver）
- Model §3（序数1–5＋タイブレーク）、§5（タイブレーク順）
- 制約: 倫理/規制/安全/ブランド等はConstraint Gateで前段判定（Model §6 I6、§7 Policy.ConstraintCheck、Algorithm内）
- 被害半径はタイブレーク要素として反映（Model §5）
- リスク予算はConstraintCheckに含めて運用可能（Framework側Policyに載せる想定）
- スケジューリング（WIP＋並列条件）
- Model §4 並列化、cost_switchの扱い（FitCapacityで調整）
- Framework 1-5（WIP/ボトルネック）、cost_switch=Highはバッチ化
- CoD高×agingの救済（SLA）を割当に反映（Model §4 飢餓回避、Framework ラベル/ビュー）
- 実行
- Explore: TB＋Exit（ExperimentPlan必須）: Framework アーティファクト
- Deliver: DoR/DoD/Rollback（必要時）: Framework アーティファクト、Rollback必須条件 1-8
- Sub‑Problem: StructurePlanで構造化→子Hypothesis/Task生成→再評価
- JDIはADR不要（JDIログで代替）: Model §6 I3、Framework 1-3
- 結果でPM更新→再評価トリガー→次ループ
- Model §8 終端とPolicy.ReevaluationTriggers、Framework 1-6（緊急時は即再評価）
- Constraint Gate（ROI比較の前段に）: 制約NGは Reject か Explore-Legal にルーティング
- 飢餓回避（候補生成とスケジューリングの双方で）: CoD=High が2バッチ滞留したら次バッチで必ず割当（sla:rescue）
コメント