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

本ファイルの位置付け: Gemini Deep Research が回答した本文を改変なしで保存。整理・解釈は突合フェーズ (_synthesis.md) で行う。

業界横断のソフトウェア開発組織化パラダイムと実装戦略：法人会計SaaSにおける案件整理と進行の最適解

TL;DR

採用を推奨するパラダイムは、「User Story Mapping (Walking Skeleton)」と「Now / Next / Later Roadmap」のハイブリッド戦略である。この組み合わせは、機能検証を最速化する垂直スライスと、監査要件を満たす水平基盤（認証・監査ログ）の早期構築を両立させる条件下で機能する。一方で、SAFe等の重厚なフレームワークや成果主義（Outcome-Driven）は、1人法人のリソース制約およびコンプライアンス要件と極めて相性が悪く破綻を招くため採用すべきではない。進捗管理においては、現状の二重Markdown運用を直ちに廃止し、Linear等の単一データベースへ移行して一元管理を図るべきである。

1. ユーザー仮説の評価 (ユースケースおよびビジネスプロセス・スライシング)

ユーザーが提示した「業務ユースケース単位で機能を実装し、業務の塊ごとにテストする」という仮説は、アジャイルソフトウェア開発において「垂直スライシング (Vertical Slicing)」と呼ばれるアプローチに該当する。個人開発かつ監査要件を伴う会計システムにおいて、この仮説は極めて有効な側面を持つと同時に、適用方法を誤ると致命的なアーキテクチャの破綻を招く二面性を有している。

学術的根拠に基づく評価とメカニズム

ソフトウェアの要求分析において、Alistair Cockburnが提唱したユースケースの階層モデルは、要件の粒度を「Cloud (戦略的目標)」「Kite (要約)」「Sea (ユーザー目標)」「Fish (サブ機能)」「Clam (技術的詳細)」の5段階に分類する。ユーザーの仮説は、この中の「Sea Level（業務ユースケース）」を軸に開発を進めるアプローチである。Cockburnの理論によれば、システム全体の価値をユーザー視点で定義・検証する上で、Sea Levelの粒度が最も適切であるとされている。

この理論をさらに発展させたのが、Jeff Pattonによる「User Story Mapping」である。Pattonは、Sea Levelのユースケースを時系列のユーザージャーニー（バックボーン）として並べ、各機能（Fish/Clam Level）を優先度順にマッピングする手法を体系化した。Pattonの枠組みにおいて特に重要なのは、システムがエンドツーエンドで動作する最薄の実装「Walking Skeleton（歩く骨格）」を最初に構築するという概念である。これは、アーキテクチャの全レイヤを貫通する最小限の機能群を初期に実装することで、技術的リスクを早期に排除し、継続的な統合の基盤を築く手法である。

個人開発における成功要因と適合度

アーキテクチャ（Modular Monolith）および技術スタック（Google Apps Script V8 + Cloudflare Workers）という条件下において、本仮説は特定の前提を満たすことで強力に機能する。

1名体制での開発において、フロントエンドからデータベース（Google Sheets）までの全レイヤを横断して実装する垂直スライシングは、レイヤ間の統合コストを最小化し、フィードバックループを高速化する効果をもたらす。小規模チームで成功を収めたSaaS企業の多くが、この垂直スライシングに近いアプローチを採用している。例えば、Plausible AnalyticsやTailscaleといった企業は、特定のユーザー目標を達成するユースケースの完遂をリリース単位として定義し、価値の反復的な提供を実現している。

個人開発においては、技術レイヤごと（水平スライス）の開発よりも、ユースケースごとの開発の方が「何が完成したか」が明確になり、モチベーションの維持とプロジェクトの推進力を生み出しやすい。

監査要件およびGAS制約下での失敗パターン

