リリース計画

位置づけ: 全体を横断する計画ページ

概要

新CRMは3段階のフェーズで段階リリースする。第1弾は催事・アイテム（商品マスタ）・商社（卸）の3モジュールで構成する。後続フェーズは顧客・商談CRM本体・見積/価格表・KPI予実・チャット・データ移行を含む。将来フェーズはAIエージェント・SaaS化・分社化を含む。

第1弾の対象は当初「催事」単独だった。2026-07-15の定例会で商社機能と催事管理の先行が要望され、2026-07-22の定例会で催事（代理店統合・権限・報告拡張）と卸（シリーズ・部材/パッケージ）の是正が確定し、以降モックへ全反映済み（催事・アイテムおよびこの範囲の卸是正は本番反映済み）。2026-07-29の定例会で卸金額・発注管理・決済フロー・商社別軸案件の4要件が追加提示され、第1弾スコープは「催事」から「催事＋アイテム＋商社」へ拡張した。この追加要件は試作確認済みであり、本番反映は次回以降となる。拡張の理由は、商社（卸）の卸金額（WholesalePrice）が商品・パッケージのマスタ（商品は型番Product.modelとのID連携、パッケージ等は品名）を参照する構造であり、商社機能の実装にはアイテム（商品マスタ）が前提になるためである。

決定経緯の一次情報は redesign/meeting-log を正本とする。ValueOSとの機能差分・項目突合は redesign/valueos-gap を正本とする。本ページはこの2つの正本を横断し、フェーズ分類（第1弾／後続フェーズ／将来フェーズ）を一元管理する計画ビューである。他ページはフェーズをここで定義した分類のみを参照し、独自にフェーズ名を再定義しない。

スコープ/対象

フェーズ	定義	状態
第1弾（旧定義）	催事・アイテム・商社（卸）の3モジュール	廃止。9/9 に案1コアへ再定義。催事・卸の実装は 9/10 に削除（アイテム＝マスタは継続）
後続フェーズ	顧客・商談CRM本体・見積/価格表・KPI予実・チャット・データ移行	第1弾完了後に着手
将来フェーズ	AIエージェント・SaaS化・分社化	12月のCRM完成後に着手

機能×フェーズ管理表

機能	フェーズ	主要エンティティ・実装状況	依存関係	詳細ページ
催事	第1弾	`EventStore`（系列）・`EventCompany`（代理店）・`EventShift`（1店舗×1代理店）・`StartReport`（朝礼）・`EndReport`（現場ファネル）。event-shift-systemを `/events` として先行取り込み済み	依存なし。単独リリース可	features/events
アイテム（商品マスタ）	第1弾	`Product`（型番＝主キー、kind＝PV/BT/EQ/IH/AC/付帯、メーカー必須、在庫3状態）＋周辺マスタ（Series/Supplier/Vendor/LoanCompany）＋フィールド単位の変更履歴。価格は持たない設計	商社（卸）の前提。商社より先にリリースする	features/item-master
商社（卸）	第1弾	`WholesalePrice`（仕入/卸/反映日）・決済区分5種・工程STEP7種・`WholesaleCase`・`WBucket` 6状態・`DealerIntakeForm`・`WholesaleTask`	アイテム完了後に着手。アイテム単独完了が前提条件	features/wholesale・features/wholesale-settlement
顧客・商談CRM	後続フェーズ	案件パイプライン本体・チャット連携等	催事・アイテム・商社とは独立に着手可能	features/crm-core
見積・価格表	後続フェーズ	ValueOS準拠の価格表/見積モジュール。`Manufacturer`（メーカーマスタ）を含む。価格は当方CRM側で保持する方針（2026-07-17更新）	アイテム（商品マスタ）・顧客・商談CRM本体に依存	features/quote-pricing
KPI予実	後続フェーズ	売上・粗利・未入金の集計、業務アラート	商社（卸）の発注/請求/入金エンティティ化に依存	features/kpi-forecast
チャット	後続フェーズ	案件詳細タブ＋受信箱型画面（/chat）、Slack通知連携	顧客・商談CRM本体に依存	features/chat-collab
データ移行	後続フェーズ	年末休業中に一括移行。申請系は独立業務のため先行納品を検討	第1弾・後続フェーズの主要マスタ確定後	redesign/migration-plan
AIエージェント	将来フェーズ	中間やりとりの自動化	基本機能確定後に着手する方針	features/ai-agent
SaaS化	将来フェーズ	代理店へ無料提供（アライアンス条件で実質利用）、自社導入は課金	12月のCRM完成後	redesign/future-vision
分社化	将来フェーズ	商社別軸案件と元請（販売店）の統合ビューを分離した組織設計	商社（卸）の別軸運用が定着した後	redesign/future-vision

