顧客管理システムの開発｜パッケージで足りない要件の見極め方と4つの開発方式【2026年版】

顧客管理システムを開発するかどうかは、「既製品が合わない気がする」という感覚ではなく、どの要件がどの方式で満たせないかで決まります。開発の選択肢は、SaaSの設定だけで組む、SaaSの上に拡張開発を重ねる、ローコード基盤で組む、スクラッチで作る、の4つです。この記事では4方式が届く範囲を比べ、独自の商流・基幹システムとの連携・個人情報の権限という3つの観点で、パッケージで足りない要件を切り分けます。要件定義からデータ移行、段階リリースまでの進め方と、開発に進むべき企業・見送るべき企業の条件も受託開発の立場で整理しました。

まとめ：顧客管理システムの開発は要件の切り分けと方式選びで決まる

顧客管理システムの開発で最初に決めるのは「作るか買うか」ではありません。要件を一つずつ見て、SaaSの標準機能で満たせるもの、設定や拡張開発で届くもの、スクラッチでなければ満たせないものに仕分けることです。多くの企業では大半の要件がSaaSの設定で満たせ、残る一部だけが開発の対象になります。

開発が必要になりやすいのは、取引先が代理店や販売店を挟む多階層の商流を持つ場合、受注・請求を持つ基幹システムと顧客マスタを同期させる必要がある場合、そして部署や拠点ごとに閲覧範囲を細かく分ける必要がある場合です。この3つに当てはまらないなら、まずSaaSの設定で始めてください。当てはまる場合も、いきなりスクラッチに進むより、SaaSの上に拡張開発を重ねる方式が先の候補になります。

進め方は、顧客の単位と名寄せのルールを決める要件定義、既存データの重複整理と移行リハーサル、1部署に絞った初回リリースの順です。開発費用の相場は別記事で扱い、ここでは方式の選び方と進め方に絞って解説します。

顧客管理システムを開発する4つの方式と、それぞれが届く要件の範囲

顧客管理システムの基本機能（顧客台帳・対応履歴・商談管理）は、顧客管理システムとは何か、Excelとの違いを整理した記事で解説しています。ここでは、その機能を自社向けに作り込む方式を4つに分け、どこまでの要件に届くかを比べます。

表のSaaSの設定はSalesforce・HubSpot・Zoho CRM、SaaS上の拡張開発はSalesforce（Apex等）・HubSpot（API）が代表例です。表の上から順に、初期の手間と運用の負担が重くなります。実務では上の方式から検討し、届かない要件が出たときだけ一段下に進むのが基本です。

SaaSの設定だけで構築する方式と、項目・画面・権限で届く範囲

SalesforceやHubSpot、Zoho CRMは、項目の追加、入力画面の並べ替え、ロール別の閲覧権限、条件に応じたメール通知や担当者の自動割り当てを、プログラムを書かずに設定できます。営業担当が10〜30名程度で、顧客と商談の関係が「1社に複数の担当者、1担当者に複数の商談」という標準の形に収まるなら、この方式で足ります。

限界は、データ構造そのものを変えたいときに出ます。製品が用意した「取引先」「取引先責任者」「商談」の関係を前提に画面が作られているため、その外側にある関係（たとえば契約と設置先が別の住所を持つ、など）を表すには次の方式が必要です。

Salesforce等のSaaS上に拡張開発を重ね、独自要件を足す方式

SaaSを土台にしたまま、独自のデータ構造やロジックを追加する方式です。Salesforceではカスタムオブジェクトと、Apexと呼ばれる専用言語で業務ロジックを書けます。HubSpotでもカスタムオブジェクトを設定画面またはAPIで定義できますが、HubSpotのナレッジベース（2026年9月12日更新）では対象がMarketing Hub・Sales Hubなど各製品のEnterpriseエディションとされています。独自オブジェクトが必要と分かった時点で、契約エディションの見直しが費用に響く点を先に確認してください。

