最終更新: 2026/06/22 18:56
commonid: rq-049-synthesistype: research-synthesisstatus: active

RQ-049 調査統合 (Synthesis) — JTBD粒度定義の外部標準と3軸テスト妥当性検証

調査日: 2026-05-15 調査モデル: Gemini Deep Research / Claude Deep Research / ChatGPT (GPT-4o) Deep Research 対象ADR: ADR-0040（JTBD粒度定義標準の確立）

総合判定

3者一致: Partial（部分的整合）

軸GeminiClaudeGPT統合判定
達成可能ゴール軸✓ Keep✓ Keep（文言強化）✓ Keep（Outcomes束まで踏み込む推奨）✓ 維持・強化
実行時間軸△ → Appetite別レイヤー✗ → JTBD外へ分離✗ → 「運用アペタイト軸」に改名分離✗ JTBD粒度層から除外
担当役割軸△ → Context & Dependency軸に改名△ → Job Executor Consistency軸に再定義△ → customer-side performer / internal-side owner に分割△ 再定義必須

3者意見一致率: 3/3（100%） — 実行時間軸の分離、ゴール軸の維持、役割軸の再定義という方向性は完全一致。

統合推奨：改訂軸テスト

現行3軸テストの扱い

現行軸推奨理由（3者共通）
達成可能ゴール軸維持・文言強化Ulwick ODI "desired outcomes" (measurable, stable over time, solution-agnostic) と整合。「Direction + Metric + Object of control が明示できるか」に強化
実行時間軸（1h〜3営業日）JTBD層から分離し Appetite層へ移管JTBD一次文献の中核は "stable over time" と "progress"。時間は delivery planning（Shape Up Appetite / Scrum Sprint）の軸であり、job discovery 理論軸ではない
担当役割軸「Job Executor Consistency（実行者一貫性）」に再定義ソロ法人代表では役割識別力が低い。「単一 Job Executor ロールで一貫実行可能（複数ロールが分断するなら別ジョブ）」として再定義。GPT追記: customer-side performer と internal-side owner を区別する視点も有効

追加推奨軸（3者の提案統合）

優先度軸名内容提唱モデル
高Solution-Free 軸ジョブ文に GAS / Google Sheets / freee 等の解決手段が含まれていないかClaude・GPT
高Stable-over-Time 軸技術変化・法令変更で陳腐化しないか。「freee の API で〜」は不可Claude・GPT
高Syntax 軸Ulwick「verb + object + contextual clarifier」または Christensen「When/I want/so I can」構文に統一されているかClaude・GPT
中抽象度適正軸Moesta の too high / too low を避け、core job と discrete steps が引ける水準かGemini・GPT
中Altitude（階層）軸Main Job か Sub-job かを Kalbach の Why?/How? テストで確認済みかGemini
参考Job Map Decomposability 軸8ステップ（Define→…→Conclude）に分解可能で各ステップが Main Job レベルでないかClaude
参考Wake-up-in-the-morning Test朝起きて「今日これをやらねば」と感じる粒度か（thrv）Claude・GPT間接

最小実装案（ADR-0040 改訂用）

現行3軸を以下の「3軸+Appetite分離」構成に改訂することを推奨:

JTBD粒度ゲートウェイ（3軸）:
  軸1. 完了アウトカム軸: Direction(minimize/maximize) + Metric + Object of control が明示できるか
  軸2. Solution-Free 軸: 解決手段・ツール名に依存しない文言で書けるか
  軸3. Job Executor Consistency 軸: 単一 Job Executor ロールで一貫実行可能か（複数ロール分断→別ジョブ）

Appetite層（開発スコーピング用、JTBD層とは別管理）:
  軸A. 運用アペタイト: 1時間〜3営業日で完結するか（Shape Up / Scrum の設計ルールとして使用）

会計業務粒度評価（3者統合）

業務統合粒度判定推奨アクション
月次決算Main Job（顧客価値上）/ sub-job分解推奨（1h〜3営業日ルール下）SSOT に Main Job として登録。「Close the monthly books on time for the period」に改訂。銀行照合・月次財務レポート確定・差異分析を Sub-job として配下に整理
銀行照合Sub-job / Main Job境界（done状態が非常に明確）Sub-job として管理する場合は「Reconcile bank transactions for the accounting period」と context を明示
資金繰り予測Main Job 妥当（time horizon を clarifier に追加で完成）「今後13週間の資金繰り見通しを把握する」等、horizon を明示する。「資金繰り予測する」のみでは短期・月次・調達説明の job が混在しやすい
予実比較Main Job 妥当（decision-ready な end state に書き直し推奨）「月次の予実差異を把握し、意思決定できる状態にする」のように end state を明示。artifact 名（「予実管理」）のままでは done 判定が曖昧
取引→請求書照合Job Step（Sub-job）独立 Main Job として運用すると粒度が低すぎる。月次決算の Job Map "Execute" ステップに配置

遡及確認（Audit）手順（統合版）

既存ジョブ定義の遡及確認には以下の5問を推奨（3者共通の指摘を統合）:

  1. Syntax: verb + object (+ clarifier) で表現され、solution-specific ではないか
  2. End-State: 完了を判定できる成功条件（desired outcome）を1つ以上書けるか
  3. Stability: 技術変化・法令変更で5年後も成立するか
  4. Executor: 単一 Job Executor ロールで一貫実行可能か（複数ロール分断→別ジョブ候補）
  5. Altitude: Kalbach Why?/How? テストで Main Job / Sub-job の位置づけが確認されているか

3者の立場の違いと本プロジェクトへの適用方針

論点GeminiClaudeGPT本プロジェクト採用方針
追加軸数3→4軸3→6軸3→4+1軸3+Appetite分離（最小実装優先）
役割軸の改名Context & Dependency軸Job Executor Consistency軸customer/internal二分割Job Executor Consistency軸（Ulwick原典に最も近い）
階層表現Altitude軸として独立Job Map Decomposability軸抽象度適正軸**Altitude軸（補助）**として保持
採用ベース理論Ulwick + Kalbach（階層派）Ulwick + Kalbach（階層派）Christensen + Moesta + UlwickUlwick + Kalbach 階層派（実装フレンドリー）

ADR-0040 改訂への反映事項

  1. 3軸テストを「3軸+Appetite分離」に改訂: 実行時間軸を JTBD 粒度層から除外し、Appetite 層（Shape Up / Scrum に連動する設計ルール）として別管理
  2. ゴール軸の文言強化: 「明確なアウトカムが存在する」→「Direction(minimize/maximize) + measurable metric が明示できる」
  3. 役割軸の再定義: 「単一の役割（代表者1名）が実行できる」→「Job Executor Consistency: 単一の Job Executor ロールで一貫実行可能（複数ロールが分断するなら別ジョブ）」
  4. Solution-Free 軸を追加: ジョブ文に解決手段名（GAS / freee 等）が含まれていないかのチェックを義務化
  5. Stable-over-Time 軸を追加: 技術変化・法令変更で陳腐化しないかのチェックを義務化
  6. 会計業務分類の更新: 月次決算=Main Job / 銀行照合・取引照合=Sub-job として整理（本 synthesis の Q4表を参照）