機能×フェーズ管理表のフィールド定義

上表「機能×フェーズ管理表」が持つ列を、名称・型/値域・必須・既定・制約の観点で定義する。

フィールド	型/値域	必須	既定	制約
フェーズ	enum（第1弾／後続フェーズ／将来フェーズ）	必須	なし	「スコープ/対象」節で定義した3値のみを用いる。他ページはこの3値を再定義しない
機能	文字列（機能名）	必須	なし	featuresディレクトリの詳細ページ1件に対応させる
主要エンティティ・実装状況	文字列（自由記述。TypeScript型名＋実装状態語彙）	必須	なし	実装状態語彙は「フェーズの状態遷移」節の状態名（未着手／モック試作／定例会レビュー／本番反映済み）を用いる
依存関係	文字列（本表内「機能」列の値、または「依存なし」）	必須	依存なし	依存先は本表に実在する機能名のみを指す
詳細ページ	内部リンク	必須	なし	features/またはredesign/配下の既存slugのみ

依存関係（アイテム → 商社）

flowchart LR
  A[催事] -. 依存なし・独立リリース可 .-> P1((第1弾))
  B[アイテム] --> C["商社（卸）"]
  C -.->|"productModel は任意のID連携<br/>未設定行は itemName 名称一致"| B

WholesalePrice は商品行に任意の productModel（Product.model への ID 連携）を持ち、currentWholesalePriceByModel() で型番引き当てができる。ただし productModel を持たない行（パッケージ全件・型番未設定の商品）は itemName の名称一致に依存する。この併存の扱いは「確認事項」に記載する。
上記の参照関係により、アイテム → 商社の順序は必須である。商社（卸）単独の先行リリースは行わない。
催事は他2モジュールと依存関係を持たず、独立にリリースできる。/events として先行取り込み済みのため、段階リリースの先頭に位置づける。
アイテム内部の Product-Series と、見積・価格表（後続フェーズ）が扱う Manufacturer は名称一致で結ばれている。この階層を正規化しないまま商社・見積が参照を始めると、データ品質リスクが商社側・見積側へ伝播する。正規化は「非スコープ」節の課題台帳へ送る。
決済フローの工程STEPは経理（settlement/approval/prepay/invoice/payment）と発注担当（order/deliver）で担当が分かれる。リリース時は両部署の運用開始を同時に行う。

フェーズの状態遷移（リリース状態）

各機能の実装状況は次の4状態を遷移する。状態名は「機能×フェーズ管理表」「マイルストーン」で実際に使っている表現（redesign/roadmap）をそのまま用いる。

stateDiagram-v2
    [*] --> 未着手
    未着手 --> モック試作: 開発着手
    モック試作 --> 定例会レビュー: モックへ反映
    定例会レビュー --> モック試作: 是正指示（フィードバック）
    定例会レビュー --> 本番反映済み: 概ねOK方向の確認（実装レビュー）
    本番反映済み --> モック試作: 新要件の追加提示
    本番反映済み --> [*]

催事・アイテムは2026-07-22是正まで「本番反映済み」に到達済みである。
商社（卸）は2026-07-29の新要件提示により「モック試作」段階にあり、次回定例会でのレビューを経て「本番反映済み」へ遷移する予定である。時期は「確認事項」を参照する。
「本番反映済み→モック試作」の遷移は、本番反映後に新要件が追加された場合に発生する。商社（卸）は7/22是正範囲（シリーズ・部材/パッケージ）まで本番反映済みだったが、7/29の新要件（卸金額・発注管理・決済フロー・商社別軸）の追加でモック試作へ再突入した。これがこの遷移の実例であり、各機能は単発で完了するのではなく追加要件のたびにこのサイクルへ再突入し得ることを示す。