しかしながら、ユースケーススライスを過度に徹底しすぎることで、特定のドメインにおいて致命的な破綻が生じる。法人会計システムにおいて必須となる「改ざん不可・追跡可能性」を担保する監査ログや、データセキュリティ要件、認証・認可の仕組みといった「横断的関心事（Cross-cutting Concerns）」は、ユースケースごとに個別に実装すべきではない。これらの基盤機能の構築を後回しにし、ユースケースの実現のみを優先した場合、後から全機能に対して一貫した監査ログ処理を組み込むことは極めて困難となり、結果としてコンプライアンス要件を満たせなくなる。

さらに、Google Apps Script（GAS）をバックエンドとし、Google Sheetsをデータベースとして利用する本プロジェクト固有の制約も考慮する必要がある。ユースケースごとに個別のスプレッドシートのDDL（スキーマ定義）を場当たり的に変更・追加する運用は、GASにおけるシートの肥大化や列インデックスの不整合を引き起こす。結果として、getDataRange().getValues()などのデータ取得ロジックがサイレントに崩壊し、データの一貫性が失われる危険性がある。

以上の分析から、ユーザーの仮説は基本方針として採用すべきである。しかし、それは「第1スプリント（Walking Skeletonの構築）において、全ユースケースを貫く強固な監査ログ・認証・スキーマ管理基盤（水平スライス）を先行して構築する」という厳密な条件付きでのみ成立する。基盤が確立された後に初めて、ユースケース単位の垂直スライシングによる反復的な開発が安全に実行可能となる。

2. 開発・組織化パラダイムの網羅的比較と評価

1名体制の法人、厳密な監査要件、そして約276件に及ぶバックログという複合的な制約下において、11の主要な開発・組織化パラダイムの適用可否を評価する。以下の表は、各パラダイムのプロジェクト文脈における適合度（1: 不適合 ～ 5: 極めて適合）と、それらを採用した場合の運用方針を示している。

パラダイム別の詳細な適合性評価と失敗パターン

A および J. User Story Mapping (Cockburn / Patton)

業務フローを時系列（バックボーン）に並べ、各ステップの機能要件を優先度順に配置するこの手法は、1人開発において「次に実装すべき価値のある機能」を明確にし、モチベーションの維持に大きく寄与する。GAS制約下においても、シート間の連携を業務単位でテストしやすいという利点がある。しかし、この手法を採用しても破綻するケースとして「例外処理（Exception Flows）の軽視」が挙げられる。業務の正常系フロー（Happy Path）のみをマッピングし、エラー処理を後回しにする運用を行うと、会計システムにおいては不正な仕訳データが生成され、監査要件の追跡可能性を担保できなくなる。

B. Domain-Driven Design (Bounded Context)

ドメイン駆動設計における境界づけられたコンテキストの概念は、現状のModular Monolithアーキテクチャ（400_domainレイヤ等）と非常に相性が良い。法人会計ロジックと監査ログ記録のコンテキストを明確に分離することで、システムの複雑さを制御できる。一方で、1人開発において厳密なDDD（Aggregate Root、Repository、Value Objectの過剰な定義など）を全面採用すると、データ変換のためのマッパー層やインターフェースの記述が肥大化し（Boilerplate Codeの増加）、開発速度が著しく低下して実装が停止するオーバーエンジニアリングの罠に陥る。

D. Value Stream Mapping および G. WSJF (Weighted Shortest Job First)

SAFeなどで用いられるCost of Delay（遅延コスト）をJob Size（作業規模）で割るWSJFは、リソースが競合する大企業において複数チーム間でポートフォリオの優先順位を定量的に決定するためには不可欠な数学的アプローチである。しかし、このパラダイムを1人開発に適用すると破綻する。1人チームにおいてはボトルネックは常に「開発者自身」であり、バリューストリームにおける待ち時間は存在しない。また、各タスクの遅延コストを算定するための調査・見積もり作業そのものに時間を浪費し、実際のコーディング作業が滞る。さらに、監査リスクの低減といった定量化が極めて困難な要件を無理に数値化しようとすることで、不正確で歪んだ意思決定を下すリスクがある。

H. Outcome-Driven Roadmap (Marty Cagan)

