「顧客情報はExcel、案件の進捗はSaaS A、見積書はSaaS B」——気づけば、1件の商談を追いかけるだけで3つの画面を行き来している。そんな状態に心当たりがあれば、この記事が役に立つはずです。中小企業では、顧客管理・案件管理を「まずはExcelで」「とりあえず無料のSaaSで」と始めたものが、事業の成長とともに分散し、どれも中途半端に使われているケースが少なくありません。この記事では、顧客・案件情報をNext.jsで一元管理する設計と、既存のExcel台帳・複数SaaSからどう移行するかを整理します。
顧客・案件管理を内製すべきサインは何か?
「顧客の全体像を見るのに複数の画面を往復している」状態が続いているなら、内製を検討する価値があります。
以下のサインに複数当てはまる場合、情報の分散がコストになっている可能性が高いといえます。
- 同じ顧客の情報が、Excel・SaaS・メール・チャットに分散している。 過去のやり取りを確認するために、担当者の記憶かメール検索に頼っている。
- 案件の進捗が「担当者の頭の中」にしかない。 担当者が休むと、その案件の状況が誰にも分からなくなる。
- 無料〜安価なSaaSを複数契約し、どれも帯に短し襷に長し。 顧客管理はSaaS A、案件管理はSaaS B、請求はExcel、といった具合に部分最適が積み重なっている。
- SaaSの項目が自社の営業プロセスに合わない。 「初回接触」「見積提示」「社内稟議」「受注」という自社独自のステップをSaaS側のステータスに無理やり当てはめている。
- 複数のSaaSを連携させるための手作業(転記・CSV突合)が発生している。 ノーコード連携ツールでは対応しきれない項目や条件分岐がある。
一方で、以下に該当する場合は既存SaaSを続ける方が合理的です。
- 商談・案件の件数がまだ少なく、Excel1枚で十分に把握できている
- 標準的な営業プロセス(BtoB向けCRMの一般的な項目)で業務が回っている
- 社内にシステムを運用する担当者を置く余力がない