モックフィードバック方式のシーケンス

段階リリースの各Stepは、要件定義書を先に固めるのではなく、モックへ反映してから定例会でフィードバックを受け反映する運用（redesign/roadmap）で進行する。

sequenceDiagram
    participant Dev as 開発（VE/Ouver）
    participant Mock as モック（crm_app／ve-crm-mock）
    participant Client as クライアント（定例会）
    Dev->>Mock: 要件をモックへ実装・反映
    Mock->>Client: 定例会でモックを提示
    Client-->>Dev: フィードバック（是正／新要件）
    alt 是正・新要件あり
        Dev->>Mock: 反映
        Mock->>Client: 次回定例会で再提示
    else 概ねOK方向
        Dev->>Mock: 本番（ve-crm-mock）へ反映
    end

このフローは2026-07-22是正で確立した運用であり、以降のStepでも継続する。
2026-07-29定例会は「実装レビュー」に該当し、7/22是正分は「概ねOK方向」で確定すると同時に、卸金額・発注管理・決済フロー・商社別軸案件の新要件が提示された。1回の定例会で「レビュー完了」と「新要件提示」が同時に起こり得ることを示す実例である。

マイルストーン（Step構成）

Step	スコープ	Entry条件	Exit条件（受入）	利用者
Step 1 催事	シフト作成〜朝礼報告〜終了報告の一巡	2026-07-22是正の本番反映済み（達成済み）	「受入基準」節の催事シナリオをクリアする	社内（VE）＋代理店
Step 2 アイテム	商品マスタ＋周辺マスタ＋変更履歴	Step 1完了。マスタ画面はMasterScreen（テーブル＋ドロワー＋履歴、サイドバー「マスタ」集約）の定型に準拠する	初期データ投入（型番、実データで確定）＋受入基準をクリアする	社内（VE）
Step 3 商社（卸）	卸金額 → 発注管理 → 決済フロー → 案件化（`DealerIntakeForm`）の順に段階公開する	Step 2完了（型番参照が前提）	`DealerIntakeForm` による案件化まで含め受入基準をクリアする	社内（VE）＋販売店

本番反映は「モック反映 → 定例会でフィードバック → 反映」のフローを踏襲する。このフローは2026-07-22是正で確立し、以降のStepでも継続する。

Step進行の状態遷移

stateDiagram-v2
    [*] --> Step1_催事
    Step1_催事 --> Step2_アイテム: Exit条件クリア（催事シナリオが受入基準に合格）
    Step2_アイテム --> Step3_商社: Exit条件クリア（初期データ投入＋受入基準に合格。型番参照が前提）
    Step3_商社 --> [*]: DealerIntakeFormによる案件化まで含め受入基準に合格

Step 3内部の段階公開順序

Step 3は単一のリリースではなく、卸金額 → 発注管理 → 決済フロー → 案件化（DealerIntakeForm）の順に内部で段階公開する。

flowchart LR
  A[卸金額登録<br/>WholesalePrice] --> B[発注管理<br/>WOrder/WInvoice/WPayment]
  B --> C[決済フロー5種<br/>FLOW/WBucket]
  C --> D[案件化<br/>DealerIntakeForm]

各段階の技術的な公開制御方式（画面非表示・権限ガード・デプロイタイミングのいずれで区切るか）は実装未定義である。現行実装（lib/wholesale.ts・lib/wholesalePricing.ts）は4段階を分離公開する仕組みを持たず、一括で有効な状態にある。「確認事項」に記載する。

受入基準

