定例会・意思決定ログ

このページは、VE社との定例会（P1〜P5ヒアリング）と、その内容を CRM モックへ反映する過程で確定した意思決定を時系列で残す記録です。要件定義書ではなく Mock フィードバック方式で進めているため、「決まったこと」はコードとこのログが正になります。

進め方の前提

要件定義書を先に固めるのではなく、モックに反映 → 定例会でフィードバック → 反映を繰り返す方式で先方合意済み。したがって未確定事項は「次回確認待ち」として末尾に明示し、勝手に仕様を足さない方針。

タイムライン

時期	種別	要点
2026-07-08	フロー意思決定（P1〜P3＋申請の反映）	ステータス体系・チャンネル・チャット・運営マスタ・権限・モバイルを確定
2026-07	定例会（P4/P5ヒアリング）	12月納品→1月切替のスケジュール、完工書・入金の業務理解、先方待ち物4点
2026-07-15	定例会（モックレビュー）	見積書ひな形・商品/部材マスタ（仕入先別×時間軸）・段階リリース（催事/商社先行）・Slack通知/ログイン確認・保証確認
2026-07-22	定例会（催事・卸の是正）	催事会社→代理店に統合／権限（代理店は報告のみ）／報告拡張（写真・チェック編集・数値表示）／シリーズ・部材/パッケージ区分
2026-07-29	定例会（実装レビュー＋新要件）	卸金額（販売店向け卸価格）登録／発注管理（フォーム→案件化・決済フロー4種）／商社目線の別軸案件管理／ValueAuth 参照
2026-08-19	定例会（先行スコープQ&A：催事中心Q1〜33）	先行範囲=催事＋アイテム＋卸で確定／設計書(10月中)を正・11月末に現場投入・9-30実装完了目標／卸は現行運用が正で踏襲＋フロント改善／店舗・代理店マスタ拡張・一括CSV・希望店舗ヒアリング自動マッチング・担当ロールすり替え設計
2026-08-20	定例会（先行スコープQ&A続き：アイテム＋卸中心）	phase1版URL＋質問シート運用／商品マスタ確定（型番＝主・自社コード発行可・廃盤は新規登録・6区分＋その他・必須=メーカー+型番）／メーカー正式名称・締め日・支払いサイト／与信枠は全データ投入前提で現状値不要／施工店はマスタのみ・ローン会社に担当/FAX等／在庫は個数手入力（自動減算なし）／卸決済4種でValueOS基準に寄せる・自社発注も将来統合／マスタ承認ワークフロー（ユーザーベース・OR・管理権限が設定）／変更履歴フィールド単位・論理削除統一・データ移行は一括登録
2026-08-26	定例会（phase1モックレビュー・キックオフ＋権限/連携/データ方針）	最新の催事周り(phase1)を実運用視点で触って質問シートに記入する運用／Googleログイン(GCP OAuth)導入=GCP権限を付与・社内80人@valueecology.jpは全員Googleあり／代理店アカウント発行UIはVE側で／権限は5段ロールプリセット＋カスタム・催事実装時にオンオフ指定／代理店マスタは加盟店シート前提で必須/任意フラグ／KPIダッシュボードは先行から外し後回し（頻繁に変わる／基本の状況表示は出す）／DB直接操作はさせずAPI・CSV抽出権限のみ／施工店探し等はAI別枠・費用/助成金は契約側
2026-09-02	定例会（見積レビュー → スコープ方向転換）	見積の金額ロジック（人月×工数）説明／「業務は毎月変わる」前提でSaaS vs スクラッチを再検討／開発範囲を「普遍的な業務（顧客・契約・申請の大枠）」だけに絞る方向へ転換＝見積・価格表は第2/3フェーズ、卸は保留、催事も先行から外れる可能性／DBを参照・抽出できる状態が最重要／チャットは外し可（自動化を諦める前提）／Ouver ボールで見積作り直し・質問整理・モック反映
2026-09-09	定例会（再見積の提示 → 案1 コアで決定＋進め方の合意）	再見積3案を提示し案1 コア（¥5,926,700）で決定＝催事・卸は範囲外／データ抽出・参照API・ファイル保管を含む／要件定義は市原主導、田中は出来たモックの確認役・定例は「業務フロー→設計」の照合説明・現場担当者は田中がピックしてスポット参加／9/10 14:30 申請業務ヒアリングに同席／助成金は契約未着手（社労士要・1プラン40万・リスク認識）

---

2026-07-08 ｜ フロー意思決定（P1〜P3＋申請業務の反映）

P1〜P3＋申請業務のヒアリングをモックへ全範囲反映した際の確定事項。

案件ステータスの再設計

• パイプライン（アポ→前確→商談→成約→工事→完了）＋独立軸に分離。
• サンキューコール・ローン審査・審査確認コール・団信は postContract、施工フラグは construction、申請は applications として別軸で保持（旧スプレッドシートの列混在を解消）。
• 保留・失注はパイプライン外の状態として扱う。

チャンネル（商流）

• 4種：訪問販売／催事／反響／パートナー。
• テレマは現状未実施のため除外。
• 反響の大元媒体（タイナビ等）は hankyoMedia で別項目管理。

表記の是正

当初「ホーム販売」としたが、ユーザー指摘で「訪問販売」に是正（資料の併記表現に引っ張られない）。前確も「マエカク」表記をやめ、ヒアリング原文どおり「前確」に統一。

チャット

• 案件詳細タブ＋**独立した受信箱型画面（/chat）**の両方を実装。
• 案件×相手スコープでルーム分割（社内／施工店／代理店）。参加者はルーム単位で固定＝ロール権限と一致。
• 自動作成はイベント連動（成約→社内＋（代理店案件なら）代理店、工事→施工店）。
• 受信箱UIは**A-2（アバター・メッセンジャー風）**を採用。案件1行＋アバター＋未読太字、ルームは会話ペイン上部の下線タブ。3階層リスト案は不評のため、/patterns に複数案を実装して見比べて決定（この「サンプルに実装して比較」進め方が好評）。

新規画面

• /calls（架電ボード・担当割振）
• /orders（発注・納期マスター）
• /applications（書類マスター照合・印鑑証明90日期限ソート）