「機能（Output）」をリリースすることではなく、それによって得られる「成果（Outcome）」を目標とするこの手法は、プロダクトディスカバリーやB2C製品のエンゲージメント向上には極めて強力である。しかし、厳密なコンプライアンス要件が存在する環境下では機能しない。「電帳法対応」や「消費税計算の正確性」といった法令で定められた必須要件（Must-have）は、ユーザー行動の変容といった計測可能なOutcomeに変換することが不自然である。成果主義を過度に徹底した結果、計測不能なOutcome（例：監査リスクの低減）を指標として設定してしまい、ロードマップの評価軸が形骸化し、本当に必要な基盤改修が後回しにされるという運用不能パターンに陥る。

K. Wardley Mapping

ユーザーニーズから技術基盤までを「可視性」と「進化（コモディティ化）」の軸でマッピングする手法である。外部API（Cloudflare Workers等）への依存関係を整理し、自社開発領域を特定する上で有効に機能する。しかし、マップの作成や更新自体が目的化してしまい、実際のコードベースへの反映（リファクタリングや外部サービスの切り替え）が行われない場合、単なる時間の浪費となり破綻する。

3. 採択推奨パラダイムと代替アプローチ Top 3

前セクションの評価に基づき、現在のプロジェクト制約下で最も確実に機能するパラダイムの組み合わせと、採用を見送るべき代替アプローチを提示する。これらの選定は、いずれも等しい温度感で分析された結果に基づいている。

採択推奨パラダイム（ハイブリッド適用）

プロジェクトの推進において、以下の3つのパラダイムを統合して採用することを推奨する。

1. User Story Mapping (Walking Skeleton型) 要件を時系列のユーザージャーニーとして整理し、インフラからUIまでの最小実装（歩く骨格）を最初に貫通させる手法である。法人会計SaaSにおいて最も重要な監査ログ機構と認証基盤を「必ず含めるべき最初の骨格」として定義することで、後工程での監査要件の欠落を構造的に防ぐことができる。

2. Now / Next / Later Roadmap ガントチャートや厳密なタイムラインを廃止し、タスクを「今取り組む（Now）」「次に取り組む（Next）」「将来取り組む（Later）」の3段階で管理する。1人法人特有のリソース変動や不確実性に柔軟に対応でき、タスクの優先度決定にかかるオーバーヘッドを最小限に抑えつつ、進行の可視性を維持できる。

3. Wardley Mapping (戦略レベルの定期評価) 四半期に一度の頻度で、自社開発すべきコアドメイン（会計指針の実装や独自UI）と、外部化すべきコンポーネント（LLM Gatewayなどのインフラ）を可視化する。個人開発において陥りがちな「すべての技術を自作してしまう」車輪の再発明を防ぎ、限られたリソースをユーザー価値に直結する領域へ集中させる指針となる。

採用しなかった代替トップ3

以下のパラダイムは業界標準として広く認知されているが、本プロジェクトの特異な制約（1人体制・監査要件）と衝突するため、明確に採用を回避すべきである。

1. Outcome-Driven Roadmap (Marty Cagan) この手法は、顧客の行動変容を成果として測定できるプロダクトにおいては優れている。しかし、法令によって定められた要件（電帳法対応、消費税計算ロジック）の実装を「ユーザーのエンゲージメント向上」といったOutcomeとして無理に表現することは論理的ではない。機能要件が既に確定している監査基盤の実装において、この手法を徹底することは運用上の不整合を生む。

2. WSJF (Weighted Shortest Job First) とSAFe要素 大規模組織におけるリソース配分の最適化には不可欠な手法であるが、1人開発においてはタスクの遅延コスト（CoD）の算定に費やす時間自体が開発の遅延要因となる。また、監査要件の遵守といったビジネスリスクの回避を無理に経済的価値に換算する試みは、精度の低い仮定に基づいた誤った優先順位付けを引き起こす。