モジュール	受入シナリオ	合格条件
催事	シフト作成→朝礼報告（`StartReport`: 責任者・緊急連絡先・チェック7項目）→終了報告（`EndReport`: 抽選/着座/アポの総数・両面・片面）が代理店権限で一巡する	`ShiftStatus` 5状態（予定/開始済み/終了済み/未開始/終了未報告）が基準時刻から正しく導出される
アイテム	型番（`Product.model`）主キーの一意性・メーカー必須バリデーション・在庫3状態（潤沢/少/欠品）の切替・フィールド単位の変更履歴（before/after）を記録する	Seriesは履歴対象外である仕様も含めて確認する
商社（卸）	決済区分5種それぞれでFLOW通りに工程が進む（例: 掛売＝settlement→order→deliver→invoice→payment、三社間＝approval→order→deliver→payment）	`WBucket` の遷移と分割入金の残高消込を含めて確認する
権限（共通）	代理店ログインでシフト編集不可・他社シフト非表示・報告のみ可能であることを確認する	否定系テストを必須とする
堅牢性（共通）	ゼロ件・欠損値・長文名称・重複名称（名称一致階層の弱点）でも画面が破綻しないことを確認する	全モジュール共通の受入基準とする

受入基準を支える算出式・ゲート条件

催事：ShiftStatus の導出式

終了報告あり                                  → 終了済み
開始報告あり かつ 現在時刻 ≥ 終了時刻          → 終了未報告
開始報告あり かつ 現在時刻 < 終了時刻          → 開始済み
開始報告なし かつ 現在時刻 ≥ 開始時刻          → 未開始
開始報告なし かつ 現在時刻 < 開始時刻          → 予定

状態は保存値ではなく、EventShiftのstartTime/endTimeと現在時刻から都度導出する（lib/events.ts shiftStatus()）。終了報告があれば時刻に関わらず「終了済み」を優先する。

アイテム：型番一意性・在庫3状態

Product.model（型番）を主キーとし重複登録はできない。型番が変わった場合は別レコードとして扱い、変更履歴は新レコードに引き継がれず分断される（lib/masters.ts・履歴機構はlib/masterKit.ts。詳細はfeatures/item-master）。在庫は「潤沢／少／欠品」の3値で管理する。

商社（卸）：決済区分別FLOWとゲート条件

前金 :  settlement → prepay → order → deliver
掛売 :  settlement → order → deliver → invoice → payment
三社間: approval → order → deliver → payment
カード: approval → order → deliver → payment
その他: settlement → order → deliver → invoice → payment

その他のSTEP列は実装上掛売と完全に同一の配列である。受入基準の確認事項「決済区分『その他』の工程STEPを掛売と同一にしてよいか」は、現行実装が既にこの同一視で動作している事実を仕様として確定するか否かの確認である。

発注可否（canOrder）は、FLOW上でorderより前の全STEPが完了し、かつ未発注であることをゲート条件とする。請求可否（canInvoice）は同様にinvoiceより前が全て完了し未請求であることをゲート条件とする（lib/wholesale.ts wholesaleFlow()）。三社間・カードのapprovalは、承認番号（approvalNo）の入力、または決済条件詳細のローン状態「承認済／実行済」、カード状態「承認済／決済済」のいずれかで完了とみなす（settlementApproved()。後方互換で承認番号単体でも承認扱い）。

分割入金の残高消込

請求ベース = 請求書合計（請求書が無ければ卸金額合計）
残高      = max(0, 請求ベース − 入金合計)

入金合計が請求ベースを上回っても残高は0未満にならない（wholesaleBalance()）。三社間の場合は信販会社→VEの入金（WFinanceReceipt）、VE→仕入先の支払（WSupplierPayment）、VE→販売店の精算（WDealerSettlement）の3つの金銭移動を別エンティティで管理し、精算額はpayout = creditReceived − veShare + adjustmentで算出する。

WBucket（業務ボード分類）の導出

現在未完了の先頭STEPが属する分類をそのままバケットとする（決済待ち／発注待ち／納品待ち／請求待ち／入金待ち）。承認待ち（approval）も「決済待ち」に分類する。全STEP完了で「完了」に遷移する。

堅牢性（ゼロ件・欠損値）の実装済み挙動