運営マスタ（/masters）

• 商品（型番＝主キー・納期/在庫統合）・仕入先・ローン会社（2社間/3社間の入金営業日数）・施工店（ツール/エリア）・代理店を管理（管理者・事務のみ）。
• 価格・仕切りは jouken（条件マスタ）側の管轄として CRM には持たない旨を画面に明記。
• 催事の店舗/会社マスタは /events 側。

権限・通知

• 表示ロール切替デモ（管理者／営業／事務BO／発注・申請担当／代理店／施工店）。代理店＝自社経由のみ＋仕切粗利非表示、施工店＝施工タブ＋チャットのみ。lib/permissions.ts が正本。
• Slack通知は lib/notifications.ts に23イベント×宛先3系統（担当DM／機能ch／顧客ch）のマトリクス。設定画面でON/OFF。※2026-07-08時点は17件、以降のP4/P5・催事反映で追加され現在23件。

誤操作ガード・前確自動化

• 基本は取消トースト（元に戻す）。外部作用（失注＝理由必須・発注・FAX・依頼書送付・前確NG）だけ確認ダイアログ。
• 新規案件で前確タスクを自動生成、割当でアポ→前確、OK→商談／NG→失注（架電ボードとタスクカードで挙動統一）。

足さない方針

自動割当は廃止。ヒアリング原文（1.4「一覧を見て人が割り振る」）に沿い、タスク依頼も手動選択＋未完タスク数表示に変更。ドキュメントにない機能を勝手に足さない。

モバイル対応（営業はモバイル前提）

• 全画面レスポンシブ、ブレークポイント md(768px) 統一。
• <md はサイドバー非表示＋下部タブバー（ホーム/案件/チャット＋その他Sheet）。一覧はカードリスト化、架電ボードは tel: タップ発信、チャットは一覧⇄会話の2画面切替。

---

2026-07 ｜ 定例会（P4/P5ヒアリング）

スケジュール（確定）

• 12月末に本丸（P1〜P5）納品 → 12月に研修・検証 → 1月完全切替。
• データ移行は年末休業中に実施。基本は一括移行だが、申請系は独立業務のため先行納品を検討（先方合意）。

業務理解（モック反映済み）

• 完工書 ＝ 顧客サインの工事完了証明。ローン会社へ提出することが入金の条件。立会なしはレターパック送付→完工コールで督促→原本回収→PDF化。
  • 完了報告（施工店）とは別物（当初は誤って結合していた）。
• 入金：現金一括／半金／ローン。ローンは 2社間（完工書到着＋3営業日）／3社間（商社売掛経由＋6営業日・金額は同じ）。頭金は顧客から直接。
  • 入金予定の可視化が経理の最大の痛点。
• 工事日調整 → 発注の順序（工事日が決まらないと発注できない）。納品確認欄は作らない（連絡がなければ納品済み、が業務）。
• 経理は バクラク＋成約顧客一覧＋経理専用シートの3重入力が常態。

先方からの待ち物（4点）

1. 納期回答メールのサンプル
2. 契約書類フォルダの完成形
3. 経理2シート
4. 新作催事アプリのリポジトリ（搭載要望は /events で先回り済み）

---

2026-07-15 ｜ 定例会（モックレビュー：見積書・商品/部材マスタ・段階リリース）

Ouver（茗荷・市原）× VE（田中翔也）。共有済みモックを田中が試用した前提でのフィードバック回。永続化（保存）は未接続のため、この日は「動きの確認」と要件の詰め・宿題出しが中心。生の文字起こしは _archive/raw-text/20260715_定例会_文字起こし(tldv).txt（自動音声認識・誤認識あり）。

この回の位置づけ

確定というより 要件の詰めと宿題出し が主。永続化未接続で入力データは保存されない旨は共有済み（動作確認は「打ち込みながら見る」でOK）。細部は次回、実サンプル受領後に確定する。

見積書（見積もり）

• 商材追加 → 見積もり出力について、VE側に既存の見積書ひな形あり。→ 田中が書式を送付（宿題）。
• 以前の GAS版と同形式か を確認軸に。理想はワンタッチでダウンロード。

商品／部材マスタ（この回の主題）

• メーカー・商社（仕入先）ごとに仕入価格が異なる。同じ部材名でも価格が違うため照合が必要。
• 部材から登録し、部材を組んだ パッケージ単位で発注するのが基本。ただし「パッケージが違う／パッケージが無い（部材だけ）」パターンもある。部材は番号（1番・2番…）で識別。
• 発注前に施工店が現地調査し、数量が変動（例：ケーブル 20m→40m）。必須部材もある。
• 価格は時間で変わる（週単位）→ 商品/部材マスタも 反映日を持つ時間軸マスタにする（条件マスタと同じ考え方）。「◯月◯日からこの値段」で自然切替。
• 将来的に 商社から届く明細をスキャン→自動取り込みしたい（手入力が重い）。これは商社機能にもつながる。
• → Ouver: 商品/部材マスタ画面のたたき台を次回までに作成。VE: 部材・パッケージ・価格の実サンプルを共有（宿題）。

店舗／催事会社マスタ（催事運営）— カテゴリ属性（14〜16分）

• 田中「（反映日と）8種類が同じ」「絞れるようにしときたい」→ 店舗マスタ・催事会社マスタにカテゴリ（分類）属性を持たせ、カテゴリで絞り込めるように。
• 店舗のカテゴリは系列/チェーン（カインズ／島忠ホームズ／ビバホーム 等、〜8種類）が想定。催事会社は種別（実演販売／販促 等）。※値は仮置き・実データで確定。

方針更新 2026-07-17：価格は CRM で持つ

当初は「価格・仕切りは jouken（条件マスタ）側の管轄」としていたが、関連マスタ（価格・仕切・販売価格を含む）は CRM 側で保持する方針に更新。価格は価格・見積ドメイン（価格表 / 仕切〔原価 jusetsu〕/ 販売価格）が持ち、jouken とは将来 API で整合を取る。旧「CRM には持たない」の画面注記・コード注記は撤去済み。

段階リリース（部分導入）

