RQ-040 業務単位スライシング vs 代替パラダイム調査 (Deep Research プロンプト / Gemini + Claude 並列)

Gemini Deep Research と Claude Research に並行投入するための本体プロンプト。 メタ意図・制約条件は RQ-040_dev_organization_paradigm_meta_prompt.md を参照。

使い方:

• 「## 0. 調査エンジンへの依頼」以降を engine にコピペで投入
• 出力は RQ-040_*_result_gemini.md / RQ-040_*_result_claude.md として保存
• 完了後 RQ-040_*_synthesis.md で突合

0. 調査エンジンへの依頼

あなたは 業界横断のソフトウェア開発組織化パラダイムに精通したシニアプロダクトエンジニア / アーキテクトです。

以下の制約条件下で運営される個人開発プロジェクトに対し、「実装案件をどの軸で整理し、どの順で進めるべきか」の判断材料を網羅的に収集してください。採用判断そのものは依頼者が行います。あなたの仕事は 論点の漏れなき提示 と 失敗パターンを等しい温度で扱う ことです。

1. プロジェクトの前提

1.1 開発体制と制約

1.2 現状の案件規模

• 未着手 MAS 案件: 125 件 / 仕様書完了 46 件 / 完了 28 件 (= 計 199 件)
• TODO_future.md に I-* (取込) / S-* (スプレッドシート操作) / F-* (FP&A) / N-* (運用基盤) / DS-* (データセキュリティ) を含めた 約 276 件
• 過去マージ済 PR は 580+ 件 (個人開発 1.5 年間)

1.3 現状の整理軸 (二重ビュー)

案件整理の現状:

  technical category    business pattern
  (todo_master_tables.md)    (usecase_dev_mapping.md)
  ────────────────────────  ────────────────────────
  - 経費・仕訳              UC-1: 新規事業投資の意思決定
  - シミュレーション        UC-2: 資金調達準備
  - UX / UI                 UC-3: 組織施策
  - 会計指針                UC-4: ランウェイ対応
  - 電帳法・消費税          UC-5: 採用判断
  - 経理実務                OP-A1〜A10  (受発注・入金消込)
  - 監査・統制              OP-M1〜M9   (月次決算)
  - データ連携              OP-W1〜W8   (週次集計)
  - …                       OP-D1〜D8   (日次)
                            OP-X1〜X9   (例外対応)

• 技術カテゴリは MAS マスタの カテゴリ 列で表現
• 業務パターンは派生 SSoT usecase_dev_mapping.md (44 業務 × MAS マトリクス、完了率信号機 🔴/🟡/✅)
• 2 軸を行き来する経路は MAS-XXX 番号のみ (両ファイルが MAS 番号を共通キーにする)

1.4 ユーザー (代表取締役) の仮説

「業務ユースケース単位で機能を実装し、業務の塊ごとにテストする」 ことで:

1. 開発の塊が明確になる
2. ユーザー価値を 1 つずつ積み上げられる
3. 改善点が見えやすくなる

まず ビジネス要件・業務要件を洗い出して、現状の追加案件 (MAS / I / S / F / N / DS) を紐づけて 着手する。

これを 採用すべきか、採用する場合の最小コスト移行プラン、採用しない場合の代替パラダイム を調査してほしい。

2. 調査してほしい問い (Q1〜Q7)

Q1. ユーザーの仮説 (Use Case / Business Process Slicing) の評価

• 適用される学術的根拠: Cockburn の Use Case 階層 / Cohn の User Story Mapping (Patton) / Hexagonal Architecture の Adapter 切り出しが個人開発規模で機能するための前提条件
• 成功事例: 1〜5 人規模の SaaS で UC スライスを徹底し成功した実例 (匿名でなく公開事例 = Basecamp / Plausible / Fathom / Tailscale 初期 etc.)
• 失敗事例: UC スライス徹底で破綻した例。特に 横断的関心 (認証 / 監査ログ / DDL / マイグレーション) が後手に回るケース
• bizlp への適合度評価: 監査要件 (改ざん不可・追跡可能性) との相性。GAS の単一スプレッドシート前提との相性

