← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 20:19
commonid: adr-0040type: adrstatus: superseded
pagemode: Standardkruchten: Propertyscope: platformimplementation_status: Not Startedproposed_at: 2026-05-14 20:15approved_at: -deciders: [email protected] (単独)business: meta
型付き辺: 出 4 / 入 1
関連: ADR-0021 ADR-0028 ADR-0029 ADR-0034 置換された: ADR-0043全体は INDEX →

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

  • Status: Superseded
  • Superseded by: ADR-0043
  • Mode: Standard
  • Kruchten Type: Property
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-14 20:15
  • 承認日時 (JST): -
  • Deciders: [email protected] (単独)

コンテキスト

1.1 背景 (Background)

ADR-0028(全体6段ワークフロー)はD1フェーズの起点として「JTBD(Jobs To Be Done)選定」を前提とするが、「JTBDとして認められる業務粒度」の明示的な定義が存在しない。ADR-0034(Stage 1-2 ワークフロー定義)はD1〜D4の操作手順を定めているが、D1の入力である「どの業務をJTBDとして立てるか」の判断基準は「担当者の暗黙知」に委ねられたまま運用されている。

1.2 現状 (Current State / As-Is)

RQ合成率の現況(2026-05-14 実測):

  • 生成済みRQユニーク番号: 43件(RQ-001〜043)
  • synthesis.md 完成: 4件
  • synthesis未完成: 39 / 43 RQ(90.7%)
  • 1 RQ あたり所要時間(ADR-0034 §1.3記載): D1〜D4 合計 3〜4時間
  • 粒度ミスで再スコープが必要になった場合の潜在損失: 39件 × 3h = 117h〜156h

確認済みJTBD重複事例: 「証憑取込 × OCR精度改善」と「月次決算 × OCR品質向上」が別ファイルとして起案される事案が1件発生(2026-05-14確認)。粒度定義なしでは同様の重複がサイレントに蓄積する。

遡及確認工数(既存RQ43件への本ADR適用):

  • 1件あたり確認時間: 15分(RQタイトル・スコープ読み取り + 3軸テストチェック)
  • 対象件数: 43件
  • 遡及確認合計工数: 43 × 0.25h = 10.75h(≈ 11h)
  • 粒度ミスが発見された場合のリスコープ: 推定2〜3件 × 1h = 2〜3h
  • 遡及対応総工数: 11h + 2h = 13h(上限)

1.3 課題 (Problem)

JTBD粒度の暗黙知運用により以下の下流影響チェーンが発生している:

  1. D1(痛みスキャン): JTBDが大きすぎると1件に多数の痛みが混在 → D2のRQプロンプトが発散
  2. D2(RQ起案): 粒度ルールなしでは scripts/5 の出力品質が安定しない
  3. A1(課題仮説記述・ADR-0029): JTBDから課題仮説へのマッピングが非決定的になる
  4. Customer Insight エージェントペルソナ: 「月次決算」1枚か「証憑取込」「銀行消込」各1枚かでペルソナ粒度が揺れる

1.4 制約・要件 (Constraints & Requirements)

  • 3軸テスト(ゴール/時間/役割)を判定基準として採用すること
  • 境界事例は証憑取込sub-step判定と採用TCO隣接JTBD判定の2件を必ず含めること
  • 関連ADR(ADR-0021/0028/0029/0034)の整合性を本文で明示すること
  • 代替案比較表に定量スコア(各軸5点満点)を付与すること
  • ロールバック手順(revert順序)を明記すること
  • 遡及確認工数(43件 × 15分 = 11h)を数値化すること

1.5 目標 (Goals / To-Be)

JTBD粒度判定の3軸テスト(達成可能ゴール / 実行時間 / 担当役割)をADRとして明文化し、Customer Discovery・RQ設計・エージェントペルソナ設計の全ワークフローから共通参照可能なSSoT(_jtbd_list.md)を確立する。Non-Goals: 既存JTBD命名規則の刷新、UCスライス粒度の同時定義(ADR-0021範囲のため対象外)。

決定