• 田中の要望：①商社機能 ②催事管理 を先行して”動くように”進めたい。→ 茗荷「部分的な先行リリースは可能」。
• 催事管理＝ /events（催事アプリ取り込み） の本実装を先行で進める方向。※実物リポジトリ（催事シフトアプリ）受領済み。既存 /events との突合は別途。

AIエージェント

• 先方は別件（別ベンダーとの打合せ）で 中間やりとりをエージェントに任せたい意向。茗荷「AI導入は可能。まず基本機能を固めて将来的に」。
• （既存オープン事項「AIエージェント売り込み／部分利用相談」が具体化）

運用：チャット・通知・ログイン

• 一元化。メンバー増加時は招待でOK。
• チャット → Slack通知（DM／チャンネル指定可）。通知起点でチェックする運用。設定方法は Ouver から案内。
• 田中にログイン確認を依頼。チャットを質問窓口（「これはこういう解釈？」等）として運用開始。

支払い・保証（商社/催事の入金リスク）

ASR不明瞭・要確認

この区間（終盤）は自動文字起こしの精度が低く、以下は要確認の暫定メモ。

• 仕入先への支払い時期をできる限り後ろ倒ししたい／受け取れないリスクを回避したい、という論点。
• 「スノー（Snow?）は 5% でもOK」だが安すぎる懸念。対応しても（補助金/受注等が）受給されなかった場合の保証をどうするか → Ouver が確認して共有（宿題）。

この回の宿題

担当	宿題
VE（田中）	見積書ひな形の送付／部材・パッケージ・価格の実サンプル共有／モック試用フィードバック・ログイン確認
Ouver	商品・部材マスタ画面のたたき台作成／Slack通知の設定案内／未受給時の保証条件の確認・共有
方針	催事管理（/events）・商社機能を先行して本実装へ。AIエージェントは将来

---

2026-07-22 ｜ 定例会（催事の代理店統合・権限・報告／卸のシリーズ・部材/パッケージ）

催事（先行リリース）と卸・価格の是正を確定。以降 CRM モックへ全反映済み（本番 ve-crm-mock）。

ASR補正

逐語録は tldv/自動文字起こしのため用語崩れあり（催事→「最事/サイジ」、訪販→「法犯」、一次店/二次店→「一重系/二重家」、バリューエコロジー→「プレーエコロジー」等）。以下は文意で補正。

催事：代理店マスタに一本化

• 「催事会社」マスタを廃止し「代理店（販売店）」に統合。代理店の中に催事をやる会社も訪販をやる会社もいるため分ける必要がない。**事業区分（催事／訪販／催事・訪販）**で分類。
• シフトの旧「催事会社」欄＝代理店（販売店）名。店舗（開催場所＝カインズ○○店 等）は別概念。
• 商流の実態：量販店（カインズ／島忠／コメリ 等）＝アライアンス先。その下に VE が一次店、さらに下に代理店＝二次店。VE の責務は二次店（代理店）の管理。

催事：ロール・権限

• アカウントは人ごと。代理店の中に管理者／メンバーの2ロール（利益率・顧客情報を全メンバーに見せたくない）。今回の範囲では機能差はほぼ無し（枠だけ用意）。
• シフトの作成・編集は VE（社内）のみ。代理店は自社の催事だけ閲覧・開始/終了報告のみ。

催事：報告の拡張

• 報告に写真添付（ドライブ保存は今回見送り）。朝礼チェック項目を画面から編集可能（項目内容は別途 VE 送付）。終了報告の数値（抽選/着座/アポ）を一覧表示。
• 将来：終了報告のアポ → フォーム → 案件化 →「この店舗でこの日にリード獲得」と紐付け（ゆくゆく）。

卸・価格

• 商品登録のメーカーをプルダウン参照化。シリーズ項目＋シリーズマスタ新設（例：UFOシリーズに2商品）。検索で「UFO」ヒット。商品登録の列＝メーカー/シリーズ/商品名/型番/容量。
• 部材から1件ずつ登録＋パッケージ登録（標準構成部材のまとまり）。パッケージ内で部材ごとに区分（必須／選択必須／オプション）＋数量を指定 ← この回の主眼。ValueOS（クライアント自作プロトタイプ）は package を製品構成として持ち部材分解しないが、当事者の言葉（7/15・7/22）が正＝部材＋区分。
• 価格表の取込は手打ちで開始（PDFパターン膨大。将来 AI-OCR）。マスタUIは数パターン作って選ぶ。

実データ・要確認

• VE：代理店データ・店舗データをリスト提供（→店舗は 7/29 時点で 276 店投入済み）。
• 商品区分（種別）を商品登録から外すか：発言は「価格表区分だけでよい」。種別は CRM 横断で使うため実装では残置＝要確認。

---

2026-07-29 ｜ 定例会（実装レビュー＋新要件：卸金額・発注管理・決済フロー・商社別軸）

7/22 の是正（代理店統合・権限・報告・店舗・シリーズ・部材/パッケージ）を 実装レビュー（概ね OK 方向）。以降は 卸（商社目線）の管理が主題。

卸金額の登録（新規）

• 商品・パッケージはどの商社から引くか（仕入先）で仕入価格が違う → 商品/パッケージ × 仕入先の紐付けが必要。
• さらに VE は販売店へ卸す → 販売店向けの卸金額（各商品・各パッケージ）を登録したい ＝ 販売価格（卸価格）マスタを追加。

発注管理（新規・本命）

• 販売店から発注書が届く → フォーム入力（販売店が実施）→ CRM に案件化が理想（VE の転記作業をなくす）。
• 決済フローで発注・請求のタイミングが変わる（4種）:

決済	発注タイミング	入金
前金	入金後に発注	発注前に全額（VE のリスク最小／販売店はCF悪化）
売りかけ	与信枠内で先に発注	後日。会社ごと与信上限（2000万〜1億）
3社間（親決済）	審査OK（承認番号）確認後に先発注	工事後、ローン会社→VE。飛ばれない・速い
カード決済	3社間同様に先発注	カード会社→VE。飛ばれない

• 要件＝「この案件はいつ発注・請求すべきか」が一目で分かること（取引先100社・月1000案件で属人管理は破綻）。