wholesaleBalance()はMath.max(0, …)で残高のマイナス表示を防ぐ。
EventShiftはstartReport/endReportが未設定でもshiftStatus()が例外を出さず状態を返す。
未知のロール値はcanSeeNav()がfalseを返し、画面クラッシュではなく非表示に倒す（lib/permissions.tsのフォールバック実装）。

非スコープ（各フェーズへの送り先）

「やらない」ではなく「第1弾ではやらない」項目を、送り先フェーズとともに示す。

非スコープ項目	補足	送り先フェーズ
顧客・商談CRM本体	案件パイプライン・チャット等の本体機能	後続フェーズ（features/crm-core）
見積（ValueOS準拠の価格表/見積モジュール）	features/quote-pricing 参照	後続フェーズ
KPI予実	features/kpi-forecast 参照	後続フェーズ
チャット	案件詳細タブ＋受信箱型画面。顧客・商談CRM本体の実装後に着手する	後続フェーズ
AIエージェント	基本機能確定後に着手する方針	将来フェーズ（features/ai-agent）
催事の個人スタッフ管理	責任者名＋人数のみで管理する。`EventShift` の構造上、将来の個人単位拡張の受け皿は残す	要望が出た時点で検討
アイテムの廃番概念	廃番ステータスを持たない	課題台帳
階層の名称一致の正規化	`Product`-`Series`-`Manufacturer` は名称一致で結ばれており脆い	課題台帳（既知課題）
商社別軸案件と元請（販売店/deals）の統合ビュー	将来の分社化を見据えて意図的に分離する	将来フェーズ（redesign/future-vision）
催事↔商談の突合（channel=催事 & venue=店名 & 日付）	疎結合のままとする。商談CRMが後続フェーズのため、第1弾では突合先が存在しない	後続フェーズ（顧客・商談CRM着手後）

権限（第1弾）

社内（VE）のみがシフトの作成・編集を行う。代理店は自社シフトの閲覧と開始/終了報告のみを行う。個人スタッフ単位の管理は行わず、責任者名＋人数のみで管理する。権限の詳細は redesign/roles・redesign/roles-phase1 を参照する。

ロール別の操作可否（実装根拠：`lib/permissions.ts`）

ロール	催事シフトの作成・編集	催事の開始/終了報告	商社（卸）画面到達	案件・粗利の可視性
管理者	可（`canManageShifts`）	可	全画面（`NAV_ALLOW: "all"`）	全て可視
営業	可	可	不可（`/wholesale`等は対象外）	仕切原価は可視（`canSeeCost`）
事務（BO）	可	可	可（`/wholesale`・`/master-products`等）	仕切原価は可視
発注・申請担当	不可	対象外	不可（`/wholesale`は`NAV_ALLOW`対象外。`/orders`・`/applications`には到達可）	案件閲覧のみ
代理店（管理者）	不可（閲覧＋報告のみ）	可	不可	仕切原価は非表示（`canSeeCost`が`false`）
代理店（メンバー）	不可	可	不可	提案金額も非表示（`canSeeProposal`が`false`）
施工店	対象外	対象外	不可	仕切原価非表示

商社（卸）の工程STEPは担当が分かれる：settlement/approval/prepay/invoice/paymentは経理、order/deliverは発注担当（lib/wholesale.ts STEP_META）。この担当分けはUI上の表示ラベルであり、担当外ロールが操作できないよう制御する認可ガードではない。

未実装の権限ガード

卸金額（WholesalePrice）の登録・編集、WholesaleTaskの作成・アサインは事務（BO）・発注・申請担当・管理者に限定する設計上の想定であるが、現行実装（lib/wholesale.ts）は発注フォーム・案件操作に認証・権限ガードを持たず、社内（VE）担当による代行入力を前提に動作する。DealerIntakeForm（販売店発注フォーム）は外部の販売店が入力する唯一の外部起点だが、アクセス方式（認証なしフォームか専用トークンURLか）は未確定である。これらの制限・認可方式の実装は今後の対応であり、詳細はredesign/roles-phase1を正とする。

画面・操作の挙動

マスタ画面の定型（MasterScreen）

