ADR-0043: JTBD粒度定義標準の確立（Customer Discovery / RQ設計 / エージェントペルソナ共通ルール）

• Status: Accepted
• Mode: Standard
• Kruchten Type: Property/Executive
• Scope: platform
• Implementation Status: Done
• 起案者: [email protected]
• 起案日時 (JST): 2026-05-15 17:03
• 承認日時 (JST): 2026-05-15
• Deciders: [email protected] (単独)

1. コンテキスト

1.1 背景 (Background)

ADR-0028 は D1 フェーズの起点として「JTBD 選定」を前提とするが、「JTBD として認められる業務粒度」の明示的な定義が存在しない。粒度ミスで再スコープが必要になった場合の潜在損失は 117h〜156h であり、既に重複事案が 1 件発生している（2026-05-14）。

1.2 現状 (Current State / As-Is)

2026-05-14 実測:

• 生成済み RQ ユニーク番号: 43 件（RQ-001〜043）
• synthesis 未完成: 39/43 RQ（90.7%）
• 潜在損失: 39 件 × 3h = 117h〜156h
• 確認済み JTBD 重複事例: 「証憑取込×OCR 精度改善」と「月次決算×OCR 品質向上」が別ファイルで起案（2026-05-14）
• 解釈揺れ 25% の根拠: 起案メモに「?」「確認要」が付記された RQ が 43 件中 11 件（25.6%）

1.3 課題 (Problem)

下流影響チェーン:

1. D1: JTBD が大きすぎると → D2 の RQ プロンプトが発散
2. D2: 粒度ルールなしでは scripts/5 の出力品質が安定しない
3. A1（ADR-0029）: JTBD から課題仮説へのマッピングが非決定的
4. エージェントペルソナ: 「月次決算」1 枚か「証憑取込」「銀行消込」各 1 枚かで粒度が揺れる

1.4 制約・要件 (Constraints & Requirements)

• 横断ワークフロー（D1 / A1 / エージェントペルソナ）から共通参照可能であること
• 変更履歴が git 経由で追跡可能であること（PR レビュー必須）
• 承認済み JTBD は SSoT（docs/_internal/01_discovery/customer_insight/_jtbd_list.md）で一元管理
• 関連 ADR（ADR-0021 / 0028 / 0029 / 0034）の決定内容は変更しない（ADR-0034 のみ「前提条件」セクションに参照追記）
• RQ-049 外部標準調査（2026-05-15、3 者一致率 100%）の推奨は Review After 2026-11-15 まで案 D として保留

1.5 目標 (Goals / To-Be)

JTBD 粒度の判定基準を 3 軸テストとして明文化し、承認済み JTBD を _jtbd_list.md に集約することで、重複防止と RQ 品質安定化を実現する。3 ヶ月後の成功基準: 3 軸不一致率 < 10% / 起案者裁定 < 月 2 件 / 同期コスト < 0.5h/月。Non-Goals: ADR-0021 / 0028 / 0029 の決定内容変更、外部標準への完全準拠（案 D は将来検討）。

2. 決定

JTBD として立案する業務単位は 3 軸テスト（達成可能ゴール軸 / 実行時間軸 / 担当役割軸）をすべて満たすものと定義する。承認済み JTBD は docs/_internal/01_discovery/customer_insight/_jtbd_list.md を SSoT として一元管理し、git で変更履歴を追跡する。各エントリには承認日・承認 PR 番号・3 軸テスト結果・関連 RQ を記載する。

3 軸テスト（現行）:

1. 達成可能ゴール軸: 「この業務が完了した」と判断できる明確なアウトカムが存在する
   • OK: 月次決算（財務諸表 3 表が確定し確認完了）/ NG: 経理業務全般（完了が定義できない）
2. 実行時間軸: 1 回の実行が 1 時間〜3 営業日で完結する（反復は別サイクル）
   • OK: 月次決算（月 1 回、2〜3 営業日）/ NG: 証憑 OCR 読取り単体（5 分→sub-step）