JTBDとして立案する業務単位は以下の3軸テストをすべて満たすものとする。承認済みJTBDは docs/_internal/customer_insight/_jtbd_list.md をSSoTとして一元管理し、Customer Discovery / RQ設計 / エージェントペルソナ設計の各ワークフローから本ADRと当該リストを参照する。

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

  • OK例: 月次決算(財務諸表3表が確定し確認完了)
  • NG例: 経理業務全般(範囲が広すぎ、完了が定義できない)

【2】実行時間軸: 1回の実行が1時間〜3営業日の範囲で完結する(反復は別サイクル)

  • OK例: 月次決算(月1回、2〜3営業日)
  • NG例: 証憑OCR読取り単体(5分で完了 → 上位JTBDのsub-stepとして扱う)

【3】担当役割軸: 本プロジェクトで単一の役割(代表取締役)が通しで実行できる

  • OK例: 採用TCO試算(社長として単独で判断・完了)
  • NG例: 外部監査法人との連携が必要な年次監査(外部アクターが必須)

境界事例:

  • 事例1 — 証憑取込(sub-step判定): 「証憑PDFをOCRしてGoogleドライブに格納する」は実行時間軸ではOKに見えるが、達成可能ゴール軸でNG。証憑取込単体では財務諸表に反映されず、月次決算というJTBDの中間状態にすぎない。→ 「月次決算」JTBDの内部ステップとして扱い、独立JTBD立案は禁止。
  • 事例2 — 採用TCO試算(隣接JTBD判定): 「採用した場合のTCO(人件費・機器・教育費)を試算する」は3軸テストをすべて満たし独立JTBDとして成立する。「資金繰り予測」とのデータ共有はあるが「完了ゴール」と「担当役割」が別定義であるため別JTBDとして並立する。同じRQプロンプトで両方を扱わないよう、RQ設計時に参照範囲を明示する。

検討した代替案 (Alternatives Considered)

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

評価軸(配点)A: 現状維持B: プロンプト内定義C: ADR明文化(本案)
一貫性(5点)1点(暗黙知依存、RQ間で揺れる)2点(セッション内のみ安定)5点(全ワークフロー共通参照)
変更追跡性(5点)1点(変更記録なし)2点(プロンプトのdiff追跡のみ)5点(ADR改訂として下流影響明示)
重複防止効果(5点)0点(なし)2点(セッション内のみ)4点(スコープチェックの定型化)
合計2/156/1514/15
  • 案 A: 現状維持 — 不採用理由: スコア2/15。暗黙知依存により重複事案が既に発生しており、サイレントな粒度違反蓄積を防げない。
  • 案 B: プロンプト内定義 — 不採用理由: スコア6/15。セッション内のみ安定で、横断ワークフロー(D1 / A1 / エージェントペルソナ)から共通参照できない。変更履歴もプロンプトdiffに分散する。
  • 案 C: ADR明文化(本案) — 採用。スコア14/15。下流ADR(ADR-0021/0028/0029/0034)との整合を明示でき、SSoT(_jtbd_list.md)による重複防止の定型化が可能。

影響 (Consequences)

5.1 正の影響 (Good)

  • 3軸テストにより RQ-001〜043 を含む既存・新規RQの粒度判定が決定的になり、D2のRQプロンプト発散が抑止される。
  • _jtbd_list.md をSSoTとすることで、Customer Insight エージェントペルソナの粒度揺れ(「月次決算」1枚 vs 「証憑取込」「銀行消込」各1枚)が解消する。
  • 関連ADR(ADR-0021/0028/0029/0034)の前提条件として本ADRを参照することで、ワークフロー全体の整合性チェーンが確立する。
  • 重複事案(「証憑取込 × OCR精度改善」と「月次決算 × OCR品質向上」)タイプのサイレント蓄積を防止できる。

