JTBD 完了判定の定量的評価手法調査

調査日: 2026-05-26 調査者: [email protected] 目的: ADR-0043 軸 1（達成可能ゴール軸）の定性判定「この業務が完了した」を定量評価に転換する方法論を 3 vendor で調査する。RQ-049 で推奨された Direction + Metric + Object of control 構文を前提に、計測方法・達成度数値化・集約手法を明らかにする 調査モデル: Gemini 1.5 Pro (Deep Research) / Claude Opus 4.7 / GPT-4o (Deep Research) 先行調査: RQ-049 Synthesis — 3 vendor 一致で「ゴール軸を Direction + Metric + Object of control に強化」を推奨

0. 調査設問

1. Ulwick ODI の Desired Outcome Statement で書いた outcome を、実際の業務完了判定にどう計測・数値化するか？ Importance x Satisfaction Gap 分析はジョブ完了判定にも応用できるか？
2. JTBD 文献 (Ulwick, Christensen, Moesta, Kalbach, thrv) で「ジョブがどの程度完了したか」を段階的・定量的に測る手法はあるか？ binary ではなく continuous/ordinal な評価は可能か？
3. BPM / プロセスマイニングの完了度指標 (cycle time, completion rate, conformance rate 等) を JTBD 完了判定に接続する方法論はあるか？
4. 会計業務 5 件 (月次決算・銀行照合・資金繰り予測・予実差異分析・RPA 自動起票) について Direction + Metric + Object of control 形式の Desired Outcome Statement を各 2〜3 個例示し、それぞれの計測方法を提示せよ
5. ソロ開発 (起案者＝評価者) で月次 < 0.5h の運用コストで回せる定量評価の仕組みを提案せよ

1. サマリー（3-vendor 統合結論）

3 者一致率: 5/6 論点で完全一致 (83%)、1 論点で 2/3 majority (集約方式)

統合判定

統合推奨アーキテクチャ

Layer 1: Desired Outcome Statement (JTBD — 「何を測るか」)
  [Minimize/Maximize] the [Metric] of [Object of control] [Contextual clarifier]
  Metric は time / likelihood / number / % の 4 種に限定 (Ulwick 原典準拠)
      ↓
Layer 2: Achievement Score 0.0〜1.0 (BPM — 「どう測るか」)
  minimize 系: score = clamp((baseline - observed) / (baseline - target), 0, 1)
  maximize 系: score = clamp((observed - baseline) / (target - baseline), 0, 1)
      ↓
Layer 3: Job Completion Score (集約)
  主指標: JCS = min(outcome_scores)         ← ボトルネック検出
  補助指標: JCI = Σ(w_i × score_i) / Σ(w_i)  ← トレンド可視化

ADR-0043 軸 1 改訂提案 (3 vendor 方向性一致)

現行 (Before):

軸 1 (達成可能ゴール軸): 「この業務が完了した」と判断できる明確なアウトカムが存在する

改訂案 (After):

軸 1 (達成可能ゴール軸 v2): ジョブに対し、Ulwick ODI 構文 (Direction + Metric + Object of control + Contextual clarifier) に準拠した Desired Outcome Statement が 3 個以上 定義されており、かつ次の 3 条件を満たす:

1. 構文準拠: 全 outcome が 4 要素を備え、Metric は time / likelihood / count / % のいずれかで表現される
2. 計測可能性: 全 outcome に baseline (過去実績) と target threshold が固定され、自動計測比率 ≥ 60%
3. ボトルネック可視化: Min-rule による Job Completion Score が定義され、最低 outcome が一意に identifiable

2. Vendor 別分析

2.1 Gemini 分析 (Deep Research, 14 ページ, 引用 49 件)

Status: DONE (2026-05-26)

固有の貢献:

• Ulwick 構文は 3 要素 (Direction + Metric + Object of control) として整理。Metric カテゴリは「時間」「可能性・確率」「数量」の 3 分類
• Universal Job Map (Bettencourt & Ulwick 2008) の 8 ステップ (Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude) による ordinal 評価を提案
• thrv の Job Execution Metrics (Job Completion Rate / Time to Job Completion / Customer Effort Score) を continuous 指標として推奨
• BPM との接続: Case ID = Job Instance / Activity = Job Step / Timestamp = Outcome 計測根拠。Cycle Time・Conformance Rate・Step Completion Rate が直接転用可能
• Google Sheets を「軽量イベントログリポジトリ」として構成し、AVERAGEIFS / COUNTIFS でリアルタイムダッシュボード構築可能と論証
• 集約方式: 加重平均は Compensatory で致命的。Weakest Link (min 関数) + Gatekeeper (エラー率 > 5% → JCS を強制 0) を推奨。銀行照合の「速いが不正確」シナリオで加重平均が 50% と誤評価する例を図示