この方式の利点は、ログイン・権限・監査ログ・モバイルアプリといった土台をSaaS側が保守し続けることです。代わりに、Salesforceの1処理あたりのクエリ回数上限（ガバナ制限）のような実行制限の中で設計する必要があり、大量データの一括処理は工夫が要ります。

kintone等のローコード基盤で組む方式とAPI上限の考え方

kintoneは、業務ごとに「アプリ」を作り、項目と画面をドラッグ操作で組み立てる基盤です。顧客台帳・対応履歴・見積をそれぞれアプリにして関連付ければ、現場の担当者でも顧客管理の仕組みを作れます。

注意したいのは外部連携の量です。cybozu developer networkの解説（2026年1月21日更新）によると、APIリクエスト数には1アプリ・1日あたりの上限があり、日本時間の毎日午前9時にリセットされます。レコード取得は1回500件までで、501件ならリクエスト数は2リクエストです。基幹システムと数分おきに顧客データを同期する設計にすると上限に近づきやすいため、連携の頻度と件数を要件定義の段階で見積もっておく必要があります。

スクラッチ開発で一から作る方式と、公開後に引き受ける運用責任の重さ

言語・データベース・クラウドを自社で選び、顧客管理システムを一から作る方式です。データ構造にも画面にも制約がなく、ユーザー課金も発生しません。反面、ログイン認証、権限、バックアップ、脆弱性への対応、OSやライブラリの更新を、公開後もずっと自社か委託先が担います。

スクラッチを選ぶのは、商流や業務の独自性そのものが競争力で、SaaSの標準モデルに合わせると業務を崩してしまう場合に限られます。一から作る場合の体制や技術選定は、フルスクラッチ開発のサービス紹介に対応範囲をまとめています。

パッケージで足りない要件を見極める、商流・基幹連携・権限の3観点

「自社の業務は特殊だから」という理由だけで開発に進むと、SaaSで足りた部分まで作り込んで費用と保守の負担を抱えます。開発が本当に必要かは、次の3つの観点で要件を一つずつ確かめてください。

代理店や販売店を挟む独自の商流が標準の取引先モデルに収まらない場合

SaaSの標準モデルは「自社が顧客企業に直接売る」形を前提にしています。メーカーが販売店経由で売り、エンドユーザーの設置先ごとに保守契約を持つ、といった三者以上の関係は、標準の取引先と商談だけでは表しきれません。

判断の目安は、1つの商談に「誰が買い、誰が使い、誰に請求するか」が別々の会社として3つ以上登場するかです。登場するなら、独自オブジェクトでその関係を持たせる拡張開発の対象になります。2つまでなら、標準の取引先に「販売店」の参照項目を足す設定で多くの場合は対応できます。

基幹システムとの連携で、顧客マスタの正をどちらに置くかの判断

受注・請求を持つ基幹システムがすでにある企業では、顧客の会社名や住所を「どちらのシステムが正しい値として持つか」を決めないまま連携すると、両方で書き換えが起きて値が食い違います。顧客管理システムを開発する案件の多くは、実はこのマスタ同期の設計が本体です。

実務では、請求先として使う会社情報は基幹側を正にし、見込み客や担当者の情報は顧客管理システム側を正にする分け方がよく採られます。片方向の同期で済むならSaaSの標準連携や連携ツールで足ります。双方向で、かつ取引先コードの採番規則が両システムで違う場合は、変換ロジックを持つ連携部分の開発が必要です。連携方式の選び方はMA・SFA・基幹をつなぐCRM連携の設計の記事で詳しく扱っています。

個人情報の保管場所と権限設計がSaaSの標準機能を超える条件

顧客管理システムは個人データの塊です。個人情報保護委員会のガイドライン（通則編・令和8年6月一部改正）は、10章で組織的・人的・物理的・技術的な安全管理措置と外的環境の把握を求め、3-4-4で委託先の監督を定めています。外的環境の把握とは、外国にデータを置く場合にその国の制度を把握することで、SaaSのデータ保管リージョンを確認する理由になります。

