← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 20:32
commonid: adr-0021type: adrstatus: accepted
pagemode: Criticalkruchten: Existence/Propertyscope: platformimplementation_status: In Progress (UC スライス採用済、Walking Skelet…proposed_at: 2026-05-12 16:04approved_at: 2026-05-12 18:43business: mas
型付き辺: 出 11 / 入 5
部分修正する: ADR-0018 前提とする: ADR-0010 ADR-0020 関連: ADR-0024 ADR-0023 ADR-0040 ADR-0043 ADR-0062 ADR-0108 ADR-0019 ADR-0029 細分化された: ADR-0028 ADR-0027 ADR-0161 宿題回答された: ADR-0026 前提とされる: ADR-0025全体は INDEX →

ADR-0021: UCスライス開発と監査ログ機構を採用

  • Status: Accepted
  • Mode: Critical
  • Kruchten Type: Existence/Property
  • Scope: platform
  • Implementation Status: In Progress (UC スライス採用済、Walking Skeleton 実装は ADR-0027/0029 で継続)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-12 16:04
  • 承認日時 (JST): 2026-05-12 18:43

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 レビューで確定)。

判断軸の参照: プロジェクト共通の判断軸 (リスク受容方針) は docs/adr/README.md の「リスク受容方針」セクション 参照。本 ADR は同方針を前提とする。 用語定義: 略号・ドメイン用語は docs/adr/README.md の「用語定義 (Glossary)」 参照。

決定の早わかり（Y-statement）

本節は ADR-0140 の方針で遡及追加された本文の要約で、新しい意味は加えていない (意思決定内容は不変)。「文脈で問題に直面し、対抗案でなくこの案を選び、目的のため代償を受け入れる」と読む。詳細はコンテキスト以降の本文に展開する。

  • 文脈: 276 件の実装案件を二重ビュー (技術カテゴリ別 + 業務パターン別) で整理し、580+ PR ワークフローを代表取締役単独で回している。
  • 問題: 次に実装すべき案件の優先度判断が属人化し、業務塊 (ユースケース) 単位の進捗が把握しにくい。二重ビューの更新し忘れも発生し始めている。
  • 問題点と課題（直せる原因 → 発生を止めるためにやること）:
    • 276 件から選ぶ基準が不明確で、優先度・進捗が見えない → usecase_dev_mapping.md を UC 軸 SSoT とし、Now/Next/Later で優先度・リリース計画・ステータスを管理する。
    • UC 軸と技術軸の両方を手動更新し、片方を更新し忘れる → 役割分担を明文化し、slice_id 列は GitHub Actions で自動更新する。
    • Jr (2026-10 入社予定) に「何から手を付けるか」を伝える基準が未確立 → Jr 入社前に Walking Skeleton (UC-4) で開発骨格を固める。
  • 前提（解決を課題に立てない与件）:
    • 開発体制は 1 名 + 2026-10 入社予定 Jr 1 名。技術スタックは GAS V8 + Google Sheets + clasp + GitHub Actions + Cloudflare Workers。
    • 監査要件 (中小企業会計指針 + 電帳法 + 消費税 + 法人税) で改ざん不可・追跡可能性が必要。
    • ADR-0010 / ADR-0018 (根本部分) / ADR-0019 / ADR-0020 は不変。既存 580+ PR ワークフローを破壊しない。
  • 決定（対応策）: 1 軸統合 (Linear / Notion 移行) や Outcome-Driven Roadmap 等 (案 A〜F) でなく、UC スライス × Walking Skeleton × Now/Next/Later の 3 層ハイブリッドを採用し、hash chain 方式の監査ログ機構を Walking Skeleton 必須要素として組み込む。ADR-0018 は SUPERSEDE せず拡張する (個別の決定詳細は本文 §2 へ)。
  • 目的: ユーザー価値を 1 つずつ積み上げる開発フローを確立し、業務塊 (UC) 単位でリリース・テスト・追跡可能性を担保する。Jr 入社前に開発骨格を固め、監査要件を技術的に担保する。
  • 代償: 実装に 32-56 h (コンティンジェンシー込み 56-96 h) を消費する。部分完成状態が本番に常在し、先行設計の機会や単体テストの純粋さを捨てるトレードオフを受け入れる。
  • 詳細は本文の影響・撤退条件セクションを参照のこと

目次

