Customer Discovery ワークフロー (Stage 1: D1-D4)

位置付け: ADR-0034 §2.1 で正式採用された Stage 1 (Customer Discovery) の運用詳細。 ADR-0028 全体 6 段ワークフローの Stage 1 = 問題発見フェーズ の内部サブ手順 (D1-D4)。 後段 (Stage 2 = Backlog Pipeline / A1-A5) は backlog_pipeline_workflow.md を参照。

0. このドキュメントの読み方

• 目的: Steve Blank Customer Development の Customer Discovery フェーズを bizlp 文脈 (一人法人 + GAS 内製開発 + 監査要件) に適用し、属人化していた問題発見プロセスを 4 段の追跡可能な手順に明文化する
• 対象読者: 起案者 (代表取締役) / Jr 入社後の後任 / Claude Code (D2 メタプロンプト作成補助)
• 完了の判定: D4 まで通過した RQ-NNN は判定区分 (「解く価値あり」/「対象外」/「再調査必要」) が明記され、docs/_internal/research_prompts/RQ-NNN_*_synthesis.md に記録されている

Stage 1 全体像 (D1-D4)

1 サイクル所要時間目安: D1 (1h 月次振り返り内) + D2 (15min Gemini 生成 + メタプロンプト調整 30min) + D3 (Deep Research wait ≈ 30min × 2 並列、人間作業時間は 30min) + D4 (1-2h 合成 + 判定) = 約 3-4 時間 / RQ-NNN

