💻 システム開発
SCALE_List_Pool_開発依頼書
最終更新 2026年05月14日 ／ 31_システム開発部/SCALE_List_Pool/SCALE_List_Pool_開発依頼書.md
SCALE List Pool — リスト溜め置き＆案件分配システム 開発依頼書
このノートは別セッション専用の作業指示書。新セッションで Claude が読めば、前提共有なしで即実装に入れる状態を維持する。
1. 概要
一言で
SalesNOW から取り込んだ大量企業データをプールして、案件別の架電リストに条件抽出して分配するシステム。SalesNOW 解約後もデータ活用可能。
解決したい現状の課題（大串FB原文）
「リストの依頼がメンバーからあって、そのリストをSalesNOWで作るときに、メンバーからはまず300件欲しいと依頼があってもSalesNOWで指定の条件でセグメントきると、300件だけダウンロードとかできず、一気に7000件とかダウンロードするしかない。これが非常にもったいない（SalesNOWは上限などもあるから）」
「これを解消するために、まずSalesNOWからcsv化したら、新しく作るセクション（架電リストのようなリストを溜めておく場所）にリストを入れる。そして、そこから数を選んで架電リストに入れるって流れにしたい」
「4000件抽出できちゃちゃって、300件の希望が合った場合も3700件をまた他の方から依頼あったらそこから抽出できるから有効活用できる」
「例えば4000件リストを作って、その中から300件抽出して架電リストに入れたいときに、4000件の中に様々な県があるけど、それを均等に300件抽出したり、中業界を均等に300件入れたりしたい」
「あと欲しい機能はこのリストはこの案件でこの方にすでに依頼してますよってわかるようにすると、2回使っちゃうってことがなくなって安心」
「A案件とB案件でも同じリスト使いたいって場面あるけど、そのときにA案件でアポ取れているから、B案件はやめとこうってできたり、逆に不通でおわっているからB案件でこのリスト使っちゃおうってできたりする」
「毎回SalesNOWの上限までここのシステムに入れ込めば、SalesNOWを解約しても、企業のデータとして残るから何かしらに有効活用できそう（フォーム営業とかにも使えるし）」
期待する戦略的価値
| 価値 | 内容 |
|---|---|
| SalesNOW無駄使い撲滅 | 7000件DLしても300件しか使わない → 残3700件を他案件・他メンバーの依頼に再利用 |
| リスト品質向上 | 県別・業界別均等抽出で偏りを排除 |
| ダブル架電防止 | 案件横断で同社の架電状況が見えるので、2回使い事故ゼロ |
| 案件横断知見 | A案件で不通 → B案件で使う判断 / A案件でアポ取れた → B案件は避ける |
| 資産化 | SalesNOW解約後も自社プロパティとして企業データが残る（フォーム営業・メール営業に転用可能） |
2. スコープ
含む（MVP）
- [ ] CSV取込 (SalesNOW CSV判別+全フィールド自動マッピング) — 既存
_clImportCSV等のSalesNOW自動判定ロジック流用 - [ ] リストプール画面 (新規セクション・PM/admin限定)
- [ ] フィルタ機能 (大業界 / 中業界 / 都道府県 / 売上規模 / 従業員規模 / フリーワード)
- [ ] 均等抽出機能 (県別均等N件 / 中業界別均等N件 / 規模別均等N件)
- [ ] 案件分配機能 (選択N件 → 案件選択 → 担当者選択 → 各案件の
call_listに push) - [ ] 使用済み追跡 (各企業のassignmentLog で「どの案件・誰に・いつ依頼したか」記録)
- [ ] 案件横断ステータス可視化 (プール画面で「他案件で何があったか」表示)
- [ ] 同社の架電リストへのdeep link (プール内の企業から該当案件の架電リスト詳細モーダルにジャンプ)
- [ ] 重複検知 (CSV取込時に既プール企業を salesNowLink等で判別)
- [ ] PM/admin権限制御 (パートナーには非表示)
含まない（後回し / スコープ外）
- フォーム営業への自動転用機能（手動でCSVエクスポートはOK）
- メール営業自動配信
- 企業データの自動更新（SalesNOW から定期同期）
- AI による企業の優先度スコアリング
- 営業履歴の完全 timeline 化
3. 必読ノート
大串の好み・スタイル
- 22_AI運用ルール/Claude_動き方ガイド — 動き方ガイド（必読・最重要）
- 22_AI運用ルール/Claude_先回りパターン辞典
- 22_AI運用ルール/Claude_学びストック
SCALE CRM の関連ノート
- 31_システム開発部/_SCALE_CRM_最新基準点 — 最新版状態
- 31_システム開発部/_SCALE_CRM_設計書 — 既存設計
- 31_システム開発部/_SCALE_全システム配置マップ
- 31_システム開発部/_SCALE_全システム実装ルール — 退化禁止フロー
- 31_システム開発部/_SCALE_共通_トラブルシューティング集 — 過去エラー全パターン
コード上の重要箇所
/Users/oogushiyuuki/株式会社SCALE/scale-lead/calllist.js_clImportCSV周辺 (CSV取込ロジック・SalesNOW自動判別)renderCallList(UI/UX参考)ST_REQUIRED_FIELDS(ステータスモーダル定義)- CSV ヘッダマップ (calllist.js:1676-1735周辺)
/Users/oogushiyuuki/株式会社SCALE/scale-lead/core.js_initSupabase_d1PollTick(D1同期メカニズム)_safeSetItem(容量超過対策)_logCallListWrite_flushCallListToD1(削除ログ機構 v9.195)
4. 議論したいトピック（チェックリスト）
A. データモデル設計
- [ ] 重複判定キー: 何で同社判定するか?
- 候補:
salesNowLink(SalesNOW由来は確実) /phone(電話番号正規化) /company + prefecture(会社名+所在地) - 推奨:
salesNowLink第一優先 +phone第二優先 +company第三優先 - [ ] エントリ構造:
json { "id": "lp_xxxxxx", "company": "株式会社ABC", "phone": "03-1234-5678", "salesNowLink": "https://salesnow.jp/...", "industry": "製造業", "subIndustry": "機械", "revenueScale": "10-100億", "employeeScale": "50-200名", "prefecture": "東京都", "address": "...", "csvImportedAt": "2026-05-14T06:00:00Z", "importedBy": "大串", "assignmentLog": [ { "projectId": "proj_xxx", "clientName": "結グループ", "callPerson": "大串", "assignedAt": "2026-05-14T...", "latestStatus": "アポ獲得", "latestUpdateAt": "..." }, ... ] } - [ ] D1キー: グローバル
list_pool_companies(案件IDに紐付かない) でOK? - 容量懸念: 10万件超え時のパフォーマンス対策
B. UI/UX
- [ ] 画面構成:
- 上部: フィルタバー (業界 / 地域 / 規模 / フリーワード) + 均等抽出ボタン + 「N件を架電リストへ」ボタン
- 中央: テーブル (チェックボックス / 企業名 / 電話 / 地域 / 業界 / 規模 / 使用状況 / アクション)
- 「使用状況」列の表示: 「結グループ: アポ獲得✓ / 別社A: 失注 / 未使用」のような略式表示
- [ ] 詳細モーダル: 企業クリックで開く → assignmentLog 全履歴と各案件のcall_listへのdeep link
- [ ] 均等抽出UI: モーダル表示 → 「均等化キー: 県 / 中業界 / 規模」+「抽出件数」入力 → プレビュー → 「この300件を選択」
C. 案件横断ステータス同期
- [ ] 同期方式:
- 案A: 各案件の
call_list更新時に list_pool 内の assignmentLog を逆向き更新 (リアルタイム性高い・実装重め) - 案B: list_pool 画面表示時に全案件の call_list を fetch して集計 (シンプル・表示時のみ重い)
- 推奨: 案B (画面表示時集計) で MVP → 後でリアルタイム化を検討
- [ ] fetch 戦略: 全案件の
proj_<id>_call_listを並列 fetch → 各企業 ID に対応する callX_Status を集計
D. CSV取込
- [ ] 既存 SalesNOW CSV 自動判別ロジック: 流用してそのまま使えるか?
- [ ] 重複検知時の挙動: 「既プール企業を更新 / スキップ / 警告ダイアログで選択」のどれ?
- 推奨: デフォルトはスキップ + 更新オプション
E. 分配機能
- [ ] 分配先案件の選択: 案件複数選択可? それとも1案件のみ?
- 推奨: 1案件1担当者 (シンプル) でMVP
- [ ] 分配後の call_list 構造: 既存 c.salesNowLink + 必要フィールドだけコピー
- [ ] 重複検知 (分配時): 案件の既 call_list に同社が居る場合は警告 + スキップ
- [ ] 逆方向リンク: call_list 側のエントリに
sourceListPoolIdを持たせて、いつでもプールに戻れる
F. 権限・パフォーマンス
- [ ] PM/admin限定 で OK? それともパートナーも閲覧可?
- [ ] 大量データ時のページング: 4000件 → 100件ずつ表示・無限スクロール or ページネーション
G. 既存 call_list との関係
- [ ] データ重複: list_pool と call_list の両方に同社データが存在する状態 → どっちが正?
- 推奨: list_pool が原本 / call_list は「派生コピー」(担当者と架電結果のみ独自)
- [ ] call_list の企業情報更新: SalesNOW で会社情報が変わったら? → list_pool 経由で再分配?
5. 守るべきこと
退化禁止
- 31_システム開発部/_SCALE_全システム実装ルール を必読
- Write 全体書き換え禁止 → Read → Edit
- 既存関数の削除前に grep で参照確認
- デプロイ前 tar.gz バックアップ必須
- changelog 追記必須 (lib/changelog.ts or service.js COCREATE_VERSIONS)
- デプロイ後 本番URL アクセス確認
ラリー最小化（最重要・絶対遵守）
- 22_AI運用ルール/Claude_動き方ガイド の「5. エラー対応・システム開発はラリー最小化」を必読
- バグ・エラー時は 想定原因3〜10個を全部リサーチ → 全経路にトレース + 全保険的修正 を 1リリースで投入
- 1個ずつ試すラリー絶対禁止
パートナー対応のNG事項
- 15_MTG/_パートナーMTG共通NG事項
- ただし list_pool は PM/admin限定なので影響範囲外（パートナーには見えない）
1依頼1完成1デプロイ1バックアップ原則
- MVP内の機能を 1機能ずつ完結 → デプロイ → バックアップ → commit → 次へ
- 全機能まとめて実装 → 1回デプロイ は禁止 (容量オーバーリスク)
6. 出力先（フォルダ構成）
コード
- 既存:
/Users/oogushiyuuki/株式会社SCALE/scale-lead/ - 新規ファイル候補:
list_pool.js(新規) — リストプール本体ロジック- 既存
core.jspages.jscalllist.jsへの最小限の編集 - HTML:
index.htmlの script タグにlist_pool.js追加 + cache-bust
ノート (このフォルダ内)
SCALE_List_Pool_開発依頼書.md(本ノート)_SCALE_LIST_POOL_現在状態.md(進捗管理)SCALE_List_Pool_設計書.md(実装フェーズで作成)SCALE_List_Pool_changelog.md(開発進捗ログ)
7. 完了基準（MVP）
- [ ] PM/admin が「リストプール」セクションにアクセス可能
- [ ] SalesNOW CSV を取り込んで企業データがプールに登録される
- [ ] フィルタ (業界 / 地域 / 規模 / フリーワード) で絞り込み可能
- [ ] 均等抽出 (県別 / 中業界別 / 規模別) で N件抽出可能
- [ ] 抽出したN件を 1案件 + 1担当者に分配 → 該当案件の call_list に正しく追加される
- [ ] プール画面で各企業の使用状況 (他案件でのステータス) が見える
- [ ] 同社の他案件 call_list に deep link でジャンプできる
- [ ] CSV取込時に既プール企業を判別 (重複スキップ or 更新)
- [ ] 本番デプロイ済み + バックアップ取得済み
8. 完了報告フロー
1. MVP全機能の本番デプロイ完了
2. tar.gz バックアップ作成 (`~/scale-lead-backups/scale-lead-YYYY-MM-DD-HHMM-listpool-mvp.tar.gz`)
3. このフォルダの changelog.md に全実装履歴記載
4. _SCALE_LIST_POOL_現在状態.md を「MVP完了 / 検証フェーズ」に更新
5. _SCALE_CRM_最新基準点.md にも list_pool セクション追加
6. Slack に slack_post.sh で完了報告 (司令名義 / 社長メンション不要):
/Users/oogushiyuuki/株式会社SCALE/scale-company/slack_post.sh shirei "🎯 SCALE List Pool MVP デプロイ完了\n本番: https://crm.scale-group.co.jp/list_pool\n機能: CSV取込/フィルタ/均等抽出/案件分配/使用追跡/案件横断ステータス\n検証お願いします"
9. 関連ノート
- 31_システム開発部/_SCALE_CRM_最新基準点
- 31_システム開発部/_SCALE_CRM_設計書
- 31_システム開発部/_SCALE_共通_トラブルシューティング集
- 22_AI運用ルール/Claude_動き方ガイド
- 15_MTG/_パートナーMTG共通NG事項
10. 更新履歴
| 日付 | 内容 |
|---|---|
| 2026-05-14 | 初版作成（大串FB原文を元に MVP スコープ定義） |
11. 最初の一手（別セッションで議論したい順序）
- データモデル設計を確定（重複判定キー・エントリ構造・D1キー）
- MVP UI/UX のワイヤー を3案出して大串が選ぶ
- CSV取込ロジック の流用箇所を grep して確認
- 均等抽出アルゴリズム の擬似コード提示
- MVP実装フェーズ1: CSV取込 + プール表示 + フィルタ (最小機能で動く状態をデプロイ)
- フェーズ2: 均等抽出 + 案件分配
- フェーズ3: 使用状況可視化 + deep link
- MVP完了 → 大串検証 → フェーズ4以降の追加機能議論
12. 未確定事項（別セッション開始時に大串と相談）
- 重複判定キーの優先順位（salesNowLink → phone → company の3段で OK?）
- データモデルのD1キー名（
list_pool_companiesで OK? それともプロジェクト単位で複数?） - 案件横断ステータス同期方式（画面表示時集計 vs リアルタイム逆同期）
- 分配先の案件複数選択可否（MVP は 1案件 1担当者 でいい?）
- パートナーへの閲覧権限（完全非公開で OK?）
- ページングUI（無限スクロール vs ページネーション）
13. UI/UX 参考イメージ
既存の 架電リスト (crm.scale-group.co.jp → 架電リスト) のテーブル構造を踏襲しつつ、以下を追加:
| 列 | 内容 |
|---|---|
| ☑ | 選択チェックボックス |
| # | 行番号 |
| 企業名 | クリック → 詳細モーダル + assignmentLog 表示 |
| 電話番号 | 電話マスク+クリックコピー |
| 都道府県 | フィルタ可能 |
| 大業界 | フィルタ可能 |
| 中業界 | フィルタ可能 |
| 売上規模 | フィルタ可能 |
| 従業員規模 | フィルタ可能 |
| 使用状況 | 「結グループ: ✓アポ / 別案件: ❌失注 / 未使用」を色分けバッジで表示 |
| アクション | 「→ 詳細」「→ 該当案件の架電リスト」 |
14. 補足: 他システムへの転用想定
このリストプールが完成すれば、将来的に以下にも転用可能:
- フォーム営業: プールから条件抽出 → メールフォーム送信リスト生成
- メール営業: 同上
- LinkedIn営業: 個人情報フィールド追加でLinkedIn営業にも使用
- SalesNOW 解約: 企業データは自社プロパティとして保持 (継続コスト削減)
MVP段階では call_list 分配のみだが、設計時に「他チャネルへの拡張余地」を残しておくこと。
大串の戦略コメント（2026-05-13 FB原文）
「機能色々付けて最高な状態にしたい。毎回SalesNOWの上限までここのシステムに入れ込めば、SalesNOWを解約しても、企業のデータとして残るから何かしらに有効活用できそう（フォーム営業とかにも使えるし）」