オンボーディングチェックリスト — UC スライス開発 6 段ワークフローの理解確認

新しく開発に加わる人（Jr エンジニア）が、本プロジェクトの開発フロー全体を 1 つの文書で把握するためのチェックリスト。各項目を「自分の言葉で説明できる」状態を到達目標とする。

全体像の正典は ADR-0028（UC スライス開発全体 6 段ワークフロー）。本チェックリストはその理解確認用で、定義そのものは ADR-0028 を参照する。

2026-06-20 以降の構造: ADR-0152 (Accepted 2026-06-15) により ADR-0028 は umbrella 化され、責務が 2 子 ADR に分割された:

探索ライフサイクル (Stage 1-4) = ADR-0160（DRP Discovery / Decision）

検証ライフサイクル (Stage 5-6) = ADR-0161（MAS GAS-MVP Build / Verify）

概念全体の入り口は引き続き ADR-0028。具体的なライフサイクル定義は、探索なら ADR-0160 / 検証なら ADR-0161 を参照する。

入口は 2 つに分かれる。 製品（MAS = 法人会計自動化）を「どう作り検証するか」という流れの概念は ADR-0028 が正典。一方、ADR 起案や仕様書生成に使うツール（DRP）の具体的な使い方は ADR-0028 ではなく、現役の Skill / 手順書が正典（ツールは継続的に進化するため）。各段で「概念は ADR-0028 / ツール手順は各 Skill」を意識して読むこと。ADR-0028 本文に出てくる古いスクリプト名（scripts/1, scripts/2.5 等）は現行では別名・Skill 化されているので暗記しないこと。

使い方

上から順に読み、各チェック項目を理解できたら [x] を付ける
「理解できた」の基準は 暗記ではなく、なぜその段が必要かを説明できること
不明点が出たら、各項目末尾の参照 ADR / 手順書を読む
想定所要時間: 約 5〜6 時間（6 段フレームワーク把握 2〜3 時間 + ADR-0028〜0030 通読 1 時間 + UC スライス 1 本同乗 2 時間）

0. 大前提（二層構造）

UC スライス開発は 探索フェーズと検証フェーズの二層構造になっている。まずこの全体像を押さえる。

探索フェーズ（Customer Discovery / Stage 1-2） = 「この痛みを解く価値があるか」を低コストで検証してから Backlog に積む段階だと説明できる
検証フェーズ（Customer Validation / GAS MVP / Stage 3-6） = GAS を MVP として実際に解けるかを実機で検証する段階だと説明できる
なぜ「探索 → 検証」の順序を構造的に固定するのか（＝問題未検証のまま実装投資するリスクを防ぐため）を説明できる

参照: ADR-0028 §決定「二層構造」

1. 6 段ワークフローの各段

各段が「何を入力に・誰が主担当で・何を出力するか」を説明できることを確認する。

Stage 1: Discovery（問題発見） — Gemini Deep Research + Claude Research で「解く価値がある」と判定済みの課題記述（RQ-NNN）を作る段だと説明できる（ツール手順は customer_discovery_workflow.md が正典。具体的なスクリプト名は手順書側を見る。ADR-0028 本文の scripts/5_* 等の記載は当時の名称）
Stage 2: Backlog（UC スライス化） — 課題を UC スライスに分割し usecase_dev_mapping / todo_master_tables に積む段だと説明できる（手順: backlog_pipeline_workflow.md）
Stage 3: Decision（ADR 起案） — 設計判断を Decision Pipeline (DRP) で ADR として残す段だと説明できる。DRP は triage → socratic → scoring → cross-validation → parallel review → gate の多段審査に発展しており、ツール操作は drp-ops Skill が正典（背景は decision_pipeline/README.md、運用は operator_guide.md）。ADR-0028 本文の「Decision Pipeline + 技術調査」は概念レベルの記述で、実際の手順は DRP 側を見る
Stage 4: Spec Pipeline — 開発仕様書（dev_*.md）を生成する段だと説明できる。現行は spec-gen-pipeline Skill（B2→B3→B4→B5→B6）が正典（テンプレートは dev_spec_prompt_template.md）。ADR-0028/0029 本文の scripts/1 + scripts/2.5 + scripts/2 + scripts/4 は移行前の名称なので、実ファイルは探さず Skill 経由で実行する
Stage 5: Impl Pipeline — Claude Code で「1 PR = 1 UC スライス」を実装する段だと説明できる（B1-B6 / C1-C6 の内部詳細は ADR-0029、検証ライフサイクル全体 (Stage 5-6) は ADR-0161）
Stage 6: Verify + Pivot Gate — npm run push:dev/prod で GAS 実機検証し、98_audit_log に判定結果を記録する段だと説明できる（Pass/Pivot/Fail 判定の運用は ADR-0161 §1.5、stage6_verdict 列の運用開始は ADR-0161 KPI 4）

参照: ADR-0028 §決定「6 段の定義」

2. Stage 6 ピボット判定ゲート

このワークフローの肝。「動くが使われない」失敗を構造的に検知する仕組み。

Pass（実際の月次処理に組み込まれ問題が解消） → 次の UC スライスの Stage 1 へ、を説明できる
Pivot（動くが使われない / 解くべき問題がずれていた） → Stage 1-2 に戻り問題仮説を修正、を説明できる
Fail（技術）（6 分制限超過 / 設計変更が必要） → Stage 3（ADR）に戻り設計を修正、を説明できる
判定結果は changelog に「Stage 6 … Pass/Pivot/Fail」の形式で記録する運用だと理解している

参照: ADR-0028 §決定「Stage 6 ピボット判定」

3. Walking Skeleton 4 要素

UC スライスの初回実装から横串で貫通させる先行実装制約。

Walking Skeleton 4 要素（認証 / DDL / 監査ログ / Feature Flag）を列挙できる
これらが Stage 4-5 の横断的先行実装制約であり、後から追加すると移行コストが指数的に増える理由を説明できる

参照: ADR-0028 §決定「Walking Skeleton の位置づけ」、正式定義は ADR-0028 §採用方針

4. GAS = MVP の位置づけ

GAS は本番プラットフォームではなく「検証用 MVP」だと説明できる
Stage 6 で Problem-Solution Fit が確認できた機能の本番移行（GCP / ローカル LLM）は、6 段の外側の別ライフサイクルだと理解している

参照: ADR-0028 §決定「GCP / ローカル LLM 移行」

5. 関連 ADR の通読

ADR-0028（全体 6 段ワークフロー = 概念フレーム / umbrella）を通読した
ADR-0152（ADR-0028 umbrella 化 + 2 子 ADR 分割の親決定）を通読した
ADR-0160（探索 = DRP Discovery / Decision ライフサイクル Stage 1-4）を通読した
ADR-0161（検証 = MAS GAS-MVP Build / Verify ライフサイクル Stage 5-6）を通読した
ADR-0034（Stage 1-2 ワークフロー定義）を通読した（Stage 1-2 の詳細は ADR-0030 ではなくこちら）
ADR-0029（Stage 4-5 Spec/Impl Pipeline の詳細）を通読した

6. UC スライス 1 本に同乗

進行中または直近の UC スライス 1 本について、Stage 1 から Stage 6 までの流れを実例で追えた
その過程で git commit → push:dev → 動作確認 → git push → PR → main マージ の順序（git_workflow.md）を確認した

完了の目安

上記すべてに [x] が付けば、本プロジェクトの開発フロー全体像を把握したとみなす。次は実際の UC スライスに Stage 5（実装）から参加する。