ロードマップ

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

概要

新CRMは第1弾（催事・アイテム・商社）→後続フェーズ（顧客・商談CRM本体・見積/価格表・KPI予実・チャット/通知・データ移行）→将来構想（AIエージェント・業務自動化、SaaS化・分社化）の三段で展開する。開発は要件定義書を先に固める方式ではなく、モックへ反映して定例会でフィードバックを受け反映するMockフィードバック方式で進めており、決定事項の正本はredesign/meeting-logである。

本ページは各段の成果物・前提となる前段成果物・フェーズ間の依存関係を1画面で見渡すための横串ビューである。各領域の詳細は個別ページ（redesign/scope-phasing、redesign/valueos-gap、featuresディレクトリ配下の各ページ）を正とし、本ページでの重複記載は最小限にとどめる。

フェーズ構成

フェーズ	主題	主要成果物	前提となる前段成果物	状態
第1弾	催事	シフト作成〜朝礼〜終了報告の一巡（`/events`）	なし（独立リリース可）	本番（ve-crm-mock）へ反映済み
第1弾	アイテム	価格を持たない商品マスタ＋周辺マスタ	催事と独立	本番（ve-crm-mock）へ反映済み（7/22是正まで反映）
第1弾	商社（卸）	卸金額登録・発注管理・決済フロー5種（前金/掛売/三社間/カード/その他）・商社別軸案件管理	アイテムに依存	試作（crm_app）で実装確認済み。本番反映は次回定例以降
後続①	商談CRM本体	案件パイプライン・世帯360度ビュー・活動/架電ログ・タスクボード	第1弾（催事＋アイテム）	試作（`lib/crm.ts`）で実装確認済み
後続②	見積・価格表	価格表・見積書出力（PriceBook/Part/SalesPrice/quotes）	商談CRM本体＋アイテム	試作で実装確認済み
後続②	KPI予実	予実ダッシュボード（営業マンマスタ/予算/実績）	商談CRM本体＋見積の成立データ	未着手（現行はExcel運用）
後続③	チャット・通知	CRM内一元化＋Slack通知	商談CRM本体	定例会で方針合意済み
後続③	データ移行	既存BT社DB→新DBの一括移行（申請系は先行納品）	全後続モジュールの横断前提	定例会でスケジュール確定済み
将来①	AIエージェント・業務自動化	中間やりとりAI化・商社明細スキャン取込・太陽光設計自動化	後続フェーズ完了（基本機能確定）	定例会で構想提示済み・未着手
将来②	SaaS化・分社化	代理店向けSaaS提供・商社機能の分社化	後続フェーズ完了＋事業判断	定例会で構想提示済み・未着手

フェーズ全体マップ（相関図）

催事とアイテムは独立に第1弾を構成し、商社はアイテムに依存する。商談CRM本体は催事とアイテムを前提に立ち上がり、見積・KPI予実・チャットの起点となる。データ移行は全後続モジュールの稼働開始時期を拘束する横断前提である。

flowchart LR
  EV[催事] -. 独立リリース可 .-> P1done((第1弾))
  IT[アイテム] --> WS[商社・卸]
  IT --> CRM[商談CRM本体]
  EV --> CRM
  CRM --> QP[見積・価格表]
  CRM --> KPI[KPI予実]
  QP --> KPI
  MG[データ移行] -. 横断前提 .-> CRM
  MG -. 横断前提 .-> QP
  MG -. 横断前提 .-> KPI
  MG -. 横断前提 .-> CH[チャット・通知]
  CRM --> AI[AIエージェント/自動化]
  QP --> AI
  KPI --> SAAS[SaaS化・分社化]
  CRM --> SAAS

第1弾: 催事・アイテム・商社

催事＝event-shift-systemを/eventsとして取り込み、本番（ve-crm-mock）へ反映済み。
アイテム＝価格を持たない商品マスタ。7/22是正（催事会社マスタを代理店へ統合、店舗/催事会社のカテゴリ属性、商品登録のメーカープルダウン化、シリーズマスタ新設、部材＋パッケージの必須/選択必須/オプション区分）まで本番へ反映済み。
商社（卸）＝7/29新要件（卸金額登録、発注管理、決済フロー5種（前金/掛売/三社間/カード/その他）、商社目線の別軸案件管理）を試作（crm_app）に実装。本番反映は次回定例以降。
順序制約: WholesalePriceが型番参照構造のため、アイテムを商社より先に構築する。商社単独の先行リリースは行わない。
後続フェーズへの引き継ぎ課題: WholesalePrice.itemNameのフリーテキストが商品マスタと未連結であること、Product-Series-Manufacturer間の名寄せが名称一致処理であることは、後続フェーズのデータ品質前提に影響する。
詳細はredesign/scope-phasing、決定経緯はredesign/meeting-log、機能詳細はfeatures/events・features/item-master・features/wholesale・features/wholesale-settlementを参照する。