商社目線の別軸案件管理（新規）

• 現行の案件管理は販売店目線（元請け）。商社（卸）は勝者目線で管理項目が異なる → 別軸の「商社/卸」案件管理を用意（将来の分社化も視野）。
• 参照：ValueAuth（クライアント自作。GitHub/Vercel で共有・更新中）に案件・受注・請求・入金・タスクの5本柱イメージが詰まっている。ValueOS ともども突合対象。

表記について：ValueAuth

定例会当日は「ValueAuth」と呼称されたが、その後 GitHub 実体を確認した結果、5本柱（案件／受注／請求／入金／タスク）の構成が一致することから同一システムは ValueOS の呼称で確認済み（valueos/overview・valueos/data-model 参照）。表記ゆれとみられるため以降の資料では ValueOS に統一するが、本記録は当日の発言のまま残す。

将来構想（メモ・実装は 12 月の CRM 完成後）

• SaaS 化：代理店には無料提供（アライアンス条件で実質強制利用）、自社導入は課金。太陽光設計の AI 自動化、J クレジット、業務可視化ツールのテスト導入。
• リスキリング（社労士・研修会社選定）は継続。

---

2026-08-19 ｜ 定例会（先行スコープQ&A：催事中心）

先行リリース範囲（催事＋アイテム＋卸）を確定させるための質問事項 Q1〜Q33 に、VE側から回答を得た回。生の文字起こしは _archive/raw-text/20260819_定例会_文字起こし.txt（自動音声認識、正本は本節）。

進め方・合格基準の合意

• 週1回の定例＋随時回答で「確認→反映」のチェックを回す。
• 合格基準＝業務が回ること。そのうえで 10月中に確定する「設計書」を正義とし、明記されている部分を責任範囲とする（設計の共有・承諾を記録し、後日の齟齬を防ぐ）。追加機能は範囲外になり得る／「思ってたのと違う」が修正なのか追加機能なのかは設計書で判断する。
• 11月末に一旦現場投入してチェック、修正はバッファ期間内で消化可否を判断。先行実装完了は9/30目標。本番データで運用する。

卸（商社）の方針

• クライアントが ValueOS を実運用しながら改善中で「ほぼ完成・使用中」。現行運用（データの流れ・業務フロー）が正としてそのまま踏襲する。
• ただし ValueOS のフロント実装は1ファイルが数千行級に肥大化し保守性が低いため、Ouver 側で共通化等のフロント改善を行う（裏側のバックエンドは堅牢と評価）。
• 卸は「正解が現状出ている」領域のため、それを基準に進め、他の質問事項を優先的に回答してもらう方針。

先行スコープ確定（Q1〜5）

• 範囲＝催事＋アイテム（商品マスタ）＋卸（商社・発注）で確定。顧客・商談・見積・KPIは後続。
• 対象ユーザー＝社内（本部管理者／社内営業／経理／発注担当）＋外部（代理店＝管理権限者ロール、催事スタッフ＝そのメンバーの2パターン）。

催事の確定事項（Q6〜33の要点）

• 単位＝日×店舗×代理店（自社もあり得る）。同日同店舗での複数催事・複数代理店はなし。
• 店舗マスタに 電話番号／責任者／メモ を追加。系列・カテゴリをマスタ化し、全マスタにCSV一括登録を用意。
• 代理店マスタは加盟店契約シート準拠で項目を大幅拡張（いらない項目も一旦保持）。代理店ロールのログイン（外部招待）が必要、約40社に個別アカウントを発行。
• シフトはVEが登録し代理店は登録しない。一括登録＋個別修正が可能。希望店舗ヒアリング（2ヶ月先を日別＋希望店舗3店舗＋漏れた場合のエリア指定）→自動マッチングで割当の叩きを生成する機能を用意。
• 開始報告に当日入るメンバー名を追加項目とする。チェック項目は編集可＋店舗のカテゴリ別に出し分け。
• 終了報告のファネル（抽選→着座→アポ）は両面／片面／計で記録（合計は自動計算、両面を2カウントしない）。
• 「部門」はログインアカウントの部署から自動導出＋部署履歴を保持（イレギュラーな上書きも可）。
• 終了報告の売上金額・受注金額・契約件数は不要（アポになった後は商談側で管理）。
• 通知はメール／LINE／Slack（会社ごとに使う手段を分ける）＋前日リマインド／終了報告未提出アラートに加え、開始報告のアポ数と実際の登録数の乖離アラートを追加。
• 現場入力はスマホ主体＋PCも対応。オフライン一時保存は不要。帳票印刷は催事では不要（見積・発注書はPDF化）。

次回確認待ち・重要論点

• 担当ロールのすり替え：催事のアポ→訪問1回目→クロージング（訪問2回目）の過程で担当が別会社／別部署に移るケースがある。案件ごとにあらかじめ数フェーズを用意し、後から「ここは誰」を割り当てられる設計とする（登録時点では割当できず、1週間に1回まとめて割り振る運用のため）。Mockに出して設計を検討する（後続だが重要論点）。
• KPI（着座率／アポ率／両面率）：先行では出さず、データが揃った最後にBIツール的に一括提示する方針。ただし「可視化したい数字のゴール」は先に書き留めておいてもらう（必要データを後から遡って残せないため）。
• 通知手段（LINE／Slack）：メールはシンプルに実装可能だが、LINE・Slack連携の実装方式は要確認。

---

2026-08-20 ｜ 定例会（先行スコープQ&A続き：アイテム＋卸中心）

前日 8/19（催事Q1〜33）の続き。催事の反映確認から入り、アイテム（商品マスタ）Q34以降と卸（商社）の決済フロー・案件管理、さらに横断論点（権限・承認ワークフロー／変更履歴／削除／データ移行）を確定。生文字起こしは _archive/raw-text/20260820_定例会_文字起こし.txt。

運用の前提（今回の合意）

先行リリース範囲だけに絞った phase1版URL を Slack で共有し、チェックはそのURLで実施。あわせてダウンロードして書き込める質問シートを用意し、気づき・回答を随時追記→埋まった分から先に反映する運用にする。「決定済み（ValueOS 等）」の項目も確定として設計に取り込む。