多くのSaaSはロール別の閲覧権限とアクセスログを標準で持つため、それだけで足りる企業がほとんどです。開発が必要になるのは、「同じ顧客でも、営業部は連絡先を見られるがサポート部は契約内容しか見られない」のように項目単位・部署単位で閲覧範囲を分け、さらに拠点ごとに例外を設けるような場合です。

顧客管理システム開発の進め方｜要件定義からデータ移行・段階リリースまで

方式が決まったら、開発は次の3段階で進めます。どの方式でも順番は同じで、省くと公開後の手戻りが大きくなります。

要件定義で最初に決める顧客の単位と、重複登録を防ぐ名寄せのルール

最初に決めるのは「顧客」を何の単位で数えるかです。法人単位か、事業所単位か、担当者個人単位かで、データ構造も画面も変わります。BtoBでは法人と担当者の2階層、店舗型のBtoCでは個人1階層が基本になります。

あわせて、同じ顧客が二重に登録されたときに「同一」とみなす条件を決めます。法人なら法人番号、個人ならメールアドレスと電話番号の組み合わせ、のように機械で判定できるキーを選ぶと、移行時と運用時の両方で重複を防げます。

Excelや名刺データを移行するときの重複整理と移行リハーサル

既存の顧客データは、営業担当ごとのExcel、名刺管理サービス、問い合わせフォームの受信履歴などに分散しているのが普通です。移行の前に、先に決めた名寄せのキーで重複をまとめ、表記の揺れ（株式会社の位置、全角と半角）を揃えます。

本番の切り替え前に、全件を検証環境へ流し込む移行リハーサルを最低1回行ってください。件数の突き合わせと、担当者・対応履歴の紐付けが正しく残っているかを確認しておくと、切り替え当日に「履歴が消えた」という問い合わせを防げます。

初回リリースを1部署に絞り、入力が定着してから範囲を広げる段階計画

全社に一度に展開すると、入力ルールが固まる前に例外の要望が集中し、改修が追いつきません。初回は1部署・必須項目を最小限に絞って公開し、2〜3か月使って入力が定着してから他部署へ広げます。

顧客管理システムは使われないと価値が出ません。必須項目を増やすほど入力は止まりやすく、現場がすでに記録している場所（メール、カレンダー、名刺）から自動で取り込める仕組みを先に作るほうが定着は早まります。

受託開発に進むべき企業と、SaaSの設定で済ませるべき企業の条件

ここまでの観点を踏まえ、判断を言い切ります。迷ったときは、下の条件に一つでも当てはまるかで決めてください。

拡張開発やスクラッチに進むべき条件と、その判断を裏付ける根拠

次の条件のいずれかに当てはまるなら、開発に進む価値があります。優先度の高い順に並べました。

1. 基幹システムと顧客マスタを双方向で同期する必要があり、取引先コードの採番規則が両システムで異なる
2. 1つの商談に買い手・使い手・請求先が別会社として3社以上登場する商流を持つ
3. 項目単位・部署単位の閲覧制限に拠点ごとの例外があり、SaaSのロール設定で表せない

1と2はSaaS上の拡張開発で解ける場合が多く、スクラッチが必要になるのは、3つすべてに当てはまり、かつ利用者が数百名規模でユーザー課金の総額が重くなる企業です。開発費用の積み上げ方と保守費の見込み方はCRMシステム開発の費用相場の記事で解説しています。

開発を見送りSaaSの設定で済ませるべき場面と、典型的な失敗の型

営業担当が30名以下で、顧客と商談の関係が標準モデルに収まり、基幹との連携が片方向で済むなら、開発はしません。この条件でスクラッチを選ぶと、ユーザー課金の節約分を保守費が上回りやすく、費用面で回収できないからです。

典型的な失敗は、既存のExcelの列をそのまま項目として再現しようとして作り込むことです。Excelの列には「とりあえず作った」項目が混ざっており、全部を移すと入力負担だけが増えます。SaaSの利用料と3年総額の考え方は顧客管理システムの費用相場の記事を、製品のタイプ選びは規模・業種別のおすすめタイプを整理した記事を参考にしてください。

