← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0034type: adrstatus: accepted
pagemode: Standardkruchten: Existence/Propertyscope: platformimplementation_status: Not Startedproposed_at: 2026-05-14 00:04approved_at: 2026-05-14 00:19deciders: [email protected] (単独)business: mas
型付き辺: 出 6 / 入 1
細分化する: ADR-0028 前提とする: ADR-0025 ADR-0026 関連: ADR-0020 ADR-0029 ADR-0040 部分修正された: ADR-0043全体は INDEX →

ADR-0034: Stage 1-2 ワークフロー定義

  • Status: Accepted
  • Mode: Standard
  • Kruchten Type: Existence/Property
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-14 00:04
  • 承認日時 (JST): 2026-05-14 00:19
  • Deciders: [email protected] (単独)

コンテキスト

1.1 背景 (Background)

ADR-0028 (2026-05-13 Accepted, PR #657) で全体 6 段ワークフローを採用したが、Stage 1 (Discovery / 問題発見) と Stage 2 (Backlog / UC スライス化) の内部サブワークフローは「ADR-0029 / ADR-0030 に委ねる」と明記。実際には ADR-0029 が Stage 4-5 (Spec / Impl Pipeline の B1-B6 / C1-C6) を定義し、ADR-0030 は Kruchten 分類ラベルに転用されたため、Stage 1-2 の詳細はまだ未定義のまま運用されている。

handover_adr-0029_spec_impl_pipeline.md §7 では次の方針が議論済み:

  • Stage 1 = Customer Discovery (D1-D4): scripts/5 + Gemini/Claude Research で問題空間を探索
  • Stage 2 = Backlog Pipeline (A1-A5): 課題仮説記述 → Mom Test 形式確認 → Pain Ranking → Problem-Solution Fit 判定 → UC スライス化 + ADR-0026 同期
  • 顧客開発モデル (Steve Blank Customer Development) の Customer Discovery を GAS 内製開発の文脈に適用
  • Mom Test (Rob Fitzpatrick) の「仮説の語り」ではなく「過去の行動」を尋ねる形式を採用

2026-06-20 corrigendum (ADR-0152 umbrella 化 + ADR-0160 受理): 本 ADR は ADR-0028 6 段ワークフローの Stage 1-2 内部サブワークフロー (D1-D4 / A1-A5) を規定する。ADR-0152 (Accepted 2026-06-15) で ADR-0028 が umbrella 化され、ADR-0160 (Accepted 2026-06-20 PR #2315 / DRP Discovery / Decision ライフサイクル) が Stage 1-4 全体を引き継いだ後も、本 ADR の D1-D4 / A1-A5 内部詳細は不変。本 ADR は Stage 1-2 内部詳細を、ADR-0160 は探索ライフサイクル (Stage 1-4) 全体を担当する二重所属で運用する。本訂正は注記行追加のみで本文改変なし (ADR-0031 corrigendum パターン)。

1.2 現状 (Current State / As-Is)

  • 既存スクリプト: scripts/5_generate_rq_prompt.js (調査依頼起案、起動済)、Gemini Deep Research + Claude Research の Web UI 経由運用
  • 既存ドキュメント: docs/_internal/research_prompts/RQ-NNN_*_{prompt,result_claude,result_gemini,synthesis}.md 形式の研究調査記録、過去 RQ-001〜042 まで蓄積 (42 件)
  • 既存ドキュメント: docs/_internal/usecase_dev_mapping.md で UC × MAS マッピング・slice_id・walking_skeleton_status・now_next_later を SSoT 管理
  • 既存 ADR: ADR-0025 (slice_id 命名規則)、ADR-0026 (slice_id 自動同期 GitHub Actions) が Backlog 同期インフラを提供済
  • 「価値判定 → Backlog 同期」のフローが暗黙運用: 代表取締役の記憶ベースで「これは Now / Next / Later のどこに置くか」を判定、属人化

1.3 課題 (Problem)

  1. Discovery → Backlog の引き継ぎ点が不明確: RQ-NNN_synthesis.md で「解く価値あり」と判定された問題が、いつ・どうやって usecase_dev_mapping.md に登録されるかが口頭運用。RQ 42 件のうち実際に UC スライス化されたのは推定 20 件 (約 48%)、残 22 件は Discovery で止まったまま追跡不能
  2. Mom Test 形式の欠如: 課題仮説が「あったら便利だろう」レベルで記述されることがあり、Steve Blank の「過去の行動を尋ねる」原則が破られる。Pain Ranking の精度が下がる
  3. Problem-Solution Fit 判定基準の暗黙化: 「Now にすべき問題」と「Later でよい問題」の境界が不明確、代表取締役の直感ベース
  4. Jr 入社後の独学コスト: Stage 1-2 の運用ルールがドキュメント化されておらず、後任が問題発見 → UC スライス化までの流れを再現できない

1.4 制約・要件 (Constraints & Requirements)

  • ADR-0001〜0033 の本文は不変 (イミュータブル原則)
  • 既存 scripts/5 / Gemini-Claude Research / usecase_dev_mapping.md / ADR-0026 自動同期 のインフラは活用
  • 既存 RQ-NNN_*.md 42 件は不変 (遡及記述変更なし)
  • Stage 4-5 (Spec/Impl Pipeline) と整合 (B1 = UC スライス選定 = A5 完了 = Backlog に積まれた状態を前提)
  • 1 サイクル (D1 → A5) の所要時間 ≤ 4 時間 (Stage 1-2 が重すぎると価値判定が遅れ Stage 3 に進めない)

1.5 目標 (Goals / To-Be)

  • Stage 1 (Discovery) を D1-D4 の 4 段サブワークフローとして正式採用
  • Stage 2 (Backlog) を A1-A5 の 5 段サブワークフローとして正式採用
  • Discovery → Backlog の引き継ぎ点 (D4 → A1) を明示し、追跡不能 RQ をゼロに
  • Mom Test 形式 + Problem-Solution Fit 判定基準を明文化
  • Jr 入社後の Stage 1-2 学習コストを 30 分以内 (README ガイドで完結)

決定

Discovery (D1-D4) + Backlog (A1-A5) サブワークフローを 1 つの ADR として一括採用する。Stage 1 (Customer Discovery) を「問題空間スキャン → 調査依頼起案 → 並列 Deep Research 実施 → 結果合成 + 価値判定」の 4 段に、Stage 2 (Backlog Pipeline) を「課題仮説記述 → Mom Test 形式確認 → Pain Ranking → Problem-Solution Fit 判定 → UC スライス化 + 自動同期」の 5 段に定義し、各段の担当ツール・完了条件・判定基準を明文化する。Steve Blank Customer Development + Rob Fitzpatrick Mom Test の業界標準を採り入れつつ、既存 scripts/5 / Gemini-Claude Research / usecase_dev_mapping.md / ADR-0026 自動同期インフラを改修なしで活用する。

前提条件

ADR-0043 (JTBD 粒度定義標準、2026-05-15 Accepted) が本 ADR の前提条件として追加された。D1 で痛みポイント候補を抽出し D2 で RQ を起案する前に、対象の業務が docs/_internal/01_discovery/customer_insight/_jtbd_list.md の承認済み JTBD（3 軸テスト合格）に紐付いていることを確認する。本 ADR の決定内容・判定基準は変更しない。

2.1 Stage 1: Customer Discovery 内部 4 段 (D1-D4)

#段担当ツール / 担当者完了条件
D1問題空間スキャン手動 (代表取締役月次振り返り + 運用ログ集計)痛みポイント候補 ≥ 3 件のリストアップ (docs/_internal/TODO_future.md に記録)
D2調査依頼起案scripts/5_generate_rq_prompt.js (Gemini で RQ プロンプト生成)docs/_internal/research_prompts/RQ-NNN_*_prompt.md 作成済、問題仮説と調査観点が明示
D3並列 Deep Research 実施Gemini Deep Research + Claude Research (Web UI 経由)両エンジン結果が RQ-NNN_*_result_{gemini,claude}.md に保存済
D4結果合成 + 価値判定手動 (synthesis ドキュメント作成、Mom Test 観点で再検証)RQ-NNN_*_synthesis.md 完成、判定区分 (「解く価値あり (Backlog 行き)」 / 「対象外 (Closed)」 / 「再調査必要 (D2 戻り)」) を明記

2.2 Stage 2: Backlog Pipeline 内部 5 段 (A1-A5)

#段担当ツール / 担当者完了条件
A1課題仮説記述手動 (docs/_internal/usecase_dev_mapping.md 編集)痛みの記述 + ユーザー (誰が困るか) + 影響 (どのくらい困るか、月次頻度・規模) を 3 行以内で記述
A2Mom Test 形式確認手動 (代表取締役本人の過去行動を 3 件以上想起)「仮説の語り」(○○があったら便利) ではなく「過去の行動」(先月 N 回手作業した) の形式に再記述、検証可能な仮説のみ通す
A3Pain Ranking手動 (Pain Score = 頻度 × 痛み × 影響範囲 の 5 段階スコア、ADR-0020 の Bezos Type 1/2 補助)Pain Score 算出済、bizlp 月次運用上の他課題との相対順位を明示
A4Problem-Solution Fit 判定手動 (Discovery の synthesis を引いて、解決策が概念的に妥当か検証)「Problem-Solution Fit あり」 = Now Bucket、「概念は妥当だが実装制約あり」 = Next Bucket、「未検証 / 妥当性不明」 = Later Bucket、「対象外」 = Closed、のいずれかに分類
A5UC スライス化 + 自動同期手動 (usecase_dev_mapping.md 編集) + ADR-0026 sync_slice_id.yml 自動実行slice_id 採番 (UC-{N}-S{NN}、ADR-0025 準拠)、walking_skeleton_status=pending、now_next_later=Now/Next/Later、関連 RQ-NNN リンクを記録

2.3 判断基準 (重み付き)

  1. 属人化リスク低減 (最重要) — Stage 1-2 の各段の担当ツール・完了条件・判定基準を明文化、Jr 入社後の再現性確保
  2. 既存インフラの最大活用 (高) — scripts/5 / Gemini-Claude Research / usecase_dev_mapping.md / ADR-0026 を改修なしで活用、新規実装は最小限
  3. Customer Development 原則準拠 (高) — Steve Blank Customer Discovery + Rob Fitzpatrick Mom Test の業界標準を取り入れ、外部知識との接続性確保
  4. Stage 3-6 (Spec/Impl Pipeline) との整合 (高) — A5 完了 = B1 (UC スライス選定) の前提条件、Stage 間引き継ぎを明確化

検討した代替案 (Alternatives Considered)

  • 案 A (採用): Discovery (D1-D4) + Backlog (A1-A5) を 1 つの ADR-0034 として一括採用 — 採用理由: Stage 1-2 の引き継ぎ点 (D4 → A1) が同一 ADR 内で明示され境界が明確。Steve Blank Customer Development + Rob Fitzpatrick Mom Test の業界標準を取り入れ外部知識との接続性確保。既存 scripts/5 / Gemini-Claude Research / usecase_dev_mapping.md / ADR-0026 自動同期を最大活用、新規実装最小。ADR-0028 §決定で「ADR-0030 で対応」と委譲された分の宿題を回収 (実際は ADR-0030 が Kruchten に転用されたため未対応のまま放置されていた)。
  • 案 B: Discovery (D1-D4) のみ ADR-0034、Backlog (A1-A5) は後日 ADR-0035 — 不採用理由: D4 → A1 の引き継ぎが ADR をまたいで曖昧になる、ADR-0029 で同じパターン (B6 → C1 引き継ぎ) を避けた判断と矛盾。Discovery 単体では Backlog 同期が動かず、Stage 2 暗黙運用が継続。
  • 案 C: ADR-0028 に Stage 1-2 詳細を遡及追加 (本 ADR-0034 不要) — 不採用理由: ADR-0028 が Critical サイズ (400 行超) になり全体フレームワークと内部詳細が結合。ADR-0028 はイミュータブル原則準拠で本文編集不可、新 ADR が必要。
  • 案 D: Stage 1-2 を明文化せず暗黙運用継続 (現状維持) — 不採用理由: 追跡不能 RQ 22 件が継続、Jr 独学コスト固定化、Pain Ranking の精度低下が続く。
  • 案 E: Customer Development を完全に外部委託 (BizDev コンサル等に Stage 1-2 を任せる) — 不採用理由: 1 人法人で外部委託コストが過大 (月 [MASKED:AMOUNT]k 想定)、業務知識の社内蓄積が止まる。bizlp の「外部ツールロックイン受容不可」方針と矛盾。

影響 (Consequences)

5.1 正の影響 (Good)

  • Discovery → Backlog 引き継ぎの明示化: D4 判定区分 (「解く価値あり」/「対象外」/「再調査必要」) と A1-A5 の完了条件で、追跡不能 RQ をゼロに近づける (現状 22/42 件 ≈ 52% から 0 件目標)
  • Mom Test + Problem-Solution Fit の明文化: A2 で「過去の行動」形式を必須化、A4 で Now/Next/Later/Closed 判定基準を明示、Pain Ranking 精度向上
  • 既存インフラ活用: scripts/5 / Gemini-Claude Research / usecase_dev_mapping.md / ADR-0026 を改修なしで利用、新規実装は workflow .md 2 件のみ
  • Jr 学習コスト削減: README ガイド 2 ファイル整備で Stage 1-2 学習 30 分以内
  • 年間削減効果: 追跡不能 RQ 削減 ([MASKED:AMOUNT]/年) + Pivot 率低下 ([MASKED:AMOUNT]/年) = 年 [MASKED:AMOUNT] 削減見込み、投資回収約 2.5 ヶ月

5.2 負の影響 (Bad)

  • 9 段サブワークフローの学習負担: ADR-0029 の B1-B6 + C1-C6 と合算で 全 21 段 になり Jr 学習負荷大 (ADR-0029 完了条件 #13 の簡易チートシートで緩和)
  • 手動段が多い (D1 / A1-A4 = 5 段): LLM 自動化は不採用、人間判断を維持。Customer Discovery は業務知識・直感が本質だが、形骸化リスクあり
  • Mom Test の主観性: 「過去の行動」が思い出せない場合の代替手段は本 ADR では未定義、将来 ADR で対応 (シャドウイング・観察等)

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

  • 手動段の形骸化リスク: 6 ヶ月後に D1 / A1-A4 が形式的通過になる可能性 → PR テンプレで判定根拠の必須記入を ADR-0029 完了条件 #13 で対応済

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

  • コスト試算: 起案 + Accepted 化 + マージ 1.5h ($3) / customer_discovery_workflow.md 2h / backlog_pipeline_workflow.md 2h / usecase_dev_mapping.md 列追加 1.5h / docs/_config.json 0.25h / RQ-043 初回実走 1.5h ($5) = 合計 約 8.75 時間、約 $8 (≈ [MASKED:AMOUNT])
  • 影響範囲:
    • 新規作成: docs/_internal/customer_discovery_workflow.md、docs/_internal/backlog_pipeline_workflow.md
    • 既存編集: docs/_internal/usecase_dev_mapping.md (「関連 RQ-NNN」列追加)、docs/_internal/TODO_future.md (D1 完了条件として運用継続・規約明文化)、docs/_config.json (nav 登録)
  • 将来 ADR 委譲: Mom Test 代替手段、Pain Ranking 自動化、Discovery → Backlog GitHub Actions 自動同期
  • 完了条件 (定量メトリクス):
    1. ADR-0034 Accepted 化: grep -E "^- \*\*Status\*\*: Accepted" docs/adr/0034-*.md → exit 0
    2. customer_discovery_workflow.md 存在: test -f docs/_internal/customer_discovery_workflow.md → exit 0
    3. backlog_pipeline_workflow.md 存在: test -f docs/_internal/backlog_pipeline_workflow.md → exit 0
    4. usecase_dev_mapping.md に「関連 RQ」列追加済: grep -c "関連 RQ" docs/_internal/usecase_dev_mapping.md → >= 1
    5. docs/_config.json に nav 登録: grep -cE "customer_discovery_workflow|backlog_pipeline_workflow" docs/_config.json → 2
    6. RQ-043 (動作確認用) で D1-D4 + A1-A5 を初回実走済: ls docs/_internal/research_prompts/RQ-043_* → 4 ファイル (prompt + result × 2 + synthesis)、grep "UC-N-S" docs/_internal/usecase_dev_mapping.md で新規 slice_id が追加
    7. CI markdown-link-check PASS
  • 観測指標 (月次):
    • D1 → A5 通過時間 (中央値): 目標 < 4 時間
    • D4 「対象外 (Closed)」判定率: 目標 30-50%
    • A4 「Now」判定率: 目標 10-20%
    • 追跡不能 RQ 数 (D4 結論なし): 目標 0 件

撤退条件 (Rollback Plan)

判定指標閾値判定タイミング対応
9 段が重くて Stage 1-2 サイクル時間 > 8 時間月次集計で平均 8h 超1 ヶ月後 Review AfterD1 と D4 を統合 (3 段化)、A2 と A3 を統合 (4 段化)
Mom Test の主観性で判定不能ケース頻発月 3 件超 「過去の行動が思い出せない」発生月次振り返りA2 を任意化、シャドウイング ADR を起案
Discovery → Backlog 引き継ぎ点で追跡不能発生月次集計で D4 → A1 引き継ぎミス 1 件超月次振り返りsync_discovery_to_backlog.yml (GitHub Actions) を起案
Jr 入社後「9 段が重い」フィードバック月次 1on1 で × 評価 2 ヶ月連続Jr 入社後月次 1on1D1-D4 を「Discovery」1 段に、A1-A5 を「Backlog 化」2 段に簡略化

Review After

  • 1 ヶ月後 (2026-06-13): RQ-043 で初回実走、各段の所要時間と詰まりポイント記録
  • 3 ヶ月後 (2026-08-13): UC-2 / UC-3 で複数スライス実走、形骸化候補段の特定
  • 6 ヶ月後 (2026-11-13): Jr 入社後の運用感ヒアリング、21 段 (D + A + B + C) の統合チートシート整備状況確認

Confirmation (準拠確認 / Fitness Function)

本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。

  • 検証手段: N/A (ワークフロー定義ドキュメントのため実装検証対象外)
  • 実行頻度: —
  • 違反時の対応: —

参照 (References)

  • 関連 ADR:
    • ADR-0028 (全体 6 段ワークフロー、Stage 1-2 詳細委譲元)
    • ADR-0029 (Stage 4-5 Spec/Impl Pipeline B1-B6 / C1-C6、整合対象)
    • ADR-0030 (Kruchten 分類、当初委譲先だが転用された)
    • ADR-0025 (slice_id 命名規則、A5 で利用)
    • ADR-0026 (slice_id 自動同期 GitHub Actions、A5 で利用)
    • ADR-0020 (Bezos Type 1/2、A3 補助)
    • ADR-0043 (JTBD 粒度定義標準、D1/D2 開始前提条件として参照)
  • 関連 PR/Issue: PR #657 (ADR-0028 マージ)
  • 外部資料:
    • Steve Blank "Customer Development Model" (Customer Discovery)
    • Rob Fitzpatrick "The Mom Test"
    • docs/_internal/handover_adr-0029_spec_impl_pipeline.md §7