最終更新: 2026/06/22 18:56
commonid: rq-040-dev-organization-paradigm-resul…type: research-resultstatus: archived

RQ-040 結果 (Claude Research): bizlp 実装案件の整理軸 — ADR-0021 起案のための調査レポート

エンジン: Anthropic Claude Research 実行日: 2026-05-12 対応プロンプト: RQ-040_dev_organization_paradigm_prompt.md 対応メタプロンプト: RQ-040_dev_organization_paradigm_meta_prompt.md ペア結果 (Gemini Deep Research): RQ-040_dev_organization_paradigm_result_gemini.md 突合 (次工程): RQ-040_dev_organization_paradigm_synthesis.md (未作成)

本ファイルの位置付け: Claude Research が回答した本文を改変なしで保存。整理・解釈は突合フェーズ (_synthesis.md) で行う。 Claude には事前に「B (bizlp 文脈重視) + Q1〜Q3 比較表は埋める / Q4 業界事例は Gemini 担当のため薄めで OK」の重み付け指示を渡している (本体プロンプト §3.2 の役割分担)。

bizlp 実装案件の整理軸: ADR-0021 起案のための調査レポート

TL;DR

  • 推奨採用パラダイム: 「Use Case Slice (Use-Case 2.0) × Walking Skeleton × Now/Next/Later」の3層ハイブリッド。縦軸=業務UC(usecase_dev_mapping.md)、横軸=技術カテゴリ(todo_master_tables.md)の現行二重ビューは 1軸統合せず維持 し、UC側を「リリース単位の第一軸」、技術カテゴリを「コードレイアウト・命名規約のままの第二軸」として役割分担する。
  • 判断基準: bizlp は (a) 1人開発+Jr1名 (b) 監査要件あり (c) GAS 単一スプレッドシート前提 という3制約が同時に成立する稀な環境。Use Case Slice (Jacobson) は「監査要件下で End-to-End の塊単位にテスト・リリース・追跡可能性を担保できる」点で適合、Walking Skeleton (Cockburn) は「Jr 入社前に骨格を固める」のに有効、Now/Next/Later (Bastow) は「進捗報告に時間を取られない」点で1人法人と相性が良い。
  • 採用しないもの: SAFe/LeSS/DAD の完全採用、純粋な Outcome-Driven Roadmap (OKR連動)、純粋な JTBD/ODI は、それぞれ 1 人開発・監査要件・GAS 制約のいずれかで破綻する。要素引用にとどめる。

1. パラダイム比較表 (Q2)

評価軸: ① 採用判断軸 / ② bizlp 文脈での適合度 (1-5) / ③ 既存ドキュメント改修コスト (低/中/高) / ④ 失敗パターン / ⑤ 個人開発適合度 (1-5)

#パラダイム① 採用判断軸② 適合度③ 改修コスト④ 失敗パターン⑤ 個人開発適合度
AUse Case / User Story Mapping (Cockburn / Cohn / Patton)UC スライスが End-to-End で価値を出せるか、テストケースに直結するか5中 (usecase_dev_mapping.md を「バックボーン+優先順位」付き拡張)「すべての UC をフラットに並べる」→ バックボーン消失で優先度が分からなくなる4
BDDD / Bounded Context (Evans / Vernon)ユビキタス言語と境界が安定しているか3高 (400_domain を BC ベースに再編が必要)1人開発で BC を分け過ぎて Anti-Corruption Layer が肥大化2
CBusiness Capability Map (Wardley / TOGAF)「能力」階層の固定化が長期的に価値を生むか2高 (新ファイル必要)TOGAF G189 の網羅性が過剰、bizlp の46 業務パターンと粒度がズレる1
DValue Stream Mapping / Team Topologies (Reinertsen / Skelton-Pais)複数チーム間のフローが対象か1高「Stream-aligned/Platform/Enabling/Complicated-subsystem の4類型」は1-2人規模では純粋な過剰投資 (第三者解説 umbrex.com は「very small teams (e.g., 10–15 people) may not need all four types」と整理)1
EWalking Skeleton / Tracer Bullet (Cockburn / Pragmatic Programmer)主要アーキ要素を End-to-End に通せているか5低 (補助原則として記述するのみ)「Skeleton を本番に届けず社内 PoC で終わらせる」→ 監査要件の検証が走らない5
FNow / Next / Later Roadmap (Janna Bastow / ProdPad)期日コミットを避けつつ優先順位を可視化したいか5低 (3 列の MD 表に直せる)「Later が肥大化してゴミ箱化」→ 276 件のうち Later の半数が Stale 化5
GWSJF (Reinertsen / SAFe)経済価値で順序付けたいか、Cost of Delay が定量化できるか2中1 人で複数評価者がいないため Agility-at-Scale 指摘の「Denominator gaming through feature slicing」「Single-stakeholder scoring」に構造的に陥る2
HOutcome-Driven Roadmap / OKR 連動 (Cagan "Empowered")アウトカム指標が観測可能か2高「監査リスク低減」のような計測不能 outcome に逃げ、結局 output に戻る2
IJTBD / ODI (Ulwick / Christensen)顧客の Job が安定しているか、Desired Outcome が定量できるか3高 (Strategyn 公式 "a single market typically contains 50 to 150 measurable desired outcomes" の棚卸は1人開発では破綻)「Job を抽象化しすぎて MAS 案件と紐付かない」2
JStory Mapping (Patton 2014)Backbone(横軸) × Walking Skeleton(縦軸) で MVP を切り出すか4中「Backbone を作ったきり更新せず形骸化」4
KWardley Map + Cynefin (Wardley / Snowden)コンポーネントの進化段階や問題の性質を可視化したいか3中swardley 自身が「mash these frameworks into one all-encompassing ubermensch framework」になることを警告 (medium 2022)3