Q2. 代替パラダイム比較 (各々独立に評価)

以下の各パラダイムについて、1 人法人 + 監査要件 + 200+ 案件規模 での適用可否を評価してください:

各パラダイムについて以下の構造で:

• 採用判断軸: いつ採用すべきか / いつ採用すべきでないか
• bizlp 文脈での適合度 (1-5)
• 必要な既存ドキュメント改修コスト (低 / 中 / 高)
• 失敗パターン: そのパラダイムを採用しても破綻するケース

Q3. ハイブリッド戦略 (複数パラダイム併用)

• 「縦軸 = 業務ユースケース」「横軸 = 技術レイヤ」 の 2 軸併用は実務でどう運用されているか
• どのパラダイム同士の組み合わせが矛盾せず、どの組み合わせがダブルメンテで崩壊するか
• bizlp の現状 (技術カテゴリ × 業務パターンの二重ビュー) をどちらか 1 軸に統合するべきか / 2 軸維持するべきか

Q4. 業界事例 (公開資料ベース、推測排除)

以下の SaaS の 公開ロードマップ / 機能リリースノート / 技術ブログ から組織化方法を抽出してください:

• 国内会計 SaaS: freee / マネーフォワード / 弥生
• 国内 FP&A: Loglass / Manageboard
• 海外 FP&A: Vena / Pigment / Cube / Anaplan / Mosaic / Causal / Runway
• 個人開発 SaaS (1〜5 名で成功した実例): Plausible / Fathom / Carrd / Tailscale 初期 / Linear 初期 / Notion 初期
• コンプライアンス重い SaaS: Stripe Atlas / Pilot.com / Bench Accounting

各社について:

• 公開ロードマップの整理軸 (UC ベース / Capability ベース / 機能カテゴリベース / 顧客セグメントベース)
• リリース粒度 (機能単位 / ユースケース単位 / リリース塊 / Canary)
• 公開している意思決定基準 (OKR 公開 / Cost of Delay 公開 / 顧客投票 etc.)

Q5. 進捗可視化ツールの実装パターン

業務単位 / UC 単位でロードマップを管理するツール:

• Linear / GitHub Projects / Notion / Airtable / Productboard / ProductPlan の業務スライス可視化機能
• 「業務塊が ✅ Done になるまで隠す」(顧客向けロードマップで未完成 UC を非公開にする) 運用パターン
• bizlp の現状 usecase_dev_mapping.md (Markdown 表) をそのまま拡張するべきか / ツール移行すべきか

Q6. 業務塊単位テストの実装パターン

• BDD (Cucumber / Gherkin) で業務シナリオ単位のテストスイートを構築する事例
• 業務塊 = 1 つの E2E テスト群 / 1 つの統合テスト集合、として粒度を保つベストプラクティス
• 監査要件下 (会計仕訳・改ざん不可) で業務シナリオテストとユニットテストをどう棲み分けるか
• GAS + Apps Script Test Runner (900_test/901_test_runner.js) で業務塊単位テストを構成する具体パターン

Q7. リリース戦略 (CI/CD への落とし込み)

• 業務塊単位 (1 つの UC が完成) でリリースする CI/CD パターン
• Feature Flag / Trunk-Based Development / Vertical Slice / Canary の小規模開発適用可否
• GAS + clasp 環境での業務塊単位デプロイの実現可能性 (現状は dev / prod の 2 環境のみ)
• リリース時のロールバック容易性 vs 業務塊スライスのトレードオフ

3. アウトプット要件

3.1 必須セクション (両エンジン共通)

1. TL;DR (5 行以内) — 推奨パラダイム + 採用判断軸
2. パラダイム比較表 (Q2 の 11 項目 × 5 評価軸 = 55 セル)
3. 採択推奨パラダイム + 採用しなかった代替の Top 3 (各々等しい温度で理由付け)
4. 既存ドキュメントの改修プラン — usecase_dev_mapping.md / todo_master_tables.md / prd.md / product_overview.md を具体的にどう書き換えるか
5. 6 ヶ月ロードマップ (Now / Next / Later) — 現状 (技術カテゴリ × 業務パターンの二重ビュー) からの段階移行プラン
6. 失敗パターン Top 5 — 採用しても破綻するケース (1 人開発特有 / 監査要件特有 / GAS 制約特有)
7. ツール・運用パターン (Q5 / Q6 / Q7 の結論)
8. 業界事例の根拠リンク集 (公開資料 URL を明示、推測排除)