第1弾の全マスタ画面（商品・シリーズ・仕入先・施工店・ローン会社・代理店等）はテーブル＋ドロワー＋変更履歴の定型（MasterScreen）に統一し、サイドバーの「マスタ」に集約する。Step 2のEntry条件はこの定型への準拠を明記している（「マイルストーン」節）。

DealerIntakeForm送信時の挙動（実装根拠：`lib/wholesale.ts`・`lib/wholesalePricing.ts`）

販売店発注フォーム（DealerIntakeForm）の送信はWholesaleCaseを自動生成し、進捗フラグ（settlementConfirmed/paymentReceived/ordered/delivered/invoiced）は全て未完了で初期化される。これによりワークフロー判定は自動的に先頭STEP（決済区分に応じて「決済条件の確定」または「審査OK（承認番号）の確認」）を指し、対応するWBucket（決済待ち）に配置される。明細の品名を卸金額マスタから選択すると、currentWholesalePriceForDealer()が販売店指定価格を優先し、無ければ標準価格へフォールバックして単価を自動引き当てる。マスタ卸価を採用した明細には「マスタ卸価」、単価を上書きした明細には「手入力」のバッジを表示する。

ナビゲーションの可視性

画面到達可否はNAV_ALLOW（ロール→到達可能パスの配列、または"all"）で判定する。未知のロール値はNAV_ALLOWに存在しないためcanSeeNav()はfalseを返し全画面が非表示になる（クラッシュ回避のフォールバック）。代理店（メンバー）は/eventsのみに限定され、催事シフトの閲覧と開始/終了報告以外の画面には到達できない。

エッジケース・異常系

卸価格の反映日タイブレーク：currentWholesalePrice()は反映日が同日の複数行がある場合、卸価格が最も安い行を採用する（実装上のタイブレークルール）。この規則を仕様として確定するか、反映日をまたぐ価格改定の適用ルールと合わせて確認事項に残す。
品名の仕入先非区別：明細のプルダウン選択肢（wholesaleItemOptions()）はitemKindとitemNameの組でのみ重複排除し、仕入先（supplier）を区別しない。同一品名で仕入先違いの卸価格行が複数存在する場合、選択肢は1件にまとまり、価格引き当ては反映日・価格のタイブレークで自動的に決まる行のみが使われる。仕入先を指定して選ぶ導線は無い。
productModel未設定行の名称一致依存：WholesalePrice.itemNameはフリーテキストであり、productModel（Product.modelとのID連携）を持たない行（パッケージ全件・型番未設定の商品）は名称一致に依存する。名称の表記ゆれがあれば価格引き当てが失敗する。
与信枠の自動判定は未実装：Supplier.creditLimit（与信枠）は参照値として保持するのみで、掛売の与信超過を検知する自動判定は無い。
残高のマイナス表示防止：入金合計が請求額を上回っても残高表示は0未満にならない（wholesaleBalance()のMath.max(0, …)）。ただし超過入金そのものの返金・調整処理は未実装である。
未知ロール・欠損データでの非クラッシュ：ロール値がROLES定義外、またはシフトの報告データが未入力でも、canSeeNav()・shiftStatus()は例外を投げず安全側（非表示／初期状態）に倒れる。
型番の重複登録・表記ゆれ：Product.modelは主キーで重複登録はできないが、全角/半角・ハイフン・スペース等の表記ゆれを正規化するルールは未定義である（features/item-masterに既知課題として記載）。
段階公開の技術的裏付けの不在：Step 3内部の4段階公開順序（卸金額→発注管理→決済フロー→案件化）を区切る画面非表示・権限ガード・デプロイタイミングのいずれの機構も実装上は存在しない。現状は一括で有効な状態にある。

確認事項

WholesalePrice ↔ 商品マスタの連結方式（現行実装はproductModel任意のID連携とitemName名称一致の併存。併存のまま仕様確定するか、参照必須へ切り替えるか）
卸価格の反映日をまたぐ価格改定の適用ルール
決済区分「その他」の工程STEPを掛売と同一にしてよいか
受入の実施体制（実施者・合格判定者）
Step 1〜3の公開時期（具体的日付）
催事の3工程（アポ固め）の扱い
卸価格の反映日が同日で複数行ある場合の「卸価格が最も安い行を採用」というタイブレーク実装を仕様として確定してよいか
Step 3内部の段階公開（卸金額→発注管理→決済フロー→案件化）を技術的にどう区切るか（画面非表示／権限ガード／デプロイタイミング）