業界ベンチマーク:

• APQC: 月次決算 cycle time median 6.4 日 / top quartile ≤ 4.8 日 (n=2,300)
• Hackett Group 2025: "35-57% shorter close cycles" / "~99% JE automation" (Digital World Class)

2.2 Claude 分析 (Opus 4.7, 14 ページ)

Status: DONE (2026-05-26)

固有の貢献:

• Ulwick 構文は 4 要素 (Direction + Metric + Object of control + Contextual clarifier) と明示。Metric は time / likelihood / number / % の 4 種に限定 (Strategyn whitepaper 準拠)
• Opportunity Score (= Importance + max(Importance - Satisfaction, 0)) の bizlp 転用法: Importance = 「監査リスク・経営インパクト」、Satisfaction = 「現状自動化率」に読み替え → outcome 優先順位付けに応用可
• JTBD 文献サーベイ: Ulwick / Christensen / Moesta / Kalbach / thrv の 6 文献を横断比較し「集約スカラーは意図的に避けられている (低スコアが高スコアに隠蔽されるため)」と結論
• BPM 側の理論的根拠: van der Aalst Conformance Checking 4 軸 (fitness / precision / generalization / simplicity)、del-Río-Ortega PPINOT メタモデル (Base / Derived / Aggregated measure)、APQC PCF 8.0/9.0、Six Sigma Cpk/DPMO
• 集約方式: Min-rule (主指標) + Weighted Average (補助指標) のハイブリッド。GQM (Basili 1994) の Goal/Question/Metric 3 層を Sheets 構造に直接マッピング
• 評価者バイアス対策 6 項目: (a) baseline を PropertiesService で凍結 (b) 自動計測比率 ≥ 60% (c) 3-strike rule (d) 過去ベースラインのロック (e) Min-rule の構造的強制 (f) QUnitGS2 による閾値ロジックの単体テスト
• Sheets テンプレート 4 シート構造: outcomes_catalog / measurements_log / dashboard / adr_links。数式例まで提示 (=MIN(FILTER(...)) / =SUMPRODUCT(scores, weights)/SUM(weights))
• Caveats 10 項目: 特に「1-day close は Fortune 500 のみ、ソロ法人は 5-7 営業日が現実的」「STP 99% は auto-generation rate であり no-review rate ではない」が実務的に重要

2.3 GPT 分析 (Deep Research, 5 ページ, 引用 14 件)

Status: DONE (2026-05-26)

固有の貢献:

• Desired Outcome Statement を「達成方向 (方向性) + 性能指標 + 制御対象 (Outcome) + 文脈」の構造で整理
• Opportunity Score は「改善余地の発見」用であり完了度評価には不適切と明言。「むしろ上記の実行性能指標 (時間・率・エラー数など) を測定し、目標値との乖離で評価するのが一般的」
• BPM 指標との接続を「ジョブ = 社内プロセスとみなした上で、その進捗や品質指標を Outcome と対応させる」と簡潔に定式化
• 集約方式: Weighted Average を推奨しつつ、Min-rule は「代替手段」として言及。「初期は均等重み (閾値クリア = 1 点、未達 = 0 点) にしても良い」と段階的導入を提案
• 運用コスト削減: 「可能な限り自動化しつつ、セルフチェックリストで確認」形式を推奨。Balanced Scorecard 的な「複合 KPI ダッシュボード」として各 Outcome の詳細も併記する構成を提案

3. 3-vendor 一致度分析

一致率: 8 論点中 7 論点で一致 (87.5%)。1 論点 (Weighted Average の位置づけ) は 2/3 majority で Min-rule 優先を採用。

分裂点の裁定: 集約方式

Gemini と Claude が「加重平均は Compensatory で致命的誤評価リスクがある」と理論的根拠を示して Min-rule 優先を主張。GPT は実装容易性から Weighted Average を推奨しつつ Min-rule の有用性は認めている。

裁定: Gemini の「銀行照合でスピード 100%・正確性 0% → 加重平均 50% vs min 方式 0%」の例が会計業務の実態 (正確性が致命的) を正確に反映しており、Gemini + Claude の majority を採用する。Weighted Average はトレンド可視化の補助指標として併用。

