型付き辺: 出 7 / 入 6
ADR-0028: UC スライス開発 全体 6 段ワークフローの正式採用 (Customer Discovery / GAS MVP 二層構造)
- Status: Accepted
- Mode: Standard
- Kruchten Type: Property/Executive
- Scope: platform
- Implementation Status: In Progress (残=完了条件 #4: UC-4-S01 の Stage 6 判定記録が changelog に未記録・期限 ≤2026-06-30 で撤退トリガー。完了条件 #6 onboarding は達成済 PR #2000)
- 起案者: [email protected]
- 起案日時 (JST): 2026-05-13 16:22
- 承認日時 (JST): 2026-05-13 16:30
- Deciders: [email protected] (単独)
Kruchten Type は ADR-0031 (2026-05-13) で遡及追加。分類根拠は ADR-0031 §決定セクションおよび docs/adr/README.md の Kruchten 3 分類ガイドを参照。 Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。 Implementation Status は 2026-06-15 に訂正 (ADR-0031 corrigendum パターン)。旧値「In Progress (Step 7 進行中、PR #661 〜 #668)」は ADR-0032 の一括 backfill で混入した誤記。当該 PR #661〜#668 は ADR-0029/0030/0031 (DRP パイプライン整備) の作業で本 ADR の完了条件とは無関係、かつ 2026-05-13 にマージ済。実態の残作業は §撤退条件の完了条件 #4 のみ (#6 onboarding は PR #2000 で達成)。意思決定内容は不変。
コンテキスト
1.1 背景 (Background)
ADR-0021 (UC スライス × Walking Skeleton × Now/Next/Later) で開発パラダイムは確定したが、「何を作るか」を発見するフェーズと「GAS で作って検証する」フェーズの境界、GAS 実装が失敗・ズレた場合のピボット経路、scripts/1 → scripts/2 → scripts/4 という既存パイプラインの全体フローにおける位置づけが明示されていない。
1.2 現状 (Current State / As-Is)
ADR-0021 で UC スライス / Walking Skeleton / Now/Next/Later の三本柱は確定済み。scripts/1 scripts/2 scripts/4 を中心とした Spec / Impl パイプラインは稼働しているが、その前段の問題発見プロセスと後段の検証・ピボット判定は暗黙運用に留まる。
1.3 課題 (Problem)
- 問題が未検証のまま実装に投資するリスクが構造的に防止できない
- GAS の位置づけ (MVP か本番か) が不明確で、将来の GCP / ローカル LLM 移行の判断根拠が曖昧
- Jr エンジニア入社時に全体像を 1 つの ADR で把握できる文書が存在しない
1.4 制約・要件 (Constraints & Requirements)
- ADR-0021 の UC スライス / Walking Skeleton / Now/Next/Later と矛盾しないこと
- 既存 ADR-0001〜0027 の本文と既存スクリプト実装を改変しないこと
- 後任 (Jr エンジニア) が全体像と判断根拠を 1 つの ADR で把握できること
- Decision Pipeline / Gemini / Claude Code は既存契約内で完結すること (追加金銭コスト 0 円)
1.5 目標 (Goals / To-Be)
UC スライス開発を「探索フェーズ (Stage 1-2: Customer Discovery)」と「検証フェーズ (Stage 3-6: Customer Validation / GAS MVP)」の二層構造として正式定義し、Stage 6 にピボット判定ゲートを設けることで「問題を検証してから実装に投資する」順序を構造的に担保する。Non-Goals: GCP / ローカル LLM への本番移行ライフサイクルの定義 (将来 ADR に委ねる)。
決定
ADR-0021 の実装詳細として、UC スライス開発の全体 6 段ワークフローを正式採用する。Stage 1-2 を Customer Discovery (探索) フェーズ、Stage 3-6 を Customer Validation / GAS MVP (検証) フェーズと位置づけ、Stage 6 に Pass / Pivot / Fail(技術) のピボット判定ゲートを設置する。Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) は Stage 4-5 の横断的先行実装制約として組み込み、GAS は検証用 MVP プラットフォームと明示する。サブワークフローの詳細は ADR-0029 (Spec/Impl Pipeline) および ADR-0030 (Backlog 同期) に委ねる。
二層構造
| フェーズ | 段 | 目的 |
|---|---|---|
| 探索フェーズ (Customer Discovery) | Stage 1-2 | 「この痛みを解く価値があるか」を低コストで検証してから Backlog に積む |
| 検証フェーズ (Customer Validation / GAS MVP) | Stage 3-6 | GAS を MVP として実際に解けるかを実機で検証する |
6 段の定義
| 段 | 名称 | 主担当 | 出力 |
|---|---|---|---|
| 1 | Discovery (問題発見) | scripts/5_generate_rq_prompt.js + Gemini Deep Research + Claude Research | 「解く価値がある」と判定済みの課題記述 (RQ-NNN_*.md) |
| 2 | Backlog (UC スライス化) | Markdown 手編集 + ADR-0026 自動同期 (詳細サブワークフローは ADR-0030) | usecase_dev_mapping.md / todo_master_tables.md |
| 3 | Decision (ADR 起案) | Decision Pipeline + 技術調査 | docs/adr/NNNN-*.md |
| 4 | Spec Pipeline (詳細は ADR-0029) | scripts/1 + scripts/2.5 + scripts/2 + scripts/4 | docs/dev/dev_{slice_id}_*.md |
| 5 | Impl Pipeline (詳細は ADR-0029) | Claude Code (Opus/Sonnet) + Codex MCP + Gemini MCP | 1 PR = 1 UC スライス |
| 6 | Verify + Pivot Gate | npm run push:dev/prod + GAS 上動作確認 | 98_audit_log 記録 / 判定結果 |
Stage 6 ピボット判定
| 判定 | 条件 | 次アクション |
|---|---|---|
| Pass | 実際の月次処理に組み込まれ問題が解消された | 次の UC スライスの Stage 1 へ |
| Pivot | 動くが使われない / 解くべき問題がずれていた | Stage 1-2 に戻り問題仮説を修正 |
| Fail (技術) | 6 分制限超過 / 設計変更が必要 | Stage 3 (ADR) に戻り設計を修正 |
Walking Skeleton の位置づけ
Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) は「Customer Validation の合否基準」ではなく、GAS MVP が監査・コンプライアンス要件を満たすための横断的先行実装制約として Stage 4-5 に組み込む。後からの追加は移行コストが指数的に増大するため、UC スライスの初回実装から横串で貫通させる。
GCP / ローカル LLM 移行
GAS は検証用 MVP プラットフォームと位置づける。Stage 6 で Problem-Solution Fit が確認できた機能の本番移行 (GCP / ローカル LLM) は、本 6 段の外側の別ライフサイクルとして将来 ADR で定義する。
検討した代替案 (Alternatives Considered)
案 A【採用】探索 (Stage 1-2) / 検証 (Stage 3-6) の二層構造 + Stage 6 ピボット判定
- Good, because Customer Discovery → Customer Validation の順序が明示され、実装前の投資判断タイミングが明確になる
- Good, because GAS = MVP と明示することで将来の GCP/LLM 移行の意図と根拠が伝わる
- Good, because Stage 6 ピボット判定で「動くが使われない」失敗を構造的に検知できる
- Bad, because Stage 6 の Pivot/Pass 判定が代表取締役の観察に依存し、自動化できない
案 B【不採用】二層構造を明示せず、6 段を対等なシーケンスとして定義
- Good, because シンプルで理解しやすい
- Bad, because 問題未検証のまま実装投資するリスクが構造的に防止できない
- Bad, because GAS の位置づけが不明確で将来の移行判断の根拠が曖昧になる
案 C【不採用】Spec 前に軽量 MVP を独立させ 7 段に拡張
- Good, because Blank モデルの Customer Validation に忠実
- Bad, because GAS での実装自体が MVP であり、Spec 前の別 MVP を作るのは二重投資
- Bad, because GAS の特性上、簡易プロトタイプと本実装の差が小さく段の独立が過剰
影響 (Consequences)
5.1 正の影響 (Good)
- Customer Discovery → Customer Validation の順序が構造化され、未検証問題への実装投資を防止できる
- GAS = MVP の位置づけが明示され、将来の GCP / ローカル LLM 移行判断の根拠が ADR として残る
- Stage 6 ピボット判定により「動くが使われない」失敗パターンを構造的に検知できる
- Jr エンジニア入社時に 1 つの ADR で全体像と判断根拠を把握可能 (オンボーディング 5〜6 時間で吸収)
- 初期構築コストは約 8.25 時間 / 0 円 (Decision Pipeline / Gemini / Claude Code はすべて既存契約内)
5.2 負の影響 (Bad)
- GAS の本番利用断念: GAS は MVP 専用と位置づけ、スケーラビリティは GCP/LLM 移行後に担保。検証速度を本番品質に優先した選択
- ピボット判定の運用依存: Stage 6 の「動くが使われない」判定は自動化できず、代表取締役の月次観察に依存する
- 運用工数の追加: Stage 1 Discovery 明示化で +30〜60 分 / スライス、Stage 6 Pivot 判定記録で +15 分 / スライス、合計 +45〜75 分 / スライス。UC スライス 10 件で最大 12.5 時間の追加
5.3 中立・トレードオフ (Neutral / Trade-offs)
- 影響範囲は本 ADR (ADR-0028) のみで、ADR-0001〜0027 の本文と既存スクリプト実装は不変。実装ファイルの変更は ADR-0029 / ADR-0030 の範囲に委譲
- Jr エンジニア学習コスト約 5〜6 時間 (6 段フレームワーク把握 2〜3 時間 + ADR-0028〜0030 通読 1 時間 + UC-4-S01 同乗 2 時間)
- 撤退時コストは約 2.25 時間 (導入コストの 27%) で、撤退リスクは低い
撤退条件 (Rollback Plan)
完了条件 (採用判定)
完了条件 #3 / #4 / #6 の検証コマンドのパスは 2026-06-15 に docs reorg 後の実パスへ訂正 (ADR-0031 corrigendum パターン)。
docs/_internal/直下から番号付きサブディレクトリ (02_project/06_ops/05_how-to/) へファイルが移動済みのため。検証の意図・しきい値は不変。2026-06-20 corrigendum: 完了条件 #4 (UC-4-S01 の Stage 6 判定記録) と #5 (サブワークフロー ADR の起案完了) は ADR-0152 (Accepted 2026-06-15 / umbrella 化決定) と ADR-0161 (Accepted 2026-06-20 PR #2343 / MAS GAS-MVP Build / Verify ライフサイクル) へ移管した。#4 は ADR-0161 §1.5 KPI 4 (≤ 2026-09-15 までに UC-4-S01 Stage 6 判定記録を 1 件以上) として、#5 は ADR-0152 §決定 + ADR-0160 / ADR-0161 の起案完了として再帰属する。本 ADR 側の検証コマンドはそのまま残し (本文改変なし・ADR-0031 corrigendum パターン)、ADR-0152 KPI 4 で本 ADR を umbrella 化する次の改訂 (status: accepted → umbrella + adr-lint umbrella-readonly ルール導入) で本文の完了条件節は ADR-0161 への参照に置換される。
即時検証 (ADR-0028 Accepted 化時)
- ADR-0028 が Accepted 化:
grep -E "^\- \*\*Status\*\*: Accepted" docs/adr/0028-*.md→ exit 0 - 既存 ADR への遡及改変なし:
git diff main..HEAD -- 'docs/adr/00[0-2][0-9]-*'→ 0 byte - Stage 6 判定記録インフラの存在:
grep -c "stage6_verdict" docs/_internal/02_project/usecase_dev_mapping.md→ >= 1
近期検証 (UC-4-S01 の Stage 6 完了後、≤ 2026-06-30)
- Stage 6 判定記録が 1 件以上存在:
grep -cE "Stage 6.*(Pass|Pivot|Fail)" docs/_internal/06_ops/changelog.md→ >= 1 - サブワークフロー ADR の起案完了:
ls docs/adr/0029-*.md docs/adr/0030-*.md 2>/dev/null | wc -l→ = 2
Jr 入社前検証 (≤ 2026-09-30)
- オンボーディングチェックリストに 6 段理解確認項目が存在:
grep -cE "6段|6-stage|Stage [1-6]" docs/_internal/05_how-to/onboarding_checklist.md→ >= 6
撤退条件
以下のいずれかが成立した場合、本 ADR を Supersede し旧暗黙運用に戻す:
- 2026-06-30 までに UC-4-S01 の Stage 6 判定記録が 0 件 (=ワークフローが運用されていない)
- 運用工数追加が +75 分/スライスを大幅に超過し、検証速度を逆に損ねていることが 3 スライス連続で確認された
- Stage 6 ピボット判定が 3 回連続で機能せず、「動くが使われない」失敗を検知できなかった
撤退コスト: 約 2.25 時間 (Light Mode ADR 起案 2 時間 + usecase_dev_mapping.md から stage6_verdict 列削除 0.25 時間)
Confirmation (準拠確認 / Fitness Function)
本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。
- 検証手段: N/A (ワークフロー定義ドキュメントのため実装検証対象外)
- 実行頻度: —
- 違反時の対応: —
参照 (References)
- 関連 ADR: ADR-0021 (UC スライス × Walking Skeleton × Now/Next/Later, 準拠), ADR-0026 (Backlog 自動同期, 準拠), ADR-0029 (Spec/Impl Pipeline 詳細, 後続起案予定), ADR-0030 (Backlog サブワークフロー, 後続起案予定)
- 関連 PR/Issue: -（要追記）
- 外部資料: -（要追記）