§見出し
1コンテキスト
1.1〜1.6現状 / 課題 / 要求 / 前提条件 / 制約条件 / 判断基準
2決定
2.1〜2.10採用方針詳細 / Walking Skeleton 対象 / Walking Skeleton 前提 / GitHub Actions 自動更新仕様 / 監査ログ機構 / 過渡期運用ルール / clasp / GAS 並行開発戦略 / 影響範囲 / コスト試算 / 完了条件
3検討した代替案
4影響 (Consequences)
4.1〜4.5正の影響 / 負の影響 / リスク / 長期影響 / 採用に伴うトレードオフ
5撤退条件 (Rollback Plan)
5.1〜5.3判定指標 / バックアップ・リカバリ / 期限
6参照 (References)

1. コンテキスト

1.1 現状 (Current State)

  • bizlp-gas-accounting プロジェクトは 276 件の実装案件 (MAS / I / S / F / N / DS) を抱えている
  • 整理軸は 二重ビューで運用: 技術カテゴリ別 (todo_master_tables.md) + 業務パターン別 (usecase_dev_mapping.md)
  • 既存 580+ PR ワークフロー (1.5 年運用) を代表取締役単独で回している
  • 案件の内訳 (2026-05-12 時点): 完了済 28 件 / 仕様書完了 46 件 / 未着手 P1 約 50 件 / 残 152 件

1.2 課題 (Issues)

  • (a) 優先度が見えない — 次に実装すべき案件の重要度判断が属人化、276 件から選ぶ基準が不明確
  • (b) 進捗が見えない — 業務塊 (ユースケース) 単位で「何が完成して何が未完か」が把握しにくい
  • 二重メンテ崩壊の予兆 — UC 軸と技術軸の両方を都度更新する負荷で、片方を更新し忘れる事態が発生し始めている
  • Jr 入社前の負債 — 2026-10 入社予定の Jr エンジニアに「何から手を付けるか」を伝える基準が未確立

1.3 要求 (Requirements — どうしたいか)

  • ユーザー価値を 1 つずつ積み上げる 開発フローを確立する
  • 業務塊 (UC) 単位でリリース・テスト・追跡可能性を担保する
  • Jr 入社前に 開発骨格 (Walking Skeleton) を固める
  • 監査要件 (改ざん不可・追跡可能性) を技術的に担保する
  • 進捗報告のオーバーヘッドを最小化 (1 人法人 + 業務委託 Jr 1 名の規模に見合う運用)

1.4 前提条件 (Preconditions — 動かせない事実)

  • 開発体制: 1 名 (代表取締役) + 2026-10 入社予定 Jr 1 名
  • 監査要件: 中小企業会計指針 + 電帳法 + 消費税 + 法人税の遵守、改ざん不可・追跡可能性が必要
  • 技術スタック: GAS V8 + Google Sheets (単一スプレッドシート) + clasp + GitHub Actions + Cloudflare Workers (Decision Pipeline)
  • アーキテクチャ: Modular Monolith (000_infra → 100_config → 200_data → 300_ui → 400_domain → 500_import → 600_report → 800_ops → 900_test の数値プレフィックス)
  • 既存資産: UC-1〜5 + OP × 44 業務パターン (docs/use_cases.md)、580+ PR ワークフロー、ADR-0001〜0020 = 20 件の既存決定
  • RQ-040 並列研究の合意 (2026-05-12): Gemini Deep Research + Claude Research が UC スライス × Walking Skeleton × Now/Next/Later の 3 層 を完全一致で推奨。詳細は docs/_internal/research_prompts/RQ-040_dev_organization_paradigm_synthesis.md

1.5 制約条件 (Constraints — 守るべきルール)

  • ADR-0010 (Modular Monolith Numbering) 不変 — 数値プレフィックス命名規約 (000_infra → 900_test) は変更不可
  • ADR-0018 (TODO 管理 3 軸グルーピング / GitHub Issues 移行保留) の根本部分は不変 — TODO_future.md を Markdown 単一ファイルで維持、GitHub Issues 移行は保留、3 軸グルーピングは維持 (本 ADR で拡張 = SUPERSEDE ではない)
  • ADR-0019 (Decision Pipeline) / ADR-0020 (Triage 基準) 不変 — 起案フロー・採点ルールに干渉しない
  • 既存 580+ PR ワークフローを破壊しない — 段階移行で吸収、過去 PR の事後分類は許容
  • Reversibility 確保 — 6 ヶ月後 (2026-11) に再評価条項で方針転換可能であること
  • 本 ADR は Critical モード — 開発プロセスと情報管理の根幹を変更し監査要件にも影響するため、Decision Pipeline で Critical 判定

1.6 判断基準 (重み付き)

