RQ-040 突合 (Synthesis): 業務単位スライシング vs 代替パラダイム — bizlp 採択方針

位置付け: Gemini Deep Research と Claude Research の RQ-040 両回答を 論点ごとに突き合わせ、bizlp 文脈での採択方針案を整理する。

本ファイルは「ADR-0021 候補の起案準備資料」。正式採択判断は Decision Pipeline 経由で ADR-0021「開発組織化パラダイムの採用」 として行う。本ファイル単独では決定権を持たない。

突合対象: RQ-040_*_result_gemini.md / RQ-040_*_result_claude.md

元プロンプト: RQ-040_*_prompt.md / RQ-040_*_meta_prompt.md

起票日: 2026-05-12

0. TL;DR

両エンジン完全一致の核心: Walking Skeleton + Now/Next/Later + UC スライス の組み合わせを採用、SAFe / Outcome-Driven Roadmap / 厳密 DDD は不採用、失敗パターン (二重メンテ地獄 / Outcome 逃避 / Feature Flag 負債化 / 6 分制限超過) は共通指摘。
3 つの相違点 (本ファイルで bizlp 文脈の採択方針を提示):
1. 進捗管理ツール: Gemini = Linear / Notion 移行推奨 / Claude = Markdown 維持で十分 → Claude 案 (Markdown 維持) を推奨
2. 二重ビュー (UC × 技術カテゴリ): Gemini = 1 軸統合 / Claude = 2 軸維持で役割分担 → Claude 案 (2 軸維持) を推奨
3. Wardley Mapping: Gemini = 四半期定期評価で採択 / Claude = 補助的扱い → Claude 案 (補助的扱い) を推奨
上記突合の結果、bizlp の暫定採用案は Claude 案ベース + Gemini の Q4 業界事例 / Q7 リリース戦略の具体パターンを補強として組み合わせる。
次工程: 本 synthesis を Decision Pipeline (POST /draft) に投入 → ADR-0021「開発組織化パラダイムの採用」 として起案 → 採点・整合性チェックを通過させて PR 化。

1. 完全一致部分 (採用根拠)

両エンジンが独立に到達した一致点は、bizlp 文脈における採択根拠の中で最も強い。

1.1 推奨採用パラダイム (両者一致)

要素	採用理由 (両者共通)
Walking Skeleton / Tracer Bullet	UI → Domain → Data → Infra を End-to-End で貫通する最薄スライスを最初に作る。Jr 入社 (2026-10) 前にアーキ骨格と CI/CD を固める用途と相性が良い
Now / Next / Later Roadmap	期日コミットなし、優先順位を 3 列で可視化。1 人法人の進捗報告オーバーヘッドを最小化
UC / User Story スライス	業務塊単位の End-to-End 価値提供。Apps Script Test Runner (`900_test`) との相性も良い

1.2 不採用パラダイム (両者一致)

要素	不採用理由 (両者共通)
SAFe / LeSS / DAD 完全採用	PI Planning / Inspect&Adapt 等の儀式が 1 人開発に過剰投資、説明責任の対象がいない
WSJF (Cost of Delay 完全採用)	1 人開発で複数評価者がいないため Denominator gaming / Single-stakeholder scoring に構造的に陥る
Outcome-Driven Roadmap (純粋採用)	「監査リスク低減」「コンプライアンス遵守」等の計測不能 outcome に逃げ、結局 output に戻る
厳密 DDD (Aggregate Root / VO の過剰定義)	GAS Modular Monolith でボイラープレートが肥大化、1 人開発で実装速度が低下

温度感: 両者ともに「要素引用は OK (例: WSJF の Cost of Delay 3 要素 / DDD の 400_domain 内ユビキタス言語) だが完全採用は避ける」という同じスタンス。

1.3 失敗パターン (両者一致 / 警戒対象)

失敗パターン	Gemini	Claude
大企業 FW の形骸化 (SAFe / Team Topologies 完全採用)	✓	✓
計測不能 Outcome 逃避	✓	✓
Markdown / バックログ二重メンテ	✓	✓
Feature Flag 負債化 (PropertiesService 容量超過 / コードパス爆発)	✓	✓
GAS 6 分制限を貫通するスライス粒度	✓ (場当たり DDL 変更として)	✓ (スライス粒度判定基準として)