2. 採択推奨 + 不採択 Top 3 (等温度評価)

採択推奨: Use Case Slice × Walking Skeleton × Now/Next/Later の3層ハイブリッド

条件付き根拠:

  • Use-Case 2.0 (Ivar Jacobson, Ian Spence, Brian Kerr, Communications of the ACM, Vol. 59, No. 5, May 2016, p. 69) は「a use-case slice is a collection of front-to-back flows through a use case, including the associated test cases that is of clear value to the customer」と定義しており、各スライスが 1つ以上のテストケースを必ず伴う。これは bizlp の監査要件 (追跡可能性) と Apps Script Test Runner (900_test) の構造に直結する。
  • Walking Skeleton (Cockburn, Crystal Clear, 2004) は「a tiny implementation of the system that performs a small end-to-end function ... It need not use the final architecture, but it should link together the main architectural components」と定義され、Jr 入社前 (2026-10) に骨格と CI/CD を固める用途で有効。Pragmatic Programmer の Tracer Bullet と等価。
  • Now/Next/Later は Janna Bastow が ProdPad ブログ "8 Steps to Convert Your Timeline Roadmap to a Now-Next-Later" (2024-02-29) で「I created the Now-Next-Later roadmap years ago to help teams cut through date theater and focus on outcomes」と明記する通り、期日コミットがない 点が 1 人法人と相性が良い。Linear・Plausible も類似 (3 列ベース) を採用。

不採択 Top 3 (等温度)

① Shape Up (Basecamp / Ryan Singer)

採用しない理由: 6 週間サイクル + Betting Table + Hill Chart は「dedicated shapers and builders」を前提とし、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 (時間予算) の概念のみ「実装ノートに記載する補助概念」として引用する。

② SAFe / LeSS / DAD の完全採用 (大企業フレームワーク)

採用しない理由: 進捗報告・PI Planning・Inspect&Adapt ワークショップ等の儀式が1人法人では純粋な過剰投資。WSJF は SAFe 公式 (framework.scaledagile.com/wsjf) が「relative cost of delay divided by relative job duration」と定義するが、Agility-at-Scale が指摘する複数アンチパターンに 1 人開発は構造的に陥る。ただし「Cost of Delay 3 要素 (Business Value / Time Criticality / Risk Reduction)」は ADR-0021 の優先順位付け補助スコアとして要素引用。

③ Outcome-Driven Roadmap (Cagan "Empowered" 型)

採用しない理由: Cagan の Empowered モデルは「empowered product team」前提で、1 人法人だと「PM ≡ Engineer ≡ CEO」の単独3役。Outcome (例: 「監査リスク低減」「ランウェイ可視化精度」) は計測スキームを別途構築せねばならず、計測コストが実装コストを上回る。Teresa Torres は producttalk.org "Product Roadmaps: How the Best Product Teams Plan for Uncertainty" (2026-04-08) で自身の運用について「that's an outcome that will guide my direction but doesn't constrain my path」とアウトカムを目印程度に扱う方が現実的と述べている。bizlp では「アウトカム = MAS 案件群が一つ Done する」という output 寄りの定義で代用する。

3. 適合度評価 (推奨案を 3 軸 1-5 で)