意思決定で各代替案を評価する際の優先順位:

  1. ADR-0010 整合性 (最重要) — 数値プレフィックス命名規約と矛盾しないこと
  2. 監査要件適合度 (最重要) — 改ざん不可・追跡可能性を担保できること
  3. 1 人法人の運用コスト (高) — ツール切替・学習コストが実装時間を侵食しないこと
  4. 既存メモリ整合性 (中) — 過去判断 (GitHub Issues 移行保留) との連続性
  5. Jr 受け入れ容易性 (中) — 2026-10 入社時の学習コスト最小化
  6. Reversibility (中) — 6 ヶ月後再評価で方針転換可能

2. 決定

UC スライス (Use-Case 2.0 / Jacobson 2016 ACM) × Walking Skeleton (Cockburn) × Now/Next/Later Roadmap (Bastow) の 3 層ハイブリッドを採用する。usecase_dev_mapping.md を UC 軸 SSoT (優先度・リリース計画・ステータス管理) とし、todo_master_tables.md を技術軸 Cross-Reference Index として役割分担を明文化、slice_id 列は GitHub Actions で自動更新する。進捗管理ツールは Markdown 維持 (Linear / Notion 移行は 2026-11 再評価条項付き)、Wardley Mapping は ADR 起案時の任意分析ツールに格下げ、Walking Skeleton = UC-4 (ランウェイ対応) で骨格貫通を実施し、hash chain 方式の監査ログ機構 (99_audit_log シート / 000_infra/099_audit_log.js) を Walking Skeleton 必須要素として組み込む。本 ADR は ADR-0018 を SUPERSEDE せず、①役割分担明文化 ②3 列追加 ③GitHub Actions 自動更新 の 3 点で拡張する。

2.1 採用方針詳細

  1. 採用パラダイム (両エンジン完全一致): UC スライス (Use-Case 2.0 / Jacobson 2016 ACM) × Walking Skeleton (Cockburn) × Now/Next/Later Roadmap (Bastow) の 3 層ハイブリッド。
  2. 二重ビュー維持 (役割分担明文化): usecase_dev_mapping.md (UC 軸 SSoT / 優先度・リリース計画) + todo_master_tables.md (技術軸 Cross-Reference Index)。ステータス管理は UC 軸のみ、技術軸の slice_id 列は GitHub Actions で自動更新。
  3. 進捗管理ツール: Markdown 維持。Linear / Notion 移行は 6 ヶ月後 (2026-11) 再評価条項付き。
  4. Wardley Mapping: 補助的扱い。四半期定期評価は不採用、ADR 起案時の任意分析ツールに格下げ。
  5. 失敗パターン警戒: SAFe 形骸化 / Outcome 逃避 / Markdown 二重メンテ崩壊 / Feature Flag 負債化 / 6 分制限超過 を四半期レビューでチェック。
  6. 共通技術運用: 擬似 BDD (QUnit + Gherkin コメント、関数命名規約 test_{slice_id}_{condition}) / PropertiesService Feature Flag / Trunk-Based Development + 短命ブランチ + 業務塊単位 PR / 監査ログ機構を Walking Skeleton の必須要素にする。

2.2 Walking Skeleton 対象 = UC-4 (ランウェイ対応) 確定

選定基準: ①監査ログ機構の薄さ (骨格貫通効果が大きい) ②Now 層優先度 (代表取締役の現状運用で頻発) ③失敗時の早期検証価値 — の 3 軸すべてで UC-4 > UC-2。

2.3 Walking Skeleton (UC-4-S01) が確定させる前提 — なぜ「最初に」やるのか

UC-4-S01 を最初のスライスとして通すことで、以降の全スライスが依存する以下の前提を実地で確定させる:

  • GAS が 33_wrk_bank に書き込める — 権限スコープ・スキーマ定義 (setupAllSchemas 適用結果)・列構造の実在を本番経由で確認。
  • hash chain 計算が動く — Utilities.computeDigest(SHA_256, ..., Charset.UTF_8) が GAS V8 ランタイムで期待通り動作、前行ハッシュとの連鎖が UTF-8 文字列レベルで一意に決まる。
  • 実行時間が 6 分以内に収まる — LockService.getScriptLock() + SpreadsheetApp.flush() の組合せで Walking Skeleton 1 サイクルの実時間を計測し、GAS のハードリミット内に収まる粒度であることを確認。
  • LockService が正常に取得・解放される — try/finally 構造でデッドロック・leak を防止。タイムアウト時はフェイルセーフ設計 (UI へ安全なエラー返却 + 自動リトライ禁止) を採用。具体的なタイムアウト値・UI 文言は実装側の責務。
  • 全レイヤーの接合面が実装上確定する — UI (HTML / Web App /exec) → Domain (400_domain) → Data (200_data) → Infra (000_infra/099_audit_log.js) → Spreadsheet の貫通経路が動くコードとして存在する状態に到達。以降の UC-X-S0X はこの貫通経路を再利用 (コピー → 用途別に差分実装) して書ける。