温度感: bizlp は 5 つすべてを ADR-0021 の警戒項目 として明文化する。

1.4 共通の技術運用パターン

領域	両者一致の推奨
テスト戦略	Apps Script ネイティブ Cucumber は不在 / Gherkin 風コメント + QUnit ベースのテスト関数命名規約で擬似 BDD
Feature Flag	PropertiesService キーで実現、フラグの定期クリーンアップをルール化
リリース戦略	Trunk-Based Development + 短命ブランチ + Feature Flag 隠蔽 + 業務塊単位 PR
ロールバック	コード revert ではなくフラグを `disabled` に切替で瞬時無効化
Walking Skeleton の必須要素	監査ログ機構 + 認証 + DDL スキーマ管理を最初の骨格に含める (横断的関心の後手化を構造的に防ぐ)

2. 相違点 1: 進捗管理ツール (Linear / Notion 移行 vs Markdown 維持)

2.1 両エンジンの主張

観点	Gemini Deep Research	Claude Research
推奨	Linear or Notion へ移行	Markdown のまま拡張
根拠	・SSoT 化で UC ↔ 技術カテゴリのビューを切替可能・Markdown 二重メンテ崩壊を構造的に防ぐ・「Done になるまで隠す」運用は Hidden 状態として表現可	・Lenny's Newsletter "How Linear builds product": Linear 自身が「about 50 people, single product team」と公表 → 1+1 名規模では過剰投資・Markdown + Git + GitHub Actions スクリプトで「Done まで隠す」も自動化可能・既存 580+ 件の PR ワークフローを変えなくて済む
ドキュメント改修コスト	高 (276 件の MAS をエクスポート + インポート + スキーマ設計)	低 (3 列追加で完了)

2.2 bizlp 文脈での評価軸

軸	評価
既存メモリとの整合性	`MEMORY.md` 既存メモ「案件管理は TODO_future.md で継続 — GitHub Issues 移行はチーム拡大時まで保留」と一致するのは Claude 案 (Markdown 維持)
代表取締役の慣れ	VS Code + Markdown + Git で既に 1.5 年運用、580+ PR 実績。ツール切替自体の学習コスト + 既存ワークフロー再構築コストが Jr 入社 (2026-10) 5 ヶ月前に発生するリスク
Linear / Notion 月額コスト	Linear Standard $10/user/月、Notion Plus $10/user/月 (Jr 含めて $20/月 = 年 $240)。個人開発として高くはないが、Markdown で済むなら不要な固定費
データ移行作業	276 件 × MAS / UC / OP マッピング / カテゴリ / 優先度 / スコアの再入力は半日〜1 日のコスト。移行ミスのリスクも
Jr 受け入れ時の見直し可能性	Jr 入社後 1-2 ヶ月の Markdown 運用観察で本当に破綻するなら、その時点で Linear 移行を判断可能 (今決め打つ必要はない)

2.3 採択方針 (Synthesis 推奨)

Claude 案 (Markdown 維持) を推奨。理由:

既存メモリ (GitHub Issues 移行保留) と整合
ツール切替コスト > 二重メンテのコスト (まだ崩壊していない)
Jr 入社後の運用観察で再判断する余地を残す
Markdown でも 役割分担明文化 + slice_id 列追加 で「両者一致部分 = 二重メンテ廃止」は達成可能

条件: 6 ヶ月 (2026-11 まで) Markdown 運用を続け、以下のいずれかが起きたら Linear 移行を再検討:

(a) 二重メンテで月 1 件以上の優先度判断ミスが発生
(b) Jr が Markdown 運用に明確な不満を表明
(c) 案件数が 400 件超に拡大

2.4 Gemini 側の主張を捨てない部分

「ビュー切替 (UC 軸 / 技術カテゴリ軸の両方から同じデータを見られる)」のアイデアは強力。Markdown でも usecase_dev_mapping.md (UC ビュー) + todo_master_tables.md (技術ビュー) という疑似的なビュー切替は既に成立しており、Claude 案で 2 軸維持するため機能的には Gemini が懸念したダブルメンテ問題は Claude 案でも残る。これは相違点 2 の判断で対処する。

