reserve-optimizer 次期フェーズロードマップ（ブレスト全書き出し）
作成: 2026-06-26・更新: 2026-06-26（採用最優先で再評価） 経緯: 機能実装は Wave 1-3（リピート率向上 / 施術品質・運用柔軟性 / 収益マーケ基盤）で一通り完了。リファクタリング P0-P3（31項目）+ v3レビューP0/P1 も完了。 前身:
FEATURE_ROADMAP_2026-06-12.md（Wave 1-3 計画・実装済み）
🎯 メインゴール: 採用最優先（2026-06-26 決定）
ロードマップ全体の基準は「採用面接で勝つポートフォリオ」。 頂点は E11（公開デモ環境） — 「見せて・説明できて・品質証明されている」を実現する。 事業/SaaS化（C1実導入・B4マルチテナント・D3 Supabase）は採用では後回し（Phase δ）。
現在地（スナップショット）
実装済み機能
- Wave 1: スタッフ指名予約（前回担当者をQuickReply先頭）・クーポン（CRMタグ連動カムバック配信）・口コミ依頼自動化（評価分岐型Googleレビュー誘導）
- Wave 2: 事前Web問診票（GLM要約添付）・簡易施術カルテ（テキスト+タグ）・運用柔軟性設定（バッファ/締切/地図URL）
- Wave 3: デジタルスタンプカード・Stripeサブスク定期課金・セグメント配信
- 既存資産: ウェイティングリスト（キャンセル自動埋め）・デポジット決済・回数券・GLM-4.7 AIチャット・6言語i18n・CRMタグ自動付与・KPIダッシュボード・2段階リマインダー
品質
- リファクタリング P0-P3（31項目）完了・v3レビュー P0/P1 完了
- Test CI バッジあり（README）・カバレッジバッジなし
既知の残課題（ISSUE/IMPROVEMENT_PLAN 由来）
- 自動テスト薄い（Worker側ゼロ・GAS統合中心）
- Worker: CORS
*（決済APIに不適）・console.log本番残・302リダイレクトハックのフラジリティ - ステートマシン if/switch ベース・ScriptProperties 平文キー・英語README不在
- 実導入 0 件・公開デモ環境なし（採用で最大の穴）
A. 採用ポートフォリオ完成度（面接で突かれる弱点を潰す）
| ID | 項目 | 概要 | 価値 / 理由 | 参考 | 想定工数 |
|---|---|---|---|---|---|
| A1 | 自動テスト拡充 | Worker: vitest で verifyLineSignature / verifyStripeSignature / timingSafeEqual / 状態遷移。GAS: StateHandler 15状態×主要入力の遷移行列。CI カバレッジバッジ追加 | 「テストどうしてますか？」に即答可能・デグレ防止 | ISSUE-001, HIGH-3 | 1-2日 |
| A2 | README Impact 数値化 | 処理件数・受付削減時間・決済成功率・レイテンシを実データ（無ければベンチマーク計測値）で冒頭に | 「何がどれだけ改善したか」30秒で答えられる | ISSUE-002 | 1-2時間 |
| A3 | 英語 README | abstract 1段落 + README.en.md | 外資/英語圓志向・OSS PR 時の説得力 | ISSUE-007 | 30分 |
| A4 | セキュリティ硬化 | CORS *→ALLOWED_ORIGIN・console.log 除去・ScriptProperties 権限制限/ローテーション手順明記 | 決済APIの基本・平文キー指摘回避・デモ公開の前提 | HIGH-1, HIGH-2, ISSUE-005 | 2-3時間 |
| A5 | アーキテクチャ/シーケンス図 | Mermaid で全体構成・予約フロー・Stripe/Webhook シーケンスを README に | 「設計を説明できる」証拠・コード読解負荷低下 | — | 2-3時間 |
| A6 | ADR 整備 | docs/decisions/ に「なぜGAS+Sheetsか」「なぜWorkerを挟むか」「なぜデポジットか」等の意思決定記録 | 設計意図の言語化・トレードオフ理解の証拠 | — | 半日 |
B. 機能追加（Wave 4 候補）
| ID | 項目 | 概要 | 価値 / 理由 | 参考 | 想定工数 |
|---|---|---|---|---|---|
| B1 | セルフチェックイン | 来院時タップ→スタッフ通知・待ち時間表示。/checkin/:reservationId | 受付対応削減・密回避・UX | G12, RESERVA | 1-2日 |
| B2 | Googleカレンダー双方向同期 | 個人セラピストのカレンダーと予約を双方向反映。CalendarService 拡張 | 個人セラピスト/カウンセラー向けの強需要（ピボット先直結） | G13, ポチコ | 2-3日 |
| B3 | LINEミニアプリ / LIFF 化 | Web予約を LIFF でネイティブ体験・トーク内遷移 | UX向上・ブランディング・LINE公式連携の説得力 | STORES予約 | 2-3日 |
| B4 | マルチテナント・複数セラピスト管理 | 院/セラピスト単位のデータ分離・管理画面。Phase2 SaaS の前提 | 販売可能化・スケール | STORES, Phase2 | 1週間+ |
| B5 | Googleレビュー連携強化 | Place ID 連動・レビューサイト誘導の最適化・A/B | 集客（MRR と相関）の自動化 | G6 発展 | 1-2日 |
| B6 | ビデオ相談 / オンライン予約 | カウンセラー向けオンライン施術予約・Zoom/Meet 連携 | ピボット先（カウンセラー）の直接訴求 | — | 2-3日 |
| B7 | 施術メニューカスタマイズ UI | セラピスト毎にメニュー・所要時間・料金を設定可能に | 個人差の大きい業態への適合・設定化方針の延長 | W2-3 発展 | 1-2日 |
C. 事業化・実運用（0件脱却）
| ID | 項目 | 概要 | 価値 / 理由 | 参考 | 想定工数 |
|---|---|---|---|---|---|
| C1 | 実導入 1 件獲得 | 知人院 または demo-site-sales スキルで DM 営業し試験導入。実データ取得 | A2 の数値化の前提・「動いている実績」が最大の説得力 | PRODUCT_VISION Phase1 | 営業含 1-2週間／知人1件トライアルなら S-M |
| C2 | 料金設定確定 | 月額/初期費用の確定 + 管理者側サブスク管理画面 | 販売可能化・Stripe 請求の実運用 | Phase2 | 半日 |
| C3 | LP / サービス紹介サイト | サービス概要・料金・導入事例の静的サイト | 集客・営業時のパンフレット | — | 1-2日 |
| C4 | 利用規約・免責・プライバシーポリシー | 個人情報・決済を扱うための法的文書整備 | 法的必須・事故時の免責・デモ公開の前提 | PRODUCT_VISION §8 | 半日（要レビュー） |
| C5 | 運用監視 | UptimeRobot・エラーアラート（LINE管理者/Discord）・障害即時検知 | SLA の体・ダウン時の機会損失防止 | PRODUCT_VISION §8 | 半日 |
| C6 | アナリティクス | 予約 CV ・離脱ポイント・枠埋まり率の計測 | 改善PDCA・KPIダッシュボードの拡張 | — | 1-2日 |
D. 技術債 / アーキテクチャ
| ID | 項目 | 概要 | 価値 / 理由 | 参考 | 想定工数 |
|---|---|---|---|---|---|
| D1 | ステートマシン宣言的化 | TRANSITIONS = { state: { input: nextState } } 辞書化・不正遷移の明示的拒否 | 新状態追加コスト抑制・バグ防止・テスト容易 | ISSUE-004, MED-2 | 1-2日（M） |
| D2 | Worker 脆弱性解消 | 302ハック→Apps Script Execution API 化 or fetch POST body 化・URL長制限リスク除去 | GAS仕様変更で即死する設計の解消 | ISSUE-003, MED-1 | 半日-1日 |
| D3 | GAS→Supabase 移行（設計） | Phase2 SaaS 化の DB 移行・段階的設計のみ（実装は別途） | スケール前提・Sheets の限界超え | PRODUCT_VISION Phase2 | 1-2日（設計） |
| D4 | DBIF 抽象化 | SheetService 依存を interface 背後に隠す（D3 を容易に） | 移行コスト低減・テスト容易 | MED-3 関連 | 1-2日 |
| D5 | 構造化ログ・Logpush | Cloudflare Logpush で外部保存・検索可能化・課金ノイズ除去 | 障害解析・監査証跡 | ISSUE-003 補足 | 半日 |
E. 追加候補（2026-06-26 採用ブレストより）
| ID | 項目 | 概要 | 価値 / 理由 | 想定工数 |
|---|---|---|---|---|
| E11 | 公開デモ環境＋サンプルデータ | 誰でも触れるライブデモ（sample data・readOnlyモード・公開URL）。本番GASとは別デプロイ | 採用の頂点・「見せて」に即応・実導入0でも説得力・C1のハードル低下 | M |
| E4 | データエクスポート/ポータビリティ | 顧客・予約データのCSV/JSON出力・持ち出し | Supabase移行時の必需・「誠実なSaaS設計」アピール（採用で語れる） | M |
| E12 | README スクショ/GIF リフレッシュ | Wave1-3機能の画面キャプチャ更新 | 第一印象の陳腐化防止（採用で最初に見える嘘を防ぐ）・参考候補 | S |
| E3 | バックアップ/災害復旧 | Sheetsの自動バックアップ・誤削除対策 | 運用品質・C5監視の延長・参考候補 | S |
評価（2026-06-26・採用最優先）
基準: 採用インパクト / 事業インパクト（★1-5）・工数（S/M/L/XL）・依存リスク・総合優先度（S>A>B>C） ※採用最優先決定により再評価。C1工数 XL→S-M・D1工数 L→M に修正。
採用S群（核・6件）
| ID | 項目 | 採用 | 事業 | 工数 | 依存 | コメント | |—|—|—|—|—|—|—| | E11 | 公開デモ環境 | 5 | 4 | M | A4/C4 | 頂点・「見せて」に即応・実導入0でも説得力 | | A1 | 自動テスト | 5 | 3 | M | 低 | 「テストどうですか」の決定打・デモの信頼性基盤 | | A4 | セキュリティ硬化 | 4 | 5 | S | 低 | E11デモ公開の前提・CORS/キー放置は即減点 | | C4 | 規約/免責/PP | 3 | 5 | S | 低 | E11デモ公開の法的必須・安い | | C1 | 実導入(知人1件) | 5 | 5 | S-M | A4/C4 | 実績=最強。デモ(E11)があるので導入ハードル激減 | | A2 | Impact数値化 | 5 | 4 | S | C1/E11 | デモのベンチマーク数値で今すぐ暫定可 |
A群（6件）
| ID | 項目 | 採用 | 事業 | 工数 | コメント | |—|—|—|—|—|—| | A5 | アーキ/シーケンス図 | 4 | 2 | S | 設計説明力・安い・デモとセット | | D1 | 状態機械宣言化 | 4 | 3 | M | 設計語りの種・A1テスト容易化・工数L→M修正 | | B2 | Googleカレンダー同期 | 3 | 5 | L | ピボット先直結の最大差別化 | | C2 | 料金設定 | 2 | 5 | S | C1導入の前置き | | C5 | 運用監視 | 3 | 4 | S | SLA・デモの安定性担保 | | D2 | Worker脆弱性解消 | 4 | 4 | M | 安定性・302即死リスク除去 |
B群（10件）
A3・A6・B1・B5・E4・C3・C6・D3・D4・D5
C群（3件）
B3・B6・B7
B4（マルチテナント）は Phase δ（SaaS化）へ後退・採用では非核
推奨シーケンス（採用最優先・E11デモ頂点）
| Phase | タスク | 意図 |
|---|---|---|
| α 採用デモ基盤（頂点:E11） | A4(セキュリティ) → C4(規約) → E11(公開デモ+サンプルdata) → A1(テスト) → A5(図) → A2(数値化) | 「見せて・説明できて・品質証明」の最小セット。E11が頂点・A4/C4はその前提 |
| β 実績強化 | C1(知人導入・デモで容易化) → A2(実データで真値化) | 採用で「動いている実績」が載る・デモがあるので導入ハードル激減 |
| γ 差別化・語り種 | D1(状態機関) → B2(カレンダー) → E4(エクスポート) → D2(Worker) | 設計語り+ピボット先直結 |
| δ SaaS化（採用では後回し） | D3/D4 → B4 | 独立時に |
採用の核は Phase α。E11デモを公開するために A4+C4 が必須前置き、A1+A5+A2 で「デモの質」を担保する構造。
面接で語るストーリー（REVIEW_ISSUES 既存3種 + 採用強化2種）
- エッジ署名検証 + waitUntil（Cloudflare Workers 正しい使い方）
- CacheService→PropertiesService 二層 state ストア（GAS eviction バグ対応）
- timingSafeEqual 自前実装（HMAC タイミング攻撃対策）
- NEW: 公開デモで触れる（E11）— 「見せて」に即応
- NEW: CI通るテスト基盤（A1）— 品質証明
依存関係メモ
- E11（公開デモ）は A4（セキュリティ）+ C4（規約）+ サンプルdata偽装 が必須前置き — 本番データ漏洩・法的穴を防ぐ
- A2（Impact数値化）は E11/C1 に依存 — デモのベンチマーク or 実データ
- B4（マルチテナント）は D3/D4（Supabase/DBIF）に依存 — Sheets 構成のままでは困難
- C2（料金）・C4（規約）は C1（導入）の前置き
- D1（状態機関）は B 系追加すべての前置き — やらずに機能増やすと複雑度爆発
次ステップ
本書をレビュー✅（採用ブレスト反映済）順位付け基準を決定✅（採用最優先）- Phase α（採用デモ基盤）を spec 化 →
docs/specs/へ落とし込み（E11の中身：サンプルdata生成・readOnly仕切り・公開URL 等） - SSOT
01_DECISIONS/reserve-optimizer/に決定記録