3. 厳密な Domain-Driven Design (Strict DDD) 大規模な開発組織でドメインの境界を維持するためには有効であるが、GASのModular Monolith上でこれを過剰に適用すると、インフラ層とドメイン層の間でのデータ変換ロジックやインターフェース定義が肥大化する。1人開発においてこのボイラープレートコードの記述に時間を奪われることは、機能提供の速度を致命的に低下させる原因となる。

4. ハイブリッド戦略の運用と既存ドキュメント改修プラン

「縦軸 = 業務ユースケース（UC）」「横軸 = 技術レイヤ（000〜900）」の2軸を併用するアプローチは、ソフトウェアの構造とビジネス価値を紐づける上で強力な概念である。しかし、実務における運用方法を誤ると、管理コストの増大によりプロジェクトが停滞する。

2軸併用の運用実態と矛盾の回避

アジャイル開発の実務において、ビジネス要件（UC）とアーキテクチャ（Tech）の2軸はマトリクス組織のように管理される。この2軸を矛盾なく運用するためのベストプラクティスは、「計画とトラッキングはUC（縦軸）で行い、コードの構成とテストの責任範囲はTech（横軸）で担う」という役割の明確な分離である。

現在のように、todo_master_tables.md（技術軸のタスクリスト）とusecase_dev_mapping.md（業務軸のステータス表）の二重管理を続けることは、ダブルメンテナンスによる崩壊を招く。実装が完了するたびに両方のファイルを整合性を保って更新する運用は、1人開発において確実に行き詰まる。

この問題の解決策は、データを単一のデータベース（SSoT: Single Source of Truth）に統合し、ビュー（見せ方）のみを分けるアプローチを採用することである。NotionやLinearなどのツールを利用し、「アイテム（行）＝ 実装案件」とし、「技術カテゴリ」と「ユースケース」をプロパティ（列・タグ）として付与することで、どちらの軸からも一元的な情報を参照・更新できるようになる。

既存ドキュメント改修プラン（具体案）

上記の戦略に基づき、既存のMarkdownファイル群を以下の通りリファクタリングすることを強く推奨する。

docs/_internal/usecase_dev_mapping.md の改修 (非推奨化)

表形式でのステータス（🔴/🟡/✅）の手動管理を即座に廃止する。ファイルの冒頭に以下の宣言を追記し、以後の進捗管理を専用データベースへと移行させる。

⚠️ DEPRECATED: 本ファイルでのステータス管理は廃止されました。 ユースケースと案件のマッピングおよび進捗状況は <ツール名> の「UC Matrix View」を参照してください。 本ファイルは過去の要件定義のアーカイブとしてのみ保持します。

docs/_internal/todo_master_tables.md の改修 (データソース化と役割変更)

現在リストアップされている276件のタスク群をCSVまたはJSONとしてエクスポートし、進捗管理ツールにインポートする。インポート完了後、タスクの羅列をすべて削除し、各技術カテゴリにおける実装ガイドラインや命名規則のみを残す形へリファクタリングする。

# Technical Categories & Conventions
(個別のタスクは削除し、例えば「経費・仕訳ドメインにおける共通関数設計方針」といった技術ガイドラインのみを記述)

docs/prd.md の改修

静的な機能リストを廃止し、Now / Next / Laterのフォーマットに書き換えて動的な計画を示す文書へと変更する。改修例:

## ロードマップ (Now / Next / Later)
- **Now (進行中)**: UC-1 (新規事業投資) + 基盤となる監査ログ機構のE2E実装
- **Next (次期)**: UC-2 (資金調達準備) + OP-M (月次決算フロー)
- **Later (未定)**: UC-5 (採用判断) + 複雑なシミュレーション機能群

docs/product_overview.md の改修

単なる機能の羅列ではなく、Wardley Mapの概念を取り入れたビジネスケイパビリティの鳥瞰図を追加する。自社のコア領域（法人税ロジック、独自UI）と、外部依存領域（Cloudflare Workers、LLM Gateway）を区分けした図表（Mermaid.js等）を配置し、システムの全体像と戦略的な力点を視覚的に表現する。