「最初にやる」理由: これらの前提はコード設計上のあらゆる仮定の基盤となる。前提が崩れる (例: 33_wrk_bank に書き込めない / hash chain が UTF-8 で一意に決まらない / LockService が leak する) と、その上に書いた全コードが設計ミスとして書き直し対象になる。Walking Skeleton は「思い込みを形成する前に、最薄の経路で実地確認する」ための構造であり、書く前の検証 ではなく 動かしての検証 を最優先する Cockburn の原則に従う。

2.4 GitHub Actions 自動更新仕様 (Markdown 二重メンテ防止)

ポリシー (実装詳細は GitHub Actions ワークフローファイルと CONTRIBUTING.md に委譲):

  • slice_id 列を GitHub Actions で自動更新 — usecase_dev_mapping.md を含む PR の merged 時に技術軸 (todo_master_tables.md) の対応行を自動同期
  • 失敗時の通知: GitHub Issues 自動起票 + Slack 通知で障害を即時可視化
  • 障害時のリカバリ手段を別途用意 — 手動再生成スクリプト経由で復旧可能 (詳細は実装側)
  • 並列 PR マージ時は直列化 (concurrency 制御) で Lost Update を構造的に防止
  • ステータス管理は UC 軸のみが SSoT — 技術軸の「ステータス」「優先度」列は廃止

2.5 監査ログ機構 (Walking Skeleton 必須要素)

ポリシー宣言 — 詳細設計は別 ADR (Decision Pipeline 経由で起案予定) に委譲:

  • 改ざん不可・追跡可能性の確保: 監査ログ機構を Walking Skeleton (UC-4-S01) の必須要素として組み込む
  • 採用方式: hash chain 方式 (各行に前行ハッシュ + 当該行ハッシュ) でブロックチェーン的な改ざん検知を実現
  • PII / クレデンシャル保護: 機密情報のマスキング・ハッシュ化ルールを別途定義
  • 長期運用への対応: シート容量上限への対応 (アーカイブ機構) と並行開発時の整合性復元手段を別途定義

詳細仕様 (Hash Chain アルゴリズム / 記録項目 / アーカイブルール / マスキング方針 / Genesis 起点定義 / 並行開発時のコンフリクト解消) は別 ADR「GAS×スプレッドシート構成における Hash Chain 監査ログと機密データ保護方針」で起案する (採番は Pipeline で自動採番)。本 ADR は「Walking Skeleton 必須要素として hash chain 監査ログを採用する」というアーキテクチャ接合の方針決定に専念し、実装詳細は独立 ADR で扱う (関心事の分離 / Mega-ADR 回避)。

2.6 過渡期 (Jr 入社前) 運用ルール

  • 1 PR の粒度: 「1 PR = 1 UC スライス」を理想、複数の技術カテゴリにまたがる変更は許容、複数の UC スライスを跨ぐ変更は禁止
  • slice_id 付与: 新規 PR はコミットメッセージまたはタイトルに [slice_id: UC-X-S0X] 形式で記載。CI 自動チェックで命名規則逸脱を検出 (具体的な正規表現・ワークフロー設定は実装側 / CONTRIBUTING.md に委譲)。既存 580+ PR は事後分類
  • Walking Skeleton 期間: UC-4 完走を最優先
  • Jr 入社後完全移行: 2026-10 入社後 1 ヶ月以内に「1 PR = 1 UC スライス」厳格適用に切替

2.7 Jr 入社後の clasp / GAS 並行開発戦略

ポリシー宣言 — 詳細設計は別 ADR (Decision Pipeline 経由で起案予定) に委譲:

  • Dev/Prod 環境を完全分離: コード (.clasp.dev.json scriptId) のみならず書き込み先スプレッドシート実体も分離し、本番業務データへの汚染を構造的に防止
  • prod デプロイ権限: オーナー (代表取締役) のみ実行可、技術的にブロック済 (CLAUDE.md Prohibited + Hook)
  • コードレビュー: Jr の PR は必須レビュー (Branch Protection Rule で強制)
  • コンフリクト解消: コードは Git 通常マージ、シートレベルは Hash Chain 検証で破壊検知して専用ツールで復元

