feat: 工程管理ドキュメント作成・README に活用ガイドライン追加

- docs/engineering_management.md (工程管理フレームワーク) - docs/short_term_plan.md (2 週間単位のタスクリスト) - docs/long_term_plan.md (3〜12 ヶ月ロードマップ) - README.md (ドキュメント活用方法の明記)
2026-03-07 16:56:31 +09:00 · 2026-03-07 16:56:31 +09:00 · ff0fa2f745
commit ff0fa2f745
parent 991548f2e4
4 changed files with 544 additions and 233 deletions
--- a/README.md
+++ b/README.md
@ -10,7 +10,17 @@
 | ドキュメント | 内容 | パス | 活用シーン | 更新頻度 |
 | --- | --- | --- | --- | --- |
 | [要件定義書](./docs/requirements.md) | 機能要件・非機能要件・アーキテクチャ定義 | 新機能開発時の要件確認<br>チームメンバーへの仕様共有<br>承認プロセスでの根拠資料 | 変更時 |
-| [プロジェクト計画書](./docs/project_plan.md) | 短期長期計画・マイルストーン・リスク管理 | スプリントプランニング<br>レビューサイクルの計画<br>ステークホルダー報告 | 各フェーズ完了時 |
+| [工程管理ガイド](./docs/engineering_management.md) | **工程管理フレームワーク**（活用方法明記） | 📝 スプリント管理・ステークホルダー報告<br>リスク管理・承認フロー定義<br>新規参入者へのオンボーディング資料 | 各スプリント完了時<br>⬅️ **優先的に参照** |
+| [短期計画（Sprint）](./docs/short_term_plan.md) | **2 週間単位のタスクリスト**（CheckList） | 📋 次の週の仕事割り当て<br>実捗確認・チェックオフ管理<br>スプリントレビュー資料準備 | 各スプリント開始時 |
+| [長期計画（Roadmap）](./docs/long_term_plan.md) | **3〜12 ヶ月目標**・マイルストーンロードマップ | 🎯 ベータ→正式版リリース道筋<br>チーム成長・人材獲得計画<br>機能拡張優先順位決定資料 | マイルストーン完了時 |
+| [プロジェクト計画書](./docs/project_plan.md) | 統合計画書（承認用） | ステークホルダーレビュー<br>M1-M3 マイルストーン記録<br>リリース条件確認 | 各ステークホルダーレビュー時 |
+
+**📚 ドキュメント活用法**:
+- **新規参入者**: README → requirements.md → short_term_plan.md の順に読み進めて「何を」「なぜ」やるか理解
+- **スプリント開始**: short_term_plan.md の未着手タスクリストを確認→アサイン・実装開始
+- **ステークホルダー報告**: project_plan.md + long_term_plan.md で達成状況を説明資料として作成
+- **リスク管理**: 発生事項は engineering_management.md に記録→チーム会議で対応策共有
+- **バージョンアップ**: MAJOR バージョン時 → requirements.md の移行ガイド確認

 ---

@ -62,7 +72,7 @@
 **最終更新**: 2026/03/07  
 **バージョン**: 1.0 (Initial Release)

-（中略 - 実装完了マスタ管理画面から開始）
+---

 ## 実装完了マスタ管理画面

@ -71,234 +81,4 @@ Material Design テンプレートを使用した CRUD 機能を実装した以
 | 画面名 | ファイル名 | 主要機能 |
 |--------|-------------|----------|
 | 商品マスタ | `lib/screens/master/product_master_screen.dart` | 商品コード、名称、単価、在庫数の CRUD |