軸スコア根拠
個人開発適合度5Now/Next/Later は MD 表でメンテ可、専用ボード不要。UC スライス単位 PR は 580+ 件の既存 PR ワークフローを変えない
監査要件適合度4Use-Case 2.0 のテストケース必須要件が改ざん不可・追跡可能性に直結。ただし「UC スライス境界をどう仕訳マスタと整合させるか」は 400_domain 側の責務として ADR-0021 で別途明文化が必要
GAS 制約適合度4スライスを「6 分以内で End-to-End 完走できる単位」に切る運用ルールを定めれば、QUnitGS2 + PropertiesService チェックポイントで対応可能。ただし ADR-0010 の Modular Monolith 命名規約 (数値プレフィックス) は UC スライスの自由度を一部制約する側面あり

4. 既存ドキュメント改修プラン

ファイルパス現状改修内容
usecase_dev_mapping.md44 業務パターン × MAS 番号の Markdown 表3 列追加: ① slice_id (UC-1-S01 形式) ② walking_skeleton_status (Skeleton 通過済かどうか) ③ now_next_later (Now/Next/Later/Backlog/Hidden の 5 値)。表頭に「Backbone 行」(UC-1〜UC-5 の Activity レベル) を明示し、Patton 流の Backbone + Slice 構造に揃える
todo_master_tables.md技術カテゴリ別の MAS 案件 199 件削除しない。役割を「Cross-Reference Index」に明示変更。各 MAS 行に「対応する slice_id」列を追加し、UC ↔ 技術カテゴリの N:M リンク表 として機能させる
prd.mdプロダクト要件記述冒頭に「整理軸方針」セクションを追加: 「縦軸 = UC スライス (リリース・テスト・追跡可能性の単位)、横軸 = 技術カテゴリ (コード配置の単位)」を 1 段落で明文化。Use-Case 2.0 (Jacobson/Spence/Kerr, ACM 2016) を脚注で参照
product_overview.mdプロダクト概要「機能一覧」セクションを「UC スライス Now/Next/Later ビュー」に書き換え。UC-1〜UC-5 ごとに完了スライスをサブセクション化
900_test/901_test_runner.js (コード側)Apps Script Test Runnerテスト関数命名規約を test_{slice_id}_{condition} 形式に統一。Gherkin 風 Given/When/Then はコメント記述のみ (Apps Script V8 ネイティブの Cucumber ランナーは存在しないため。QUnitGS2 / GasTap いずれもフラットテスト API。Cucumber.js が必要な場合は gas-fakes 経由で外部実行)
新規 ADR-0021_slice_axis.md(新規)上記方針 + 「スライスの粒度判定基準: 6 分以内 End-to-End 完走 / 1 PR / 1 テスト群」を明文化

5. 6 ヶ月ロードマップ (Now / Next / Later)

Now (M1-M2, 2026-05〜2026-07): 整理軸の確立 + Walking Skeleton 検証

  1. ADR-0021 起案 (整理軸方針)・採用パラダイム決定
  2. usecase_dev_mapping.md の 3 列追加 (slice_id / walking_skeleton_status / now_next_later)
  3. todo_master_tables.md に slice_id 列を追加し、既存 199 MAS 案件を 44 業務パターンにマッピング (網羅性チェックではなく既存マージ済 PR 580 件の事後分類で OK)
  4. UC-2 (資金調達準備) または UC-4 (ランウェイ対応) のいずれかを Walking Skeleton 対象に選定し、End-to-End スライス 1 本を 900_test/901_test_runner.js でテストまで通す

Next (M3-M4, 2026-08〜2026-09): スライス単位リリースの定着 + Jr 受け入れ準備

  1. npm run push:dev → push:prod に「リリース対象 slice_id」を引数化 (Feature Flag は GAS では PropertiesService キーで実現可)
  2. Now/Next/Later 3 列の MD ビューを product_overview.md に確立、月次更新ルールを文書化
  3. Jr エンジニア (2026-10 入社) 向けに「最初の 1 スライスを最後まで通す」オンボーディング用 UC を選定し、Walking Skeleton + テスト雛形を整備

Later (M5-M6, 2026-10〜2026-11): スケール検証 + パラダイム見直し

  1. Jr 入社後、UC スライス単位の PR 運用が機能するかを 2 ヶ月観察。スライスが 6 分制限を頻繁に超える場合は「PropertiesService チェックポイント + time-based trigger」パターンで再分割 (inclucat 2021 / Medium Geek Culture / FolderPal 2026 で標準パターンとして広く紹介)
  2. M6 時点で ADR-0021 を見直し: ① Now/Next/Later が形骸化していないか ② UC スライスと技術カテゴリの二重ビューが矛盾していないか ③ 監査要件 (改ざん不可) を Use-Case 2.0 のテストケース必須要件で担保できているか
  3. JTBD/ODI の Desired Outcome 概念を、UC ごとに 3-5 個だけ抽出して usecase_dev_mapping.md に列追加するかを検討 (Ulwick の完全 ODI は採用しない)