3. 相違点 2: 二重ビュー (1 軸統合 vs 2 軸維持で役割分担)

3.1 両エンジンの主張

観点	Gemini Deep Research	Claude Research
推奨	1 軸統合: UC = Epic、技術カテゴリ = コード規約のみ残す	2 軸維持: UC = リリース・テスト・追跡可能性の単位 / 技術カテゴリ = コード配置の単位
改修プラン	`todo_master_tables.md` のタスク列を削除、技術ガイドラインのみ残す	`todo_master_tables.md` を「Cross-Reference Index」と明示変更、各 MAS 行に `slice_id` 列追加 (N:M リンク表化)
矛盾回避策	単一データベース (Linear / Notion) でビューだけ分離	「計画 / 優先度 = UC 軸 / コード配置 = 技術軸」の役割分担を ADR-0021 で明文化

3.2 bizlp 文脈での評価軸

軸	評価
ADR-0010 (Modular Monolith Numbering) との整合	ADR-0010 で 000_infra → 900_test の数値プレフィックス命名規約は変更対象外。これにより技術カテゴリはコード配置の事実上の SSoT として既に存在。1 軸統合 (Gemini 案) は ADR-0010 と矛盾するため採用不可
代表取締役の問題提起の本意	「実装の優先度 / 進捗が見えにくくなった」=リリース単位での見える化が論点。技術カテゴリそのものが邪魔なのではなく、技術カテゴリしか優先度ビューがないのが問題
業務塊単位テストとの整合	Use-Case 2.0 (Jacobson 2016 ACM) の「テストケース必須要件」は UC スライス単位、技術カテゴリ単位ではない。UC を優先度軸にすれば監査要件 + テスト整合性の両方が直結
将来の Cross-Reference 機能性	「Jr が `400_domain/410_subledger_engine.js` を改修する → 影響を受ける UC スライスは何か？」を逆引きしたい場面は必ず発生する。2 軸維持の方が逆引き経路を保てる

3.3 採択方針 (Synthesis 推奨)

Claude 案 (2 軸維持で役割分担) を推奨。理由:

ADR-0010 (Modular Monolith Numbering) と矛盾しない
代表取締役の本意 (リリース単位の見える化) は UC 軸の役割強化で達成可能
2 軸の役割を ADR-0021 で明文化することで二重メンテ問題は構造的に解消
Cross-Reference の逆引き経路を残せる

具体実装 (Claude 提案を採用):

ファイル	役割 (ADR-0021 で明文化)
`usecase_dev_mapping.md`	UC 軸 SSoT = 優先度 / リリース計画 / Walking Skeleton 状態。3 列追加 (`slice_id` / `walking_skeleton_status` / `now_next_later`)
`todo_master_tables.md`	技術軸 Cross-Reference Index = コード配置・命名規約とのリンク表。`slice_id` 列を追加して MAS から UC へ逆引き可能に、ステータス管理は UC 軸に委譲
`prd.md` 冒頭	「縦軸 = UC スライス (リリース単位) / 横軸 = 技術カテゴリ (コード配置単位)」を 1 段落で明文化

3.4 Gemini 側の主張を捨てない部分

「ダブルメンテによる崩壊リスク」は本質的な懸念。Claude 案でも、PR マージ時に両方更新する運用が崩壊し得る。
対策として ADR-0021 で「ステータス管理は UC 軸のみ。技術軸への反映は GitHub Actions で slice_id 列を自動更新」のルールを明文化する。
これにより todo_master_tables.md は能動メンテ不要 (PR マージ時に自動更新) になり、Gemini の懸念は構造的に解消される。

4. 相違点 3: Wardley Mapping の位置付け

4.1 両エンジンの主張

観点	Gemini Deep Research	Claude Research
推奨	採択 (四半期定期評価)	補助的扱い (必要時のみ)
用途	自社コア (法人税ロジック / 独自 UI) vs 外部化 (LLM Gateway / Cloudflare) の戦略判断	swardley 自身の警告「mash these frameworks into one all-encompassing ubermensch framework」を引用、補助
改修コスト	中 (定期的に Mermaid.js 等で図表更新)	中 (必要時のみ作成)

