CFCL PR・プロモCRM 意思決定ドキュメント
（統合最終版）

この資料のねらい

「入力の手間を減らしたい」「抜け漏れなく管理したい」という2つの要望に対して、あるべき業務の姿（To-Be）から考え直し、そこから逆算して必要な画面・機能を並べ、最後に 「既製のCRMを買うか／自分たちで作るか」 を比較して、進め方を1つ推奨します。

読む順番は「要求 → あるべき業務 → 必要な機能 → 作り方の比較 → 推奨」です。

1ビジネス要求の再確認（2つの軸）

すべての判断は、この2軸に立ち返って行います。

入力の基本ルール（前提）: 顧客は一人ずつ・都度記録する（まとめて一括ではなく、活動が起きたその場で1件ずつ残す）。

このため設計の合言葉は 「入力は最小、管理は最大」。入力を減らす仕組みと、管理を助ける仕組みを、はっきり分けて考えます。

2理想業務（To-Be）と現状（As-Is）の対比

2-1. あるべき姿（To-Be）

CFCLのPR/プロモは「モノを売る営業」ではなく、人との関係を丁寧に育てる仕事です。ギフティング・会食・イベント招待・手紙は、すべて「関係づくり」という1本の線でつながっています。理想は、その1本の線が記録の苦労なしに残り、次の一手が自然に見える状態です。

理想の1日のイメージ（担当者目線）

1. VIPにギフトを送った → 顧客を選んで商品を選ぶだけで記録完了。在庫は勝手に減る。
2. 会食をした → 顧客を選んで日付を入れるだけ。担当や区分は自動で入る。
3. 顧客の名前を開くと → その人との全履歴（ギフト・会食・イベント・手紙）が1画面に時系列で並ぶ。
4. 朝、画面を開くと → 「そろそろ連絡すべき人」「次アクション予定日が近い人」が自動で並んでいる。
5. イベントを開いたら → 招待した人・来た人・当日の反応がひと目でわかる。

キーワードは3つ：選ぶだけで記録できる／全部が1本につながって見える／次の一手が向こうから見えてくる。

2-2. 現状（As-Is）との対比

要点: 現状は「記録が手間 → 後回し → 抜け漏れ → 全体像が見えない」の悪循環。
理想は「選ぶだけ → その場で記録 → 自動で1本につながる → 次の一手が見える」の好循環。

3業務 → フロー → 画面 → 機能（4階層の取りまとめ）

要望どおり「業務一覧 → 業務フロー → 画面一覧（遷移）→ 機能一覧」の順で、大きいところから細かいところへ落とし込みます。機能は 「入力を減らす機能」 と 「管理を助ける機能」 を分けて記載します。

3-1. 業務一覧（何をする仕事か）

現在の管理Excelの構造にそのまま対応させています（存在しない列・シートは前提にしていません）。

除外: アンケート機能は今回のスコープから外します（要望どおり）。

3-2. 業務フロー（どう流れるか）

代表的な2つの流れを例に、「選ぶだけで進む」姿を示します。

■ ギフティングの流れ（在庫連動あり）

顧客を選ぶ ──▶ 商品を選ぶ ──▶ 数量を入れる ──▶ 在庫が自動で減る
                                                     │
                                                     ▼
                                     実施ステータスを更新（予定→実施）
                                                     │
                                                     ▼
                            Instagram投稿の有無を記録 ──▶ 投稿URLを貼る

※ 顧客ID・活動ID・担当は自動。手で書くのは「数量」と「投稿URL」くらい。

■ 自社イベントの流れ（招待→出欠→実績）

イベントを作る ──▶ 招待者を顧客から選ぶ ──▶ 招待ステータス管理
                                                │
                                                ▼
                                   出欠を記録 ──▶ 当日実績を記録

※ 顧客を選ぶだけで、そのイベントの招待者一覧に串刺しされる。

■ その他活動（会食・手紙など）の流れ

顧客を選ぶ ──▶ 活動の種類を選ぶ（会食／手紙／その他）──▶ 種類に応じた項目だけ表示
       │
       ▼