5. 業界事例からのロードマップ組織化手法の抽出

公開情報に基づき、国内外の主要なSaaS企業がどのようにロードマップを整理し、機能をリリースしているかを示す。これらの事例は、組織化パラダイムの選定における重要な実証データとなる。

上記の事例分析から、少人数で高品質なプロダクトを提供する企業（Linear、Tailscale、Fathomなど）は、複雑な数値化による優先順位付け（WSJFなど）を避け、直感的な価値（Quality）や強固な基盤（Security）に重きを置いていることが分かる。また、法務やセキュリティといったコンプライアンス要件が厳しい領域（Stripe Atlas、Tailscale）においては、機能の柔軟性よりも「安全で確実なデフォルト」を提供することがプロダクトのコア価値として認識されている。

6. ツール・テスト・リリースの運用パターン

プロジェクトの制約（1名体制、監査要件、GAS + clasp環境）に最適化された運用手法を詳述する。

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

ツールの選定と移行: 進捗管理ツールとしては、LinearまたはNotionの利用を強く推奨する。Linearは「意見を持ったデフォルト」により、設定のオーバーヘッドを極限まで削減でき、開発者の思考を妨げずに進行状況をトラッキングできる。一方、Notionは「Now/Next/Later」のボードビューとデータベースの柔軟な連携機能に優れており、文書管理とタスク管理を統合できる利点がある。いずれのツールを選択するにせよ、現状のMarkdownによる二重管理から移行し、ユースケース（UC-1等）を「Epic」または「プロジェクト」として定義して一元管理することが必須である。

非公開・塊リリースの運用: 顧客向けのロードマップや機能リストにおいて、未完成のユースケースは完全に非公開（Hidden）にし、関連するタスクの塊がすべて「Done」になった瞬間に可視化する運用が、期待値管理上最も安全である。未完成の機能を早期に見せることは、バグの報告や不要な問い合わせを誘発し、1人開発の貴重なサポートリソースを浪費する。

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

BDDと監査要件の棲み分け: BDD（Behavior-Driven Development）の実践において、CucumberやGherkinの「Given/When/Then」構文は業務シナリオの可視化に非常に優れている。しかし、1人開発かつGAS環境において、Gherkinのパーサー環境をゼロから構築・保守することは明らかな過剰投資である。

GASでの擬似BDD実装パターン: GAS + clasp 環境下では、QUnitのラッパーライブラリや独自テストランナー（900_test/901_test_runner.js）を使用し、テスト関数内のコメントとしてGherkin構文を記述する擬似BDDアプローチを採用する。これにより、可読性の高いテスト仕様と実装の簡素化を両立できる。

// 擬似BDDのテスト実装例
function test_UC1_InvestmentDecision() {
  // Given: 初期資金が100万円ある状態
  const account = createTestAccount(1000000);

  // When: 50万円の設備投資を記帳する
  recordTransaction(account, 500000, 'Equipment');

  // Then: 残高が50万円になり、監査ログがハッシュ付きで記録されていること
  assert.equal(account.getBalance(), 500000);
  assert.isTrue(verifyAuditLogIntegrity(account.getLastTransactionId()));
}

監査要件下のE2Eテスト: 監査要件を満たすためのテストは、単一の関数をモックして検証する単体テスト（Unit Test）では不十分である。「入力（UI層）→ 業務ロジック（Domain層）→ 仕訳記帳（Data層）→ 監査ログ生成（Infra層）」を貫通する垂直スライスのE2E/統合テストとして実装しなければならない。テスト実行結果として生成されるハッシュ値やタイムスタンプが、改ざん不能な状態でスプレッドシートに追記されることをアサーションで確実に検証する必要がある。

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

Trunk-Based Developmentの必須性: GASのプロジェクトは単一のクラウドプロジェクトとして存在し、clasp pushを実行するとファイル全体が上書きされるという制約がある。このため、巨大なフィーチャーブランチを長期間維持することは、深刻なマージコンフリクトの温床となる。したがって、メインブランチへの細かいコミットを継続的に行うTrunk-Based Developmentの採用が必須である。