4. 参照元

Gemini 引用 (主要)

• Ulwick, A. (2005). What Customers Want
• Bettencourt, L. & Ulwick, A. (2008). "The Customer-Centered Innovation Map." Harvard Business Review
• thrv.com (2025). "Job Execution Metrics." JTBD 用語集
• van der Aalst, W. (2011). Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer
• APQC / Wiggins, P. "Cycle Time for Monthly Close." CFO.com (n=2,300)
• The Hackett Group (2025). Digital World Class Finance research

Claude 引用 (主要)

• Ulwick, A. "What is Outcome-Driven Innovation?" Strategyn whitepaper
• Kalbach, J. (2020). The Jobs To Be Done Playbook, ch.4
• Basili, V., Caldiera, G., Rombach, H.D. (1994). "The Goal Question Metric Approach." Encyclopedia of Software Engineering
• del-Río-Ortega, A. et al. (2013). "On the definition and design-time analysis of process performance indicators." Information Systems
• APQC PCF v7.0.5, Category 8.0/9.0 Manage Financial Resources

GPT 引用 (主要)

• Ulwick, A. (2021). "Measure Customer Progress Using JTBD + Outcome-Driven Innovation." JTBD + ODI ブログ
• Mehta, H. (2026). "Month End Close KPIs: Metrics Every Finance Team Should Track." Xenett
• Pandey, A. (2026). "Account Reconciliation Metrics." ScryAI
• thrv.com (2023). "Job Execution Metrics." JTBD 用語集

5. プロジェクトへの示唆

5.1 実装ロードマップ (3 vendor 統合)

段階 1 (直近 2 週間、約 8h):

1. outcomes_catalog シートを新規作成 (5 業務 × 各 2-3 outcome = 約 12 outcome を初期投入)
2. baseline を過去 6 ヶ月の実績から手動計算
3. MC-1 (close 日数) と RPA-1 (STP rate) の 2 つだけ自動計測を実装
4. ADR-0043 を改訂案で更新、軸 1 の判定基準を明示化

段階 2 (1-2 ヶ月後): 5. 自動計測比率を 60% 以上へ拡大 (BR-1, BR-2, VA-2, CF-1 を順に自動化) 6. QUnitGS2 で閾値ロジックの単体テストを追加 7. dashboard の Min-rule alert を実装

段階 3 (3-6 ヶ月後): 8. Cpk / DPMO の RPA-2/RPA-3 導入 9. APQC PCF コードタグでベンチマーク比較レポートを月次自動生成 10. Opportunity Score で次に自動化すべき outcome を四半期ごとに棚卸し

5.2 Sheets テンプレート構造 (Claude 提案ベース、3 vendor 合意)

Sheet 1: outcomes_catalog (マスタ、ADR で変更管理)

Sheet 2: measurements_log (GAS が自動 append)

正規化式:

• Minimize 系: score = clamp((baseline - observed) / (baseline - target), 0, 1)
• Maximize 系: score = clamp((observed - baseline) / (target - baseline), 0, 1)

Sheet 3: dashboard

=MIN(FILTER(measurements_log!D:D, measurements_log!B:B="MC-*", recent=TRUE))
  → Job Completion Score (Min-rule)
=SUMPRODUCT(scores, weights) / SUM(weights)
  → Job Completion Index (Weighted Average)
=ARRAYFORMULA(IF(scores < 0.5, "🔴 BOTTLENECK", IF(scores<0.8, "🟡","🟢")))
  → outcome 別ステータス

5.3 注意事項 (3 vendor 共通指摘)

1. outcome 数は 12 個以下に抑える: Kalbach 自身も "50-150 outcomes のフル ODI 実装は執行困難" と認めている。自動計測対象は 7-8 個が上限
2. スコアインフレ対策: baseline を PropertiesService で凍結し、target 変更は ADR 起票を必須化
3. Opportunity Score の誤用回避: 元来 n≥180 の survey ツール。ソロ法人で自己採点する際は APQC / Hackett / J-SOX の外部基準から importance を参照し、自己判断のみで決めない
4. 月次決算の現実的目標: "1-day close" は Fortune 500 の Digital World Class 帯のみ。ソロ法人の現実的目標は 5-7 営業日 (APQC median 寄り)
5. STP 99% の正確な解釈: Hackett の "99% JE automation" は「仕訳の 99% がシステムから自動生成される」意味であり「人間レビュー無し」ではない。bizlp では auto-generation rate と auto-post-without-review rate を別 outcome に分解する