入力内容が自動で正しいシート（ディナー／手紙／その他）に振り分けられる

※ 担当者は「どのシートに書くか」を意識しなくてよい（自動振り分け）。

3-3. 画面一覧と遷移（どこを見て、どこへ動くか）

遷移の全体像（簡易）

ダッシュボード
   ├─ 顧客一覧 ──▶ 顧客詳細(360°) ──▶ 活動入力
   │                     └────────▶ イベント詳細 / 在庫詳細
   ├─ イベント一覧 ─▶ イベント詳細 ─▶ 顧客詳細
   ├─ 在庫一覧 ────▶ 在庫詳細 ────▶ 顧客詳細
   └─ 次アクション一覧 ─▶ 顧客詳細

※ どの画面からも「顧客詳細（360°）」に戻れるのが基本設計。すべてが顧客を中心につながる。

3-4. 機能一覧（分けて記載）

(A) 入力を減らす機能 ＝ 要求(1) を実現

(B) 管理を助ける機能 ＝ 要求(2) を実現

(C) ドリルダウン例（網羅）

(D) データ拡張が必要な機能（※実在しない列を前提にする機能）

現状Excelの列だけでは実現できず、列の追加（データ拡張）が前提になる機能を、混同しないよう別記します。

4実現方式の比較（買うか・作るか＝Make or Buy）

「どう作るか」を3案で比較します。CFCL固有の制約に照らして評価します。

CFCLの制約（評価の物差し）

• 機密性重視: 顧客の実名（VIP・メディア・インフルエンサー 約1,220件）＝ブランドの生命線。漏えいは致命傷。
• 小規模: 使うのは少人数のPR/プロモチーム。
• 独自業務: ギフティング×在庫連動という、一般CRMにない業務がある。
• ローカル運用・API課金なし志向: 手元で完結させたい。従量課金は避けたい。

4-1. 3つの案

4-2. 既製CRM各サービスの特性（①の中の選択肢）

共通の弱点: いずれも「営業パイプライン」や「汎用データベース」が前提で、ギフティング×在庫の自動連動は標準機能に無い。作り込みか外部連携が必要です。
そして最大の論点は次の機密性です。

4-3. 機密性の是非（明記）

顧客の実名（VIP・メディア・インフルエンサー 約1,220件）を外部クラウドに置くべきか。

• ①の既製CRM（特に米国クラウド系）は、実名連絡先を社外のサーバーに預けることになります。
• 万一の漏えい・サービス側事故が起きた場合、CFCLブランドの信頼毀損という取り返しのつかない損害につながります。
• 結論: 実名を外部クラウドに置くことは推奨しません。
  • どうしてもクラウドを使う場合は、「顧客は記号ID運用にし、実名は手元で別管理」といった実名の分離が前提になります（運用が二重になり、入力工数削減の要求(1)と逆行します）。
• ②内製ローカル・③Excel強化は、データが手元（社内）に留まるため、この論点をそもそも回避できます。

4-4. 比較表（6つの軸）

評価: ◎優れる ○良い △やや弱い ×弱い

4-5. 各案のメリット・デメリット（要点）

① 既製CRM

• メリット: すぐ使える。顧客360°やタイムラインが最初から付いている。ベンダーが保守。
• デメリット: 実名を外部クラウドに預ける（最大の難点）。ギフト×在庫連動が作りにくい。月額が人数分かかる。値上げ・仕様変更・サービス終了に振り回される。

② 内製ローカルWebアプリ

• メリット: 機密が手元に留まる。ギフト×在庫連動に完全適合。入力削減を業務特化で最大化。月額ほぼ0（CRMはAI不要のため従量課金も発生しない）。既存の設計資産（データモデル/画面/機能定義）とPR原稿ツールの基盤を流用できる。
• デメリット: 作る工数がかかる。基本は手元PCで動く（外出先での利用や複数人同時利用は別途対応が必要）。バックアップは自前。

③ 既存Excel強化＋HTML閲覧