3.2 各エンジン固有の強み

3.3 「失敗・撤退事例」を等しく重視する指示

• 「採用すべき」事例と「採用しても破綻した」事例を同じ重さで扱う
• 「1 人開発で大企業フレームワーク (SAFe / LeSS / DAD) を採用 → 進捗報告に時間を取られて実装が止まる」型の過剰投資パターンを必ず 1 つ以上挙げる
• 「Outcome-Driven 徹底 → 計測不能な outcome (例: 監査リスク低減) に逃げる」型の運用不能パターンを必ず 1 つ以上挙げる

3.4 1 人法人 + 監査要件 + GAS 制約への適合度

各推奨について、以下 3 軸で 1-5 評価:

• 個人開発適合度: 進捗報告・ステータス更新に時間を取られないか
• 監査要件適合度: 改ざん不可・追跡可能性・科目マスタ整合性を維持できるか
• GAS 制約適合度: 6 分実行制限・列番号ハードコード禁止・Modular Monolith 命名規約を破らないか

4. 調査対象から除外する範囲

• ADR-0010 (Modular Monolith Numbering) の見直し: 数値プレフィックス命名規約は不変、本調査の上のレイヤ
• Decision Pipeline 自体の改修: ADR-0019 / 0020 で完結
• Jr 採用戦略: RQ-033 で別途調査済、所与とする
• 特定 MAS 案件の優先度: 個別案件の Go/No-Go ではなく整理軸そのものを調査
• 大企業向けフレームワーク (SAFe / LeSS / DAD) の完全採用: 1 人開発に明らかな過剰、ただし要素技術としての引用は歓迎

5. 参考: 既存内部資料 (調査の前提として読んでほしい)

bizlp プロジェクトドキュメント (公開):

• docs/use_cases.md — UC-1〜5 + OP × 44 業務パターン
• docs/_internal/usecase_dev_mapping.md — UC × MAS マッピング (派生 SSoT、完了率信号機 🔴/🟡/✅)
• docs/_internal/todo_master_tables.md — MAS マスタ (276 件、技術カテゴリ別)
• docs/prd.md — プロダクト要件
• docs/brd_solo_ceo_financial_navigator.md — Solo CEO 特化 BRD
• docs/product_overview.md — 鳥瞰ビュー
• docs/adr/0010-modular-monolith-numbering.md — 数値プレフィックス命名規約
• docs/adr/0019-drp-migration.md — 起案フロー自動化

6. 提出形式

• Markdown
• 各セクション見出しは ## / ### を使用
• 引用は脚注または [link](url) 形式
• 「採用すべき」「採用すべきでない」の両面を必ず明示
• 断言を避けるべき箇所: 「bizlp に最適」「必ず機能する」等は使わず、「以下の条件下で機能する**」と条件付きで記述

7. 採点ルール (依頼者が結果を評価する基準)

8. 完了条件

調査エンジンが以下を満たした時点で完了:

• TL;DR + パラダイム比較表 (Q2) + 採択推奨 + 代替 Top 3 + 失敗パターン Top 5 が揃っている
• 業界事例 (Q4) の公開資料 URL が最低 10 件含まれる
• 既存ドキュメント改修プラン (3.1-4) が具体的なファイルパス + 改修内容で記述されている
• 1 人法人 + 監査要件 + GAS 制約への適合度 (3.4) が各推奨ごとに評価されている
• 失敗パターン Top 5 のうち最低 2 つは 1 人開発特有 / 監査要件特有のものを含む

(本プロンプトは Gemini Deep Research と Claude Research の両方に投入し、結果を RQ-040_*_synthesis.md で突合する想定です。両エンジンの強みの違いは §3.2 参照。)