既製のCRM/SFAではなく内製にする理由は何か?
自社の営業プロセスに合わせて項目・ステータス・帳票を自由に設計でき、他の業務データ(見積・受発注・在庫)と同じ基盤に置けることが最大の理由です。
Salesforce・HubSpot・kintoneなど、既製のCRM/SFAは機能が豊富で、標準的な営業プロセスであれば十分に対応できます。それでも内製を検討する価値があるのは、以下のような場合です。
- 自社独自の営業プロセスがある。 業界特有の商談ステップ、複数部署が関わる承認フロー、顧客ごとに異なる契約形態など、既製ツールのステータス設計に収まらない業務がある
- 他の業務データと同じ基盤に置きたい。 見積書・受発注・在庫といった他の業務システムをすでにNext.jsで内製している(または内製を検討している)場合、顧客・案件データも同じ基盤に統合すると、部門をまたいだ検索や分析がしやすくなる
- 既製ツールのカスタマイズ費用が積み上がっている。 SaaSの標準機能では足りず、追加開発(カスタムオブジェクト、API連携)のオプション費用が積み重なり、月額料金以上の負担になっている
反対に、既製CRM/SFAを使い続けるべきなのは、名刺管理・メール連携・営業支援AIといった周辺機能を含めた「エコシステム」を丸ごと使いたい場合です。これらを内製でゼロから再現するのは現実的ではありません。
Next.jsでの顧客・案件データはどう設計するか?
顧客(companies/contacts)・案件(deals)・活動履歴(activities)の3テーブルを、顧客IDで紐付ける構成が基本です。
3つの主要テーブル
| テーブル | 役割 | 主な項目の例 |
|---|
| 顧客(companies / contacts) | 会社情報・担当者情報のマスタ | 会社名、業種、担当者名、連絡先、契約状況 |
| 案件(deals) | 進行中・完了した商談の単位 | 案件名、フェーズ、金額、担当営業、想定受注日 |
| 活動履歴(activities) | 顧客・案件に紐づくやり取りの記録 | 訪問・電話・メールの日時、内容メモ、次のアクション |
顧客と案件は1対多(1社が複数の案件を持つ)、案件と活動履歴も1対多の関係になります。Firestoreであれば顧客IDをキーにサブコレクションとして案件・活動履歴を持たせる設計、PostgreSQL(Supabase)であれば外部キーで顧客・案件・活動履歴を紐付ける設計になります。
案件フェーズの設計は自社の営業プロセスに合わせる
既製CRMの多くは「リード→商談→受注→失注」のような汎用的なフェーズを用意していますが、内製の利点はここを自社の実態に合わせて自由に設計できることです。
例: 建設業の場合
問い合わせ → 現地調査 → 見積提示 → 社内稟議待ち → 契約 → 着工
例: 製造業の場合
引き合い → 仕様確認 → 試作 → 量産見積 → 受注 → 量産開始
フェーズごとに「次に誰が何をするか」を明確にしておくと、案件が停滞したときに気づきやすくなります。
他の業務データとの接続を見据える
顧客・案件データを内製する最大のメリットは、受発注・見積書・在庫といった他の業務データと同じ基盤に置けることです。たとえば、受発注管理をSaaSからNext.jsフルスクラッチに切り替える判断基準で扱った受発注データと顧客IDで紐付けておけば、「この顧客の累計取引額」や「この顧客が最後に発注したのはいつか」を案件画面から直接参照できます。SaaSを複数契約している状態では、こうした横断参照のたびに手作業のCSV突合が発生しがちです。
Excel台帳や既存SaaSからどう移行するか?
顧客マスタを先に統合し、案件・活動履歴は「今動いている案件」から段階的に移す進め方が現実的です。
一度にすべてのデータを移行しようとすると、データの重複や表記ゆれ(「株式会社」の有無、担当者名の旧字体など)の処理に時間がかかり、プロジェクトが止まりがちです。移行の手順は以下の順序が現実的です。
- 顧客マスタの統合と名寄せ。 Excel・SaaS・名刺管理ツールに分散した顧客情報を1つのリストにまとめ、重複を排除する。表記ゆれの名寄せはAIによる支援で工数を圧縮できる領域です(詳細はExcel台帳をNext.jsに移行する設計を参照)
- 進行中の案件だけを先に移す。 完了済み・失注済みの古い案件は過去データとして参照できればよく、無理に新システムのフェーズ設計に当てはめる必要はありません
- 並行運用期間を設ける。 旧SaaS・Excelと新システムを一定期間並行稼働させ、現場が新しい画面に慣れる猶予を作る
- 旧SaaSの契約終了タイミングを合わせる。 移行が安定してから解約することで、「移行したのに旧システムのデータが必要だった」という手戻りを防ぐ
なお、顧客との過去のやり取りを「意味で検索したい」というニーズがある場合は、活動履歴の蓄積とは別の設計が必要です。この点は顧客対応履歴をNext.js×AIで検索できる仕組みの設計で扱っている内容で、本記事の「情報を構造化して一元管理する」話とは目的が異なります。過去のやり取りを曖昧な言葉で探したいのか、案件の進捗を管理したいのかによって、優先すべき設計は変わります。
内製の費用感はどのくらいか?
当社の開発費用は1時間11,000円(税込)が基準です。対象データ量・既存システムとの連携範囲によって工数は変わるため、ヒアリング後に要件定義・開発・移行・テストの各工程を見積もり、概算をご案内します。
顧客・案件・活動履歴の3機能程度の最小構成であれば、既存の受発注・見積システムと同程度の規模感になることが多いですが、正確な工数はデータ移行の複雑さ(表記ゆれの多さ、連携先SaaSの数)に左右されます。お客様が開発工数をご自身で見積もる必要はありません。
判断材料として比較しやすいのは、以下の2つの費用を並べることです。
- 既製CRM/SFAを使い続けた場合の年間コスト。 月額料金 + カスタマイズオプション費用 + 連携ツールの費用を年間換算する
- 内製した場合の初期費用 + 保守費用。 保守費用の考え方はNext.js保守運用の費用と契約で扱った月額固定・チケット制の考え方がそのまま当てはまります
既製CRM/SFAの一般的な料金水準
自社が今どのくらいの料金帯にいるかを把握するために、主要ツールの公開されている料金体系(課金モデルの違い)を整理します。
| ツール | 課金モデル | 目安の料金帯(公開情報) |
|---|
| kintone | ユーザー数に応じたプラットフォーム課金 | 月額1,000円台〜/ユーザー |
| HubSpot | 有償シート数に応じたシート課金 | 無料プランあり、有償は月額2,000円台〜/シート |
| Zoho CRM | ユーザー課金 | 月額1,000円台〜/ユーザー(上位プランはより高額) |
| Salesforce | ユーザー課金 | 月額数千円〜/ユーザー(AI活用の上位プランはさらに高額) |
これらは基本プランの目安であり、カスタマイズオプションや連携ツールを追加するとユーザー数×月額の何倍にも膨らむことがあります。基本料金は安いが、自社仕様に近づけるためのオプション費用が積み上がっている——その状態であれば、内製の初期費用と比較する価値があります。 逆に、基本プランの範囲で業務が回っているなら、内製に切り替えるメリットは小さくなります。
SaaS疲れの整理と判断軸は中小企業の「SaaS疲れ」を解消するでも扱っているので、複数のSaaSを見直すタイミングであればあわせて確認してください。
まとめ
顧客・案件情報が複数のExcel・SaaSに分散し、担当者の記憶に頼った運用になっているなら、内製での一元管理を検討するタイミングです。顧客・案件・活動履歴の3テーブルを軸に、自社の営業プロセスに合わせたフェーズ設計を行い、既存の受発注・見積データと同じ基盤に置くことで、部門をまたいだ参照がしやすくなります。移行は顧客マスタの統合から始め、進行中の案件だけを先に移す段階的な進め方が現実的です。
私たちは、Next.js × Firebase構成での業務システム開発を、中小企業の実際の営業プロセスに合わせて内製する形でお手伝いしています。顧客・案件管理に限らず、「既存SaaSの一部だけ内製したい」という部分的な相談も歓迎します。15分のカジュアルな相談も受け付けていますので、要件が固まっていない段階でもお気軽にご相談ください。
技術仕様・対象バージョンは本文と参照先をご確認ください。
最終更新:2026年9月11日