後続フェーズ①: 顧客・商談CRM本体

lib/crm.tsに主要データ構造を試作済み: Deal（channel＝訪問販売/催事/反響/パートナー、venue＝催事場所）、Household（顧客・世帯）、活動ログ、架電（前確）、申込、タスク（前確/太陽光調査設計の工程）。
成果物: 案件パイプライン画面・世帯360度ビュー・活動/架電ログ・タスクボード。第1弾のマスタ画面定型（MasterScreen: テーブル＋ドロワー＋履歴）を踏襲する。
催事と商談の突合（channel＝催事かつ venue＝店名かつ日付）は、第1弾では突合先が存在しないため疎結合のままとする。本フェーズ着手後に接続する。
依存: 第1弾のアイテム（商品マスタ）と催事データを前提とする。本フェーズは見積・KPI予実の前提となる（見積・KPI予実はDealへの紐付けを想定する構成であり、Quote.dealIdは任意）。
パイプラインのステージ定義・権限設計・既存業務フローとの突合粒度は未着手であり、確認事項に記載する。
詳細はfeatures/crm-core、権限設計はredesign/roles・redesign/roles-phase1を参照する。

後続フェーズ②: 見積・価格表とKPI予実

モジュール	状態	主要データ構造	依存する前段
見積・価格	試作で実装確認済み	`PriceBook`（仕入先/催事×メーカー×件名×反映日）＋`Part`{retailPrice(希望小売)/netPrice(仕切)/tier(必須・選択必須・オプション)}＋`PackageSet`{setPrice}、`SalesPrice`{productNo×channel×price×反映日}→`currentSalesPrice`で現在価格を導出、`Manufacturer`・`quotes`まで試作済み（`quotes`はDealへの紐付けを想定するが`Quote.dealId`は任意）	アイテム＋商談CRM本体
KPI予実	未着手	営業マンマスタ（インセンティブ等級）／予算テーブル／実績テーブル／ダッシュボードの4点構成	商談CRM本体＋見積の成立データ＋商社（卸）の発注/請求/入金のエンティティ化

価格の保有方針: 価格・仕切・販売価格を含む関連マスタはCRM側で保持する（2026-07-17に方針確定）。jouken（条件マスタ）とは将来API連携で整合を取る。
KPI予実の現行運用: 営業マン別シートにM1/M2行（売上/名目粗利/実質粗利/営業利益(税抜)/インセンティブ反映率/金額）、部署・事業部集計、Q目標設定、等級表（反映率）をExcelで運用している。本番DBに予算・実績テーブルは存在しない。
依存: 見積はアイテム＋商談CRM本体を前提とし、KPI実績は商談/見積の成立データを前提とする。第1弾の卸金額（WholesalePrice）との価格体系整合は未着手であり、確認事項に記載する。加えて、KPI予実の予実（発注・請求・入金の実績反映）は商社（卸）側の発注/請求/入金がエンティティ化されて初めて成立する構成であり、第1弾時点では商社（卸）の発注管理・決済フローは試作段階のためこの依存は未解消である。
詳細はfeatures/quote-pricing・features/kpi-forecastを参照する。

後続フェーズ③: チャット・通知とデータ移行

チャット: CRM内一元化＋チャット→Slack通知（DM/チャンネル）を実装する。メンバー追加は招待制とし、質問窓口として運用を開始する。リアルタイム化は将来Pusherを採用する方針である。詳細はfeatures/chat-collab。
データ移行スケジュール: 12月末に本丸（第1弾〜後続フェーズ）を納品し、12月に研修・検証、1月に完全切替を行う（2026-07定例で確定）。移行データは年末休業中に既存BT社DBから新DBへ一括移行する。
申請系（case_registration_requests等）は独立業務であるため、一括移行の例外として先行納品する（先方合意済み）。
移行は後続フェーズ全体の横断前提であり、年末の移行時期が他モジュールの稼働開始順序を拘束する（前掲のフェーズ全体マップを参照）。
移行リハーサルの回数・切替判定基準・並行稼働期間の有無は未着手であり、確認事項に記載する。
詳細はredesign/migration-planを参照する。