• メリット: 最速・最安。手元に留まる。現場が使い慣れている。
• デメリット: シートを跨いだ自動連動・自動振り分けができず、入力削減効果が限定的。顧客360°やドリルダウンが弱い。同時編集に弱く、複雑化すると壊れやすい。HTML画面は「その時点の写し」で、更新に手間がかかる。

5推奨と次のアクション

5-1. 推奨方式

①を推さない理由: 機密性（外部クラウド）とギフト×在庫連動の不適合。この2点がCFCLの制約と正面から衝突します。

③単独を推さない理由: 入力削減効果が限定的で、要求(1)を十分に満たせません。ただし入口としては有効（下記フェーズ0）。

5-2. 段階導入案（小さく始めて、効果を見て広げる）

いきなり全部作るのではなく、すぐ価値が出るところから始めます。

フェーズ2では「各活動シートに次アクション列を追加」などデータ拡張が前提になります（第3章(D)参照）。着手前にCEOに確認します。

5-3. 次のアクション（CEOにお願いしたい判断）

1. 推奨方式（②内製・段階導入）の承認可否 … これで進めてよいか。
2. フェーズ0の即時着手可否 … 既存Excel強化＋HTML閲覧を先に出して価値を体感するか。
3. データ拡張（次アクション列の追加など）の是非 … フェーズ2で列を足してよいか。
4. 利用範囲の確認 … 手元PCでの利用で十分か／外出先・複数人同時利用が必要か（必要なら設計を追加）。

6Verification

Verification Plan

• 成果物が要望の5構成（要求再確認／To-Be・As-Is対比／業務→フロー→画面→機能の4階層／make or buy比較／推奨と次アクション）を漏れなく満たすこと
• 現状Excelの実在する列・シートのみを機能の前提にし、実在しない列を使う機能は「データ拡張が必要」と別記していること
• 制約（平易な日本語・機密の是非明記・アンケート除外・冗長回避）を満たすこと

Verification Result

• [x] 5構成の網羅: 第1〜5章で全構成をカバー（本文の見出し参照）
• [x] 入力を減らす機能／管理を助ける機能の分離: 第3-4章 (A)/(B) で明確に分離
• [x] ドリルダウン例の網羅（顧客/イベント/ギフティング/在庫）: 第3-4章 (C) に4例記載
• [x] make or buy 3案＋6軸比較: 第4-4章の比較表、①の中でHubSpot無料/有料・Notion・kintone・Airtableを第4-2章で特性比較
• [x] 機密性の是非を明記: 第4-3章で「外部クラウドに実名を置くことは推奨しない」と明記
• [x] 実在しない列前提の機能を別記: 第3-4章 (D) に「データ拡張が必要」として分離（次アクション列は手紙シートのみ実在、を根拠に記載）
• [x] アンケート機能の除外: 第3-1章に明記
• [x] 推奨1案の明示＋段階導入案: 第5章で②内製を推奨、フェーズ0〜2を提示
• 出力ファイル: agents/workers/architect/output/DESIGN_cfcl_pr_crm_make_or_buy.md

7設計完了チェックリスト

前提条件

• 現状Excelの構造（顧客一覧／ギフティング在庫・その他／ディナー／先方イベント参加／手紙／在庫管理／イベント一覧・出欠／マスタ）が本資料記載どおりであること
• 顧客規模 約1,220件、実名連絡先が機密であること

副作用・影響範囲

• フェーズ2の「次アクション横断管理」は各活動シートへの列追加（データ拡張）を伴い、既存Excelのフォーマット変更が発生する
• 内製ローカル運用は手元PC前提。外出先・複数人同時利用が要件化する場合は別途ホスティング設計が必要（バックアップ責任も自前）
• 既存資産（データモデル#101／画面#100／機能#99／PR原稿ツール基盤）を流用する前提。これらとの整合を保つこと

代替案（却下理由）

リスク・懸念事項

• 内製の保守はMNMLが担う（小規模で軽いが継続コストは発生）
• フェーズ2のデータ拡張はCEO承認が前提（未承認のまま列追加しない）
• 利用範囲（単独PC or 複数人・外出先）が未確定。ここが決まると設計規模が変わる