6. 失敗パターン Top 5

  1. 【1人開発特有】Big Framework Trap (大企業フレームワーク過剰投資): SAFe / Team Topologies の完全採用 → PI Planning や Stream-aligned / Platform / Enabling / Complicated-subsystem の 4 類型運用に時間を取られ実装が止まる。第三者解説 (umbrex.com Team Topologies summary) も「Very small teams (e.g., 10–15 people) may not need all four types」と整理。回避: 要素引用にとどめ、儀式は採用しない。

  2. 【監査要件特有】Outcome 逃避 (Outcome-Driven の罠): 「監査リスク低減」「コンプライアンス強化」のような計測不能 outcome に Cagan 型ロードマップで逃げ、計測スキーム不在のまま output (機能数) で代用 → 結局 Feature Factory 化。回避: アウトカム = 「該当 UC スライスが Done + 監査テスト Green」を tautological に定義し、計測コストを実装コストに統合。

  3. 【GAS 制約特有】Slice が 6 分制限を貫通: UC スライスを大きく切り過ぎて 1 トリガー実行が 6 分超で Exceeded maximum execution time 例外。Google 公式 quotas ページ (developers.google.com/apps-script/guides/services/quotas) が「Script runtime — 6 min / execution」とハードリミットを明示。回避: ADR-0021 内で「スライス粒度判定基準 = 6 分以内 End-to-End 完走」を明文化、超える場合は PropertiesService + 時間ベーストリガーで checkpoint 分割 (everyMinutes 引数は 1/5/15/30 のみ可)。

  4. 【二重ビュー特有】Double Maintenance Death Spiral: UC 軸と技術カテゴリ軸を両方フル更新しようとして 276 件 × 2 ビューのメンテで実装時間を食い潰す。回避: 技術カテゴリは「コード配置の単位」のみに役割を限定し、優先順位・リリース計画は UC 軸 (Now/Next/Later) 片方のみ で管理。todo_master_tables.md は「Cross-Reference Index」と明記し、能動的にメンテしない (PR マージ時に slice_id を 1 列追記するだけ)。

  5. 【パラダイム形骸化】Now/Next/Later の Later がゴミ箱化: 276 件のうち F-* / N-* / DS-* が大量に Later に積まれ、3 ヶ月後に「Later の半分が古すぎて意味不明」状態に。Bastow も "Why I Invented the Now-Next-Later Roadmap" (ProdPad, 2022) で「Discovery means staying aware of customer needs and business opportunities ... Not churning out-of-date stuff from last year's to-do list」と Stale 化への警告。回避: ADR-0021 で「Later の月次レビュー」をルール化、6 ヶ月以上動かないアイテムは Archive ラベルで usecase_dev_mapping.md から archive/ ディレクトリへ移動。

7. ツール・運用パターン (Q5/Q6/Q7 の結論)

Q5. 進捗可視化ツール

  • 結論: 現状の Markdown 表 (usecase_dev_mapping.md) を そのまま拡張 することを推奨。Linear / Notion / Productboard 等への移行は不要。
  • 根拠: Lenny's Newsletter "How Linear builds product" によれば Linear 自身が「Today, we have about 50 people at Linear. We only have a single product team, which means that we can keep the planning process quite centralized, and there is only one roadmap for the whole product」と述べており、Linear のフル機能 (Initiatives / Roadmaps / Cycles) は50人前後の単一プロダクトチーム規模で運用されている。1+1名規模の bizlp では MD + Git の組み合わせの方が「Done になるまで隠す」運用も柔軟。
  • 「業務塊が ✅ Done になるまで隠す」運用は、usecase_dev_mapping.md の now_next_later 列で Hidden 状態を許可し、PR マージ時に自動で Now → Done に昇格させる GitHub Actions スクリプトで実装可能。