催事（8/19の反映確認）

• チェック項目は本部の基本セット1つ＋系列別セットを持ち、系列に独自設定が無ければ本部基本を適用（8/19の resolveStartChecks フォールバックと一致確認）。
• 終了報告ファネルの合計は自動計算（両面・片面入力から算出）。「部門」はログイン者の部署を初期選択＋任意変更（実データ不明のため一旦マスタ選択の仮運用）。
• シフトは一括入力＋枠個別、マッチング実行で希望と取れた枠を突合（溢れは下段表示）、妥当ならシフト反映で自動生成。

アイテム（商品マスタ）Q34以降

• 商品コード：主キーは型番。型番の重複は基本ないが 1% でもあり得るため、自社コードを自社発行できる形にする（ValueOS は自社コード未発行だった）。
• 廃盤・型番変更：型番が変わる＝商品が変わる。既存を書き換えず新規登録（全く別商品として扱う）。
• 商品種別：PV / BT / QI / HAC / 2人 の6区分固定＋「その他」（当てはまらないイレギュラー用）。「思った」と「2人」は統合。
• 必須項目：メーカー＋型番（ValueOS 準拠）。容量・種別は未選択でも登録可（PV 等の種別により入力項目が変わる）。
• 一覧列：メーカー／シリーズ／表記名／型番／容量を全て表示（一覧で一気に見たい）。
• 納期：メーカー単位でなく商品ごとに保持。
• 添付（画像・カタログ・仕様書）：先行では不要、本リリースでも必須ではなく「あれば良い」程度。
• JANコード・外部メーカー品番：どちらも不要（確定）。規格・容量・倍数は構造化済み。ValueOS で持っている分は追加調整。

メーカー／仕入先マスタ・与信枠

• メーカーは名称のみ→正式名称も保持。仕入先は名称・種別・締め日・支払いサイトでOK（メーカー直送区分含む）。
• 与信枠：仕入先ごとに枠がある（2億／7000万等）が現状は未管理。全取引データを入れてスタートする前提なら加算で残枠を算出できるため、移行時点の与信枠現状値の入力は不要。

施工店マスタ・ローン会社（決済）

• 施工店：先行リリースには含めないが、マスタ登録はする（請求書PDFに施工店情報を差し込むため）。項目は ValueOS から拾う。
• ローン会社（信販）：決済条件に応じた入金期限算出に使うためマスタで保持（例：2社間は完工書提出後3営業日で入金）。持ちたい情報＝担当者情報／営業担当名・電話／メモ／信販会社特有の注意書き／FAX番号（アナログでFAX多用）。

在庫・状態（廃盤/欠品）

• 状態は ValueOS の is_active 相当を保持。廃盤か否かは持つ。欠品・廃盤の更新は当面手動（将来は発注担当）。
• 在庫は基本「受注発注で持たない」が、自社在庫品もあるため在庫管理はする。表示は「潤沢/少ない/欠品」ではなく個数（数字）入力。受注での自動減算はしない（ややこしくなるため）＝手動更新（別途スプレッドシート等）。

卸（商社）：決済フロー・案件管理【本命】

• 決済条件は4種＝前金／売掛／三者間／カード。案件登録→（前金なら）請求書作成→送付→入金確認→入金確認できるまで発注させない→発注→納品→終了、というワークフローで発注ストップを効かせる。
• 三者間で自社入金済みなのに販売店へ未振込、などの支払い漏れも管理。発注側は納期が近いものを優先表示、完了は一覧から消える。発注書・納品書はPDF出力（納品書は現状なく新規、項目は ValueOS にある）。
• ValueOS 基準に寄せる：イレギュラーは多いが ValueOS で 9.5 割対応可・今後もアップデート予定。ValueOS でできる/できないが出ないよう調整し、要件を満たせない場合は ValueOS を踏襲。
• スコープの本質：このツールは他社（商社）案件の管理用で、自社の発注案件は現状登録しない設計。ただし自社も発注しているため、最終的には自社の発注管理も同一システムに統合（CRMから同じ情報を吸い上げる）する前提を持つ。

マスタ編集権限・承認ワークフロー

• マスタ編集は管理者のみ。マスタ内でも管理者権限／プレイヤー権限を分ける。
• 価格・販売金額・仕入金額の変更は承認フロー必須（名称等は自由）。
• 承認はユーザーベースでマスタごとに承認者（上長）を設定。複数設定可＝OR（誰か一人が承認すればOK）、承認者本人は承認なしで更新可。自分でルールを細かく組む必要はなく「その人の上司が誰か」を設定できればよい。
• 承認者の設定は管理権限（システムの特別権限）を持つ人のみが行える。

変更履歴・削除・データ移行

• 変更履歴：フィールド（項目）単位で before/after を取り、変更履歴に集約（例：商品名の変更前後）。それで十分。
• 削除：論理削除に統一（表側に出なければBI等に影響なし。誤削除の復帰余地を残す。物理削除は復帰不可のため不採用）。
• データ移行：商品・店舗・代理店・仕入先・卸金額の既存データはDBとしては未保有（PDFのみ）。手動投入だが1件ずつは大変なので一括登録できるよう整理（すぐには必要にならない）。

次回確認待ち・段取り

• ValueOS（Supabase）権限の受領：Ouver 側で権限の渡し方（手順）を後送。ValueOS は 1 週間前ぐらいから実使用中。
• 画面が出揃った段階で、再度「どの画面をどうするか」を突合。カレンダーを見て次回を設定し、質問シートに追記→埋まる部分は先に埋めてもらう。
• 卸をValueOS基準に寄せるかの最終判断は、phase1 版を触った上での要件充足次第（本命論点）。

---

2026-08-26 ｜ 定例会（phase1モックレビュー・キックオフ＋権限/連携/データ方針）

8/20 の続き。今回は phase1版モックのレビュー・キックオフが中心で、あわせて権限設計・Googleログイン連携・データ抽出/DB操作方針を確定し、KPIまわりのスコープを見直した。生文字起こしは _archive/raw-text/20260826_定例会_文字起こし.txt。

進め方（モックレビュー）