詳細仕様 (具体的な scriptId 分離手順 / TARGET_SPREADSHEET_ID_DEV 等のキー定義 / dev スプレッドシート初期セットアップ / シートレベル コンフリクト解消スクリプト / setupAllSchemas の LockService 連携) は別 ADR「GAS Modular Monolith における複数人並行開発と Dev/Prod データ分離アーキテクチャ」で起案する (採番は Pipeline で自動採番)。本 ADR は「Jr 受け入れ前に並行開発インフラを整備する」という方針決定に専念し、実装詳細は独立 ADR で扱う。

2.8 影響範囲

改修対象 docs

  • usecase_dev_mapping.md: 3 列追加 + Backbone 行 (UC-1〜5) 明示
  • todo_master_tables.md: 役割「Cross-Reference Index」に明示、slice_id 列追加、廃止列削除
  • prd.md: 冒頭に「整理軸方針」セクション追加
  • product_overview.md: 「UC スライス Now/Next/Later ビュー」に書換 + UC-1〜5 サブセクション化

改修対象コード (実装詳細は別 ADR / CONTRIBUTING.md に委譲):

  • 900_test/901_test_runner.js: テスト関数命名規約を slice_id ベースに統一 (具体的な命名規則は CONTRIBUTING.md)
  • 000_infra/ 配下に監査ログ機構の新規モジュール (詳細は別 ADR)
  • .github/workflows/ に slice_id 自動更新 + CI Lint ワークフロー (詳細は別 ADR / GitHub Actions ワークフローファイル)

不変対象: ADR-0010 / ADR-0018 (根本方針) / ADR-0019 / ADR-0020、既存 580+ PR ワークフロー (Jr 入社後に段階移行)

2.9 コスト試算 (採用判断材料)

採用案 (Markdown 維持 + Walking Skeleton 構築): 概算 32-56 h (4-7 営業日)、コンティンジェンシー込みで 56-96 h (7-12 営業日)。Jr 入社 (2026-10) までに完了可能な規模。

不採用案との差額 (Linear/Notion 移行を見送った経済的根拠):

  • 不採用案: 年 $240 + 移行作業 16-24 h + 学習コスト 16-24 h
  • 6 ヶ月運用観察 (2026-11 再評価) でこの差額を判断材料に組み込む

詳細な内訳 (4 docs / Walking Skeleton / 監査ログ / 276 案件分類 / GitHub Actions ワークフロー) は GitHub Issues / プロジェクトマイルストーンで管理する。

2.10 完了条件 (検証可能メトリクス)

  1. ADR-0021 が Accepted 化 — Status / 承認日が埋まる
  2. 改修対象 docs 4 ファイル PR マージ — 各ファイルに指定セクション/列が存在 (ファイル内パターン検証)
  3. sync-slice-id.yml + regenerate-slice-id.mjs マージ + 動作確認 PR 成功 — 任意の usecase_dev_mapping.md 編集 PR から 30 分以内に todo_master_tables.md 自動 commit
  4. 監査ログ機構稼働 + verifyAuditLogIntegrity() テスト pass — 99_audit_log に 10 行以上書込 → true 返却
  5. Walking Skeleton = UC-4 で E2E スライス 1 本が test_UC4_S01_* 全 pass — 監査ハッシュ + 認証 + DDL 整合性の 3 アサーション成立
  6. 276 案件分類 100% — usecase_dev_mapping.md の now_next_later 列の空欄率 0% (1 ヶ月以内、段階移行の Phase 詳細は GitHub Issues で管理)
  7. 2026-11-15 に再評価エントリを changelog.md に追加

