SFA移行の具体的な懸念点に全部答えます-VCのSFAをSalesforceから移行した話
「Salesforceが高い」「使いこなせていない」。この2つは、ここ1年で最も多くいただくご相談です。
ただ、ご相談は必ず同じところで止まります。
「で、本当にやめて大丈夫なんですか？」
そのお気持ちはよく分かります。SFAは営業の生命線です。止まったら売上も止まる。だからこそ、コストが見合っていなくても、機能の9割を使っていなくても、稼働中のシステムに手を入れるのは怖い。経営判断としては、むしろ自然なことだと思います。
この記事は、その「本当にいけるのか」という疑問に対し、支援した立場からすべてお答えするものです。
弊社（株式会社WerdeX）は、あるベンチャーキャピタル（以下、某VC）のSalesforceからAirtableへの移行を支援しました。社名は伏せますが、何が変わり、何がそのまま動き続けたのかを、支援した側の視点でお伝えします。
先に結論を書きます。
できなくなったことは、ありませんでした。 これは強がりではなく、もともと9割の機能を使っていなかったからです
移行で最も大変だったのはデータでも設計でもなく、「過去」の扱いでした。 実際にここでエラーが出ています
定着の決め手は、説明ではありませんでした。 入力作業そのものを無くしたことです
そして、移行はゴールではありませんでした。 SFAを替えた後に、営業業務そのものを組み替える余地が出てきました
最後の1つが、この記事で一番書きたいことです。Salesforceをやめる話は、本当は「乗り換え」の話ではありません。
1. 私たちも「本当にいけるのか」を調べる側でした
正直に書くと、このプロジェクトを立ち上げるとき、私たち自身も同じ疑問を持っていました。
当時、日本語で読める「SalesforceからAirtableに移した」という一次情報はほとんどありませんでした。参考にしたのは、HAKOBUNEの栗島さんの発信です。VC自身がAirtableを使っている先行事例です。それを読んで「なるほど、いけるのか」と思った側でした。
ただ、どれだけ読んでも消えなかった不安があります。それは「使っている会社の話」であって、「乗り換えた会社の話」ではなかったことです。
最初から導入するのと、動いているものを止めて移行するのとでは、難易度が全く違います。後者には「今動いている業務を止められない」という制約が重くのしかかるからです。
だからこそ、この記事は乗り換えた側・支援した側の視点から書きます。前者の情報はすでに世にあるため、まだ語られていない領域を埋めるのが目的です。
2. 移行前に何が起きていたのか（業務の実物）
抽象論を避けるため、VCの営業でよくある業務の流れを、今回の案件に近い形で整理します。少人数のチームで回している体制です。
ソーシング（投資先を探す）
外部の情報サービスで候補企業を探す
過去に接点がないかSalesforceで確認する
連絡して、Salesforceに登録する
面談
面談先の企業を調べる
面談の内容や議事録、受け取った資料をSalesforceに登録する
見ていただきたいのは、「Salesforceに登録」が何度も出てくる点です。
負荷は、判断ではなく転記に集中していました。そして転記作業は、人が手作業でやっている限り、どうしても後回しになりがちです。
ここが重要です。 この会社が困っていたのは「Salesforceの使い方が分からないこと」ではありません。使えている。使えているからこそ、手で入れ続ける量が見えていて、その負担が重かったのです。
「Salesforceが高い」という相談の中身は、多くの場合これに尽きます。金額が高いのではなく、払っている額に対して、人間が働きすぎている。
3. 疑問①「機能が足りないのでは」──9割は使っていなかった
一番多い不安から答えます。
結論から言うと、移行によってできなくなった業務はありませんでした。
強がりに聞こえるかもしれませんが、理由は単純です。元々、Salesforceの機能を全体の1割程度しか使っていなかったからです。
これは某VCが特別なわけではありません。多機能なSFAを導入した組織では珍しくない状態です。商談管理、活動履歴、承認フロー、予実管理、レポート……導入当初は「将来使うから」と盛り込みます。そして多くの場合、使われないまま契約だけが続きます。
だから、9割を捨てても誰も困りませんでした。捨てたのは機能であって、業務そのものではなかったからです。
逆に、Airtableで「できるようになった」ことがあります
これは想定外の成果でした。担当の方が、投資家向けに情報を共有するダッシュボードを独自に作り始めたのです。
Salesforceでも似たことはできます。ただ、外部の方に見せるにはアカウントごとの課金と細かい設定が必要で、そこが壁になっていました。Airtableなら、公開したいページ単位で手軽に共有できます。
「できる」と「実際にやる」の間には、設定コストと課金体系という壁があります。 機能一覧の比較表では、この差は絶対に出てきません。
そしてこのダッシュボードは、私たちが作ったものではありません。 担当の方がご自身で作られました。ここについては、第8章でもう一度触れます。
4. 疑問②「移行作業が大変では」──本当の難所は「過去」でした
移行期間は2〜3ヶ月でした。データ移行そのものは、正直に言えばそれほど大変な作業ではありません。
本当に大変だったのは、過去データの扱いです。
移行で起きやすいエラーを1つ例に挙げます。
たとえば新しい仕組みで、2回目の面談を登録するときに企業テーブルからその会社の過去データを探しに行く処理を組んだとします。ところが初回の面談が移行前に行われていると、そのデータは新しいツールには入っていません。
システムから見ると「2回目？ 初回のデータが無いのに？」という状態になり、処理が止まってしまいます。
これはツールの不具合ではありません。 「ある日を境に器が変わった」という、移行という行為そのものが持つ構造から来ています。どのツールに移っても同じことが起きます。
つまり、移行の難所は技術的な問題ではなく、「どこまで過去のデータを持っていくか」という意思決定でした。
全件持っていくのか
進行中の案件だけか
過去データはどのステータスとして扱うのか
ここを決めずに走り出すと、移行後に必ずこの手のエラーに直面します。逆に言えば、ここさえ決めておけば、データ移行の作業量自体は大きな山ではありません。
設計は一度で決まりませんでした
もう1つ、正直に書いておきます。テーブル設計は一発では決まりませんでした。
ヒアリングを重ね、必要な情報をラベリングし、設計して確認も取りました。それでも、その時点では何が本当に必要で何が不要なのか、分からない部分がどうしても残ります。
そのため、PoC（試験導入）を挟んで実際に使ってもらい、改めてフィードバックを受ける形を取りました。開発中も「ここはおかしいのではないか」と気づいたら、随時変更する前提で進めています。
これは失敗ではなく、進め方の選択です。要件が固まりきっていない業務システムを、最初の設計だけで作り切ろうとすると、手戻りの規模が致命的になります。
5. 疑問③「現場が使ってくれないのでは」──決め手は説明ではありませんでした
「今のSFAでも入力が追いつかないのに、別のツールにしても同じでは？」
これはその通りです。ツールを替えるだけでは、入力の負担は変わりません。
今回の案件で定着につながったのは、丁寧な説明でも研修でもありませんでした。入力作業そのものを無くしたことです。
具体的にはこうです。
問い合わせフォームを外部ツールにして、日程調整とAirtable登録を同時に済ませる
文字起こしツールの議事録を、自動でAirtableに流し込む
週次レポートを、ダッシュボードの常時表示に置き換える
結果として、入力のために画面を開く機会そのものが激減しました。
ここが移行の本質だと考えています。「新しいツールを使ってください」とお願いしている限り、定着はしません。 定着するのは、お願いする対象の作業が消えたときです。
⚠️ ただし、これは「すべてを自動化すべき」という意味ではありません。私たちは自動化できる技術があっても、あえてしなかった業務もあります。プロセスが固まっていない業務を無理に自動化すると、運用の変更が入るたびにシステムを改修することになるからです。この判断については別記事で詳しく書いています。
6. 疑問④「うちの規模でも同じことが起きるのか」
ここが一番一般化しにくい部分だと思いますので、条件を分けて整理します。
同じことが起きやすい会社
社員数が数十名規模までで、意思決定が速い
SFAの機能を、実際には一部しか使っていない
業務の負荷が「判断」ではなく「転記・報告」に集中している
実際に手を動かせる人が社内に1人はいる（エンジニアである必要はありません）
起きにくい会社
承認フローが多段階で、厳しい監査要件が求められる
既存の基幹システムと深く連携している
部署をまたぐ大規模な利用で、複雑な権限設計が必要
某VCがうまくいった最大の要因は、**「規模が小さく、業務全体が見える範囲にあった」**ことです。ツールの優劣ではありません。
逆に、上記の「起きにくい会社」に当てはまる場合は、無理に移行する必要はないと考えています。弊社でも、規模や要件を慎重に判断し、Airtableの採用を見送った案件があります。月あたりのレコード数が数万件規模で、将来的に10万件に達する見込みだった案件では、Airtableを避けて別のシステム構成を選択しました。
Airtableは万能なツールではありません。 フィットする適用範囲がはっきりしているツールです。
7. コストの実際
数字を公開します。ただし、コスト削減だけを移行の理由にするのは弱いというのが率直な意見です。理由は後述します。
弊社自身がCRMをSalesforceからAirtableへ移行した際は、年間約120万円が約15万円になりました（約87%減）。 月額で見ると、10〜30万円規模だった費用が1〜2万円規模に圧縮された計算です。
某VCの支援事例でも、入力作業は約70%減少し、月あたり約60時間の作業が消えました。 内訳としては、週次レポート作成が2〜3時間からゼロに、問い合わせ登録が1件15分からゼロに、議事録入力が10分からゼロになっています。
ただ、この数字だけを見て移行を決めるのはおすすめしません。
移行には初期の構築費、2〜3ヶ月の期間、そして綿密な設計の手間がかかります。ライセンス費用の差額だけを見ていると、投資回収までに時間がかかるように思える場合もあります。
本当に効果を発揮しているのは、浮いた60時間の方です。 少人数の組織にとって月60時間は、人ひとりの働き方が変わる量です。ライセンス費用の削減は、その副産物と捉えるのが正確です。
8. ここからが本題：SFAを替えた「先」に何があったか
ここまでが「乗り換えは可能か」という話です。ここからが、この記事で最もお伝えしたかった本題です。
移行が完了した後、この会社では「Salesforceの代替が動いている」という状態にとどまりませんでした。転記作業が消えたことで、その先の業務改善に手をつける余地が生まれたのです。
具体的に実装を進めたのは、次の4領域です。
① ソーシング（投資先探し）の自動化
外部の公開情報から候補企業のデータを収集し、LLMで企業プロファイルを作成して、スコアリングのうえAirtableへ蓄積する仕組みを構築しました。これまで担当者が手作業で検索し、コピペしていた工程です。
第2章で触れた通り、移行前のソーシングは、候補探しから登録まで手作業の工程が続いていました。この工程が、1件ごとに発生していました。
ここで大きかったのは、AIが「探す」こと自体ではありません。候補企業のデータが自動でテーブルに溜まり続ける状態を作れたことです。担当者は、蓄積されたリストを見ながら優先順位を判断する役割へと移行しました。
② 商談前の情報収集
企業情報の収集を、AIによる自動リサーチへ置き換えました。1社あたり20〜30分かかっていた下調べが、数秒で終わるようになっています。
面談前に相手企業を調べる作業は、不可欠である一方で成果に直結している実感が持ちにくい業務です。「やった方がいいのは分かっているが、時間がない」の典型例でした。
自動収集の仕組みにしたことで、この工程は「やるかどうか」を判断する対象から外れました。常に完了している状態が当たり前になった、というのが正確な表現です。
③ 定例・レポート・通知
担当者が週次レポートを作成する運用を廃止し、ダッシュボードの常時表示へ切り替えました。必要な通知はSlackへ自動配信されます。
ここには明確な数値成果が出ており、週次レポートの作成工数が2〜3時間からゼロになりました。
ただ、工数の削減以上に重要な変化があります。レポートが「作るもの」から「見るもの」へと根本的に変わったことです。レポートを手作業で作っていた頃は、当然ながら作成時点の静止画の情報しか載りません。常時表示に移行してからは、確認したい瞬間の最新データが常にそこにあります。
④ 面談記録の自動登録
Webフォームへの入力から日程調整、Airtableへの自動登録、議事録の連携までを一気通貫のパイプラインに統合しました。
移行前は、問い合わせを受けると手動で日程を調整し、面談後は議事録を要約してSalesforceへ入力し、添付されたピッチ資料も手作業でアップロードしていました。第2章の業務フローで「Salesforceに登録」が何度も出てきた原因の多くが、この工程です。
問い合わせの登録工数は1件あたり15分からゼロに、議事録入力も10分からゼロになりました。件数が積み重なれば、この差は決して小さくありません。
なぜこれが「移行の後」にしかできなかったのか
順番が逆では絶対に成立しないからです。
Salesforceに手動で転記していた時代は、あらゆるデータが人の手を経由していました。 人間が介在するということは、入力されるタイミングもフォーマットも表記もバラバラになるということです。その状態のままAIに処理をさせようとしても、データの前処理にばかり手間がかかり本末転倒になります。
移行によって、データが自動的に、一定のルールで揃って蓄積される環境が整いました。 その基盤ができて初めて、LLMを実際の業務プロセスに組み込むことが可能になったのです。
つまり、守るべき順番はこうです。
転記作業をなくす（＝データが自動で整然と溜まる仕組みを作る）
蓄積された綺麗なデータを前提に、業務フロー全体を組み替える
「AIを導入したものの期待した成果が出ない」というケースの多くは、1を省略して2に手をつけてしまっています。 手入力で揺れたデータにAIを載せても、出てくるのは整っていない出力です。
実際、この4つを動かした後で、担当の方が自分で作り始めました
第3章でご紹介した投資家向けダッシュボードは、この段階で自然発生的に生まれました。私たちが仕様を聞き取って開発したものではありません。担当の方が、必要なデータが綺麗に揃っている状態を見て、ご自身で手を動かして作り上げたのです。
さらに、そこから次なる改善要望が現場主導で自発的に上がってくるようになりました。具体的には、以下のような内容です。
投資家が個別のアカウントで安全にログインする
面談履歴を閲覧し、興味を持った企業に対してワンクリックで「紹介希望」を送信する
そのアクションが社内のSlackへ即座に通知され、スムーズに紹介業務へ動き出す
これらはすべて、私たちが提案した機能ではありません。 クライアント側から「こういうユーザー体験を作りたい」と明確に言語化して持ち込まれたものです。
ここにこそ本質的な価値があります。要望の「質」が劇的に変化したのです。 移行前の要望は「Salesforceの費用が高い」「入力の手間が重い」といった、今の負担を減らしたいというものが中心でした。しかし移行後の要望は、「こういう新しい価値や体験を顧客に届けたい」という、未来志向のアイデアになっています。
これこそが、今回の移行プロジェクトにおける最大の収穫だと考えています。 単なるコスト削減や作業時間の短縮ではなく、クライアント自身が新しい仕組みを作り始めたことです。
このフェーズに至ると、私たちの役割はもはや「受託の開発者」ではありません。現場のアイデアが実現可能かを共に検証し、実装手順を設計する伴走パートナーへと変化しました。結果として、外部へ依存する範囲が自然と小さくなっていったのです。
全員がAIを使いこなせるなら、Airtableも仕組みもいらないのか
「メンバー全員がAIを使いこなせるなら、わざわざ仕組みを組まなくてもいいのでは」と思った方もいるかもしれません。
それも一つの正解だと考えています。全員がClaude Codeを使えるなら、データベースを直接作っておけば十分です。人が触りやすいようにAirtableのようなアプリケーションを間に挟む必要もありません。欲しい情報でダッシュボードを作るのも、Hooksなどの機能でデータの登録や読み取りを自動で行い、商談の事前準備を済ませておくのも、すべてClaude Code経由でできます。
一方で、Airtableのように人が触りやすい画面を用意したり、GASを組んで業務プロセスに仕組みとして組み込んだりしておくと、誰が担当しても同じアウトプットが出て、チーム全員が同じようにLLMやエンジニアリングの恩恵を受けられます。先ほどの投資家向けダッシュボードも、担当の方がAirtableのInterface機能で作ったものです。組織の人数やフェーズによっては、全員のリテラシーを揃えるより、こちらの方が早く成果につながることもあります。
どちらが正しいという話ではなく、課題の背景や組織のポテンシャル、優先度によって、合うアプローチは変わります。 今回は仕組みを先に整え、その上で現場から新しいアイデアが出てくる流れになりました。
この段階で、やらなかったこともあります
ここまで読むとすべてが完璧に進んだように見えるかもしれませんので、あえて「採用しなかった判断」も記録しておきます。
技術的には十分可能でありながら、あえて自動化を見送った業務があります。
具体的には、2回目以降の面談にまつわる処理です。このプロセスは案件ごとに出席者の顔ぶれが変わり、面談の進め方そのものも臨機応変に変動します。手順が定型化されていない流動的な業務を無理に自動化すると、運用が少し変わるたびにシステムの修正に追われることになります。
自動化を急いだ結果、かえって業務の柔軟性が失われ、システムの改修作業という新たな無駄が生まれてしまっては本末転倒です。そのため、ここは人間の柔軟な判断に委ねる形をあえて残しました。
「負荷の高い業務」と「自動化すべき業務」は、イコールではありません。 作業の重さだけを基準に自動化を選定すると、ほぼ確実にこの罠に陥ります。
もう1つ、移行プロセスの途中で作成を取りやめたテーブルもあります。設計段階で「活動履歴」に相当するテーブルを用意していたのですが、日々の実業務を精査していくと、そのテーブルが何のために存在するのか、説明がつかなくなりました。用途が説明できないものは消す、という判断をしています。
設計の段階で箱を増やすのは簡単ですが、後から減らすのは極めて困難です。 項目を増やせば増やすほど、将来誰かがそのデータを手作業で埋め続けなければならなくなります。
順番を守れなかったらどうなるか
最後にもう一度、アプローチの順番の重要性に立ち返ります。
もしこの会社が、Salesforceの環境をそのまま残し、無理やりAIだけを導入していたらどうなっていたでしょうか。
おそらく、こうなります。人間が手作業で入力したデータには、必ず表記揺れが発生します。社名1つを取っても「株式会社〇〇」と「〇〇株式会社」が混在し、入っていない項目もある。そんな状態のデータにAIを適用しようとすれば、まず揺れを吸収する処理が必要になります。
そして往々にして、その前処理パイプラインの開発・保守コストが、自動化によって削減できる工数を上回ってしまいます。「AIを鳴り物入りで導入したのに、かえって現場の手間が増えた」という失敗の本質は、ほぼ例外なくここにあります。
今回の移行は、AIを載せるための準備作業でもありました。SFAを替えたこと自体が成果なのではなく、替えたことで初めて次に進めた、というのがこの案件の実際です。
9. この移行が向く会社・向かない会社
最後に、自社で検討する際の客観的な判断材料を整理します。
向いている会社
SFAの機能を実際には一部しか活用できておらず、高額な契約だけが漫然と続いている
現場の負荷が高度な「意思決定」ではなく、定型的な「転記・社内報告」に集中している
組織規模が数十名までで、経営・現場の意思決定スピードが速い
システム移行を起点として、AIを活用した本質的な業務改革を推進したい意思がある
向いていない会社（他社への外注開発や、既存エンタープライズSaaSの維持が合理的なケース）
極めて高い稼働率・可用性や、極めて厳格なセキュリティ要件が法的に義務付けられている
レガシーな社内基幹システムとの間に、複雑かつ高度なAPI連携を維持する必要がある
大規模なウォーターフォール型の要件定義・受託開発プロセスが組織の前提となっている
数万〜10万件規模のレコードを扱う
特に4点目は極めて重要ですので強調しておきます。Airtableのアーキテクチャには、明確に不向きなデータ規模が存在します。 実際に弊社でも、データ容量の制約から採用を見送ったケースがあります。
そして言うまでもありませんが、Salesforceというプロダクト自体が悪いわけでは決してありません。 某VCの事例においては、当時の体制で使う範囲に対して、機能が多かったというだけです。提供されている高度な機能群の9割を組織として使い倒し、売上向上に直結させている企業であれば、移行する理由はどこにもありません。
まとめ
要点を3行でまとめます。
できなくなった業務はありませんでした。 もともと9割の機能を使っていなかったからです
最大の難所はデータ移行作業ではなく、「過去データをどこまで扱うか」の意思決定でした。 ここを曖昧にしたまま進めると必ずエラーが出ます
ツールの移行はゴールではありません。 手作業の転記が消えてはじめて、AIによる抜本的な業務プロセスの再設計が可能になります
もし今、「Salesforceをやめるべきかどうか」で頭を抱えているのであれば、判断の基準を「費用の多寡」だけに置くのは避けるべきです。
直視すべきは、「現在支払っているライセンス費用に対して、現場の人間がどれだけの時間を手作業の入力に奪われているか」です。 その工数が組織全体で毎月何十時間にも達しているのだとすれば、見直す価値があるのは、ツールの契約よりも業務の流れの方です。
CRM・SFAの移行を検討されている方へ
「自社の現在の業務フローが、本当にAirtableで実現可能なのか分からない」——そうした疑問の壁打ちだけでも、お気軽にご相談ください。要件を拝見し、実現が難しいと判断した場合は率直にそうお伝えします！！ 実際、この記事でも触れた通り、データ規模や要件から導入を見送った事例もございます。
無理にツールを移行させることよりも、現在の業務プロセスを棚卸しして整理することの方が、結果としてはるかに本質的な改善につながると確信しているからです。
株式会社WerdeXについて
業務を、AI前提に再設計するAIコンサルティング会社です。AirtableによるCRM構築（Agent-CRM）、AI推進の伴走支援、実践型AI研修を提供しています。