4.2 bizlp 文脈での評価軸

軸	評価
戦略判断の頻度	bizlp は GAS → GCP 移行、Cloudflare Workers 採用、LiteLLM Gateway 採用などの大型判断は年 1〜3 回程度。四半期評価は頻度過剰
既存 product_overview.md との重複	既に「鳥瞰ビュー (12 セクション)」がある。Wardley の進化軸 (custom-built → product → commodity) は鳥瞰ビューに追加した方が良い視点だが、別ファイル化は過剰
個人開発の評価コスト	マップ作成・更新自体に時間を取られる。「マップ作成が目的化する」失敗パターンを Gemini 自身も指摘
意思決定との連結	bizlp の大型戦略判断は ADR-0019 (LangGraph 移行) / ADR-0020 (Triage 基準) のように ADR で起案する文化が既に確立。Wardley は ADR 起案時の補助分析ツールとして使えれば十分

4.3 採択方針 (Synthesis 推奨)

Claude 案 (補助的扱い) を推奨。理由:

戦略判断の頻度が四半期評価に見合わない
既存 product_overview.md の鳥瞰ビューと役割が重複
マップ作成自体が目的化する失敗パターンを Gemini 自身が警告
ADR 起案時の補助分析ツールとして位置付ければ、必要時のみのコストで運用可能

具体運用:

ADR-0021 では Wardley を必須採用要素として明記しない
大型戦略判断 (例: 将来の GAS → GCP 移行、新 LLM プロバイダ採用) の ADR 起案時に、起案者が任意でADR 本文中に Wardley Map を埋め込む運用を許可
product_overview.md の鳥瞰ビューに「進化軸 (custom-built / product / commodity) のラベル付け」を今回任意で追記できればプラス、必須ではない

4.4 Gemini 側の主張を捨てない部分

「車輪の再発明を防ぐ」「自社コア vs 外部化の判断軸」の問題意識は重要。
bizlp の現状でも、adr-kit / LangGraph / LiteLLM Gateway / Cloudflare Workers などを採用する際に**「自作 vs SaaS」の判断**は実施している (ADR-0019 で実例)。
既に ADR 文化として自然に組み込まれているため、Wardley を別個に強制する必要性は低い。

5. ADR-0021 起案の骨格 (本 synthesis を基にした提案)

本セクションは ADR-0021 を起案する際の骨格メモ。Decision Pipeline (POST /draft) に投入する起案ドラフトの素材として使う。

5.1 タイトル

「開発組織化パラダイムの採用 — UC スライス × Walking Skeleton × Now/Next/Later の 3 層ハイブリッド」

5.2 Status

Proposed (起案後、Decision Pipeline 通過で確定)

5.3 Context

案件 276 件 / 1 名開発 + Jr 1 名予定 (2026-10) / 監査要件 / GAS 制約という 4 制約下で、優先度 / 進捗の見える化が課題化
RQ-040 で Gemini Deep Research + Claude Research を並列実行、本 synthesis で突合
代表取締役の当初仮説 (業務 UC 単位の縦割りスライス) は両エンジンとも採択推奨

5.4 Decision

採用パラダイム: UC スライス (Use-Case 2.0 / Jacobson 2016 ACM) × Walking Skeleton × Now/Next/Later の 3 層ハイブリッド
二重ビュー維持: usecase_dev_mapping.md (UC 軸 SSoT / 優先度・リリース計画) + todo_master_tables.md (技術軸 Cross-Reference Index) で役割分担、ステータス管理は UC 軸のみ
進捗管理ツール: Markdown 維持 (6 ヶ月再評価条項付き、再評価トリガーは §2.3 参照)
Wardley Mapping: 補助的扱い (必須採用要素として明記しない、ADR 起案時の任意分析ツール)
失敗パターン警戒項目: §1.3 の 5 つを ADR-0021 で明文化、四半期レビューでチェック
共通技術運用パターン: §1.4 の擬似 BDD / PropertiesService Feature Flag / Trunk-Based を採用

5.5 Consequences