2026-09-02 スコープ再定義（提案）

9/2 定例会の方向転換（meeting-log 2026-09-02）を受けた再定義案。VE 側の要望は「普遍的な業務だけをしっかり作る／余計なものは付けない／データを取り出せるようにする」の3点に集約される。

再定義の判断軸

軸	内容
残す	変わらないもの＝顧客・契約者の情報、商談の大枠フロー、マスタ、認証・権限
逃がす	変わるもの＝申請の必要項目（テンプレート方式で吸収）、ダッシュボード・評価（作らずデータ抽出で VE 側が自走）
後回し	まだ決まっていないもの＝卸（商社）の業務、見積・価格表

可変性の判定（発言根拠つき）

田中さんが「削る」と言ったのはモジュール単位ではなく「可変になる部分」。この軸で領域ごとに判定した根拠と、その根拠の強さを明示する。

領域	判定	根拠	強さ
A 共通基盤・認証・権限	不変	権限のオンオフは「催事の実装時に都度もらう」＝設定で吸収する既決（8/26）	中（既決からの演繹）
B 顧客・商談	不変	田中「B に関しては変わっても誤差」「ちょこっとこの項目だけ増やす程度」「顧客・契約者の必要情報は変わらない」	強（明言）
C 活動・タスク・架電	不変（推定）	言及なし。営業の日常業務として不変側と判断	弱（推測）
C 申請	可変	田中「申請は年によって必要な項目が全部変わる」	強（明言）
D マスタ群	器は不変・中身は可変	田中「A・B・D だけあればマスタ登録はできる」	強（明言）
E 見積・価格表	後回し	市原「マストではないと感じる部分は第2・第3フェーズへ」。田中は否定せず	中（提案への同意）
F 卸・発注管理	可変	田中「卸の方は結構いろいろ変わりそう。まだやり始めたばかり」／市原「業務部分はまだ分かっていない」	強（明言）
G KPI・予実・評価	可変	田中「ダッシュボードはマジで変わる。評価制度もコロコロ変わる」	強（明言）
H 催事	判定材料なし	可変とも不変とも言及なし。茗荷の「催事まわりも要らないとなると」は条件付きの確認であって、田中の指示ではない	根拠なし
I チャット	不要寄り（可変ではない）	田中「施工店は現場ごとに別の施工管理アプリを使う」＝使われない懸念	中（明言）

可変性は2種類ある（切り分けの実務線）

種類	例	扱い
データが変わる	価格、店舗、代理店、評価の数値、必要書類の組合せ	器を作って吸収する。マスタ化・テンプレート化。改修は発生しない
仕様・フローが変わる	卸の業務そのもの、評価ロジック、申請のフロー	作り込まない。抽出データで VE 側が自走するか、固まるまで保留

田中さんが嫌っているのは後者（変わるたびに数十万から数百万かかる）。前者は「変わること前提の器」なので作ってよい。この線引きが再定義の実体。

実装済みとの突合（重要）

9/2 で「削る」と言われた領域と、実際にまだ作っていない領域は一致しない。crm_next の実装状況は次のとおり。

領域	9/2 の扱い	crm_next の実装状況
A 共通基盤・認証・権限	残す	ログイン画面・共通UI（MasterScreen）実装済み。ロール権限・Google SSO が残
B 顧客・商談	残す（本丸）	未実装
C 活動・タスク・申請	残す（申請はテンプレート方式）	未実装
D マスタ群＋変更履歴	残す	ほぼ実装済み（マスタ11種＋変更履歴＋論理削除、migration 0000-0017）。承認WF・一括CSV が残
E 見積・価格表	第2/3フェーズへ	未実装（先行外で保留）
F 卸・発注管理	保留（業務未確定）	実装済み（案件・発注/納品キュー・売掛・帳票4種PDF・本番反映済み）
G KPI・予実	先行外し（8/26）	ダミー移植のみ
H 催事	外れる可能性	実装済み（シフト・マッチング・確保枠・催事系マスタ4種・本番反映済み）
I チャット	外し可	未実装