Q6. 業務塊単位テスト (BDD vs Unit)

  • 結論: Apps Script V8 上で動くネイティブ Gherkin/Cucumber ランナーは存在しない。QUnitGS2 (artofthesmart/QUnitGS2, アクティブメンテ, ライブラリID 1tXPhZmIyYiA_EMpTRJw0QpVGT5Pdb02PpOHCi9A9FFidblOc9CY_VLgG) を主軸に、「業務塊テスト = QUnit module()」「ユニット = QUnit test()」の階層で運用する。Feature/Scenario キーワードは関数命名規約 (test_UC1S01_*) でエンコード。GasT/GasTap (huan/gast) と GASUnit (gasunit/GASUnit) はそれぞれ 2017-2020 以降スポラディック / 2022-02 にアーカイブされており、新規採用は非推奨。
  • 監査要件下の棲み分け:
    • 業務シナリオテスト (UC スライス単位): 仕訳マスタ整合性、改ざん不可ログ、科目マスタ整合性を End-to-End で検証。freee 開発者ブログ "freeeの自動テストの全体構成" (2022-12, developers.freee.co.jp/entry/automated-test-structure-2022) では「会計帳簿の計算結果は重要であり、入力や設定によって膨大なバリエーションがあるため、自動でテストし計算結果を検証している ... 社内のドメインエキスパートメンバーである会計士や税理士が効率的にバリエーションを作って検証することが望ましいため、他の 3 種類のテストとは別に専用の自動テストの仕組みを作っている。具体的には、仕訳データ・事業所設定・正解の計算結果をスプレッドシートに記述し、そこからテストスクリプトを自動生成して合否を検証している。この自動テストはデプロイパイプライン内で自動実行される」と述べている。bizlp も同様の「Spreadsheet → テストスクリプト自動生成」パターンを 900_test 配下で採用可能。
    • ユニットテスト: 400_domain 内の純粋関数 (税額計算ロジック等) を QUnit test() で網羅。
  • GAS 制約: 1 テスト群が 6 分制限に近づく場合は、Spreadsheet 上の「テスト計画シート」を読んで該当 slice_id 単位でサブセットを実行する runScenario(sliceId) ランチャーを 901_test_runner.js に追加。Cucumber.js を本当に使いたい場合は Tanaike (2026) 解説の通り gas-fakes 経由で GitHub Actions 上で外部実行する経路を選択。

Q7. リリース戦略 (CI/CD)

  • 結論: UC スライス単位リリースは GAS 環境でも実現可能だが、Feature Flag = PropertiesService キー で代替する。Trunk-Based Development + 短命ブランチ (1-3日寿命) + Feature Flag の組み合わせ (trunkbaseddevelopment.com の標準パターン) を 1 人開発でも採用可能。
  • 具体パターン:
    • 1 UC スライス = 1 PR
    • npm run push:dev で dev 環境へ即時 push、push:prod の引数で --sliceId UC-1-S01 を渡し、当該 PropertiesService キーを enabled にすることで本番有効化
    • ロールバック = PropertiesService キーを disabled に戻す (clasp version での revert も 6 分制限内なら問題ない)
  • カナリア: GAS は単一スプレッドシート前提のため真のカナリア (% ベース) は不可。代替として「特定ユーザー (内部テストアカウント) でのみ flag を ON」のホワイトリスト方式。
  • トレードオフ: スライスを細かく切るほどロールバック容易性は上がるが、PR レビュー (Jr 入社後) のオーバーヘッドが増える。M5 (2026-10) 以降に「1 PR = 1 スライス」を継続するか「1 PR = 1 バックボーン分」に粒度を上げるかを再評価。

8. 業界事例の根拠リンク集

Caveats

  • 本レポートは bizlp の 3 制約 (1人開発+Jr1名 / 監査要件 / GAS 単一スプレッドシート) が同時成立する前提下での評価。前提が崩れた場合 (例: チーム 5 名超 / マイクロサービス化 / 監査要件解除) は採用判断が変わる。
  • Use-Case 2.0 のテストケース必須要件と監査要件の整合性は、ADR-0021 では「方針」レベルに留め、具体的な仕訳マスタ整合性検証ロジックは別 ADR (400_domain 配下) で詳細化が必要。
  • 「Apps Script V8 上のネイティブ Cucumber ランナー不在」は 2026 年 5 月時点。将来的に gas-fakes 等を経由した Cucumber.js 統合が標準化されれば再評価可。
  • 業界事例として網羅したかった「Money Forward / Xero / QuickBooks の BDD-under-SOX 公開事例」は今回の調査範囲では一次資料が見つからず、freee 1 社の事例で代用している。網羅性を高めたい場合は別途調査が必要。
  • 「Team Topologies が 10-15 人未満では不要」とした記述は、公式の Skelton/Pais 著作・公式サイトの一次情報ではなく、第三者解説 (umbrex.com) に基づく整理である点に留意。公式の主張ではなく「複数の第三者解説が共通して指摘するパターン」として扱うべき。