実データに近いものを保存した共有環境を用意（誰が触っても同一データ、サーバー契約済み）。VE 側はまず最新の催事周り（phase1）を実運用視点で触り、「足りない機能はないか」を質問シート（スプレッドシート）に記入→反映で回す。大枠のズレを先に潰す狙いで、以降は「ここの範囲を触ってください」と範囲指定する運用にする。スマホ表示（シフト/マッチング）も確認対象。

モックの3系統（基準の確定）

• (1) 全機能版モック（CRM全体）／(2) phase1版（催事＋アイテム＋卸に限定。(1)とソース同一で表示範囲のみ差）／(3) 実データ寄せの検証版。
• **基準は「催事周りが全部入った最新版」**でよい。以降はその最新版を見てもらう。

Googleログイン連携・ユーザー規模

• Googleログイン（GCP=Google Cloud Platform の OAuth 設定）を導入。設定に GCP 権限が要るため、VE の GCP プロジェクトに Ouver（茗荷）アカウントを追加してもらう（手順は後送）。
• 同時利用規模＝社内約80人（常用）＋代理店の登録販売員 約300人（常時ではなく閲覧範囲も狭い）。社内80人は全員 @valueecology.jp の Google アカウントあり。
• 代理店アカウントの発行/変更 UI は VE 側で操作できるように作り込む（都度 Ouver 依頼よりコスト減。誤操作リスクのみ留意）。保守での巻き取りも可。

権限設計

• 個人ごと設定は非現実的なため、5段階程度のロールプリセット＋カスタマイズ方式（段階ごとにできる機能が増える）。
• どの機能を権限でオンオフするかは、催事の実装時に「ここは出し分けたい」を都度もらう運用。

代理店マスタ・フォーム

• 代理店マスタは加盟店契約スプレッドシート準拠。各項目に必須/任意フラグを付ける（全必須だと登録不能になるため）。ホーム（Googleフォーム）入力項目は必須、それ以外はフォーム必須オフ。
• マスタ項目の途中追加は Ouver 依頼で対応（フォーム自体を VE 側で自由編集可にすると見積が約3倍のため、追加は依頼ベース）。

KPI・ダッシュボードのスコープ見直し【重要】

• KPIダッシュボードは先行（phase1）から外し後回し。評価制度変更のたびに頻繁に変わるため。
• ただし基本の「対応状況」的ダッシュボード（未対応があります等）は出す＝数字目標/成績ではなくシンプルな状況表示。
• 営業・見積のダッシュボード（部署集計/予実/翌日設定）は別物で、これも最後（後続）。

データ抽出・DB操作方針【重要】

• 本番DBを直接編集/操作させる設計は避ける（誤削除で数年分のデータが飛ぶ事故が業界的にあり、DB編集は多段承認が標準）。
• データ活用は API 経由・CSV ダウンロード権限のみを開放（参照/抽出権限だけ持てればよい）。BI・AI 可視化は「抽出したデータ」に対して行う。ダウンロード項目を選んで CSV 出力する機能を用意する方向。

後続・別枠

• 施工店探し（顧客位置→近い施工店を地図検索、複数社打診→返信/対応可能日の追跡）が非効率。AI/別枠で検討。来年からの自社施工化で不要になる部分もある（一旦は放置可）。CRM組み込みか AI 別構築かは別途相談。

参考（契約・営業：システム実装スコープ外）

• 見積 1200万は負担大 → リスキリング/教育訓練の助成金で 400〜500万の減額を狙う（株式会社パフェと打合せ）。保守費 月10万想定（≒月10数時間：アカウント登録/問い合わせ/軽微修正/データ抽出/代理店登録 等）。減額のため機能を削る調整もあり得る（KPIダッシュボードは外す候補）。これらは契約側の論点で、CRM 実装スコープには含めない。

---

2026-09-02 ｜ 定例会（見積レビュー → 開発スコープの方向転換）

前回電話で預かった見積の再提示が主題。金額ロジックの説明から「業務オペレーションが毎月変わる前提でこの費用は妥当か」という VE 側の問題提起になり、最終的に開発範囲を「普遍的な業務」だけに絞る方向転換で合意した。生文字起こしは _archive/raw-text/20260902_定例会_文字起こし.txt。

このMTGは先行スコープの前提を動かしている

8/19・8/20 で確定していた先行リリース範囲＝催事＋アイテム＋卸は、本MTGで再検討対象になった。卸は「まだ業務が分かっていない」ため保留、催事も「要らないとなると先行リリース範囲が変わる」と Ouver から確認済みで、先行スコープは次回の再提示待ち＝未確定。実装判断はこのログの確定を待つこと。

見積の金額ロジック（説明）

• 原価はほぼ人件費。各社が人月単価（ランク別に月60/80/100万等）を持ち、「この画面は何時間」という工数×時間単価で積む（例：6,000円 × 10時間 ＝ 6万円）のが一般的な算出方法。
• 若手でも人月60〜70万が下限（大手だと新人で人月180万規模）。今回は茗荷およびメンバーの人月単価を削って単純値下げに反映済みで、単純な減額は限界（「最初の600万まで到達するのはかなり難しい」）。
• チャットは省いても保守込みでは減額インパクトが出ないため、今回の提示では外していない。

VE の問題提起：SaaS に業務を当て込む方が良いのでは

• VE：業務オペレーションは1ヶ月単位で変わる前提。変わるたびに数十万〜数百万かかるならコスパが悪い。
• Ouver の回答：SaaS はリリース時点で85点、残り15点を調整できないのが SaaS、調整できるのがスクラッチ。採番ルールや既存の案件ステータスが SaaS 側で設定できない場合、「その管理をどこでやるか」という課題が必ず出る。
• SaaS でも「現状業務」と「導入後業務」の整理は必須で、そこができずに失敗する会社が大半（業務システムの SaaS 導入成功例はほとんど見ていない、という所見）。
• SaaS を選んでも、追加業務への対応・2つ目のSaaSとのデータ連携可否・連携できない場合のデータの持ち方/受け渡しの検討時間が増え、代理店分のライセンス費も嵩む（アカウント数増で月10〜20万規模）。

【確定】スコープを「普遍的な業務」に絞る