3. 検討した代替案 (Alternatives Considered)

  • 案 A: 1 軸統合 (Linear / Notion 移行 + 技術カテゴリ廃止) — Gemini 推奨 — 不採用理由: ADR-0010 (Modular Monolith Numbering) と矛盾、ツール切替コスト過大、既存メモリ「GitHub Issues 移行保留」と不整合、Linear 自身が ~50 人規模の運用 (Lenny's Newsletter 取材で公表)。潜在的利得 (定量比較): ①UI 自動集計 (ステータス推移グラフ等で月 2-3 h の集計作業削減) ②通知機能 (期限超過アラートで判断ミス減少 3-5 件/月) ③公開ロードマップ機能。ただし月額 $240/年 + 移行作業 8-16 h + 学習コスト 16-24 h を上回るかは 1+1 名規模では否定的判断。

  • 案 B: Outcome-Driven Roadmap (Cagan "Empowered" 型 / OKR 連動) — 両エンジン一致で不採用 — 不採用理由: 監査要件下では「監査リスク低減」等の計測不能 outcome に逃避する構造的リスク、計測スキーム構築コストが実装コストを上回る、PM ≡ Engineer ≡ CEO の単独 3 役で empowered team 前提が成立しない。潜在的利得: ①Outcome 計測文化醸成で経営判断精度向上 (定量化不能、Solo CEO は感覚で代用可) ②計測スキーム自体の資産化。ただし計測の月次運用コストが推定 8-16 h/月で実装時間を消費。商用化フェーズ (2027 以降) で再評価。

  • 案 C: WSJF (Weighted Shortest Job First) / SAFe 完全採用 — 両エンジン一致で不採用 — 不採用理由: 1 人開発で複数評価者がいないため Agility-at-Scale 指摘の Denominator gaming / Single-stakeholder scoring に構造的に陥る、見積もりコスト自体が遅延要因。潜在的利得: Cost of Delay 3 要素 (Business Value / Time Criticality / Risk Reduction) を要素引用として ADR 起案時の判断材料に活用 (本 ADR でも撤退条件の優先度判定に活用)。

  • 案 D: 厳密 DDD (Aggregate Root / Value Object 過剰定義) — 両エンジン一致で不採用 — 不採用理由: GAS Modular Monolith でボイラープレートが肥大化、1 人開発で実装速度低下。潜在的利得: ユビキタス言語 / Bounded Context 概念を 400_domain 配下で要素引用 (本 ADR 採用方針と両立)。

  • 案 E: Shape Up (Basecamp / Ryan Singer / 6 週サイクル + Betting Table + Hill Chart) — Claude 単独指摘 — 不採用理由: Shape Up 公式 Appendix 2 ("Adjust to Your Size") が「a tiny team can throw out most of the structure. You don't need to work six weeks at a time. You don't need a cool-down period, formal pitches or a betting table」と明記。1 人開発では Betting Table が機能しない。潜在的利得: Appetite (時間予算) の概念を Walking Skeleton 構築計画に要素引用 (本 ADR コスト試算でも明示)。

  • 案 F: Wardley Mapping 四半期定期評価 — Gemini 推奨だが格下げ — 不採用 (定期評価としては) 理由: bizlp の戦略判断頻度 (年 1〜3 回) に四半期評価は過剰、既存 product_overview.md の鳥瞰ビューと役割重複。潜在的利得: 自作 vs 外部化の判断軸を可視化 → ADR 起案時の任意分析ツールとして位置付け維持 (例: ADR-0019 LiteLLM Gateway 採用判断)。

4. 影響 (Consequences)

4.1 正の影響

  • UC 軸 SSoT 化により「次に実装すべき案件の優先度」「業務塊単位での進捗」の二大課題が解消、Now/Next/Later で意思決定が即時化
  • Walking Skeleton (UC-4) により監査ログ機構 / 認証 / DDL 整合性の E2E 骨格が早期確立、後続 UC の再利用基盤になる
  • hash chain 監査ログ機構 (99_audit_log) で改ざん不可・追跡可能性が技術的に担保され、監査要件適合度が確定的に向上
  • GitHub Actions による slice_id 自動更新で Markdown 二重メンテ崩壊リスクを技術的に予防
  • ADR-0018 を SUPERSEDE せず拡張する設計のため、既存 580+ PR ワークフローへの破壊的変更なし
  • Jr (2026-10 入社) 受け入れ時に「1 PR = 1 UC スライス」厳格適用 + Branch Protection Rule で学習・レビューコストを最小化
  • Markdown 維持により年 $240 + 学習コスト 16-24 h を回避、6 ヶ月運用観察期間を確保

4.2 負の影響

  • 4 docs 改修 + Walking Skeleton (UC-4) + 監査ログ機構 + 276 案件分類 + GitHub Actions で合計 32-56 h (4-7 営業日)、コンティンジェンシー込みで 56-96 h (7-12 営業日) の実装時間を消費
  • 過渡期 (Jr 入社前) は「1 PR = 1 UC スライス」が理想止まりで、複数技術カテゴリ跨ぎ PR が許容されるため厳密性が一時的に低下
  • 既存 580+ PR の事後 slice_id 分類が必要、Phase 3 (残 152 件 / 1 ヶ月) まで空欄が残存
  • 技術軸 (todo_master_tables.md) の役割が「Cross-Reference Index」へ縮退するため、半年ごとに ADR-0021 を再読しないと役割が形骸化する恐れ

4.3 リスク

  • Markdown 二重メンテ崩壊: GitHub Actions 障害で slice_id 自動更新が止まると技術軸が陳腐化 (失敗時 GitHub Issues 自動起票 + Slack 通知 + scripts/regenerate-slice-id.mjs で軽減)
  • Feature Flag 負債化: PropertiesService Feature Flag が回収されず累積するリスク (四半期レビューでチェック)
  • SAFe 形骸化 / Outcome 逃避: 採用パラダイムが手段化し本来目的を見失うリスク (四半期レビューで失敗パターン警戒項目に明示)
  • 6 分制限超過: GAS 実行制限に Walking Skeleton が抵触するリスク (月 3 件超で ADR-0023 起案)
  • hash chain 性能劣化: 年 1 万行規模で verifyAuditLogIntegrity() 月次バッチの性能劣化リスク (§2.5 監査ログ機構の「アーカイブ」項で半期分割により軽減、長期影響で再評価)
  • slice_id 命名規則ドリフト: UC-X-S0X → UC-X-feature-name 等の表記揺れリスク
  • Walking Skeleton (UC-4) レガシー化: 他 UC で同パターンが再利用されないまま放置されるリスク

4.4 長期影響 (Long-term Impact / 6 ヶ月以降)

半年〜1 年後 (2026-11 〜 2027-05)

  • Jr 入社後の 1 PR = 1 UC スライス厳格適用の定着確認
  • slice_id 列の手動編集発生率 (月 1 件以上で自動化ロジック改修)
  • 監査ログ機構の hash chain 検証バッチの性能 (年 1 万行で性能劣化リスク → §2.5 アーカイブ機構が想定通り作動するかを確認)
  • Walking Skeleton (UC-4) で確立した E2E パターンの他 UC 再利用率
  • Now/Next/Later の Stale 化 (Later 層が 6 ヶ月動かない案件で溢れていないか)

1 年〜2 年後 (2027-05 〜 2028-05 / 商用化フェーズ想定)

  • 案件数 500 件超で Linear / Notion 移行判断 (ADR-0022 起案)
  • チーム拡大時の UC スライス所有権分担ルール整備
  • 顧客行動データ可視化に伴う Outcome-Driven Roadmap 部分採用の再評価
  • F-59 (Agentic AI) 等の AI 自動オーケストレーションと UC スライス概念の統合

永続的負債リスク

  • todo_master_tables.md の Cross-Reference Index 役割が忘れられる → 半年ごとに ADR-0021 を再読し、形骸化チェック
  • Walking Skeleton (UC-4) がレガシー化、他 UC で同パターンが再利用されないまま放置
  • slice_id 命名規則のドリフト (UC-X-S0X → UC-X-feature-name 等)

Review After タイミング

  • 3 ヶ月後 (2026-08-15): Phase 3 (276 案件分類) 完了確認、Walking Skeleton UC-4 完走確認
  • 6 ヶ月後 (2026-11-15): 撤退条件の全項目チェック、ADR-0022 起案要否判定
  • Jr 入社 1 ヶ月後 (2026-11-15 前後): Jr の運用フィードバック収集、ペアプロ振り返り
  • 1 年後 (2027-05-12): 案件数・PR 数・自動化信頼性メトリクス集計、ADR-0021 全体の存続/改訂判定

4.5 採用に伴うトレードオフ — 何を捨てたか

代替案との優劣比較とは別軸で、3 層ハイブリッド (UC スライス × Walking Skeleton × Now/Next/Later) を採ることで放棄するものを明示する。これらは「不採用案を選んでいれば回避できた」が、本 ADR の制約 (1 人法人 / 監査要件 / GAS) 下では受け入れ可能と判断したものである。

  • 先行設計の機会 — DDL や横断的なデータ構造のリファクタは UC スライスを通すたびに事後に発生する。「全体スキーマを固めてから機能を載せる」という伝統的なボトムアップ設計の機会は捨てる。
  • ドメイン内の一貫性 — UC-4-S01 をリリースし S02 が未着手という部分完成状態が本番に常在する。「全機能が揃ってからリリース」を捨てる。
  • 単体テストの純粋さ — Walking Skeleton + 業務塊単位テストの構造上、E2E テスト中心になり、Unit テスト純粋性 (1 関数 1 アサーション・モック中心) は二次的になる。テストの実行時間が長くなり flakiness リスクも上がる。
  • 横断的関心事の一括実装 — 認証 / 監査ログ / 権限 / 多言語化等の cross-cutting concerns は「最初に全モジュール分実装」ではなく、各スライスで都度判断する。横断機能の一貫性確保には継続的な意識が必要になる。
  • 「完成してからリリース」の選択肢 — Now/Next/Later 採用により、Later 層の機能はリリース時期が確約されない。「全部できてから出す」モデルは構造的に放棄。

これらは運用上見えるコストとして常時存在するが、§4.4 リスク受容方針 の通り自分の裁量で技術的に回収可能な範囲にとどまるため受容する。

5. 撤退条件 (Rollback Plan)

5.1 判定指標 (判定主体 / 観測手段 / SLA 明示)

判定指標閾値判定主体観測手段確認 SLA
案件数拡大400 件超代表取締役usecase_dev_mapping.md の行数 (月次 wc -l 自動)月次レビュー (毎月 1 日)
Jr の Markdown 運用への不満1on1 で明確に 2 回以上代表取締役 (Jr 発言記録)tasks/handovers/jr_feedback_*.md に記録Jr 入社後の月次 1on1
優先度判断ミス月 1 件超代表取締役Actions 警告ログ + 月次 PR diff レビュー月次レビュー
GitHub Actions 障害頻度月 3 件超代表取締役Actions タブの failure 数週次 Slack 通知
6 分制限超過月 3 件超代表取締役GAS executionLog の TIMEOUT カウント月次レビュー

トリガー発生時: 案件数拡大/Markdown 不満/判断ミス は ADR-0022 起案、6 分制限超過は ADR-0023 起案 (スライス粒度判定基準) を別建てで起案。

5.2 バックアップ / リカバリ手順

将来の Linear / Notion 移行 (ADR-0022) 必要時の手順:

  1. 事前バックアップ: usecase_dev_mapping.md + todo_master_tables.md を Git tag pre-adr022-migration-YYYYMMDD で固定
  2. 移行スクリプト: scripts/export-to-linear.mjs (将来作成) で Markdown → Linear API 変換、dry-run モードで事前検証
  3. 整合性チェック: 移行後、Linear 内案件件数 = Markdown 行数 - ヘッダ
  4. ロールバック: 1 ヶ月以内に問題発生時は ① Linear プロジェクト read-only 化 ② Git tag から復元 ③ ADR-0022 を Rejected ④ changelog.md に rollback entry
  5. Linear ↔ GitHub 連携維持: 移行後も slice_id ↔ PR の双方向リンクを Linear API で維持

監査ログ機構 (99_audit_log) は移行対象外、GAS スプレッドシート内に永続保持。

5.3 期限

  • 6 ヶ月後再評価: 2026-11-15 (撤退条件全項目チェック + ADR-0022 起案要否判定)

6. 参照 (References)

  • 関連 ADR:
    • ADR-0010 (Modular Monolith Numbering / 数値プレフィックス命名規約) — 整合性最優先・不変
    • ADR-0018 (TODO 管理の Phase・優先度・レイヤー 3 軸グルーピング — GitHub Issues 移行を保留する判断) — 本 ADR で拡張 (役割分担明文化 + 3 列追加 + GitHub Actions 自動更新 / SUPERSEDE ではない)
    • ADR-0019 (Decision Pipeline LangGraph 移行) — 不変、本 ADR 起案時の Triage / Scoring / Consistency / Parallel Review 全 Gate を通過
    • ADR-0020 (ADR Triage 基準) — 不変、本 ADR は Standard〜Critical の境界判定を受けて Critical モードに分類
    • ADR-0022 (将来起案候補): Linear / Notion 移行判断
    • ADR-0023 (将来起案候補): スライス粒度判定基準 (6 分制限超過対策)
  • 関連 PR/Issue: （要追記）
  • 外部資料:
    • Jacobson 2016 ACM "Use-Case 2.0"
    • Cockburn "Walking Skeleton"
    • Bastow "Now/Next/Later Roadmap"
    • Lenny's Newsletter 取材 (Linear ~50 人規模運用)
    • Shape Up 公式 Appendix 2 "Adjust to Your Size" (Basecamp / Ryan Singer)
    • Agility-at-Scale (WSJF Denominator gaming / Single-stakeholder scoring 指摘)
    • docs/_internal/research_prompts/RQ-040_dev_organization_paradigm_synthesis.md (Gemini Deep Research + Claude Research 突合結果)

Confirmation (準拠確認 / Fitness Function)

本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。

  • 検証手段: RUNTIME_METRICS シート + Utils.measureRuntime 監視
  • 実行頻度: Nightly
  • 違反時の対応: Slack 通知