3. 担当役割軸: 本プロジェクトで単一の役割が通しで実行できる
   • OK: 採用 TCO 試算（社長として単独完了）/ NG: 外部監査法人との連携が必要な年次監査

後任が迷う具体例（解釈揺れ 25% の典型パターン）:

• 銀行照合（月次）: 月次決算の sub-step にも独立 JTBD にも見える → 独立アウトカム（残高一致）があり独立 JTBD と判定
• freee への仕訳入力: 時間軸下限 1h を下回る → sub-step 扱い
• 予実差異分析レポート: 起案者が受領者も兼ねる → 担当役割軸 OK（自己完結できるかを問う軸）
• 年次決算（外部税理士連携あり）: 担当役割軸 NG → 自己完結フェーズを独立 JTBD として切り出す

3. 検討した代替案 (Alternatives Considered)

評価軸（各 5 点満点、合計 15 点）: 一貫性 / 変更追跡性 / 重複防止効果

• 案 A: 現状維持 — 不採用（スコア 2/15）: 暗黙知依存により重複事案が既に発生。サイレントな粒度違反蓄積を防げない。
• 案 B: プロンプト内定義 — 不採用（スコア 6/15）: セッション内のみ安定。横断ワークフロー（D1 / A1 / エージェントペルソナ）から共通参照できない。変更履歴がプロンプト diff に分散する。
• 案 C: ADR 明文化 — 採用（スコア 14/15）: 3 軸テストと _jtbd_list.md SSoT 化により、一貫性・変更追跡性が最大化。
• 案 D: 外部標準改訂案（RQ-049 推奨、Review After 2026-11-15） — 現時点では見送り（スコア 14/15）: 起案時点では調査未完了。3 ヶ月後の成功基準（不一致率 < 10% / 裁定 < 月 2 件）を未達の場合、本案への移行を本格検討する。
  • 実行時間軸 → Appetite 層として分離（JTBD ゲートウェイからは除外）
  • ゴール軸 → Direction+Metric+Object of control に強化
  • 担当役割軸 → Job Executor Consistency 軸に再定義
  • Solution-Free 軸・Stable-over-Time 軸を追加

4. 関連 ADR との関係

• ADR-0021: Reference（上流入力を定義するが、ADR-0021 の決定内容は変更しない）
• ADR-0028: Reference（補完するが決定内容は変更しない）
• ADR-0029: Reference（A1 フェーズに適用するが決定内容は変更しない）
• ADR-0034: Reference・部分更新あり（「前提条件」セクションに ADR-0040 参照を追記。決定内容は変更しない。Supersede/Conflict なし）

5. 影響 (Consequences)

5.1 正の影響 (Good)

• Property 影響: JTBD 粒度判定の横断ルールが確立し、D1 / A1 / エージェントペルソナ間の解釈揺れを 25.6% → < 10% へ低減見込み。
• Existence 影響: docs/_internal/01_discovery/customer_insight/_jtbd_list.md という SSoT エントリが新規導入され、承認済み JTBD の重複検出が機械的に可能になる。
• Executive 影響: 承認プロセスが PR 経由に統一され、変更履歴が git log で追跡可能。
• 潜在損失 117h〜156h の再スコープリスクを抑止。
• adr-lint.mjs --check-jtbd-ref により JTBD 参照の整合性が CI で検証可能になる。

5.2 負の影響 (Bad)

• 既存 43 RQ の遡及確認（_jtbd_list.md 初版マージ時）に追加工数が発生する（要追記: 遡及工数の数値見積もり）。
• 3 軸テストの境界例（銀行照合・予実差異分析など）の判定で起案者裁定が発生し得る。
• PR レビューを必須化することで、JTBD 追加のリードタイムが増加する（数十分〜数時間オーダー）。

5.3 中立・トレードオフ (Neutral / Trade-offs)