• VE：業務の本質だけシステムで押さえる。余計なものは付けず、絶対に押さえないといけないところだけ。→ 見積書の A・B・D 相当に限定（記号の対応は要確認。A＝共通基盤（認証・権限）、B＝顧客・商談・契約管理と推定）。
• Ouver：マストでない「見積・価格表」などは第2フェーズ・第3フェーズへ後回し。一旦は固定で「あって役に立つもの」に限定して作る方向で問題ない ＝ 方向転換を合意。
• 卸（商社）は保留：業務がまだ分かっていないため、先に実装する必要はない。
• チャットは外せる（「現状のやり方で十分」なら）。ただし施工会社との日程調整などの自動化は諦めることが前提。施工店側は現場ごとに別の施工管理アプリを使っており、こちらのチャットを使ってもらえるか疑問、という VE 側の実感もある。
• 追加開発の考え方：「固まった／普遍的だ」と判断できた業務から中に入れ込んでいく。それまでは現行運用と併用。

【最重要】DB を参照・抽出できる状態にする

• VE：「そのデータベースがめちゃくちゃ大切」。消えない形で保持しつつ、こちらで吸い上げ（取り出し）できる状態にしてほしい。欲しい数字が出たときに、そのデータを使って自分たちで加工したい。
• ダッシュボード・評価制度はコロコロ変わるため作り込まない（8/26 の「KPIダッシュボードは先行から外す」と整合）。押さえるのは数字＝データそのもの。
• Ouver：そうなるとどこまでを DB とし、どこから Web アプリ化するかの整理が必要。
• ※ 8/26 で確定した「本番DB直接操作はさせず、API・CSV 抽出権限のみ」の方針は維持（本MTGの「取り出せるようにしてほしい」＝抽出権限の話として実装する）。

可変性への設計上の回答（Ouver・茗荷）

• フローが変わる前提でガチガチに作るのはリスク。固まっている部分から先に作る。
• 申請書類が年ごとに変わる件は開発で毎回対応するのではなく、「必要書類の組み合わせ」をテンプレートとして案件ごとに管理し、登録時にどのパターンかをテンプレートから選ぶ形にして柔軟性を確保する。
• ただし「A の後に B、B が OK なら C へ進む」というフロー構造そのものを可変にするとデータ設計から変わるため難しい。大枠は変わらない／細部は変わるという程度で予測できるなら作ってしまって問題ない（VE：7〜8割対応できる状態で作りたい）。
• VE 側の実感として、顧客・契約者の必要情報は変わらない／大まかなフローも変わらない。変わるのは申請の必要項目とダッシュボード・評価まわり。

ファイル保管（新規論点）

• 現在は Google ドライブに PDF・写真を大量保管しており、親フォルダの容量が上限に近い（残り約20%）。写真枚数が多く、上限に当たると入らなくなるのが怖い。
• Ouver：システム側なら**一定期間経過分のアーカイブ（縮小化）**で対応できる（ドライブだと追加課金）。→ ファイルストレージの持ち方は設計論点として起票。

次アクション

• Ouver ボール：(1) 最低限スコープでの見積の作り直し、(2) 質問事項の整理、(3) モックへの反映、(4) 先行リリース範囲の案の提示（催事も外れる可能性があるため）。
• 助成金は 9/4 の打ち合わせで別途。余った分は保守費・追加開発に充当する整理で合意。
• 整理は 9/4 に間に合わず翌週（9/8週） の見込み。固まり次第あらためて打ち合わせ。

9/9 時点の進捗

再定義スコープと再見積を作成済み。範囲の定義は リリース計画 §2026-09-02 スコープ再定義、金額は Atsurae 見積「VEC003 CRM 再定義スコープ 開発見積（9/2方向転換版・普遍業務コア）」（案1 ¥5,926,700 ／ 案2 ¥6,397,300＝推奨 ／ 案3 ¥6,938,100）。削減対象に挙がった催事・卸は既に実装済みで、これから作るのは顧客・商談と活動・申請、およびデータ抽出であることが突合で判明している。

---

2026-09-09 ｜ 定例会（再見積の提示 → 案1 コアで決定＋進め方の合意）

9/2 の方向転換を受けて作った再見積（3案）の提示回。約17分。案1 コアで決定し、以降の進め方（要件定義は Ouver 主導）を合意した。生文字起こしは _archive/raw-text/20260909_定例会_文字起こし.txt。茗荷は発話なし（田中の発言中の「たつき君」は市原）。

【確定】開発範囲＝案1 コア

• 提示した3案（案1 コア ¥5,926,700 ／ 案2 コア＋催事引渡 ¥6,397,300 ／ 案3 ＋卸 ¥6,938,100）のうち、田中さんは案1「左端のプラン」を選択。市原「第1 コアという形になります」で確定。
• 範囲：共通基盤・認証・権限／顧客・商談／活動・タスク・申請（テンプレート方式）／データ抽出・参照API／ファイル保管・アーカイブ／マスタ残作業／データ移行／工程。
• 催事と卸は範囲外。市原「催事などは削除になる」。
• 田中の要約：「本丸はアポ獲得から完工までの顧客を追うシステムだけ。この前話した相関的なものにほぼ網羅されている」。

実装済み資産の扱いが未決

案1 が選ばれたことで、本番反映済みの催事（シフト・マッチング・確保枠・催事系マスタ4種）と卸（案件・発注/納品キュー・売掛・帳票4種）は開発範囲外＝凍結になる。既存の本番環境で動いているものを残す／隠す／止めるのいずれにするかは本MTGでは触れられていない。次回に確認。

データ抽出・ファイル保管（見積に含む旨を説明）

• 市原：参照 API を開発するので、API で指定データを抽出し、ダッシュボードは VE 側が GAS 等で自作できる。通知なども開発可能。田中「自由度高くできる感じですね」。
• 市原：9/2 のドライブ容量の件も見積に含めている。ストレージの自動アーカイブ等、容量節約を考慮した設計開発にできる。→ 置き場（Drive 継続か CRM 側か）は引き続き未決（リリース計画 §2026-09-02 参照）。

【確定】進め方：要件定義は市原主導、田中は確認役