開発会社に相談する前に社内で用意しておく資料と決めておく範囲

相談の前に、次の3つを用意しておくと、見積もりの前提が揃い比較しやすくなります。1つ目は、顧客・担当者・商談・契約などのデータと、その関係を描いた簡単な図です。2つ目は、連携が必要な既存システムの一覧と、どちらを正にしたいかの希望。3つ目は、初回リリースの対象部署と利用人数です。

SaaSの設定で済むのか、拡張開発が必要なのかの切り分けから相談できる窓口として、一創ではSalesforce導入支援とApex開発のサービスを提供しています。既存の設定を活かしたまま、不足する要件だけを開発で補う進め方にも対応します。

顧客管理システムの開発でよくある質問｜自作・方式選び・期間・連携・費用

顧客管理システムの開発を検討する担当者から寄せられることの多い質問に答えます。

顧客管理システムは自作できますか？

小規模で、顧客台帳と対応履歴を記録するだけならExcelやkintoneのようなローコード基盤で自作できます。ただし利用者が増えると、権限の管理、バックアップ、退職者のアカウント停止、個人データの安全管理措置を誰が担うかが問題になります。社内に保守を担う担当者を置けないなら、自作よりSaaSの設定から始めるほうが確実です。

SalesforceやHubSpotをカスタマイズするのと一から開発するのはどちらがよいですか？

大半のケースではカスタマイズが先の候補です。ログインや権限、モバイル対応といった土台をSaaS側が保守し続けるため、自社は独自の要件だけに開発費を使えます。一から開発するのは、商流の独自性が強く、標準モデルに合わせると業務を崩してしまう場合に限ります。HubSpotのカスタムオブジェクトはEnterpriseエディションが対象なので、契約の見直しも含めて比べてください。

顧客管理システムの開発期間はどのくらいかかりますか？

SaaSの設定中心なら、要件定義からデータ移行までで2〜3か月が一つの目安です。拡張開発や基幹連携を含むと、連携の本数と双方向かどうかで期間が延びます。どの方式でも、期間を短く保つ方法は初回リリースを1部署に絞ることです。全社展開は初回の定着を確認してから段階的に行う計画にしておくと、手戻りを抑えられます。

既存の基幹システムと連携させることはできますか？

できます。主要なSaaSはAPIを公開しており、基幹システムと顧客データを同期させられます。先に決めるべきなのは、会社名や住所などの値をどちらのシステムが正として持つかです。片方向の同期なら連携ツールで足りることが多く、双方向で取引先コードの体系が異なる場合は、変換ロジックを持つ連携部分の開発が必要になります。

顧客管理システムの開発費用はどのくらいですか？

方式と連携の本数で大きく変わります。SaaSの設定中心なら費用の中心はユーザー課金で、スクラッチ開発では初期の開発費に加えて毎年の保守費とインフラ費がかかります。機能別の開発費の積み上げ方を解説しているのは、CRMシステム開発の費用相場の記事です。見積もりを比べるときは、データ構造の図と連携先の一覧を揃えて依頼すると前提の違いによる差を減らせます。

関連記事

• CRMとは？顧客関係管理の機能・SFA/MAとの違いと導入メリット：CRMの全体像とSFA・MAとの役割の違いを整理したピラー記事です。
• CRMシステム開発の費用相場：スクラッチとSaaSの費用構造の違いと見積もりの読み方。開発方式を決めたあとの予算づくりに使えます。
• MA・SFA・CRM連携とは：3つのツールでどのデータをどちらに置くかを決め、二重管理を避ける設計を解説しています。
• 顧客管理をクラウドで始める：クラウド型とオンプレミス型の違い、SaaSと自社構築の選び方をまとめています。
• 顧客管理システムとは：顧客管理システムの機能とExcelとの違い、脱Excelの判断基準を整理した基礎記事です。