この記事は playpark Blog からの転載です。
この記事で分かること
- 小規模チームでSFA/CRMを導入しない選択をした背景
- Gitリポジトリを営業DBにするときの設計判断
- 他の選択肢（Notion / スプレッドシート / SFA）と比較した技術選定の理由
背景: こういう課題があった
2〜3人で営業を始めたばかりのチームで、SFA/CRMの選定が重荷になっていた。
- Salesforceクラスは1人月3,000〜25,000円。3人でも年間10万円超
- HubSpot / Zohoは機能の8割が不要で、設計フェーズで消耗する
- Notionは自由度が高すぎて「どう構造化するか」で合意が取れない
- スプレッドシートは変更履歴が残らず、誰が何を変えたかが消える
必要なのはライセンス費ゼロ、変更履歴が残る、テキスト編集できる、ロックインがないという4点だった。
選択肢の検討
実際に比較したアプローチを並べる。
| アプローチ | メリット | デメリット |
|---|---|---|
| SFA/CRM | 機能充実・権限管理 | 月額費用・機能過多・学習コスト |
| Notion | 自由度・UI | 構造化設計が重い・エクスポートが壊れる |
| スプレッドシート | 誰でも編集可 | 差分なし・衝突検知なし |
| Gitリポジトリ | 差分完全追跡・無料・ロックインなし | GitHub権限依存・同時編集制約 |
なぜGitリポジトリを選んだか
判断基準は3つ。
1. データの透明性
YAML/Markdownは人間もAIも読める。Notionのようにエクスポートして構造が崩れることがない。git diffで「いつ・誰が・何を変えたか」が完全にトレースできる。
2. 移行コスト
テキストファイルそのものがデータなので、将来SFAに移行するときも変換スクリプトを書くだけで済む。ロックインがない。
3. AI CLIとの相性
Claude Codeのようなファイル操作エージェントに任せるなら、ファイルシステムを直接読み書きさせるのが一番素直。APIラッパーを書く必要がない。
実装例
データ構造はこう設計した。企業ごとにディレクトリを切り、構造化データ（YAML）と履歴データ（Markdown）を分離する。
# companies/◯◯株式会社/pipeline.yml
status: 提案中
phase: 具体的なニーズあり
last_contact: "2026-03-15"
next_action: 見積書を作成して送付
next_action_deadline: "2026-03-22"
<!-- companies/◯◯株式会社/activities/2026-03-15_提案説明.md -->
---
date: "2026-03-15"
type: 提案説明
method: オンライン
result: 先方検討中。来週回答予定
---
提案書をベースにオンラインMTGを実施。
先方から「社内稟議を通す必要がある」との回答。
1ファイル = 1活動にすることで、ディレクトリ一覧そのものがタイムラインになる。ファイル名に日付と種別を含めればエディタ上で流れが追える。
スキーマをYAML1ファイルに集約する
ステータスの選択肢やフィールド名はschema.ymlに集約し、ダッシュボードから動的に読み込む。フィールドを追加したくなったらYAMLを1行編集するだけで、TypeScriptの型もダッシュボードのUIも追随する。Single Source of Truthの恩恵が一番効く場所だった。
まとめ: どういう場面で使うべきか
- 5人以下・立ち上げフェーズ: コストゼロで始められ、「まず動く仕組み」を手にできる
- 権限分離が必要な組織: GitHubリポジトリ単位の権限しか切れないので不向き。SFAを推奨
- モバイル中心の営業: CLI操作が前提なので合わない
5人以下のチームで「SFAを入れるほどでもないが、Excelでは限界」というフェーズに、Gitリポジトリ + YAML + AI CLIは現実的な選択肢になる。
さらに深掘りしたい方へ
この記事では技術選定の理由と全体設計を解説しました。
【Claude Code×営業管理】SFA不要。Git+YAML+Skillで営業パイプラインを自動化した話 ではさらに：
- 14サブコマンド（Gmail同期・議事録生成・企業分析・メール下書き）の設計
- 停滞案件の自動検知ロジックと、毎コマンド実行前に走る自動リマインドの仕組み
- ビルドテスト失敗時にcommitを止めるauto-deploy.shの安全弁設計
を扱っています。
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