Feature Flagの実装: 完成していない業務塊（ユースケース）のコードを本番環境（prod）に安全にデプロイしつつ、ユーザーからは隠蔽するためには、PropertiesService.getScriptProperties()を利用したFeature Flag（フィーチャートグル）パターンを実装する。

// Feature Flagを利用した機能の隠蔽例
function processMonthlyClosing() {
  const props = PropertiesService.getScriptProperties();
  const isMonthlyClosingEnabled = props.getProperty('ENABLE_MONTHLY_CLOSING') === 'true';

  if (!isMonthlyClosingEnabled) {
    throw new Error("This feature is currently under development.");
  }
  // 以降、月次決算のコアロジック
}

ロールバック戦略のトレードオフ: リリース後に障害が発生した場合、ソースコードを修正して再度clasp pushを実行する（やり直す）アプローチは時間を要し、システム停止の時間を長引かせる。会計SaaSとしての可用性要件を満たす現実的な解は、PropertiesServiceの該当フラグをfalseに切り替えることで瞬時に機能を無効化する運用である。ただし、この運用はフラグの増加による設定漏れのリスク（Feature Flagの負債化）を伴うため、機能が安定稼働した後は速やかにフラグ分岐のコードを削除する継続的なリファクタリングが不可欠である。

7. 失敗パターン Top 5 (1人開発・監査要件・GAS制約特有)

これまでの分析を通じて特定された、採用すべきでない（あるいは運用を誤ると破綻する）致命的な失敗パターンを5つ列挙する。これらは、成功事例と同等の重みを持ってプロジェクトの意思決定に反映されるべきである。

1. 大企業向けフレームワーク（SAFe等）の形骸化（1人開発特有）

   • 事象: WSJF（Weighted Shortest Job First）やPI Planningといった重厚なプロセスを導入し、タスクのビジネスバリュー、時間的切迫度、リスク低減の点数付けに数時間を費やす。
   • 結果: 進捗管理やスコアリングのためのドキュメント作成に膨大な時間を奪われ、実際のコードを記述する作業が完全に停止する。ステークホルダーが自分しかいない1人チームにおいて、他者への説明責任を果たすための定量的な見積もり作業は無価値なオーバーヘッドである。

2. 計測不能なOutcome目標によるロードマップの崩壊（監査要件特有）

   • 事象: Outcome-Driven Roadmap（成果主導の計画）の哲学を徹底し、すべての機能開発において「測定可能な成果（コンバージョン率の向上など）」をKPIとして設定しようとする。
   • 結果: 「電帳法要件の遵守」や「正確な消費税計算」といったコンプライアンス要件は、A/Bテストで検証可能なユーザー行動の変容を生み出さない。結果として、計測しやすい表面的なUIの改善ばかりが優先され、コアとなる監査基盤（000〜200レイヤ）の実装が永遠に後回しにされ、会計システムとして致命的な欠陥を抱えることになる。

3. ユースケース毎の場当たり的なDDL変更（GAS制約特有）

   • 事象: 各ユースケース（Vertical Slice）を完全に独立した機能として実装しようとするあまり、要件が発生するたびにGoogle Sheetsの列（カラム）やシートを無計画に追加・削除・変更する。
   • 結果: GAS上でシートのスキーマ（DDL）が一貫性を失い、他のユースケースや過去のデータとの整合性が取れなくなる。列インデックスのズレにより、データの取得・更新ロジックがエラーを出さずにサイレントに崩壊し、改ざん不可という監査要件に抵触する深刻な事態を招く。

4. Feature Flagの負債化と容量超過（GAS制約特有）

   • 事象: リリース時のリスク軽減のためにすべての新機能をFeature Flagで管理し、PropertiesServiceに大量のフラグを永続的に保存し続ける。
   • 結果: 古いフラグを削除する運用（クリーンアップ）を怠った結果、PropertiesServiceのサイズ制限や読み込みのオーバーヘッドが増大し、スクリプトの実行パフォーマンスが劣化する。また、フラグの組み合わせ爆発により、テストされていないコードパスが本番環境で実行され、予期せぬ障害を引き起こす。