• 田中：「要件定義のやりとりは全部市原でやってもらい、出来たモックを僕がバーッと確認して『ここはこういう感じで』を言う形にしたい」「要件そのものの話はあまりしたくない。時間が足りない」「ガシガシ推進してほしい。1〜2ヶ月で認識は固まる」「主導権は Ouver 側に持ってもらいたい」。
• 定例の型：Ouver が「ここまで進みました。御社の業務フローはこうだと思うので、これをここに落とし込んでこういう設計になっています」を案内し、田中が「これちょっと違います」を返す。業務フローと設計の照合を定例の場でやる。
• 市原：動線・UI は Ouver で作れるが、詳細項目のチェックは必須。現場の人にも触ってもらいたい。毎回でなくても担当者に60分だけ出てもらう形。
• 田中：担当者は僕が振る。「ここを開発したい」と言われたらそこのメンバーをピックして出す。
• 市原：モックの作り直しから始め、画面モックを作りながら操作性を詰める。要件さえ固まればいい。そこだけ慎重に。（市原は「茗荷にパスして大丈夫かな」とも口にしており、Ouver 内での分担は要整理）

9/10 申請業務ヒアリング

• 田中：市原の前回訪問で代理店・完工は見えたと思うが、申請の部分だけ見えていない。9/10 14:30 の別件打ち合わせ（「業務がパツっている。何がパツっていて、どう改善できるか」）に同席してほしい。→ 市原が同席。

参考（契約・助成金：システム実装スコープ外）

• リスキリング会社との契約は未着手（田中「全然できていない」）。契約日を 8/1 以前にする件は、契約書のチェックだけのはずで、就業規則確認後に開始する会社もあるため不自然ではなさそう（市原の見立て）。
• 申請サポートは先方が行うが社労士が必要そう。1プランあたり約40万と高いのでミニマムで進める。
• 市原：万が一社員が「助成金目的で」と言ってしまうリスクは残る。

次アクション

• Ouver（市原）：案1 の範囲で要件定義を主導し、モックを作り直す。定例で「業務フロー→設計」の照合説明を行う。Ouver 内での茗荷との分担は要整理。
• Ouver（市原）：9/10 14:30 申請業務ヒアリングに同席。
• VE（田中）：詳細項目チェック時の現場担当者のピックアップ。リスキリング会社との契約手続き。
• 要確認：凍結する催事・卸の本番資産の扱い。案1（692h）の実スケジュール提示。

---

次回MTG確認待ち・オープン事項

9/2 で前提が動いた項目

9/2 の方向転換を受け、9/9 に開発範囲＝案1 コア（顧客・商談・活動・申請・データ抽出・ファイル保管・マスタ残作業・データ移行）で確定。催事・卸・見積/価格表に紐づく下記項目は**範囲外（後続）**として扱う。

9/9 起票（最優先）

• 凍結する催事・卸の本番資産の扱い（残す／隠す／止める）。本番反映済みのため、案1 の範囲外になった後の見え方を決める
• 案1（692h）の実スケジュール提示。田中の見立ては「1〜2ヶ月で認識固まる」。11月末の現場投入目標との整合
• 9/10 14:30 申請業務ヒアリングの結果を、申請書類テンプレート設計に反映
• 定例の型の運用：Ouver が「業務フロー→設計の照合」を毎回用意する。現場担当者のスポット参加は田中がピック

9/2 起票

• 最低限スコープでの再見積＋先行リリース範囲の案の提示 → 9/9 に案1 コアで決定（催事は先行から外れた）
• 見積書の項目記号 A/B/C/D の対応の確定（A＝共通基盤（認証・権限）は確定、B＝顧客・商談・契約管理と推定、C/D 未確定）。見積書 PDF と突合
• 「どこまでを DB とし、どこから Web アプリ化するか」の線引き（VE の最重要要望＝データを取り出して自分たちで加工したい）
• 申請書類のテンプレート方式（必要書類の組み合わせを案件ごとに持ち、登録時に選択）の設計・合意
• ファイル（PDF/写真）ストレージの持ち方：Google ドライブが容量上限に近い。一定期間経過分のアーカイブ/縮小化方針を設計に含める
• チャットを外すか否かの最終確認（外す＝施工会社との日程調整の自動化を諦める、が前提）
• データ移行の費用：範囲を絞っても一定発生する旨は伝達済み。新スコープでの金額提示待ち

既存（〜8/26 起票）

• 見積自動作成／商品マスター連携（jouken 分離と MTG資料§6「CRM統合合意」の整合説明が必要）→ 7/15で見積書ひな形・部材/パッケージ実サンプルの受領待ち、価格の CRM 保有範囲 × jouken 切り分けは次回整理
• 商品/部材マスタを 仕入先（メーカー・商社）別 × 反映日（時間軸） で持つ設計。将来は明細スキャン取り込み（7/15）
• 未受給時の保証条件（Ouver 確認中・7/15）
• AIエージェント連携：中間やりとり自動化の要望が具体化（基本機能確定後に着手）
• 催事の3工程（アポ固め）の扱い
• 新規事業（商社・消費者）のスコープ
• 補助金・保証・トラブル窓口の書類名（現状は仮置き）
• マネフォAPI連携（部門マスター×案件紐付け、PL/CF突合）は提案待ち
• 商社業（卸・3社間の商社側業務）はクライアント整理後にDXコンサル枠で対応
• 先方はAIエージェントの売り込みを受けており、部分利用の相談が来る可能性
• 商品区分（種別）を商品登録から外すか（7/22。実装では残置＝要確認）
• パッケージ／チェック欄の呼称確認（「全開設」「美行」＝標準構成一式／区分の列と解釈）
• 卸金額（販売店向け卸価格）マスタの追加（7/29）
• 発注管理：販売店フォーム→案件化、**決済フロー4種（前金/売りかけ/3社間/カード）**に応じた発注・請求タイミングの可視化（7/29・本命）
• 商社目線の別軸案件管理（元請け＝販売店目線 と分離。ValueAuth/ValueOS を参照・突合）（7/29）
• SaaS化・太陽光設計AI自動化・業務可視化ツールは将来構想（12月のCRM完成後）