再定義後のフェーズ

フェーズ	範囲	備考
Phase 1（コア）	A 共通基盤・認証・権限／B 顧客・商談／C 活動・タスク・申請（テンプレート方式）／L データ抽出（CSV・参照API）／M ファイル保管・アーカイブ／D マスタ残作業（承認WF・一括CSV）／J データ移行／K 工程	9/2 で言う「普遍的な業務」。L と M は 9/2 で新規に起票
Phase 1+（推奨）	Phase 1 ＋ H 催事の残作業	実装済み資産を現場投入（11月末）まで持っていく
Phase 2	F 卸・発注管理（要件確定後）／E 見積・価格表	卸は業務ヒアリング後に着手
Phase 3	G KPI・予実／I チャット	評価制度の変更頻度が高いため最後

可変性の受け止め方（設計方針）

申請書類：様式が年ごとに変わる → 必要書類の組合せをテンプレートとしてマスタ管理し、案件登録時に選択。様式変更を運用側で完結させ、追加開発を発生させない。
ダッシュボード・評価：頻繁に変わる → 作らない。代わりに CSV 出力と参照 API を用意し、VE 側が GAS・BI で自走する（8/26 の「DB直接操作はさせず API・CSV 抽出権限のみ」と同一方針）。
フロー構造そのもの（A の後に B、OK なら C へ）は可変にしない。データ設計から作り直しになるため、大枠不変・細部可変の範囲で作り切る（VE 側も「7〜8割対応できる状態」で合意）。

実装進捗（Phase 1）

領域	状態	備考
A 共通基盤	一部	Google SSO・共通UIは実装済み。5段ロールプリセット／代理店アカウント発行UIは未着手
B 顧客・商談	第1弾実装済（2026-09-10）	世帯／人物／商談／ステータス履歴。詳細は顧客・商談CRM §実装メモ
C 活動・タスク・申請	未着手	申請テンプレートは 9/10 ヒアリング待ち
L データ抽出	一部	マスタ一覧の CSV 出力のみ。顧客／商談の項目選択出力・参照APIは未着手
M ファイル保管	未着手	置き場（Drive 継続 or CRM 側）が未決
D マスタ残作業	閉じた	一括CSV登録は11マスタで実装済み。承認WFは卸価格向けに実装済み（案1では対象なし）
J データ移行	未着手

見積（Atsurae）

VEC003 CRM 再定義スコープ開発見積（9/2方向転換版・普遍業務コア） に3案で登録済み。単価は 9/2 の値下げ提示を継承して 6,500円/h、係数はレビュー20%・PM15%（K工程はPMのみ）。

案	範囲	工数	金額
案1 コア	Phase 1 のみ	692h	¥5,926,700
案2 コア＋催事引渡（推奨・主案）	Phase 1 ＋催事残作業	748h	¥6,397,300
案3 コア＋催事＋卸	＋卸の残作業（参考・要件確定後）	812h	¥6,938,100

旧見積（1,288h / ¥12,765,000）比で、案2 で約 50% 減。助成金 400万を充当した場合の実質負担は案2 で約 240万。案1 は 600万を下回る。

第2版で直した2点

K 工程別追加工数を案ごとに按分：結合テストとレビュー対応は範囲に比例するため、案1は40h/32h、案2は48h/40h、案3は56h/48h とした。デザインとデプロイは新規画面が B・C のみ（催事・卸は実装済み＝デザイン済み）かつ環境は1つのため、案によらず固定。
B を「普遍」だけに圧縮（176h → 140h）：商談はレコード・進捗ステータス・履歴までが普遍で、カンバンUIは見せ方＝可変のため後続へ（56h → 36h）。顧客詳細はタブ数がPhase1範囲に限られるため 32h → 24h。名寄せ（統合・マージ）は運用が固まってからで、登録時の重複警告のみ残す（16h → 8h）。