• 3 軸テストは現行案であり、RQ-049 推奨の Solution-Free 軸・Stable-over-Time 軸は案 D として保留。Review After 2026-11-15 で再判定する。
• _jtbd_list.md のメンテナンスコスト（目標 < 0.5h/月）が想定を超えた場合、案 D への移行を検討。
• エージェントペルソナの粒度（月次決算 1 枚 vs 証憑取込・銀行消込個別）は本 ADR の 3 軸テストに従うが、運用初期は揺れが残る可能性。

6. 実装計画と Confirmation

6.1 実装完了の定義と数値基準

• PR-α: adr-lint.mjs に --check-jtbd-ref サブコマンド追加（承認から 2 週間以内にオープン）
• PR-β: _jtbd_list.md 初版マージ（遡及確認 43 件の結果を反映）

Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。

• 3 ヶ月後の成功基準: 3 軸不一致率 < 10% / 起案者裁定 < 月 2 件 / 同期コスト < 0.5h/月

6.2 _jtbd_list.md 版管理

git で管理し、承認済み JTBD の変更は必ず PR 経由。各エントリに承認日・承認 PR 番号・3 軸テスト結果・関連 RQ を記載する。

6.3 遡及失敗時の復旧

git log で変更コミットを特定 → git revert → 影響 RQ の frontmatter を修正 → 翌営業日に 5 Whys 分析。

6.4 Review After

2026-11-15（承認から 6 ヶ月後）に案 D（外部標準改訂案）への移行可否を判断する。

6.5 Confirmation (準拠確認 / Fitness Function)

• 検証手段 1（自動）: scripts/adr-lint.mjs --check-jtbd-ref により、RQ frontmatter の JTBD 参照が _jtbd_list.md の承認済みエントリと一致することを CI で検証する。違反時は PR チェック失敗。
• 検証手段 2（自動 + 手動）: _jtbd_list.md の各エントリに 3 軸テスト結果フィールドを必須化し、adr-lint.mjs でフィールド欠落を検出。3 軸判定の妥当性は PR レビューで人手確認。
• 検証手段 3（手動・定期）: 月次レビューで 3 軸不一致率・起案者裁定件数・同期コストを集計し、3 ヶ月後の成功基準（不一致率 < 10% / 裁定 < 月 2 件 / 同期コスト < 0.5h/月）と照合。
• 実行頻度: 検証手段 1・2 は PR 毎（CI）/ 検証手段 3 は月次
• 違反時の対応:
  • CI 失敗 → マージブロック、起案者が JTBD 参照または _jtbd_list.md を修正
  • 月次成功基準未達 → Review After 2026-11-15 を待たず案 D 移行検討を前倒し起案

7. 撤退条件 (Rollback Plan)

• 判定指標: 3 ヶ月後（2026-08-15 目処）の成功基準（不一致率 < 10% / 裁定 < 月 2 件 / 同期コスト < 0.5h/月）を 1 つでも未達。
• 期限: Review After 2026-11-15。
• 代替案: 案 D（RQ-049 外部標準改訂案）への移行 — 実行時間軸を Appetite 層へ分離、ゴール軸を Direction+Metric+Object of control に強化、担当役割軸を Job Executor Consistency 軸に再定義、Solution-Free 軸・Stable-over-Time 軸を追加。
• 遡及失敗時の即時復旧: §6.3 に従い git revert → frontmatter 修正 → 5 Whys 分析。

8. 参照 (References)

• 関連 ADR: ADR-0021 (Reference), ADR-0028 (Reference), ADR-0029 (Reference), ADR-0034 (Reference・部分更新)
• 関連 PR/Issue: PR-α（adr-lint.mjs --check-jtbd-ref 追加、承認から 2 週間以内）, PR-β（_jtbd_list.md 初版マージ）
• 外部資料: RQ-049 外部標準調査（2026-05-15、3 者一致率 100%）
• 関連ファイル: docs/_internal/01_discovery/customer_insight/_jtbd_list.md, scripts/adr-lint.mjs, scripts/5_*