RQ-040 (meta): 200+ 案件規模の 1 人法人 × 監査要件下での開発組織化パラダイム調査

Gemini Deep Research + Claude Research に投げる 本体プロンプト (RQ-040_dev_organization_paradigm_prompt.md) の前提整理メタプロンプト。 調査の前にどの粒度・どの視点で問いを立てるかを揃えるための「研究の研究」。

1. 調査が必要になった経緯

bizlp-gas-accounting プロジェクトは GAS + Google Sheets で法人会計を自動化する個人開発。監査要件あり。直近の状態:

• 未着手 MAS 案件: 125 件 / 仕様書完了 46 件 / 完了 28 件 (= 計 199 件、追加で TODO_future へ起票中の F-* / I-* / S-* / N-* / DS-* を含めると合計 約 276 件)
• 既存の整理軸: 技術カテゴリ別 (経費・仕訳 / シミュレーション / UX / 会計指針 / 電帳法・消費税 / 経理実務 等) で todo_master_tables.md に集約
• 業務シナリオ別の見方として docs/use_cases.md (UC-1〜5 + OP-A/M/W/D/X = 44 業務パターン) と docs/_internal/usecase_dev_mapping.md (UC × MAS マッピング) を派生 SSoT として保有
• 仕様書作成パイプライン (Gemini 起案 → Claude 実装) + Decision Pipeline (LangGraph TS) で起案・採点・PR 化は自動化済 (ADR-0019 / ADR-0020)
• 一方で 「次に何を実装すべきか」「業務単位での Done をどう判定するか」「進捗をどう可視化するか」は人間 (代表取締役) が個別判断

ユーザー (代表取締役) の問題提起 (2026-05-12):

実装の優先度やなにがどこまで実装できているかわかりにくくなってきました。追加案件が増えてきたこともあり。 ここで私は ユースケースごとに機能を実装して、業務の塊ごとで実装してテストをする みたいなことで、開発の塊がわかりやすくするのと ユーザーへの価値を 1 つづつ積み上げていけるようにした方がいい のかなと思っています。 まずは ビジネス要件や業務要件を洗い出して、現状の追加案件を紐づけて紐づいた開発を進める アイディアがあります。ただ代替案もあると思うので調査したい。

仮説 = 業務ユースケース (UC / OP) 単位の縦割りスライス。これを採用すべきか / 採用しない場合の代替は何か、を学術・業界の両面から調査する。

2. 制約条件 (調査エンジンに必ず明示すること)

3. 期待する成果物の形

調査エンジンには以下を 明示的に要求 する:

1. TL;DR (5 行以内) — 推奨パラダイム + 採用すべき判断軸
2. パラダイム比較表 — Use Case Slicing / DDD Bounded Context / Capability Mapping / Value Stream / Walking Skeleton / Now-Next-Later / WSJF / JTBD / Outcome-Driven Roadmap / その他 を、「1 人法人 + 監査要件 + 200+ 案件」適合度で評価
3. 採択推奨パラダイム + 採択しなかった理由 (各パラダイムごとに等しい温度で比較)
4. 既存ドキュメントの改修プラン — usecase_dev_mapping.md / todo_master_tables.md / prd.md / product_overview.md をどう書き換えるか、SSoT 重複の解消方針
5. 6 ヶ月ロードマップ (Now / Next / Later) — 現在の整理軸からの段階移行
6. 失敗パターン Top 5 — 採用しても破綻するケース (1 人開発特有 / 監査要件特有)
7. ツール・運用パターン — 進捗可視化、業務単位テスト化、CI/CD への落とし込み
8. 業界事例 — freee / MoneyForward / 弥生 / Vena / Pigment / Notion / Linear 等の 公開ロードマップ・組織化方法 (匿名・推測ではなく公開資料ベース)

4. 「失敗・撤退事例」を等しく重視する理由

RQ-035 / RQ-039 の知見と同様、bizlp は 採用すべきパターン より 避けるべきアンチパターン を先に把握したい:

• 1 人開発で大企業フレームワーク (SAFe / DAD) を採用 → 進捗報告に時間を取られて実装が止まる
• UC スライス徹底 → 横断的関心 (認証・監査ログ・スキーマ DDL) が後手に回り技術負債爆発
• Outcome-Driven 徹底 → 計測不能な outcome (例: 「監査リスク低減」) に逃げて優先度が決まらない
• ロードマップに仕様書未着手案件を含める → 着手前見積もり誤差で全体計画が崩壊
• パラダイム切替自体に時間を取られ、本来の実装が遅延

→ 「今までの整理軸 (技術カテゴリ × 業務パターン) を捨てる代わりに何を得るのか / 何を失うのか」を必ず両面で評価させる。

5. 並行実行と突合の方針 (RQ-035 / RQ-039 と同じ運用)

6. 本メタプロンプトが対象外とすること

• 採用判断そのもの: 調査は判断材料の収集まで。最終採用は ADR-0021 起案ループに委ねる
• 既存 ADR-0010 (Modular Monolith Numbering) との衝突解消: 数値プレフィックス命名規約は不変、本調査はその上のレイヤ (案件整理軸)
• Jr 採用戦略: RQ-033 で別途調査済。本調査は採用前提を所与とする
• Decision Pipeline 自体の改修: ADR-0019/0020 で完結。本調査は ADR 起案フローではなくMAS 案件起票フローを対象

7. 参照 (調査エンジンに与えるリンク群)

bizlp 内部資料 (調査エンジンに「現状理解の前提」として読ませる):

• docs/use_cases.md — UC-1〜5 + OP × 44 業務パターンの SSoT
• 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 — 鳥瞰ビュー (12 セクション)
• docs/_internal/changelog.md — 直近変更ログ (構造化形式 + テーブル形式)
• docs/adr/0010-modular-monolith-numbering.md — 数値プレフィックス命名規約

外部の必読領域 (調査エンジンに探索を促す):

• Beck (2002) "Test-Driven Development"
• Cockburn "Hexagonal Architecture" / Writing Effective Use Cases (2000)
• Cohn (2004) "User Stories Applied" / (2009) "Succeeding with Agile" の Story Mapping
• Patton (2014) "User Story Mapping"
• Pichler "Strategize" (プロダクトロードマップ)
• Reinertsen (2009) "Principles of Product Development Flow" (WSJF 原典)
• SAFe / LeSS / DAD 各フレームワークの 1 人〜小規模開発への適用可否
• Marty Cagan "Inspired" / "Empowered" (Outcome-Driven Roadmap)
• Wardley Mapping (Capability Mapping の進化形)
• Team Topologies (Skelton & Pais, 2019) ※1 名チーム適用可否
• freee / MoneyForward / 弥生の公開技術ブログ・ロードマップ公表事例
• Linear / Notion / Vena / Pigment / Causal の機能ロードマップ公開ページ
• ULID 採番・JTBD (Job-to-be-Done) / Outcome-Driven Innovation (Ulwick) の財務 SaaS への適用事例

8. 本プロンプトのバージョン管理

• v0.1 (2026-05-12): 初版起案
• 以降の改訂は _meta_prompt.md 自身に変更履歴表を追加