ADR-0152: UC スライス開発ワークフローを DRP discovery と MAS GAS-MVP の 2 ライフサイクルに構造分割する

• Status: Accepted
• Mode: Standard
• Kruchten Type: Executive/Existence
• Scope: platform
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-15 11:38
• 承認日時 (JST): 2026-06-15 11:57 (Pipeline 通常 flow Standard 44/50 通過 + Cross-Validation 却下なし・Consistency INFO、PR #2012 マージ)
• Approver Role: platform
• Approver Who: [email protected]
• Driver: [email protected]
• Consulted: Decision Pipeline AI 審査 (Gate 0-4)
• Review After: 2026-12-15 (起案半年後・撤退条件 2026-09-15 判定後の長期影響レビュー)

コンテキスト

1.1 背景

ADR-0028 は UC スライス開発を「探索フェーズ (Stage 1-2) / 検証フェーズ (Stage 3-6)」の 6 段ワークフローとして 1 本に定義した。しかし運用してみると、この中には性質の異なる 2 つのライフサイクルが混在していた。

• DRP の塊(何を作るか発見し ADR・仕様に落とすまで: 研究 → ADR → spec)。drp-ops / spec-gen-pipeline / ADR-0117 以降として独立に高度進化し、現在フル稼働している。
• MAS の塊(GAS で実装し実機で Stage 6 検証・Pivot 判定する)。まだ一度も Stage 6 まで到達していない。

1.2 現状 (As-Is)

2026-06 の ADR-0028 監査で以下の実害が表面化した。

• implementation_status が別ライフサイクル (DRP の PR #661-668) を誤って指していた。
• 完了条件 #4「Stage 6 判定記録 0 件 = ワークフローが運用されていない」が、DRP 側は酷使されている事実と矛盾する (片方のライフサイクルの活動で、もう片方を測る誤較正)。
• ツール参照 (scripts/1/2/4) が陳腐化し、オンボーディングが混乱した。

個別の誤りは corrigendum で訂正済み (PR #2000/#2001/#2003/#2006) だが、根本原因である「1 本の ADR に 2 ライフサイクルを束ねた構造」自体は未解決のまま残っている。

1.3 課題

• 1 本の ADR が 2 ライフサイクルを束ねているため、片方の活動量で他方の指標が誤較正される (DRP 稼働中なのに #4 が「未運用」を示す)。
• implementation_status / 撤退条件 / ツール参照が両ライフサイクルで意味が異なるのに 1 本に同居しており、誤参照と監査コストが累積する。
• onboarding 時に「探索 = DRP / 検証 = MAS」の区別が ADR 上で分離されていないため、新規参画者の理解所要時間が長い (約 5〜6 時間)。

1.4 制約・要件

• 既存参照の破壊を最小化する (ADR-0028 は ADR-0029 / ADR-0034 / onboarding_checklist / ADR-0117 以降から参照されている)。
• 型付き辺 (refines) の整合性を CI で機械検証している前提を維持する (INDEX 整合性チェックを失敗させない)。
• Stage 2 Backlog / Stage 3 Decision の帰属を確定させ、パイプライン (drp-ops / spec-gen-pipeline) の二重トリガーを防ぐ。
• 撤退条件 #4 の期限 (2026-06-30) を MAS ライフサイクルへ再配置し、製品優先度で再設定可能にする。

1.5 目標 (To-Be)

ADR-0028 を 2 ライフサイクルの全体像 umbrella として残し、その下に DRP Discovery / Decision (ADR-X) と MAS GAS-MVP Build / Verify (ADR-Y) の 2 子 ADR を refine で分割する。Non-Goals: MAS の Stage 6 到達そのものを加速する施策 (リソース割当・スプリント計画) は本 ADR のスコープ外。

決定

ADR-0028 を「2 ライフサイクルの全体像 umbrella」として残し、その下に 2 つの子 ADR を refine で分割する (案 B)。

• 新 ADR-X: DRP Discovery / Decision ライフサイクル — 発見 → 意思決定 → 仕様 (概念上の Stage 1 / 2 / 3 / 4)。正典ツールは drp-ops / spec-gen-pipeline。Stage 2 Backlog および Stage 3 Decision はこの ADR-X に帰属させる (継ぎ目確定: 「何を作るか決める」までが DRP 側)。
• 新 ADR-Y: MAS GAS-MVP Build / Verify ライフサイクル — 実装 → 実機検証 → Pivot ゲート (概念上の Stage 5-6)。Walking Skeleton 4 要素・GAS=MVP・Stage 6 判定記録条件はこちらに帰属させる。

umbrella ADR-0028 は status: umbrella (読み取り専用) として CI で直接編集を拒否する。撤退条件 #4 は ADR-Y に再配置し、製品ロードマップで再設定する。ADR-0029 / ADR-0034 の refine 辺張り替え、および ADR-0028 を参照している既存文書の完全リスト化と張り替えを本 ADR の承認完了条件に含める。

判断基準 (Decision Drivers)

3.1 評価軸

K.O. criterion: Must 軸 (#maintainable / #operable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

加重和は K.O. 通過候補のタイブレーク用。案 B のみ Must 軸を通過。

検討した代替案 (Alternatives Considered)

• 案 A: 分割しない (注記のみ) — ADR-0028 のまま、#4 を「MAS ライフサイクルの指標」と注記。軽量だが #maintainable の K.O. を通過せず、2 ライフサイクル混在の構造的認知負荷が残るため不採用。
• 案 B: umbrella + 2 子 ADR に分割 (採用) — ADR-0028 を全体像として残し ADR-X / ADR-Y を refine。既存参照の破壊を最小化しつつ責務を分離。
• 案 C: 完全 supersede — ADR-0028 を 2 本で完全置換し umbrella を残さない。最も clean だが ADR-0028 を正典参照している onboarding_checklist / ADR-0117 以降を含む既存資産の張り替え範囲が広く #operable の K.O. を通過しないため不採用。

影響 (Consequences)

5.1 正の影響 (Good)

• ADR 1 本あたりの責務が単一ライフサイクルに揃い、implementation_status / 撤退条件 / 指標の誤較正が構造的に解消する。
• 撤退条件 #4 が ADR-Y に再配置されることで、DRP 稼働と切り離して製品ロードマップ判断ができる。
• onboarding_checklist が「探索 = DRP / 検証 = MAS」の 2 入口を別ライフサイクルとして参照できる。

5.2 負の影響 (Bad)

• umbrella + 2 子 ADR の 3 文書構造により、新規参画者が「どこまで読めば十分か」の境界判断を求められ、参照疲労で onboarding 所要時間がむしろ増加する可能性 (盲点 #4)。本 ADR では umbrella ADR-0028 を status: umbrella とし「読み取り専用・全体像のみ・実装詳細は子 ADR」と明示することで境界を機械化する。
• 構造分割は MAS の Stage 6 未達という開発進捗問題そのものには作用せず、DRP 稼働で全体が活発に見えることで MAS 遅延が可視化されにくくなる Goodhart リスクが残る (盲点 #7)。本 ADR のスコープ外であり、加速施策は ADR-Y 起案時に別途検討する。
• ADR-0117 以降の DRP 系 ADR 群が ADR-0028 を正典参照している場合、分割後も旧参照が残り umbrella 化の意図が形骸化するリスク (盲点 #8)。

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

• 型付き辺の張り替えにおいて、ADR-0029 は ADR-Y 寄り、ADR-0034 は ADR-X 寄りに再配置する見込みだが、最終確定は子 ADR 起案時に行う。
• umbrella ADR-0028 を残すことで既存参照の破壊は最小化されるが、案 C (完全 supersede) と比較して長期的な clean-up コストが残る。

撤退条件 (Rollback Plan)

• 分割後 3 ヶ月 (≤ 2026-09-15) で、ADR-X / ADR-Y のいずれかが自ライフサイクル内の後続 ADR から 1 度も refine 参照されない (= 分割が形骸化) 場合、umbrella の ADR-0028 に再統合する。
• 分割により「どちらの ADR を見ればよいか」の迷いが減らず、オンボーディング所要時間が分割前 (約 5〜6 時間) から短縮しない場合、案 A (注記のみ) へ縮退する。
• ADR-Y については、2026-09-15 までに Stage 6 判定記録が 1 件も生成されない場合、製品ロードマップ上の MAS 投資継続/撤退をステークホルダーに上申する (盲点 #5 への対応)。

コスト試算

• 分割 ADR 起案: DRP run 2 本 (ADR-X / ADR-Y) × 約 0.5 ドル = 約 1 ドル + 人間レビュー 1〜2 時間。
• 既存参照の張り替え: onboarding_checklist の正典参照更新 約 0.5 時間 + 型付き辺の張り替え (ADR-0029 / ADR-0034) 約 0.5 時間 + INDEX 再生成 (自動)。
• ADR-0028 参照文書の完全リスト化 (リポジトリ全体 grep + ADR-0117 以降の DRP 系 ADR 群を含む): 約 1 時間 (盲点 #8 への対応で追加)。
• 合計: 約 3〜4 人時 + LLM 約 1〜2 ドル。

備考: 過去の ADR-0028 監査で corrigendum PR が 4 本に膨らんだ実績があるため、実工数は試算の 1.5〜2 倍に振れる可能性がある。子 ADR 起案前の参照完全リスト化で先送りバイアスを抑制する。

Confirmation

• KPI 1: 分割後、Stage 6 判定記録条件 (#4 相当) が ADR-Y にのみ存在し ADR-X には存在しない。
  • 検証手段: grep でリポジトリを機械確認 (ADR-Y に 1 件 / ADR-X に 0 件)
  • 実行頻度: ADR-X / ADR-Y 承認時および月次 adr-lint
  • 違反時対応: 該当 ADR を修正し再レビュー
• KPI 2: ADR-Y が MAS 実装フェーズの後続 ADR から ≥ 2 件、ADR-X が DRP フェーズの後続 ADR から ≥ 1 件、それぞれ refine 参照を受ける (盲点 #6 への対応で非対称閾値に変更)。
  • 検証手段: 型付き辺グラフの自動集計
  • 実行頻度: 分割後 3 ヶ月時点 (2026-09-15)
  • 違反時対応: 撤退条件に従い案 A へ縮退または umbrella 再統合
• KPI 3: ADR-0029 / ADR-0034 の refine 辺張り替えが ADR-X / ADR-Y 承認後 2 週間以内に完了する (盲点 #2 への対応)。
  • 検証手段: INDEX 整合性チェック (CI) と PR レビュー
  • 実行頻度: ADR-X / ADR-Y 承認後 2 週間時点
  • 違反時対応: 起案者 ([email protected]) が張り替え PR を提出
• KPI 4: umbrella ADR-0028 が status: umbrella フラグを持ち、CI が直接編集 PR を拒否する (盲点 #3 への対応)。
  • 検証手段: adr-lint ルール追加 (umbrella-readonly)
  • 実行頻度: 全 PR で CI 実行
  • 違反時対応: PR を CI で機械拒否
• KPI 5: onboarding_checklist が「探索 = DRP / 検証 = MAS」を別ライフサイクルとして参照でき、新規参画者が 2 つの入口を区別して説明できる (定性確認)。
  • 検証手段: 新規参画者ヒアリング
  • 実行頻度: 分割後 1 ヶ月および 3 ヶ月時点
  • 違反時対応: onboarding_checklist 改訂または案 A へ縮退

参照 (References)

• 関連 ADR:
  • ADR-0028 (amends: 本 ADR で status: umbrella へ遷移させ撤退条件 #4 を子 ADR-Y へ再配置。本 ADR は ADR-0028 の構造改訂者であり親子関係ではない。umbrella の子は後続の ADR-X/ADR-Y)。逆辺 amended_by: ADR-0152 は ADR-0131 辺整合 (両端宣言) のため本 PR で ADR-0028 へ追記済み。ただし ADR-0028 の status: umbrella 遷移自体は本 ADR 承認後の実装で反映する (承認前に状態を確定させないため・KPI 4 で機械化)。
  • ADR-0029 (refine 辺の張り替え対象: ADR-Y 寄り見込み)
  • ADR-0034 (refine 辺の張り替え対象: ADR-X 寄り見込み)
  • ADR-0117 以降の DRP 系 ADR 群 (ADR-0028 参照の張り替え対象、完全リストは起案時に確定)
• 関連 PR/Issue: PR #661-668 (誤参照の原因), PR #2000 / #2001 / #2003 / #2006 (corrigendum), PR #2012 (本 ADR 起票)
• 外部資料: -

11. 参照: Pipeline 審査履歴 (2026-06-15 実行, sessionId e828131e)

本セクションは Decision Pipeline (Workflows on Cloudflare Workers) で本 ADR 草案を審査した結果のログ (audit trail)。triage〜numbering の全 Gate を直列通過し Scoring 44/50 (Standard 閾値 40 クリア)・Cross-Validation 却下なし・Consistency INFO・Policy Alignment 整合 (採択推奨) で受領。デフォルト折りたたみ。