「売上表が絶対」— 研修会社が案件管理を自社で作り直した記録(中小企業 × AI 経営シリーズ)
案件の進捗と確定売上がバラバラだった研修会社が、1枚の売上表を『絶対の真実』に据え、Slack・スプレッドシート・ローカルDBを同期する案件管理基盤(SalesPoint)を自社で作り直した現場記。事故と恒久対策、二重登録を防ぐ設計まで。
はじめに:この記事の前提
Koinobori 代表取締役の杉﨑です。 社員5人の研修会社を経営しながら、自分で手を動かして社内の仕組みを作っています。この記事は、散らばっていた営業データを「自社の案件管理基盤」として作り直した記録です。完成形をきれいに見せる話ではなく、途中で本番データを壊して冷や汗をかいた話も含めて、ありのままに書きます。
1. なぜ作り直したのか — 「真実が2つある」問題
私たちの営業データには、ずっと “ねじれ” がありました。
- 確定した売上は、経理も使う1枚のスプレッドシート(研修事業の売上表)が事実上の「正」。
- 一方で、**案件の進捗(見込み・提案中・受注予定)**は、頭の中・メモ・Slack に散在。
つまり「これから受注しそうな案件」と「もう確定した売上」が別々の場所にあり、経営判断のときに突き合わせができない。月末に「で、目標に対して今どこ?」と聞かれても、即答できませんでした。
加えて私たちには制約があります。営業データは社外に出さない——顧客との守秘があるので、AIに処理させる場合もローカルのLLM(自社マシンのMLX/Ollama)だけ。外部APIには流しません。だから「クラウドの既製SaaSに全部預ける」も選びにくい。
そこで、自社内で完結する案件管理基盤を作ることにしました(社内名「SalesPoint」)。中身は地味で、SQLite・Googleスプレッドシート・社内Slack botの組み合わせです。
2. 何を作ったか(時系列)
3日ほどで、小さな機能を積み上げました。
| 作ったもの | 何が嬉しいか |
|---|---|
| 案件パイプライン(一覧・カンバン・見込み) | 進行中案件と確度別の見込み売上が一目で |
| Slack コマンド(案件追加/更新/フェーズ変更等) | 移動中でもスマホから案件を更新 |
| スプレッドシート双方向同期 | 専用アプリを覚えず、いつものシートで登録・編集 |
| ベタ貼り→ローカルLLM構造化 | 電話メモを貼るだけで案件化(※既出回) |
| 論理削除(消しても戻せる) | 誤操作が怖くない。チェック1つで削除、Slackで復元 |
| 確定売上との自動照合・金額追従 | 売上表が変わると案件側も自動で揃う |
| 担当の3区分(案件担当/講師/部署) | “担当” の意味が混ざっていたのを整理 |
| 目標シミュレーション | 去年の季節性×目標額で「今のペース」を可視化 |
ポイントは、新しいツールを増やさなかったこと。社員が普段触るのは「いつものスプレッドシート」と「Slack」だけ。裏で同期が回るようにしました。
3. 改善は、ほぼ「失敗から」だった
きれいに一直線では進みませんでした。むしろ学びは全部つまずきから来ています。
3-1. 作ったフォームを、その日に捨てた
最初に入力フォーム(スプレッドシートのサイドバー)を作り込みました。でも代表である自分が使ってみて「重い」。結局いつものシートで足りると気づき、フォームは撤去。手軽さを最優先しました。
3-2. 列を1本足したら、本番データが壊れた
項目を追加した直後、5分ごとに走る同期処理が列のズレを誤読してデータベースを書き換えてしまいました。担当者名が別の列に飛び、金額の対応が崩れた。幸い直前のバックアップから完全復旧(損失ゼロ)。そして再発しないよう、同期は「列の位置」ではなく「見出しの名前」で対応させ、レイアウトが変わった時は自動で書き直すだけにする恒久対策を入れました。壊れたら、その場しのぎでなく仕組みごと直す。
3-3. 「見込みと売上が少し違う」の正体
ある日「シミュレーションの数字と売上表が少しズレてる」と気づきました。差を分解するとちょうど数件分。原因は、最初の取り込み時の金額が凍結されていて、その後の売上表の修正(講師の休講などで金額は後から変動します)に追従していなかったこと。そこで「売上表が絶対。案件側は毎朝それに追従し、変わった分は私に通知してレビューさせる」仕組みにしました。
3-4. 営業→事務の「継ぎ目」で二重になりかける
最後に自分で気づいた穴。営業が「受注」にした案件を、後で事務が注文書をもとに売上表に登録すると、同じ取引が2件に増えてしまう。これを防ぐため、「同じ顧客に未確定の案件があるときは自動登録せず、“これは既存の○○と同じ案件ですか?”と必ず私に確認が飛ぶ」ようにしました。
4. 経営判断としての結論
作りながら言語化できた設計の芯は、4つでした。
- 真実は1つに置く:確定売上は売上表が絶対。システムは”正”を作らず、それに追従する。
- 自動化は継ぎ目で事故る:人と人(営業と事務)の受け渡し地点こそ、人の確認を1枚挟む。
- 手軽さが正義:立派なUIより、社員が既に使っている道具に寄せる。
- データの目利き:壊れている同期を使わず、信頼できるソースを選ぶ。
派手なAIの話ではありません。でも、経営者が自分で作ると、自社の”ねじれ”にピンポイントで効く。それが一番の収穫でした。
まとめ:3つのテイクアウェイ
- 営業の「見込み」と「確定売上」は、どちらが絶対かを先に決めると設計が一気に楽になる。
- 自動化を入れるほど、手動と自動の継ぎ目に確認を置く価値が上がる。
- 失敗(データ破損)は、仕組みを一段強くするチャンスにできる。バックアップだけは死守。
読者への問い: あなたの会社にも、「進行中」と「確定」で別々に管理されている数字、ありませんか?
この記事を読んだ方へ
中小企業の “自社に合った” 仕組みづくり、設計から伴走しています。
関連記事: ローカル LLM × Salesforce で案件登録を 10 分 → 5 秒に
執筆:Koinobori 株式会社 代表取締役 杉﨑
RELATED — 関連コラム
こちらもどうぞ
- HANDS-ON
ローカル LLM × Salesforce で案件登録を 10 分 → 5 秒に(中小企業 × AI 経営シリーズ #02)
Salesforce の案件入力に 10 分かかっていた壁を、自社ローカル LLM(MLX/Qwen 7B)で 5 秒に。社員 5 人の会社の代表(杉﨑)が自分で、電話メモのベタ貼りから JSON 抽出 → Salesforce API 登録までを自社内で完結させた現場記。幻覚対策と sanitize の二段構えも。
- HANDS-ON
なぜ私たちはローカル LLM を導入したのか(中小企業 × AI 経営シリーズ #01)
ChatGPT・Claude を API で便利に使っていた社員 5 人の会社が、2026 年 3 月、自社の中に LLM を持つことに決めた。シリーズ第 1 話、「使う側」から「持つ側」へ移った理由。
- HANDS-ON
タスク管理を「雑な初版」で 1 日で立ち上げ、3 週間で社内に馴染ませた話 — 中小企業 DX の完璧主義との決別(2026 年 5 月)
中小企業のタスク管理ツール導入が続かない最大の理由は『完璧な仕組みを半年かけて作ろうとする』こと。雑な初版を 1 日で出し、毎日 1 か所ずつ直して 3 週間で運用に乗せた、社員 5 人の会社の代表自身が手を動かした実録。