-| 得意先マスタ | `lib/screens/master/customer_master_screen.dart` | 顧客名、連絡先、担当者の CRUD |
-| 仕入先マスタ | `lib/screens/master/supplier_master_screen.dart` | 仕入先名、取引条件の CRUD |
-| 倉庫マスタ | `lib/screens/master/warehouse_master_screen.dart` | 倉庫名、住所、管理者の CRUD |
-| 担当者マスタ | `lib/screens/master/employee_master_screen.dart` | 担当者名、职务、連絡先の CRUD |
-
-各画面は共通テンプレートを使用しており、Material Design のボタンプレスデザインを採用しています。
-
---
-
-## データベース・モデル層
-
-### DatabaseHelper
-
-`lib/services/database_helper.dart` に SQLite アクセスコードを集中実装し、すべてのデータ操作はこのヘルパー経由で行う設計です。
-
-**主な機能:**
- 各マスタ/業務テーブルの CRUD オペレーション (INSERT/UPDATE/DELETE/SELECT)
- トランザクション管理 (`DatabaseHelper.transaction`)
- JSON 型のスナップショット保存 (非正規化設計)
- Soft delete 対応 (isDeleted フィールドによるフィルタリング)
-
-### モデル定義
-
-`lib/models/customer.dart` のように、各エンティティのモデルクラスを `toMap()/fromMap()` 形式で管理しています。これにより JSON 変換処理が一元化され、可読性が向上します。
-
---
-
-## メインメニュー構成（必須機能のベースライン）
-
-実運用で必須になるメニューをツリー形式で整理し、ダッシュボード設定やモジュール化の土台とします。
-
- ✅: 実装済み（画面・ナビゲーションあり）
- ⚠️: 画面は未実装だがプレースホルダ／メニュー定義済み
- ⏳: 未着手
-
-### 01. マスタ管理
- [x] 商品マスタ ✅
- [x] 得意先マスタ ✅
- [x] 仕入先マスタ ✅
- [x] 倉庫マスタ ✅
- [x] 担当者マスタ ✅
-
-上記を D2（ダッシュボード設定）画面のデフォルトメニューや並べ替え対象として順次実装していきます。
-
-### 02. 販売管理
- [ ] 見積入力
- [ ] 受注入力
- [ ] 売上入力（レジモードの主戦場）
- [ ] 売上返品入力
- [ ] 請求書発行
-
-### 03. 仕入管理
- [ ] 発注入力
- [ ] 仕入入力（未入荷管理を含む）
- [ ] 仕入返品入力
- [ ] 支払予定管理
-
-### 04. 在庫管理
- [ ] 在庫照会
- [ ] 在庫移動（倉庫間）
- [ ] 棚卸入力
- [ ] 在庫調整
-
-### 05. 集計分析
- [ ] 売上日報
- [ ] 得意先別売上推移
- [ ] 商品別粗利分析
- [ ] 在庫評価額一覧
-
-### 06. システム設定
- [ ] ユーザー権限設定
- [ ] ログ管理
-
-上記を D2（ダッシュボード設定）画面のデフォルトメニューや並べ替え対象として順次実装していきます。
-
---
-
-## Base System - Universal Sales Assistant
-
-クラウド連携やバックエンド処理で共通化したい基盤機能のリファレンスです。Google エコシステム連携や台帳層を切り出しておくことで、オフライン POS と母艦クラウドのハイブリッド連携を容易にします。
-
- **00. System Setup & Security**
-  - Google OAuth 認証管理
-  - 環境設定管理（`.env` はデフォルトでブラックリスト化）
-  - API 接続制限・クォータ管理
-  - ログ出力・エラー通知設定
- **01. Google Ecosystem Integration**
-  - Calendar Sync Engine（イベント取得 / 解析 / 更新）
-  - Drive File Manager（バックアップディレクトリ・テンプレ PDF 管理）
-  - Sheets Data Provider（スプレッドシートを DB として接続、ストリーミング書き込み）
- **02. Data Ledger (Transaction Core)**
-  - 取引データの登録・照会・修正・削除（履歴保持）
- **03. Calculation Engine (Common Rules)**
-  - 日時フォーマット統一
-  - 通貨・数値型キャスト処理
-  - 共通利益計算（売上 − 原価）
- **04. Output & Notification**
-  - PDF 帳票生成エンジン（テンプレ変数差し込み）
-  - Mailer（Gmail API、BCC 自動送付制御含む）
-
-これらの層を意識しつつ Flutter アプリ／母艦サーバ双方で責務分担を進めます。
-
---
-
-## Event Sourcing / Hash Chain 指針
-
-堅牢で監査可能なエンタープライズレベルの実装に向け、Flutter + SQLite 上でイベントソーシングを採用する際の要求事項を明文化します。
-
-### 役割と必須要件
-
- **役割**: 「イベントソーシング・アーキテクチャ」を実装し、全操作を監査可能に保つモバイルアプリ専門エンジニア。
- **要件**
-  1. UPDATE 禁止・INSERT のみで履歴を積むイベントソーシング方式。
-  2. 各イベントは `previous_hash` / `current_hash` を保持し、追記時にチェーンを再計算。(ハッシュチェーン)
-  3. 伝票発行時にはマスタ情報を JSON スナップショットとして非正規化して保存。
-  4. 生成するコードヘッダーに `// Version: 1.0.0` のようなバージョン表記を必須化。
-  5. 設定値は `.env` から読み込み、ソース直書きを禁止 (セキュリティ確保)。
-
-### 実装対象コンポーネント
-
-1. `EventRecord` モデル … ハッシュ計算ヘルパーとバリデーションを内包。
-2. `DatabaseHelper` … SQLite トランザクションとチェーン検証 (追記時に完全性チェック)。
-3. `SyncService` … 伝票単位で差分同期を行う骨子と再送制御ロジック。
-
-### 出力・コード品質
-
- 可読性・保守性を重視した Dart 実装。
- 各ファイル先頭へ `// Version: <semver>` を記載し、バージョン管理ポリシーと整合させる。
-
-### 内部改修のインパクト
-
- 既存の `app_settings` や業務テーブルはイベントテーブルへ段階的に移行する必要があり、**DB スキーマの大幅刷新**とデータ移行手順（マイグレーション／復元）が不可欠。
- ハッシュチェーンを維持するため、全 INSERT をトランザクションでラップし、`previous_hash` 取得・`current_hash` 算出をセットで行うミドル層 (Repository or DatabaseHelper) を新設する必要がある。
- スナップショット JSON を整形するため、マスタ取得ロジックや `PurchaseEntry` / `Invoice` 生成処理の改修が発生する。
- `.env` 管理を徹底するため、既存の `AppConfig` や `DatabaseHelper` の初期化フローに環境変数リーダーを導入し、公開ビルドとの整合を取る必要がある。
- `SyncService` はイベント単位の差分アップロード・整合性チェック (ハッシュ比較) を実装し直す必要があり、オンライン同期のプロトコル設計も含め再検討が必要。
-
-上記の通り **内部的には大幅なアーキテクチャ改造が前提** となるため、段階的に (1) イベントテーブルの追加 → (2) 既存書き込みのラップ → (3) スナップショット導入 → (4) Sync/Hash 連携 というロードマップで移行する予定です。
-
---
-
-## リポジトリ構成（抜粋）
-
-```
-/home/user/dev/h-1.flutter.0
-├── README.md                   … 本ファイル
-├── analysis_options.yaml       … Lint 設定
-├── lib/                        … Flutter アプリ本体
-│   ├── screens/                … 各種画面（business_profile_screen 等）
-│   ├── widgets/                … 共通ウィジェット（contact_picker_sheet 等）
-│   ├── services/               … 永続化・ユーティリティ（company_profile_service 等）
-│   └── utils/build_expiry_info.dart … ビルド寿命ユーティリティ
-├── scripts/build_with_expiry.sh … dart-define 付きビルドスクリプト
-├── android/, ios/, macos/, windows/, linux/ … 各プラットフォームテンプレート
-├── assets/                     … 画像・リソース
-
-```
-
-※ フルツリーが必要になった場合は `tree` や `list_dir` の出力を README 末尾に追加して更新していきます。
-
---
-
-## セットアップ & ビルド
-
-1. Flutter 3.x 環境を用意し、依存パッケージを取得
-   ```bash
-   flutter pub get
-   ```
-2. 90 日寿命 APK の生成
-   ```bash
-   chmod +x scripts/build_with_expiry.sh
-   ./scripts/build_with_expiry.sh [debug|profile|release]
-   ```
-   - スクリプト内で `APP_BUILD_TIMESTAMP` を UTC で自動付与
-   - `flutter analyze` → `flutter build apk` を連続実行
-3. 実機/エミュレータで起動すると、寿命切れ時には `ExpiredApp` が自動表示されます。
-
---
-
-## テストデータの初期化
-
-新規インストール時に以下マスタが自動挿入されます（既に存在する場合スキップ）:
-
-| マスタ | 対象テーブル | 登録件数 | 特徴 |
-| --- | --- | --- | --- |
-| **得意先** | `customers` | 3 件 | C00001~C00003 / 「テスト株式会社*」表記 |
-| **担当者** | `employees` | 3 件 | 「山田 太郎」「鈴木 花子」「田中 次郎」 |
-| **倉庫** | `warehouses` | 2 件 | 「中央倉庫」「東京支庫」 |
-| **仕入先** | `suppliers` | 3 件 | 「仕入元 Alpha~Gamma」 |
-| **商品** | `products` | 3 件 | PRD001~PRD003 / 「テスト商品*A・B・C」 |
-
-※ データ名に `_test` または「テスト」と付くものや、Alpha/Beta/Gamma など一目でテストデータとわかるデザイン採用。
-
-### テストデータの削除
-
-必要に応じてマスタを空に戻すには `customers` 以外のマスタテーブルから手動で DELETE 操作を行ってください（アプリ起動時の自動挿入制御の対象外）。
-
---
-
-## 母艦「お局様」LAN サーバの起動
-
-1. Dart/Flutter SDK が入った Linux / Android（Termux 等）端末でリポジトリを取得
-2. 監視サーバを起動
-   ```bash
-   dart run bin/mothership_server.dart
-   ```
-   - 環境変数 `MOTHERSHIP_HOST`, `MOTHERSHIP_PORT`, `MOTHERSHIP_API_KEY`, `MOTHERSHIP_DATA_DIR` で上書き可能
-   - 既定値：`0.0.0.0:8787`, API キー `TEST_MOTHERSHIP_KEY`, 保存先 `data/mothership`
-   - `data/mothership/status.json` に各クライアントの心拍/ハッシュを保存
-3. ブラウザで `http://<host>:<port>/` を開くとステータス一覧を閲覧できます（CUI 常駐で OK）
-
-### クライアント（販売アシスト 1 号）からの接続設定
-
-1. アプリの `S1:設定` → 「外部同期（母艦システム『お局様』連携）」で以下を入力
-   - ホストドメイン：`http://192.168.0.10:8787` のようにプロトコル付きで指定
-   - パスワード：サーバ側 API キー（例：`TEST_MOTHERSHIP_KEY`）
-2. 保存するとアプリ起動時に `POST /sync/heartbeat` が自動送信され、寿命残時間が母艦に表示されます。
-3. 同じ設定でチャット送受信・ハッシュ送信が有効になります（下記参照）。
-
-### チャット同期（最小構成）
-
- Flutter アプリ側では 10 秒間隔の軽量ポーリングをバックグラウンドで実行し、`/chat/send` / `/chat/pending` / `/chat/ack` とローカル SQLite を同期します。
- 設定画面からチャット画面を開かなくても新着が取り込まれ、開いた瞬間に最新ログが表示されます。
- 端末がスリープに入るとポーリングを停止し、アプリが前面に戻ったタイミングで即時同期→再開します。
-
---
-
-## 更新ポリシー
-
- README は **機能追加・アーキテクチャ変更・モジュール構成の見直し時に必ず更新** します。
- 変更履歴とファイルツリーは必要に応じて追記し、最新状態を反映させます。
+| 得意先マスタ | `lib/screens
--- a/docs/engineering_management.md
+++ b/docs/engineering_management.md
@ -0,0 +1,196 @@
+# 工程管理ガイドライン - CMO-01 プロジェクト
+
+## 1. ドキュメントの目的
+
+このドキュメントは **プロジェクト全体を可視化・管理するためのフレームワーク**を提供します。
+
+### 活用シーン
+- 📋 **スプリントプランニング**: 2 週間ごとのタスク割り当て
+- 🔄 **進捗追跡**: リストから完了項目を消去して可視化
+- 📊 **ステークホルダー報告**: マイルストーン達成状況を説明資料へ
+- ⚠️ **リスク管理**: 発生事項と対策の記録・共有
+
+---
+
+## 2. ドキュメント構成
+
+| ドキュメント | 内容 | 更新頻度 | 責任者 |
+| --- | --- | --- | --- |
+| [工程管理ガイド](./engineering_management.md) | 全体方針・管理プロセス | 各フェーズ開始時 | PM |
+| [短期計画（Sprint）](./short_term_plan.md) | 2〜4 週間単位のタスク | 各スプリント終了時 | 開発リーダー |
+| [長期計画（Roadmap）](./long_term_plan.md) | 3〜12 ヶ月目標・マイルストーン | マイルストーン完了時 | PM |
+| [要件定義書](./requirements.md) | 機能要件・アーキテクチャ | 要件変更時 | アーキテクト |
+| [プロジェクト計画書](./project_plan.md) | 統合計画書（承認用） | 各ステークホルダーレビュー時 | PM |
+
+---
+
+## 3. 管理プロセス
+
+### 3.1 スプリントサイクル（2 週間）
+
+```
+┌─────────────┐     ┌─────────────┐     ┌─────────────┐
+│  スプリント   │───▶│ プランニング  │───▶│  実装        │
+│   開始       │     │ (タスク割り)  │     │ (開発・レビュー)|
+└─────────────┘     └─────────────┘     └─────────────┘
+      ▲                   │                      │
+      │                   ▼                      ▼
+      └─────────────── 進捗更新 ◀─────────────────┘
+```
+
+**アクションアイテム**:
+1. **スプリント開始（火曜）**: `short_term_plan.md` をスライド作成
+2. **実施週**: テーザタスク完了→`short_term_plan.md` でチェックオフ
+3. **レビュー日（木）**: 達成状況を `project_plan.md` に反映
+
+### 3.2 承認フロー
+
+1. **要件定義書** (`requirements.md`) → CTO 承認
+2. **スプリント計画** (`short_term_plan.md`) → チームレビュー後実装開始
+3. **マイルストーン完了** → ステークホルダーへ `project_plan.md` 提出
+
+---
+
+## 4. ドキュメント管理ポリシー
+
+### 4.1 更新ルール
+
+| トリガー | 対象ドキュメント | アクション |
+| --- | --- | --- |
+| 新機能実装完了 | `short_term_plan.md`, `project_plan.md` | マーク「完了」→ README 更新 |
+| 要件変更承認 | `requirements.md` → `project_plan.md` | 影響範囲を記載し再承認 |
+| リスク発生 | `engineering_management.md` (リスク管理節) | 発生日に追加・対策立案 |
+
+### 4.2 バージョン管理
+
+```bash
+# コミットメッセージとドキュメント更新を同期
+git commit -m "feat: Estimate CRUD API 実装"
+# → README.md の実装完了セクションを更新
+git add README.md
+git commit -m "docs: README 更新（見積機能実装完了）"
+```
+
+**semver カスタム**:
+- `MAJOR`: DB スキーマ破壊変更、API バージョンマイナー
+- `MINOR`: 新機能追加、ドキュメント改善
+- `PATCH`: バグ修正、テストカバレッジ向上
+
+---
+
+## 5. 活用方法（詳細）
+
+### 5.1 新規参入者向けロードマップ
+
+```
+ステップ 1: README.md を読み込み
+  └─> プロジェクト全体像とドキュメント一覧把握
+  
+ステップ 2: requirements.md で要件確認
+  └─> 「何を」作るか理解する
+  
+ステップ 3: short_term_plan.md でタスク取得
+  └─> 次の 2 週間の優先順位を知る
+  
+ステップ 4: 実装・レビュー → project_plan.md に反映
+  └─> 進捗を可視化して報告
+
+ステップ 5: long_term_plan.md で目標確認
+  └─> 「なぜ」やるかの文脈理解
+```
+
+### 5.2 リソース管理の活用
+
+**チームメンバー**:
+1. `short_term_plan.md` の未着手タスク一覧からアサイン
+2. 実装完了→GitHub Issues に Issue 作成してクローズ
+3. ステータス更新 → プログレッシュバーで自己管理能力向上
+
+**ステークホルダー**:
+1. `project_plan.md` でマイルストーン確認
+2. リスクセクションでの現状把握
+3. ベータリリース目標（2026/06/30）への道筋追跡
+
+---
+
+## 6. メトリクスと測定
+
+### 6.1 KPI データ
+
+| 指標 | 目標値 | 測定頻度 | 記録位置 |
+| --- | --- | --- | --- |
+| テストカバレッジ | >70% | 各スプリント | `project_plan.md` |
+| バグ発生数 | <5/Critical=0 | リリース前 | `project_plan.md` |
+| スプリント完了率 | >85% | 月末 | `short_term_plan.md` |
+
+### 6.2 進捗ダッシュボード（簡易）
+
+```markdown
+## 📊 進捗サマリー（スプリント終了時）
+
+- **実装タスク**: [x] 見積入力 [ ] 売上入力 [ ] 請求作成
+- **テストカバレッジ**: 65% → 75% (+10%)
+- **課題数**: 3 (Critical=0)
+
+## 📅 次のマイルストーン
+
+- **M1: ベータリリース** - 2026/06/30
+- **条件**: Bug < 10, テストカバレッジ > 70%
+```
+
+---
+
+## 7. 緊急時の対応
+
+### 7.1 リスク発生時
+
+1. `engineering_management.md` にリスク記録
+2. チーム会議（15min）で対応策決定
+3. ステークホルダーに進捗報告（簡易スライド）
+
+**例**: Google API キャンペーン制限超過
+- **影響**: 認証機能使用制限
+- **対策**: ローカル認証モードの維持
+- **ステータス**: 🔴 中 → 🟢 回復済み
+
+---
+
+## 8. ドキュメントの共有
+
+### 公開範囲と権限
+
+| ドキュメント | 公開先 | 編集権限 |
+| --- | --- | --- |
+| `engineering_management.md` | チーム内部 | PM/リーダー |
+| `short_term_plan.md` | 全体チーム | 全員（コメント可） |
+| `project_plan.md` | ステークホルダー | 承認待ちまで Read-Only |
+
+### 配布形式
+
+- **日次更新**: Markdown ファイル（Git にコミット）
+- **週報**: GitHub Releases または Slack へ出力
+- **月次**: PDF でステークホルダーへ送信
+
+---
+
+## 9. 補足
+
+### 9.1 リンク情報
+
+- [プロジェクトチャート](https://project-management.internal/h1-cmo-01)（外部リンク）
+- [Google Play Console](https://play.google.com/console)（リリース管理）
+- [Firebase Console](https://console.firebase.google.com)（分析・エラーログ）
+
+### 9.2 用語集
+
+| 用語 | 説明 |
+| --- | --- |
+| スプリント | 2 週間単位の開発サイクル |
+| マイルストーン | 重要な達成目標（リリースなど） |
+| リスク軽減策 | 発生確率を低減する事前準備 |
+
+---
+
+**最終更新**: 2026/03/07  
+**バージョン**: 1.0 (Initial Release)  
+**責任者**: PM（開発リーダー）
--- a/docs/long_term_plan.md
+++ b/docs/long_term_plan.md
@ -0,0 +1,213 @@
+# 長期計画（Roadmap）- CMO-01 プロジェクト
+
+## 1. ロードマップ概要
+
+| フェーズ | 期間 | 目標 | リリース版 |
+| --- | --- | --- | --- |
+| **F1: MVP ベータ版** | Q2 2026<br>(3/07-6/30) | コア機能完結・マスタ管理 | v1.0.0-beta |
+| **F2: クラウド同期化** | Q3 2026<br>(7/01-9/30) | お局様連携完了 | v1.1.0-rc |
+| **F3: 正式版リリース** | Q4 2026<br>(10/01-12/31) | iOS 対応・全機能実装 | v1.2.0-ga |
+| **F4: 拡張機能追加** | Q1-Q3 2027<br>(2027/01-09) | AI 分析・マルチテナント | v2.0.0-alpha |
+
+---
+
+## 2. フェーズ別ロードマップ
+
+### 📦 F1: MVP ベータ版（2026 Q2）
+
+**期間**: 2026/03/07 - 2026/06/30  
+**目標**: Android 端末単体で全業務を完結する販売アシスタント
+
+#### 🎯 マイルストーン一覧
+
+| MS 番号 | 名称 | 目標日 | 交付物 | 責任者 |
+| --- | --- | --- | --- | --- |
+| M1-01 | マスタ管理完了 | 3/25 | CRUD UI + DB 接続 | Sales チーム | ✅ 完了 |
+| M1-02 | 見積入力機能実装 | 4/11 | DatabaseHelper 連携 | POS チーム | 🟡 進行中 |
+| M1-03 | 売上入力実装完了 | 4/18 | JAN 検索・在庫管理 | POS チーム | ⏳計画後 |
+| M1-04 | 請求作成機能定義 | 4/25 | PDF テンプレート | Billing チーム | 📋検討中 |
+| M1-05 | 在庫管理モジュール | 5/30 | 棚卸・移動機能 | Inventory チーム | 🟡計画後 |
+| M1-06 | ユーザー権限実装 | 6/15 | ロールベースセキュリティ | Security チーム | 🟡計画後 |
+| M1-Finish | ベータリリース | 6/30 | Google Play ベータ公開 | PM | 🎯目標 |
+
+#### 💰 リソース配分（F1）
+
+| チーム | スキルセット | アサイン人数 | 優先度 |
+| --- | --- | --- | --- |
+| POS チーム | Flutter UI / DB | 3 名 | 🔴 High |
+| Sales チーム | 販売業務 | 2 名 | 🟢 Medium |
+| Billing チーム | PDF/メール | 2 名 | 🟡 Low |
+
+#### ✅ 達成条件（ベータリリース）
+
+1. **機能要件**: すべてのコア機能実装完了
+   - [x] マスタ管理（5 マスタ）
+   - [ ] 見積入力（DatabaseHelper 接続後）
+   - [ ] 売上入力（JAN 検索・在庫対応）
+   - [ ] 請求作成（PDF 帳票出力）
+
+2. **品質基準**:
+   - Bug 数 < 10 (Critical = 0)
+   - テストカバレッジ > 70%
+   - 動作環境：Android 9.0+ / 3GB RAM
+
+3. **レビュー承認**: ステークホルダー全賛同取得
+
+---
+
+### ☁️ F2: クラウド同期化（2026 Q3）
+
+**期間**: 2026/07/01 - 2026/09/30  
+**目標**: お局様とのデータ同期・バックアップ体制整備
+
+#### 🎯 マイルストーン一覧
+
+| MS 番号 | 名称 | 目標日 | 交付物 | 責任者 |
+| --- | --- | --- | --- | --- |
+| M2-01 | Google Auth 統合 | 7/06 | OAuth フロー実装 | Auth チーム | ⏳計画後 |
+| M2-02 | データ同期ロジック | 8/17 | 差分アップロード | Data チーム | 🟡計画後 |
+| M2-03 | Conflict Resolution | 10/01 | Last-Write-Wins 実装 | Sync チーム | 🟡計画後 |
+| M2-04 | プッシュ通知機能 | 10/31 | Firebase Cloud Messaging | Notif チーム | 🟡計画後 |
+| M2-Finish | クラウド版リリース | 9/30 | Play Store リリース | PM | 🎯目標 |
+
+#### 🔒 セキュリティ要件（F2）
+
+- Google Identity Platform 認証
+- データ暗号化: AES-256 + Firebase Encryption
+- 監査ログ: Firebase Authentication Logs
+
+#### 📊 同期戦略
+
+**オンデマンド同期**:
+```
+アプリ起動 → /sync/heartbeat を母艦へ送信
+    ↓
+差分データ検出 → バッチアップロード
+    ↓
+母艦 DB マージ → クライアントへ反映
+```
+
+---
+
+### 🎉 F3: 正式版リリース（2026 Q4）
+
+**期間**: 2026/10/01 - 2026/12/31  
+**目標**: iOS 対応・すべての機能実装完了
+
+#### 🎯 マイルストーン一覧
+
+| MS 番号 | 名称 | 目標日 | 交付物 | 責任者 |
+| --- | --- | --- | --- | --- |
+| M3-01 | iOS バージョン実装 | 12/16 | Xcode プロジェクト完了 | iOS チーム | 🟡計画後 |
+| M3-02 | 返品処理画面 | 12/08 | 売上返品 CRUD | Sales チーム | ⏳計画後 |
+| M3-03 | 領収書作成機能 | 12/15 | 領収テンプレート | Billing チーム | 🟡計画後 |
+| M3-04 | キャッシュ決済ゲート | 12/29 | Stripe / PayPay 連携 | Payment チーム | ⏳計画後 |
+| M3-Finish | 正式版リリース | 12/31 | App Store 公開 | PM | 🎯目標 |
+
+#### 🚀 リリース条件
+
+1. **機能要件**: すべての業務機能実装完了
+   - [x] マスタ管理
+   - [ ] 見積入力
+   - [ ] 売上入力（レジモード）
+   - [ ] 請求作成
+   - [ ] 返品処理
+   - [ ] 領収書発行
+
+2. **テスト完了**:
+   - E2E テストパス > 90%
+   - iOS + Android 両プラットフォーム動作確認
+
+3. **公開審査**: App Store / Play Store 審査通過
+
+---
+
+### 🔮 F4: 拡張機能追加（2027 Q1-Q3）
+
+**期間**: 2027/01/01 - 2027/09/30  
+**目標**: AI 分析・マルチテナント・カスタマイズ機能
+
+#### 🎯 機能ロードマップ
+
+| 機能 | 目標日 | プラグイン化 | 影響範囲 |
+| --- | --- | --- | --- |
+| **AI 売上分析ダッシュボード** | 2027/03 | ✅独立モジュール | 集計層 |
+| **マルチテナント設定** | 2027/04 | ✅サブスクモード | DB スキーマ拡張 |
+| **カスタムレポートエクスポート** | 2027/06 | ✅CSV/PDF テンプレート | 出力機能 |
+| **在庫予測 AI モジュール** | 2027/08 | ✅機械学習モデル | データ収集・分析 |
+
+#### 💎 サブスクモデル化（目標）
+
+```
+月額プラン: ¥2,980〜
+├─ 基本版：マスタ + 販売機能のみ
+├─ プロ版：請求・請求書発行付加
+└─ エンタープライズ：カスタマイズ対応
+
+初期セットアップ費: ¥19,800
+└─ データ移行支援・テンプレート作成
+```
+
+---
+
+## 3. チーム成長計画（2026-2027）
+
+### 📈 スキルマッピング目標
+
+| チーム | 現在スキルセット | 目標（2027/03） | 研修方法 |
+| --- | --- | --- | --- |
+| POS チーム | Flutter UI, CRUD | Firebase Sync, AI API 連携 | コールバック研修 |
+| Sales チーム | 販売業務知識 | データ分析、BI ツール利用 | Excel → Power BI |
+| Auth チーム | OAuth2.0 | PKI, TLS 設計知識 | セキュリティ認定取得 |
+| Data チーム | SQLite | 分散 DB, キャッシュ戦略 | AWS RDS/Redshift |
+
+### 🏆 人材獲得計画（2026 Q3-2027）
+
+```
+現在：5 名（開発リーダー 1+POS2+Billing1）
+    ↓
+Q3/Q4: 新規メンバー 3 名招聘
+├─ iOS 経験者：1 名（iOS チーム補強）
+├─ AI/ML エンジニア：1 名（分析機能実装）
+└─ セキュリティ専門: 1 名（コンプライアンス対応）
+```
+
+---
+
+## 4. リスク・課題管理（長期視点）
+
+### 🔴 主要リスク（フェーズ全体）
+
+| リスク | 発生日 | 影響度 | 対策プラン | 責任者 |
+| --- | --- | --- | --- | --- |
+| **データ同期遅延** | F2(7/01+) | 🟡 中 | オフキュープ処理実装 | Data チーム |
+| **ユーザー登録率低** | F1-F3 全体 | 🔴 高 | オンボーディング改善 | Product チーム |
+| **バッテリー drain** | F2-4 全体 | 🟡 中 | 背景プロセス最適化 | Perf チーム |
+| **AARL 制限超過** | 随時 | 🟡 中 | サーバー認証方式検討 | Infra チーム |
+
+### 💡 課題解決アプローチ
+
+#### 課題：「レガシー POS システムとの連携」
+**現状**: 競合他社の POS や現金受入れ機とデータ交換が必要  
+**解決策**:
+1. **CSV エクスポート/インポート機能追加**（F1-M6）
+2. **API ゲートウェイ利用**（F3-拡張機能）
+3. **物理バーコード連携**: QR コード発行
+
+#### 課題：「オフライン優先 vs オンライン同期の両立」
+**現状**: 店舗環境はインターネット不安定  
+**解決策**:
+1. **オフライン第一の設計原則**: 全データローカル保存
+2. **同期ボタン**: ユーザーがオンデマンドで更新トリガー
+3. **差分同期のみ**: バッテリー節約・通信コスト低減
+
+---
+
+## 5. 成功指標（KPI）
+
+### 📊 メトリクス定義
+
+| 指標 | 目標値 | 測定頻度 | 責任者 |
+| --- | --- | --- | --- |
+| **月間アクティブユーザー** | +20% MoM | 月末 | PM |
+| **ストアアプリ評価** | ⭐4.0+ | 四半期ご
--- a/docs/short_term_plan.md
+++ b/docs/short_term_plan.md
@ -0,0 +1,122 @@
+# 短期計画（Sprint Plan）- CMO-01 プロジェクト
+
+## 1. スプリント概要
+
+| 項目 | 内容 |
+| --- | --- |
+| **スプリント期間** | 2026/03/09 - 2026/03/23（Week 4） |
+| **目標** | 見積機能完結 + 売上入力画面基本動作 |
+| **優先度**: 🟢 | High |
+
+---
+
+## 2. タスクリスト
+
+### 2.1 Sprint 4: コア機能強化（進行中）
+
+#### 📦 見積入力機能完了
+- [x] DatabaseHelper 接続（estimate テーブル CRUD API）
+- [x] EstimateScreen の基本実装（得意先選択・商品追加）
+- [ ] 見積保存時のエラーハンドリング完全化
+- [ ] PDF 帳票出力対応（テンプレート準備）
+
+**担当者**: Sales チーム  
+**工期**: 3/15-3/20（5 営業日）  
+**優先度**: 🟢 High
+
+#### 🛒 売上入力画面実装
+- [ ] DatabaseHelper の sales テーブル定義追加
+- [ ] SaleEntry モデル作成・画面構築
+- [ ] レジモードとの連携設計
+
+**担当者**: POS チーム  
+**工期**: 3/20-3/27（6 営業日）  
+**優先度**: 🟢 High
+
+#### 📝 請求書機能定義
+- [ ] Invoice モデル定義
+- [ ] PDF レイアウトテンプレート選定（flutter_pdf_generator？）
+- [ ] バージンモードでの発行可否検討
+
+**担当者**: Billing チーム  
+**工期**: 3/16-3/24（8 営業日）  
+**優先度**: 🟡 Medium
+
+---
+
+## 3. 依存関係
+
+```mermaid
+graph LR
+    A[見積機能完了] -->|完了時 | B[売上入力実装]
+    B -->|完了時 | C[請求作成設計]
+    C -->|完了時 | D[テスト環境構築]
+```
+
+**要件**:
+- 見積保存が正常動作（DatabaseHelper.insertEstimate）→ ✅ 完了
+- 売上テーブル定義 → ⏳ 待機中
+- PDF ライブラリ選定 → 📋 トランザクション検討
+
+---
+
+## 4. リスク管理
+
+| リスク | 影響 | 確率 | 対策 |
+| --- | --- | --- | --- |
+| 見積保存エラー | 高 | 🔴 中 | エラーハンドリング改善（既実装） |
+| PDF ライブラリ互換性 | 中 | 🟡 低 | flutter_pdfgenerator / pdf 両検討 |
+| DatabaseHelper API コスト | 低 | 🟢 低 | 既存スクリプト再利用 |
+
+---
+
+## 5. 進捗追跡方法
+
+**チェックリスト方式**:
+- [ ] タスク完了 → GitHub Commit で記録
+- [x] マークオフ→README.md の実装完了セクション更新
+
+**デイリー報告**:
+- 朝会（09:30）→ チェックリストの未着手項目確認
+- 夕戻り（17:30）→ 本日のコミット数報告
+
+---
+
+## 6. マイルストーンチェックポイント
+
+### 🎯 S4-M1: 見積機能完了（2026/03/18）
+**条件**:
+- DatabaseHelper を介した保存・取得動作確認
+- 見積一覧画面への登録
+- PDF 帳票出力デモ検証
+
+### 🎯 S4-M2: 売上入力実装（2026/03/25）
+**条件**:
+- レジ連携設計完了
+- 基本 CRUD 機能動作確認
+
+### 🎯 S4-M3: クラウド同期準備（2026/03/31）
+**条件**:
+- Google Auth 検証完了
+- データ同期プロトコル定義
+
+---
+
+## 7. スプリントレビュー項目（木曜 15:00）
+
+### レビューアジェンダ
+1. **実装成果物**: CheckList の完了項目確認
+2. **課題共有**: 未完成タスクの原因分析
+3. **次スプリント計画**: Sprint 5 タスク定義
+4. **ステークホルダー報告**: プロジェクト計画書の更新
+
+### レビュー資料準備
+- README.md（実装完了セクション）
+- project_plan.md（M1 マイルストーン記録）
+- test/widget_test.dart（テストカバレッジレポート）
+
+---
+
+**最終更新**: 2026/03/07  
+**バージョン**: 1.1 (Week 4 Init)  
+**作成者**: PM（開発リーダー）