5.2 負の影響 (Bad)

  • 遡及確認工数 11h + リスコープ予備2h = 最大13h が発生する(既存43件に対する3軸テスト適用)。
  • 純粋なRQ再スコープ防止のROIは投資回収9.3年と長く、定量便益単独では正当化しにくい。
  • 3軸テストの解釈揺れ(推定25%)が残り、境界事例判定で起案者裁定が必要になるケースが残存する。
  • 改訂対象ファイル4件(customer_discovery_workflow.md / backlog_pipeline_workflow.md / research_prompts/README.md / 新規 _jtbd_list.md)に実装工数 4.5h を要する。

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

  • ROI根拠: 将来のRQ粒度ミス発生頻度 0.5件/年(現状2件/年 × 防止率75% = 1.5件/年を保守的に0.5件/年と設定)、1件あたりリスコープコスト3h、年間節約 1.5h/年。投資回収: 実装4.5h ÷ 1.5h/年 = 3年(遡及確認11h込みで9.3年)。

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

  • 主目的はワークフロー整合性確保(ADR-0021〜0034への波及防止)であり、RQ再スコープ防止は副次的便益と位置づける。
  • ADR-0034の「前提条件」セクションを更新し本ADRを参照する形に書き換える必要があるが、ADR-0034本文の決定内容は不変。

撤退条件 (Rollback Plan)

本ADR実装後にロールバックが必要となった場合の手順(参照切替順序を厳守):

  1. docs/_internal/customer_insight/_jtbd_list.md を削除(新規ファイルのため単純削除)
  2. docs/_internal/research_prompts/README.md を git revert(JTBD確認手順セクションを削除)
  3. docs/_internal/backlog_pipeline_workflow.md を git revert(A1フェーズJTBD参照を削除)
  4. docs/_internal/customer_discovery_workflow.md を git revert(§2.1 JTBD定義セクションを削除)
  5. ADR-0034の「前提条件」参照を削除(本ADRへの参照を除去)

注意: 手順4→5の順序で実施しないと、ADR-0034が存在しないファイルを参照する状態になる。 ロールバック所要時間見積もり: 約2h(git revert + レビュー)

判定指標: ① 3軸テストの解釈揺れにより起案者裁定が月3件以上発生する状態が2ヶ月継続、または ② SSoT _jtbd_list.md の同期コストが想定(0.5h/月)の3倍以上に膨らむ場合、本ADRを撤退候補とし Review After (要追記) に再評価する。

Confirmation (準拠確認 / Fitness Function)

  • 検証手段:
    1. scripts/adr-lint.mjs 拡張または新規 lint スクリプトにて、新規RQ起案PR時に _jtbd_list.md に存在するJTBDを参照しているかをチェック(JTBD名の機械可読タグを各RQファイル冒頭に必須化)。
    2. 手動レビューチェックリスト(D2レビュー時):「該当RQは3軸テスト(ゴール/時間/役割)をすべて満たすか」「_jtbd_list.md の既存JTBDと重複しないか」の2項目をPRテンプレートに追加。
    3. scripts/4_review_specs_by_gemini.js のレビュー観点に「JTBD粒度3軸テスト適合性」を追加し、自動レビューで違反を指摘可能にする。
  • 実行頻度: 新規RQ起案PRごと(自動 lint + 手動チェックリスト)、四半期ごとに _jtbd_list.md 全件の3軸テスト再確認(0.5h/回)。
  • 違反時の対応: lint失敗時はPRブロック、手動チェックリスト違反時はD2レビュアーがRQ起案者へ差し戻し、四半期レビューで粒度違反が発見された場合は当該RQを再スコープ(該当JTBDの sub-step 化または隣接JTBD分離)。

参照 (References)

  • 関連 ADR:
    • ADR-0021(UCスライス開発と監査ログ機構): JTBDからUCスライスへの変換を前提。粒度が不定だとUCスライス粒度も揺れる。
    • ADR-0028(全体6段ワークフロー採用): D1でJTBD選定を前提とするが定義は委ねられている。本ADRが補完する。
    • ADR-0029(B1-B6/C1-C6詳細ワークフロー): A1(課題仮説記述)でJTBDを暗黙使用。本ADRの基準を適用。
    • ADR-0034(Stage 1-2 ワークフロー定義): D1フェーズ操作手順を規定。JTBD粒度は本ADRを「前提条件」として参照する形に更新。
  • 関連 PR/Issue: (要追記)
  • 外部資料:
    • docs/_internal/customer_discovery_workflow.md(324行、§2.1 改訂対象)
    • docs/_internal/backlog_pipeline_workflow.md(368行、A1フェーズ改訂対象)
    • docs/_internal/research_prompts/README.md(54行、RQ設計セクション改訂対象)
    • docs/_internal/customer_insight/_jtbd_list.md(新規作成、承認済みJTBD 6件のSSoT)