5. スプレッドシートとMarkdownの二重メンテナンス地獄（1人開発特有）

   • 事象: 案件の優先度や状況を、複数軸のMarkdownファイル（業務軸のusecase_dev_mapping.mdと技術軸のtodo_master_tables.md）や静的なスプレッドシートで手動管理する。
   • 結果: Pull Requestをマージするたびに、ソースコードだけでなく複数の管理用ドキュメントを同期して更新する必要が生じ、認知負荷が限界を超える。管理ファイル自体が徐々に陳腐化し、最終的にどのタスクが未了なのか誰（自分自身）にも正確に分からなくなる状態に陥る。

8. 6ヶ月ロードマップ (Now / Next / Later) と段階移行プラン

二重ビュー（技術カテゴリ×業務パターン）の現状から、単一データベース上の「Now / Next / Later」モデルへ段階的に移行するための6ヶ月のロードマップを提示する。

フェーズ 1: Now (月 1-2) - 運用基盤の刷新とWalking Skeletonの確立

• 運用基盤の移行: todo_master_tables.md と usecase_dev_mapping.md に散在するタスク情報をLinearまたはNotionにエクスポートし、単一バックログ（SSoT）を構築する。既存のMarkdownファイルには直ちに「DEPRECATED」の警告を明記し、二重管理を即日停止する。
• 実装 (Walking Skeleton): ビジネスロジックの実装に先立ち、監査要件を満たす最小限のインフラレイヤ（000_infra）とデータレイヤ（200_data）を構築する。UIから入力されたテストデータが、改ざん不能なログとして一貫性を保ってGoogle Sheetsに保存されるまでの垂直スライスを最初に行通す。
• テスト環境の整備: 上記の垂直スライスに対する自動E2Eテスト環境を900_testに構築する。この際、完全なBDDフレームワークの導入は避け、擬似的なGherkinコメントを用いた軽量なテストランナーを運用する。

フェーズ 2: Next (月 3-4) - ユースケース単位の実装とTrunk-Basedの運用

• Epicベースの計画: 新規バックログツール上で、UC-1（新規事業投資）やOP-M（月次決算）を「Epic」として設定し、関連する技術タスクを紐付けて管理する。
• 段階的実装と隠蔽: 構築済みのWalking Skeletonの上に、ビジネスロジックを載せていく。未完成の機能はFeature Flag（PropertiesService）で隠蔽し、長期間ブランチを分岐させることなく、Trunk-Basedでメインブランチに頻繁にマージ（clasp push:dev）する。
• 価値の提供（塊デプロイ）: 該当ユースケースを構成するすべてのタスクが完了し、E2Eテストをパスした時点でFeature Flagをオンにし、一括でユーザーに価値を提供する。

フェーズ 3: Later (月 5-6以降) - 機能拡張とスケールアップ

• 新メンバーの受け入れ準備: 2026年10月のJrエンジニア参画に向けたタスクの切り出しを行う。SSoT化されたバックログと、確立されたFeature Flag + Trunk-BasedなCI/CDパイプラインが存在することで、新メンバーが本番環境を破壊するリスクを最小化しつつ、安全にオンボーディングを進めることが可能となる。
• 戦略的見直し: UC-2（資金調達準備）や複雑なFP&A機能（シミュレーション等）の開発に着手する。この段階で、定期的にWardley Mapを用いた戦略的見直しを実施し、不要になった技術負債やコモディティ化した領域を特定し、外部サービス（SaaS等）への置き換えを検討する。

本報告書で提示したパラダイムと運用戦略の採択により、個人開発におけるリソースの限界と、法人会計システムに求められる厳密な監査要件という二律背反を克服し、持続可能かつ高速なプロダクト開発が実現できるものと確信する。