所要時間目安の補足 (PR #692 Claude/GPT-4o 指摘反映、2026-05-14 追記):

• D3 Deep Research の待機時間 (各 30 分〜数時間) は async、人間作業時間ではない
• 実時間カウント = D1 (1h) + D2 (45min) + D3 人間作業 (30min、起動 + 投入) + D4 (1-2h) = 3-4 時間
• Deep Research 待機中は他作業 (別 RQ 起案 / Stage 2 進行 / Spec Pipeline / 月次決算等) を並列で実行可能
• ADR-0034 §影響 §5.3 「D1 → A5 通過時間 (中央値) < 4 時間」は 人間作業時間の中央値を指し、Deep Research の wall-clock wait は除外する

1. D1: 問題空間スキャン

1.1 目的

業務運用・月次決算・既存仕様書の隙間から、「次に解くべき問題候補」を構造的に発見する。仮説の語り (○○があったら便利) ではなく 過去の行動 (先月 N 回手作業した / 検算で M 回ズレた) に基づく痛みを抽出する。

1.2 担当ツール / 担当者

• 担当者: 代表取締役 (現状の単独運用者)
• ツール: なし (月次振り返り + 運用ログ手動集計)
• 入力源:
  • docs/_internal/changelog.md の直近 30 日分の障害対応
  • docs/_internal/BUG_tracking.md の未解決バグ
  • docs/_internal/TODO_future.md の未着手 MAS のうち月次運用で痛みを感じた項目
  • 直近月次の決算実行ログ (90_test_results シートで時間超過した処理)

1.3 完了条件

1. 痛みポイント候補 ≥ 3 件を docs/_internal/TODO_future.md の月次振り返りセクションに追記
2. 各候補に「いつ・何回・どれくらいの時間」を具体記述 (Mom Test 形式の前段)
3. 候補ごとに「D2 起案候補」フラグ (☆) を付ける/付けない判断を記録
4. ☆ 付き候補ごとに、属する JTBD が docs/_internal/01_discovery/customer_insight/_jtbd_list.md の承認済みエントリに存在することを確認する。既存エントリに存在しない場合は 3 軸テスト（ADR-0043 §2）を適用し、独立 JTBD として成立するなら PR で _jtbd_list.md に追加してから D2 へ進む

1.4 例: 「請求書 OCR 自動仕訳の自動化」候補抽出

2026-04 月次振り返りで以下を記録:

• 2026-04 中の発生回数: 紙請求書受領 12 件 → 全件手入力 (1 件あたり 5 分 = 60 分)
• 過去 3 ヶ月の傾向: 月 8-15 件で安定推移、コピー&ペースト時の打鍵ミスで月 1-2 件は仕訳訂正発生
• 既存代替: クラウド会計 SaaS の OCR は精度 70% (内製で 90% を目指したい)
• D2 候補: ☆ (Pain Score 想定 = 頻度 12回/月 × 痛み 3/5 × 影響 2/5 = 72。比較対象として MAS-145 銀行 CSV (済) は当初 144 点だった)

1.5 アンチパターン

1.6 観測指標

• D1 → D2 進出率 (目標 50-70%): 「全部 ☆ を付けて Deep Research に投入」では Pain Ranking の前段で詰まる
• 「いつ・何回・どれくらいの時間」記述率 (目標 100%): 過去行動形式の徹底

2. D2: 調査依頼起案

2.1 目的

D1 で抽出した痛み候補のうち ☆ 付き項目について、Deep Research に投入できる完成版プロンプトを生成する。bizlp の事実パッケージ (該当 dev_mas-NNN_*.md / spec_*.md / ADR-NNNN.md) を引用形式で含め、調査の前提を共有する。

JTBD 粒度確認（ADR-0043 前提条件）: RQ 起案前に、対象の痛みが docs/_internal/01_discovery/customer_insight/_jtbd_list.md の承認済み JTBD に紐付いていることを確認する。紐付いていない場合は D1 §1.3 の条件 4 に戻る。各 RQ ファイルの frontmatter には jtbd: JTBD-NNN タグを必ず付与する（adr-lint.mjs --check-jtbd-ref で CI 検証される）。

2.2 担当ツール / 担当者

• ツール: scripts/5_generate_rq_prompt.js (Gemini 2.5 Pro で完成版プロンプトを生成)
• 担当者: 代表取締役 + Claude Code (メタプロンプト下書き補助)
• 入力:
  • docs/_internal/research_prompts/RQ-NNN_{slug}_meta_prompt.md (手動作成のメタ指示)
  • --context で参照ファイル指定 (関連 dev_mas / spec / ADR)
• 出力:
  • docs/_internal/research_prompts/RQ-NNN_{slug}_prompt.md (Deep Research 投入用)
  • docs/_internal/research_prompts/RQ-NNN_{slug}_result.md (空テンプレ)
  • tasks/rq_prompts/{timestamp}_RQ-NNN_raw.md (デバッグ用)

2.3 完了条件

1. RQ-NNN_{slug}_prompt.md が存在 (scripts/5 実行成功)
2. プロンプト本文に 事実パッケージ (関連 dev_mas / spec / ADR の引用ブロック) が含まれる
3. プロンプト末尾に「相談者ペルソナ」「求める出力形式」「参考リンク要求」が明記される
4. RQ-NNN の番号採番が既存と衝突しない (ls docs/_internal/research_prompts/RQ-* で事前確認)
5. RQ ファイルの先頭 frontmatter に jtbd: JTBD-NNN（例: jtbd: JTBD-001）が記載されている（_jtbd_list.md の承認済みエントリの ID）

2.4 RQ-NNN 採番ルール

• 連番 3 桁ゼロパディング (RQ-001 〜 RQ-999)
• 採番は docs/_internal/research_prompts/ の既存ファイルの最大番号 + 1
• メタプロンプト作成時に番号を確定 (Deep Research 投入後の renumber は不可、リンク腐敗の原因)

2.5 メタプロンプトの書き方 (重要)

メタプロンプト (RQ-NNN_*_meta_prompt.md) は以下の構造で作成:

# RQ-NNN メタプロンプト: <調査タイトル>

## 0. 用途・調査背景
- 起票日 / 起票者 / 関連 MAS or ADR

## 1. 事実パッケージ (Deep Research に渡す前提)
- 関連 dev_mas / spec / ADR への参照 (相対パス、`scripts/5` が自動展開する)
- bizlp 文脈の制約 (1 人法人 / GAS / 監査要件)

## 2. 調査項目
- Q1. ...
- Q2. ...
- (調査項目は **5-8 個**、各項目に「結論 → 根拠 → 比較表 → 推奨案 → 参考リンク」を要求)

## 3. 求める出力形式
- 文量 (8,000-15,000 字)
- 章立て
- 参考リンク必須

## 4. 除外論点
- 「○○ は調査範囲外」と明示

2.6 例: RQ-035 (Agentic AI 金融計画 / 投入実績)

docs/_internal/research_prompts/RQ-035_agentic_ai_financial_planning_meta_prompt.md を参考に: 関連 dev_mas-056 / MAS-067 を --context 指定、Gemini が事実パッケージを抽出してプロンプト本文に引用ブロックで埋め込んだ。出力 12,000 字、両エンジン投入後 D4 で synthesis 化済。

2.7 アンチパターン

2.8 観測指標

• メタプロンプト作成時間 (目標 30 分以内)
• 事実パッケージ抽出ファイル数 (目標 3-7 ファイル、これ未満だと文脈不足、これ超だと焦点ボケ)

2.9 PII マスキング規約 (機微情報の外部送信リスク管理)

GPT-4o 指摘反映 (PR #692)、2026-05-14 追記

• メタプロンプト + 投入 prompt の事実パッケージに 取引先名 / 金額 / 個人氏名 / 口座番号 を含めない ([MASKED:PARTNER] / [MASKED:AMOUNT] / [MASKED:PERSON] 形式に置換)
• 機密データ (creds.json / .clasp*.json / 個人 PII / 本番スプレッドシート ID) は scripts/5 の --context 指定対象から除外、参照源はマスク済のスペック・ADR・公開ドキュメントに限定
• Deep Research の result_*.md にマスク逆引き可能な記述が混入していないか、コミット前に検出:

  grep -nE "(株式会社|有限会社|[0-9]{4}/[0-9]{2}/[0-9]{2}|[0-9,]+円|@[a-z0-9.-]+\.(co|com|net))" \
    docs/_internal/research_prompts/RQ-*_result_*.md
  

• 検出時は該当箇所をマスクして再コミット (履歴に残った場合は別途 BFG / git-filter-repo で除去判断)

3. D3: 並列 Deep Research 実施

3.1 目的

RQ-NNN_*_prompt.md を Gemini Deep Research と Claude Research の両方に並列投入し、独立した 2 つの調査回答を得る。両者の 完全一致部分 を採用根拠の強い証拠とし、相違点 を bizlp 文脈で判断する材料とする。

3.2 担当ツール / 担当者

• 担当者: 代表取締役 (Web UI 経由、両エンジンを並列起動)
• ツール:
  • Gemini Deep Research: aistudio.google.com (Deep Research モード) — 出力 6,000-12,000 字
  • Claude Research: claude.ai (Research モード) — 出力 8,000-15,000 字
• 保存先:
  • docs/_internal/research_prompts/RQ-NNN_{slug}_result_gemini.md
  • docs/_internal/research_prompts/RQ-NNN_{slug}_result_claude.md

3.3 完了条件

1. 両エンジン結果が RQ-NNN_{slug}_result_{gemini,claude}.md に保存済
2. 各結果ファイル冒頭に 投入先 / 投入日 / Generated from のヘッダ記載 (renumber 防止のため)
3. 出力が極端に短い (< 2,000 字) 場合は再投入を試みる (調査不十分の兆候)

3.4 並列起動の運用

両エンジンを同時に投入する目的は「独立した 2 つの調査」を得ること:

• 順次 (Gemini → Claude) に投入すると、人間が無意識に Gemini の回答に引きずられた質問追加を Claude にしがち → 独立性が損なわれる
• 同じ RQ-NNN_*_prompt.md を両方にコピペ、追加質問なしで投入、結果が出るまで待つ
• 「Claude には Gemini と違う追加質問を投げよう」と思った時点で D3 を逸脱 → D2 に戻ってプロンプト改訂

3.5 アンチパターン

3.6 観測指標

• 両エンジン保存完了率 (目標 100%、片方欠落の場合は D4 進めない)
• 平均出力字数 (両エンジンとも 6,000 字以上が目安)

4. D4: 結果合成 + 価値判定

4.1 目的

D3 の両エンジン結果を 論点ごとに突き合わせ、bizlp 文脈の採択方針案を整理する。Mom Test 観点で再検証し、「解く価値あり (Backlog 行き)」/「対象外 (Closed)」/「再調査必要 (D2 戻り)」のいずれかに判定する。

4.2 担当ツール / 担当者

• 担当者: 代表取締役 (手動合成、Claude Code に補助依頼可)
• 出力: docs/_internal/research_prompts/RQ-NNN_{slug}_synthesis.md

4.3 完了条件

1. RQ-NNN_{slug}_synthesis.md が存在
2. 冒頭に TL;DR (両者一致核心 / 相違点 / bizlp 採択方針)
3. 完全一致部分 (採用根拠) と 相違点 (bizlp 文脈で判断) を章として分離
4. 末尾に 判定区分 を明記 (下記 4.4)
5. 判定区分が「解く価値あり」の場合は A1 への引き継ぎ情報 (痛み記述 + ユーザー + 影響) を 3 行以内で記録

4.4 判定区分 (3 値)

4.5 Mom Test による再検証

D4 で synthesis.md 起草中に、以下のチェックを実施:

1. 「過去の行動」根拠が synthesis 内に再記述されているか?
   • YES → そのまま進行
   • NO → D1 の TODO_future.md エントリを参照、痛みの定量データを再掲載
2. 両エンジン回答に「○○があったら便利」レベルの仮説が混入していないか?
   • 混入あり → synthesis でその部分を「仮説 (未検証)」と注釈
   • 全体が仮説ベース → 判定は「対象外」または「再調査必要」へ
3. 「代表取締役自身が先月実際に行動した」根拠で説明できるか?
   • 説明可能 → Mom Test PASS
   • 説明不可能 → 痛みは存在しない or 観測不足、判定再考

4.6 例: RQ-040 (開発組織化パラダイム)

docs/_internal/research_prompts/RQ-040_dev_organization_paradigm_synthesis.md を参考に:

• TL;DR で「両者完全一致: Walking Skeleton + Now/Next/Later + UC スライス採用」を明記
• 相違点 3 件 (進捗管理ツール / 二重ビュー / Wardley Mapping) を独立章で整理
• bizlp 採択方針として「Claude 案ベース + Gemini の Q4/Q7 補強」を提示
• 判定: 「解く価値あり → ADR-0021 起案準備資料」 (Stage 2 ではなく直接 ADR 起案、メタ ADR のため例外)

4.7 D4 → A1 引き継ぎ

「解く価値あり」と判定されたら、以下の最低限情報を A1 に渡す (synthesis の末尾セクション「Stage 2 引き継ぎ情報」として記載):

## Stage 2 引き継ぎ情報 (A1 入力)

- **痛み記述**: 紙請求書受領時の手入力作業
- **ユーザー (誰が困るか)**: 代表取締役 (現状単独運用)
- **影響 (どのくらい困るか)**: 月 12 件 × 5 分 = 60 分/月、打鍵ミスで月 1-2 件の仕訳訂正発生
- **関連 RQ**: RQ-NNN

A1 で usecase_dev_mapping.md に新規行を追加する際の元情報となる。

4.8 アンチパターン

4.9 観測指標

• 「対象外 (Closed)」判定率 (目標 30-50%): これ未満だと Mom Test が形骸化、超過は D2 でフィルタしきれていない
• 「再調査必要」判定率 (目標 5-10%): 多すぎる場合は D2 メタプロンプト品質が低い

5. 観測指標 (Stage 1 全体)

ADR-0034 §影響 §5.3 で定義された月次集計指標:

6. References

• ADR: ADR-0034 Stage 1-2 ワークフロー定義
• 関連 ADR:
  • ADR-0028 全体 6 段ワークフロー
  • ADR-0029 Spec/Impl Pipeline B1-B6 / C1-C6
• 関連ファイル:
  • scripts/5_generate_rq_prompt.js (D2)
  • docs/_internal/research_prompts/README.md (RQ 採番ルール)
  • docs/_internal/TODO_future.md (D1 痛み記録先)
• 外部資料:
  • Steve Blank "Customer Development Model" (Customer Discovery)
  • Rob Fitzpatrick "The Mom Test"
• ADR-0034 §5 完了条件 #5 の検証手順正規化 (GPT-4o 指摘反映):
  • ADR 本文の grep -cE "customer_discovery_workflow|backlog_pipeline_workflow" docs/_config.json は同一行に両語混在時に過小カウントするため、以下を使用:
  • grep -oE "customer_discovery_workflow|backlog_pipeline_workflow" docs/_config.json | wc -l → 2
  • python3 -c "import json; n=json.load(open('docs/_config.json'))['nav']; files=[p['file'] for g in n if 'pages' in g for p in g['pages'] if 'file' in p]; assert sum(1 for f in files if 'customer_discovery_workflow' in f or 'backlog_pipeline_workflow' in f)==2"
  • 本 ADR 本文はイミュータブル原則のため未変更、将来 ADR-NNNN の corrigendum で本文側の補正を検討