最終更新: 2026/06/22 18:56
Backlog Pipeline ワークフロー (Stage 2: A1-A5)
位置付け: ADR-0034 §2.2 で正式採用された Stage 2 (Backlog Pipeline) の運用詳細。 ADR-0028 全体 6 段ワークフローの Stage 2 = UC スライス化フェーズ の内部サブ手順 (A1-A5)。 前段 (Stage 1 = Customer Discovery / D1-D4) は
customer_discovery_workflow.mdを参照。 後段 (Stage 4-5 = Spec/Impl Pipeline / B1-B6 / C1-C6) は ADR-0029 を参照。
0. このドキュメントの読み方
- 目的: Discovery で「解く価値あり」と判定された問題を、Mom Test 形式 + Pain Ranking + Problem-Solution Fit 判定を経て UC スライスに変換する 5 段サブワークフローを明文化する
- 対象読者: 起案者 (代表取締役) / Jr 入社後の後任 / Claude Code (A1-A5 完了確認補助)
- 完了の判定: A5 まで通過した UC スライスは
usecase_dev_mapping.mdの §4 or §5 テーブルに行追加され、slice_id (UC-{N}-S{NN}) と now_next_later (Now/Next/Later) が記録されている
Stage 2 全体像 (A1-A5)
| # | 段 | 担当ツール / 担当者 | 完了条件 (要約) |
|---|---|---|---|
| A1 | 課題仮説記述 | 手動 (usecase_dev_mapping.md 編集) | 痛みの記述 + ユーザー + 影響を 3 行以内で記述 |
| A2 | Mom Test 形式確認 | 手動 (過去行動を 3 件以上想起) | 「仮説の語り」を「過去の行動」に再記述、検証可能仮説のみ通過 |
| A3 | Pain Ranking | 手動 (Pain Score = 頻度 × 痛み × 影響範囲) | Pain Score 算出済、他課題との相対順位明示 |
| A4 | Problem-Solution Fit 判定 | 手動 (Discovery synthesis を引き、解決策の概念妥当性検証) | Now/Next/Later/Closed のいずれかに分類 |
| A5 | UC スライス化 + 自動同期 | 手動 + ADR-0026 GitHub Actions | slice_id 採番、walking_skeleton_status=pending、関連 RQ リンク記録 |
1 サイクル所要時間目安: A1 (30min) + A2 (30min Mom Test 想起) + A3 (15min Pain Ranking) + A4 (30min PSF 判定) + A5 (15min 編集 + 自動同期待ち) = 約 2 時間 / UC スライス
1. A1: 課題仮説記述
1.1 目的
D4 で「解く価値あり」と判定された問題を、痛みの記述 + ユーザー + 影響 の 3 要素に分解して usecase_dev_mapping.md の候補行として書き出す。後段 A2-A4 の判定材料を整える。
1.2 担当ツール / 担当者
- 担当者: 代表取締役
- ツール: なし (手動編集)
- 入力源: D4 synthesis の末尾「Stage 2 引き継ぎ情報」セクション
1.3 完了条件
- 候補行の素材として 3 要素が 3 行以内 で記述されている (冗長な背景説明は禁止、後段で判断ぼけする)
- ドラフトは
usecase_dev_mapping.mdの §4/§5 ではなく 作業メモ (PR description 等) に書く (A4 通過前に SSoT を汚染しない) - 候補が属する JTBD が
docs/_internal/01_discovery/customer_insight/_jtbd_list.mdの承認済みエントリ（JTBD-NNN）に存在することを確認する（ADR-0043 前提条件）
1.4 3 要素の書き方
## 候補: <短い名称>
- **痛み**: <何が、どんな状況で起きているか> (例: 紙請求書受領時の手入力)
- **ユーザー (誰が困るか)**: <現状の運用者 or 想定ユーザー> (例: 代表取締役 / 単独運用)
- **影響 (どのくらい困るか、月次頻度・規模)**: <定量データ> (例: 月 12 件 × 5 分 = 60 分/月、打鍵ミスで月 1-2 件の仕訳訂正)
- **関連 RQ**: RQ-NNN (Discovery 元)
- **関連 JTBD**: JTBD-NNN (docs/_internal/01_discovery/customer_insight/_jtbd_list.md の承認済みエントリ)
1.5 アンチパターン
| やってはいけない | なぜ |
|---|---|
いきなり usecase_dev_mapping.md を編集 | A4 で「対象外」と判定されたら戻すコストが発生、SSoT が一時的に嘘になる |
| 痛み記述に「便利になる」「効率化」を含める | 解決策の語りであり、痛みの定義になっていない (A2 で必ず引っかかる) |
| 影響の定量データを省略 ("結構困る" 等) | A3 Pain Score 算出不能、A4 PSF 判定の客観性も失う |
1.6 観測指標
- A1 草案の 3 要素記述率 (目標 100%)
- 影響の定量データ完備率 (目標 100%)
2. A2: Mom Test 形式確認
2.1 目的
A1 で記述した候補が 「仮説の語り (○○があったら便利)」ではなく「過去の行動 (先月 N 回手作業した)」 の形式になっているかを再検証する。Rob Fitzpatrick "The Mom Test" の原則「過去・具体・コミットメント」を bizlp 文脈に適用。
2.2 担当ツール / 担当者
- 担当者: 代表取締役本人 (過去行動の想起が必要なため代理不可)
- ツール: なし (記憶 +
changelog.md/BUG_tracking.md/ 月次決算ログ参照)
2.3 完了条件
代表取締役自身が 過去 3 ヶ月以内の具体的行動を 3 件以上想起し、A1 草案に追記:
- **過去の行動**:
- 2026-04-12: 紙請求書 3 件を手入力 (15:00-15:18、18 分)
- 2026-04-18: 別の紙請求書 4 件を手入力、うち 1 件の金額入力ミスを翌日発見・仕訳訂正
- 2026-04-25: 月末締めで未処理請求書 5 件を一気に手入力 (45 分)
2.4 Mom Test 判定基準
各候補について以下のチェックを通過したら A3 へ進む:
| チェック | OK 例 | NG 例 |
|---|---|---|
| 過去か? | 「先月 12 件処理した」 | 「将来 OCR があったら便利」 |
| 具体的か? | 「2026-04-12 に 18 分かかった」 | 「結構時間がかかる」 |
| コミットメント (自分の時間や金) | 「実際に 60 分/月を投入している」 | 「やればきっと改善する」 |
3 件想起できない場合は判定:
- 「想起不能 → 痛みは存在しない or 観測不足」 → 対象外候補 として A4 で Closed
- 「1-2 件のみ想起 → 痛みは存在するが頻度低い」 → A4 で Later 候補
2.5 例: 「請求書 OCR 自動仕訳」候補の Mom Test 適用
A1 草案: 「紙請求書受領時の手入力作業」
A2 Mom Test 検証:
- 過去行動 (3 件): 2026-04-12 (3 件 18 分) / 2026-04-18 (4 件、1 件訂正) / 2026-04-25 (5 件 45 分)
- 過去か? ✅ 4 月実績
- 具体的か? ✅ 日付・件数・所要時間明示
- コミットメント ✅ 月 60 分の実時間投入
- 判定: Mom Test PASS → A3 へ
2.6 アンチパターン
| やってはいけない | なぜ |
|---|---|
| 過去行動を「だいたい毎月やってる」と書く | 具体性なし、A3 Pain Score 算出が直感頼みに退化 |
| Mom Test 失敗 (想起不能) なのに「気持ちは分かる」で先に進める | Backlog が形骸化候補で埋まる、Now 判定の信頼性低下 |
| 代理人 (例: Claude Code) に過去行動を想起させる | bizlp の運用実体を知らない LLM が捏造、Mom Test の意義消失 |
2.7 観測指標
- A2 通過率 (目標 60-80%): これ超過は Mom Test 形骸化、これ未満は A1 でフィルタしきれていない
- 想起 3 件記述率 (目標 通過案件の 100%)
3. A3: Pain Ranking
3.1 目的
A2 通過候補に Pain Score を付与し、bizlp 月次運用上の他課題との 相対順位 を明示する。ADR-0020 の Bezos Type 1/2 補助を併用 (不可逆性が高い場合は Pain Score 高でも慎重判断)。
3.2 担当ツール / 担当者
- 担当者: 代表取締役
- ツール: なし (5 段階スコアリング)
3.3 Pain Score 算出式
Pain Score = 頻度 × 痛み × 影響範囲
各因子 1-5 の 5 段階 (最大 125):
| 因子 | 1 | 3 | 5 |
|---|---|---|---|
| 頻度 | 年 1-2 回 | 月 1-3 回 | 月 10 回以上 (週 2 回以上) |
| 痛み (1 回あたり) | 軽微 (5 分未満 / 微小ストレス) | 中程度 (15-30 分 / 集中力を要する) | 強度 (1 時間超 / 訂正リスク高 / 監査リスク) |
| 影響範囲 | 1 機能内に閉じる | 関連 2-3 機能に波及 | UC 横断 (4 機能以上 / 月次決算ブロック) |
3.4 完了条件
- 候補に Pain Score 数値 (例: 72) を付与
- 比較対象として 直近の Now/Next/Later 採用済 / 完了済 案件の Pain Score を 2 件以上引用 (相対化)
- Bezos Type 判定 (Type 1 = 不可逆 / Type 2 = 試して戻せる) を併記
3.5 Pain Score 比較表 (相対化用、運用継続更新)
| 案件 | 頻度 | 痛み | 影響範囲 | Pain Score | 結果 |
|---|---|---|---|---|---|
| MAS-145 銀行 CSV インポート (完了) | 4 (月 8-15 回) | 3 (15 分/回) | 3 (関連機能波及) | 36 (改定後算出) | Now 採用、完了 |
| MAS-157 写真 OCR (未着手) | 3 (月 3-5 回) | 2 (10 分/回) | 2 (UI 機能内) | 12 | Later 維持 |
| MAS-218 タイムトラッキング (未着手) | 5 (毎日) | 1 (3 分/回) | 4 (R&D 税制 + 月次) | 20 | Next 検討 |
※ 上記は記述例。実値はメンテ運用で更新する。
3.6 アンチパターン
| やってはいけない | なぜ |
|---|---|
| Pain Score を 100 点満点で書く | 因子 5×5×5 = 125 最大なので 100 点と紛らわしい |
| 比較対象を引かず単独スコアで判断 | Bezos 言うところの "Type 1 trap" - 自分案件のスコア膨張バイアス |
| Pain Score だけで Now/Next/Later 決定 | A4 の Problem-Solution Fit 判定 (解決策の概念妥当性) を飛ばすと、痛いが解けない問題を Now に積む |
3.7 観測指標
- 比較対象引用件数 (目標 2 件以上)
- Bezos Type 判定記述率 (目標 100%)
4. A4: Problem-Solution Fit 判定
4.1 目的
Pain Score が付いた候補について、Discovery の synthesis を引いて、解決策が概念的に妥当かを検証する。痛みが大きくても解決策が未検証なら Now に積めない。最終的に Now/Next/Later/Closed のいずれかに分類する。
4.2 担当ツール / 担当者
- 担当者: 代表取締役
- ツール: なし (D4 synthesis の再読 + 解決策の概念検証)
4.3 4 値判定基準
| 判定 | 条件 (AND) | 配置 |
|---|---|---|
| Now | Pain Score 高 (50+ 目安) AND PSF 検証済 AND Bezos Type 2 (戻せる) AND 同時 WIP 1 スライス枠が空き | now_next_later=Now、即 A5 へ |
| Next | PSF 検証済 AND (Pain Score 中程度 OR 実装制約あり) AND Now 枠埋まっている | now_next_later=Next、A5 進行 |
| Later | (Pain Score 低 OR PSF 未検証 OR Bezos Type 1 で慎重判断必要) | now_next_later=Later、A5 進行 |
| Closed | Pain Score 不足 (Mom Test 通過したが頻度低い) OR PSF が概念的に不可 OR 外部 SaaS で十分 | A5 進めず、Discovery synthesis に Closed 理由追記 |
4.4 「PSF 検証済」の定義
D4 synthesis に以下の 3 点が明記されている:
- 同種事例の存在: 他社 (外部 SaaS / OSS / 業界記事) が同じ解決策で痛みを解消した実績
- bizlp 文脈での実装可能性: GAS 6 分制限 + 監査要件 + 1 人法人開発体制で実装できる根拠
- 想定アーキ概略: どのレイヤー (UI/Domain/Data/Infra) で実装するかの粗い見立て
3 点いずれかが欠けるなら「PSF 未検証」 → Later 配置 (PSF 検証のための追加調査を A4 完了後に実施)
4.5 Now の同時 1 スライス原則
ADR-0021 の Now/Next/Later で「Now は同時 1 スライス」が規約。判定時に既存 Now が埋まっている場合は:
- 既存 Now の完了予測 (1-2 週間) を見積もる
- 短期で空くなら本候補は Next (枠待ち)
- 長期化しそうなら Pain Score 比較で 入れ替え判定 (現 Now を Next に降格、本候補を Now に昇格 — 入れ替えは月 1 回上限)
4.6 例: 「請求書 OCR 自動仕訳」候補の A4 判定
入力:
- Pain Score: 72 (頻度 4 × 痛み 3 × 影響範囲 3 + 訂正リスク考慮で 5/3/3 → 45 修正、相対化で 36 - 45 域)
- PSF 検証: D4 synthesis に「Gemini API (PDF 解析) / Cloud Vision API の事例」「GAS UrlFetchApp で 6 分以内処理可能」「500_import レイヤー想定」が明記 → 検証済
- Bezos Type: Type 2 (Feature Flag で即無効化可)
- 既存 Now 状況: UC-4-S01 (ランウェイ Walking Skeleton) が WIP、完了予測 2 週間
判定: 既存 Now が短期で空く → Next に配置、UC-4-S01 完了後に Now へ昇格
4.7 アンチパターン
| やってはいけない | なぜ |
|---|---|
| Pain Score だけで「Pain Score 80 だから Now」と即決 | PSF 未検証なら実装失敗で Stage 6 Pivot を踏む、サイクルコスト無駄 |
| 「Now 同時 1 スライス」原則を破って 2 件並列 | 1 人開発で context switch コストが累積、結局両方遅延 |
| Closed 判定の理由を synthesis に書かない | 3 ヶ月後に「あの候補どうした?」が再発、追跡不能 RQ 化 |
4.8 観測指標
- A4 → A5 通過率: Now (目標 10-20%) / Next (20-30%) / Later (40-60%) / Closed (10-20%)
- 「Now 入れ替え発生」頻度 (月 1 回以下が健全)
5. A5: UC スライス化 + 自動同期
5.1 目的
A4 で Now/Next/Later 判定された候補を usecase_dev_mapping.md に正式登録する。slice_id (ADR-0025) を採番し、walking_skeleton_status を pending で初期化、関連 RQ-NNN リンクを記録、ADR-0026 GitHub Actions による todo_master_tables.md への自動同期を待つ。
5.2 担当ツール / 担当者
- 担当者: 代表取締役 (
usecase_dev_mapping.md編集) - 自動同期:
.github/workflows/sync_slice_id.yml(ADR-0026、push 時 / 日次 cron 02:00 JST)
5.3 完了条件
usecase_dev_mapping.mdの §4 (戦略 UC) or §5 (業務 OP) の該当テーブルに新規行追加- slice_id 採番 (
UC-{N}-S{NN}、ADR-0025 準拠、grep -E "UC-${N}-S[0-9]" usecase_dev_mapping.mdで衝突確認) - walking_skeleton_status =
pending(4 値 enum: pending / skeleton / in_progress / done) - now_next_later = A4 判定値 (
Now/Next/Later) - 関連 RQ-NNN カラム に Discovery 元の RQ 番号を記録 (本ファイル新規列、A5 完了の必須要件)
- PR 作成・マージ後、ADR-0026 GitHub Actions が
todo_master_tables.mdを自動更新 (auto-sync-brokenラベル付き Issue が起票されないこと)
5.4 slice_id 採番ルール (ADR-0025 準拠)
| 項目 | 形式 | 例 | 制約 |
|---|---|---|---|
| slice_id | UC-{N}-S{NN} | UC-4-S02 | N: UC 番号 (1-9) / NN: 通し番号 (01-99、ゼロ埋め) |
| 採番起点 | 既存 UC-{N}-S{NN} の最大 NN + 1 | UC-4 既存最大 S01 → 新規 S02 | 既存値の 再利用禁止 (削除済スライスでも欠番として残す) |
| 横断スライス | UC 番号は 主たる目的 で選択 | 請求書 OCR は UC-4 (ランウェイ) より UC-3 (組織施策) 寄りなら UC-3 | 1 スライス = 1 UC 紐付け原則 |
5.5 行追加の書式例
usecase_dev_mapping.md §5 業務 OP の該当テーブルに以下の形式で追加 (関連 RQ 列が新規追加):
| ● 必須 | MAS-147 | 請求書OCR自動仕訳 | 📝 仕様書完了 | UC-3-S04 | pending | Next | RQ-NNN |
カラム順: 役割 | MAS | 案件名 | ステータス | slice_id | walking_skeleton_status | now_next_later | 関連 RQ
5.6 GitHub Actions 自動同期の挙動
ADR-0026 で .github/workflows/sync_slice_id.yml が以下を実行:
- トリガー: SSoT (
usecase_dev_mapping.md) への push / PR / 毎日 JST 02:00 cron / 手動 dispatch - 同期内容:
todo_master_tables.mdの各カテゴリ別テーブルのslice_id列を SSoT 値で上書き - 手動上書き耐性: 同期先で手動編集された値は次回 cron で SSoT 値に戻る
- エラー時:
auto-sync-brokenラベル付き Issue 自動起票
A5 完了確認手順:
# A5 完了 = 自動同期通過の確認
gh run list --workflow=sync_slice_id.yml --limit=3
# 直近 run が conclusion=success であることを確認
gh issue list --label auto-sync-broken --state=open
# Issue が空であることを確認
5.7 アンチパターン
| やってはいけない | なぜ |
|---|---|
| slice_id 採番時に既存 NN を再利用 | Git 履歴・Feature Flag キー (FF_UC{N}_S{NN}_xxx) が衝突、ADR-0026 同期が壊れる |
walking_skeleton_status を pending 以外で開始 | Stage 3-4 (Spec/Impl Pipeline) を飛ばして開始することになり、Walking Skeleton 4 要素貫通が抜ける |
| 関連 RQ 列を空欄のまま PR マージ | Discovery → Backlog → Spec の追跡経路が切れる、3 ヶ月後に「なぜこのスライス?」が不明 |
todo_master_tables.md を手動編集して slice_id を入れる | 同期先で手動編集された値は次回 cron で消える、運用混乱 |
5.8 A5 → B1 引き継ぎ
A5 完了 = usecase_dev_mapping.md 行追加 + 自動同期成功 = B1 (UC スライス選定 / Spec Pipeline 開始) の前提条件成立。
B1 開始時に Stage 4 Claude が参照する情報:
- slice_id (Spec Pipeline 全体で識別子として使用)
- walking_skeleton_status = pending (B3 Walking Skeleton 注入の対象)
- 関連 RQ-NNN (D4 synthesis を Spec の事実パッケージとして再利用)
- 関連 dev_mas-NNN_*.md (既存仕様書があれば B1 のサーベイ対象)
5.9 観測指標
- A5 完了時間 (目標 15 分以内)
- 自動同期成功率 (目標 100%、
auto-sync-broken発生時は ADR-0026 §撤退条件参照) - 関連 RQ 列記入率 (目標 100%)
6. 観測指標 (Stage 2 全体)
ADR-0034 §影響 §5.3 で定義された月次集計指標:
| 指標 | 目標値 | 集計方法 |
|---|---|---|
| D1 → A5 通過時間 (中央値) | < 4 時間 | RQ-NNN の起票日 → A5 完了 (usecase_dev_mapping.md 行追加 PR マージ) の elapsed |
| A4 「Now」判定率 | 10-20% | usecase_dev_mapping.md の now_next_later=Now の件数 / 通過候補総数 |
| A4 「Closed」判定率 | 10-20% | D4 synthesis に「Closed」と書かれた件数 / A2 通過件数 |
| 追跡不能 RQ 数 (A5 未完了の Backlog 候補) | 0 件 | RQ-NNN_synthesis で「解く価値あり」かつ usecase_dev_mapping.md に行追加されていない案件 |
7. References
- ADR: ADR-0034 Stage 1-2 ワークフロー定義
- 関連 ADR:
- ADR-0028 全体 6 段ワークフロー
- ADR-0025 slice_id 命名規則
- ADR-0026 slice_id 自動同期 GitHub Actions
- ADR-0029 Spec/Impl Pipeline B1-B6 / C1-C6
- ADR-0020 (Bezos Type 1/2、A3 補助)
- 関連ファイル:
docs/_internal/usecase_dev_mapping.md(Backlog SSoT、A1/A5 編集対象)docs/_internal/todo_master_tables.md(ADR-0026 自動同期先).github/workflows/sync_slice_id.yml(A5 自動同期)docs/_internal/customer_discovery_workflow.md(Stage 1 / D1-D4)
- 外部資料:
- Steve Blank "Customer Development Model" (Customer Validation 連携)
- Rob Fitzpatrick "The Mom Test" (A2 形式)