将来構想①: AIエージェント・業務自動化

2026-07-29定例で提示した構想群: 中間やりとりのAIエージェント化、商社明細スキャン→自動取込、業務可視化ツールのテスト導入、Jクレジット対応。
太陽光設計の自動化は課題定義まで具体化している: 図面読取→寸法算出→入力工程を自動化する。現行は都度手作業で図面から寸法を算出しており、属人化が課題である（実データで確定）。
着手方針: 第1弾＋後続フェーズの商談CRM本体を確定させた後に着手する（定例会で合意済み）。フェーズ全体マップにおける本構想のEntry条件である。
各構想の前提データ: 商社明細スキャンはWholesaleCase、設計自動化はDeal/申込を土台とする。第1弾・後続フェーズの成果物が将来構想の土台となる構造である。
詳細はfeatures/ai-agent・redesign/future-visionを参照する。

将来構想②: SaaS化・商社機能の分社化

方向性（2026-07-29言及）: 本CRMを代理店にも提供してSaaS化する。代理店には無料提供する（アライアンス条件で実質必須利用）。自社導入は課金する。商社機能は分社化を視野に入れる。
第1弾で商社別軸案件と元請（販売店/deals）を意図的に分離した設計は、将来の分社化を見据えた判断である。
SaaS化の技術前提（マルチテナント・権限分界・課金）は未着手であり、確認事項に記載する。
Entry条件: 後続フェーズの完了と事業判断。想定時期は置かず、条件駆動で管理する。
詳細はredesign/future-visionを参照する。

フェーズ間依存関係

成果物（依存する側）	前提となる成果物	依存の内容	前提が崩れた場合のリスク
商社（卸）	アイテム	`WholesalePrice`が型番参照構造	商社単独リリース不可、卸金額登録ができない
商談CRM本体	第1弾（催事＋アイテム）	`Deal`のchannel/venueが催事・アイテムのマスタを参照	突合先マスタが揃わずDeal生成が手作業化する
見積・価格表	商談CRM本体＋アイテム	`quotes`はDealへの紐付けを想定（`Quote.dealId`は任意）、`Part`が商品マスタを参照	見積の紐付け先が無く単票運用に戻る
KPI予実	商談CRM本体＋見積の成立データ＋商社（卸）の発注/請求/入金のエンティティ化	実績テーブルは成約・売上イベントに加え商社側の発注/請求/入金実績から積み上げる	実績が手集計のまま、ダッシュボードが空になる。商社側エンティティ化が未了だと商社起因の予実が反映できない
全後続モジュール	データ移行	年末一括移行が他モジュールの稼働開始時期を拘束する	移行遅延が商談CRM本体以降の稼働開始を全て後ろ倒しにする
決済フロー運用（商社）	経理＋発注担当の同時運用開始	組織側の運用開始タイミングの一致が必要	片方の運用開始が遅れると発注/請求フローが機能しない
将来のAI・SaaS化	後続フェーズ完了	「基本機能確定後に着手」の合意	前段が不安定なまま着手すると自動化対象が固まらない
後続フェーズ全体（データ品質）	第1弾の名寄せ（`Product`-`Series`-`Manufacturer`）／`itemName`未連結	商社の卸金額・将来のOCR取込元となるデータ品質	名寄せ誤りが商談CRM・見積に伝播する

確認事項

商談CRMパイプラインのステージ定義・権限設計・既存業務フローとの突合粒度
KPI予実の予算・実績テーブル設計（現状Excel運用の再現方針を含めて未着手）。商社（卸）の発注/請求/入金のエンティティ化が前提となるが、第1弾時点では試作段階であり未解消
第1弾の卸金額（WholesalePrice）と見積・価格表の価格体系整合
データ移行リハーサルの回数・切替判定基準（Exit条件）・並行稼働期間の有無
SaaS化の技術前提（マルチテナント・権限分界・課金）
商品区分（種別）を商品登録から外すか（2026-07-22定例、実装では残置のまま）
WholesalePrice.itemNameのフリーテキスト未連結、Product-Series-Manufacturerの名寄せ方式が後続フェーズのデータ品質に与える影響