Positive: 業務塊単位の見える化 + 監査要件直結のテスト構造 + ツール切替コスト不要 + Jr 受け入れ前にスケルトン完成
Negative: Markdown 二重メンテリスクは残存 (自動化スクリプトで対処) / Wardley の戦略視点は失う可能性 (ADR 起案時に任意採用) / 1 軸統合のシンプルさは諦める
Reversibility: 6 ヶ月後再評価条項あり (案件数 400 件超 / Jr 不満 / 月 1 件以上の判断ミスが発生時)

5.6 撤退条件

上記再評価条項 3 つのうち 1 つでも発生したら、Linear / Notion 移行を ADR-0022 として起案
Walking Skeleton 構築で 6 分制限超過が頻発 → スライス粒度判定基準を再設計 (ADR-0023 候補)

5.7 Alternatives Considered

案	採用しなかった理由
1 軸統合 (Linear 移行 + 技術カテゴリ廃止 / Gemini 推奨)	ADR-0010 と矛盾、ツール切替コスト過大、既存メモリ「GitHub Issues 移行保留」と不整合
Outcome-Driven Roadmap	監査要件下では計測不能 outcome に逃避するリスク (両エンジン一致指摘)
WSJF / SAFe	1 人開発で複数評価者がいない、見積もりコスト自体が遅延要因 (両エンジン一致指摘)
厳密 DDD	GAS Modular Monolith でボイラープレート肥大化、`400_domain` 配下で要素引用に留める
Shape Up (6 週サイクル + Betting Table)	Shape Up 公式 Appendix 2 が「tiny team can throw out most of the structure」と明記 (Claude 単独指摘)
Wardley Mapping 四半期評価 (Gemini 推奨)	戦略判断の頻度が見合わない、ADR 起案時の任意採用に格下げ

6. 次のアクション

本 synthesis を Decision Pipeline (POST /draft) に投入 → Triage / Socratic / Scoring / Consistency / Parallel Review を通過させて ADR-0021 PR を自動生成
ADR-0021 がマージされたら、§5.4 Decision 2 (二重ビュー維持) に基づいて以下の docs 改修 PR を起案:
- usecase_dev_mapping.md に slice_id / walking_skeleton_status / now_next_later 3 列追加
- todo_master_tables.md を「Cross-Reference Index」と明示変更、slice_id 列追加
- prd.md 冒頭に「整理軸方針」セクション追加
- product_overview.md を「UC スライス Now/Next/Later ビュー」に書き換え
Walking Skeleton 対象 UC の選定 (UC-2 資金調達準備 / UC-4 ランウェイ対応のいずれか) と End-to-End スライス 1 本の実装 → 900_test/901_test_runner.js でテスト合格まで通す
6 ヶ月後 (2026-11) に §2.3 再評価条項に基づき Markdown 運用継続可否を判定

7. Caveats

本 synthesis は 2 エンジンの回答に対する代表取締役 + Claude (sub workspace) の解釈。Gemini 自身の判断ではない。
採択方針 3 件 (相違点 1〜3) はすべて Claude 案寄りだが、これは bizlp の既存制約 (ADR-0010 / 既存メモリ / 1 人開発のツール慣れ) との整合性によるもの。Gemini 案が誤りではなく、適用文脈が異なる。
ADR-0021 起案後、Decision Pipeline の Gate 2 (Consistency) で過去 ADR との矛盾チェックが入る。ADR-0010 (命名規約) との整合は事前確認済 (§3.2)。
6 ヶ月後再評価で「やっぱり Linear 移行が必要」という判断になった場合、本 synthesis の判断を Reverse する ADR-0022 を起案する想定。Reversibility は確保されている。

8. 関連ドキュメント

突合元: RQ-040_*_result_gemini.md / RQ-040_*_result_claude.md
元プロンプト: RQ-040_*_prompt.md / RQ-040_*_meta_prompt.md
関連 ADR (既存): ADR-0010 (Modular Monolith Numbering) / ADR-0019 (Decision Pipeline)
既存ドキュメント (改修対象): docs/use_cases.md / docs/_internal/usecase_dev_mapping.md / docs/_internal/todo_master_tables.md / docs/prd.md / docs/product_overview.md
関連 Memory: MEMORY.md > project_todo_management.md (GitHub Issues 移行保留)