顧客管理システムの設計：顧客データの項目と名寄せの考え方

顧客管理システムの設計で最初に決めるべきなのは、画面のレイアウトや入力項目の一覧ではなく、「顧客」とは何を指すのか、そして法人・担当者・取引がどのような関係でつながっているのかというデータの構造です。この構造を曖昧にしたまま項目を並べ始めると、同じ会社が何件も登録される、担当者が異動すると履歴が追えなくなる、集計のたびに数字が合わない、といった問題が後から必ず起きます。

この記事は、顧客管理システムを新しく作る、または既存のExcelや旧システムから作り直そうとしている企業の担当者や、開発会社に要件を伝える立場の方に向けて書いています。顧客データの基本構造、法人・担当者・取引の関係の持ち方、項目設計の手順、重複データを防ぐ名寄せの方針、設計段階で決めておくべき運用ルールを、具体例を交えて説明します。

要点を先にまとめると、顧客データは「会社（法人）」「人（担当者）」「関係（所属・役割）」「出来事（取引・活動）」を分けて持つこと、項目は「誰が何に使うか」で選ぶこと、そして重複をどう見つけ、どちらを残すかの名寄せ方針を、データを入れ始める前に決めておくことが重要です。

顧客管理システムの設計で失敗しやすい理由

顧客管理システムの設計が難しいのは、現実の顧客の姿が単純な一覧表に収まらないからです。たとえば次のような状況は、どの会社でも日常的に起こります。

• 一つの会社に、窓口の担当者、決裁者、経理の担当者など、役割の違う複数の人がいる
• 担当者が異動や転職で別の部署や別の会社に移る
• 同じ会社に、本社、支店、グループ会社など複数の拠点や法人がある
• 個人の顧客が、ある時期から法人の顧客にもなる
• 同じ会社が、表記の違い（株式会社の位置、略称、全角・半角）で別々に登録される

Excelの顧客台帳では、これらを一行に詰め込んで管理していることが多く、そのままの形でシステムに移すと、問題もそのまま移ってしまいます。システム化は、顧客データの構造を整理し直す機会でもあります。

顧客データの基本構造：法人・担当者・関係・取引を分ける

顧客データを設計するときは、まず情報を次の四つに分けて考えます。

このように分ける理由は、それぞれの情報が変化するタイミングが違うからです。法人の情報はあまり変わりませんが、担当者は異動し、役割は変わり、出来事は日々積み重なります。一つの表にまとめてしまうと、担当者が変わったときに過去の出来事が誰の対応だったのか分からなくなったり、法人の住所を変えるために何行も直したりすることになります。

法人と担当者の関係を「所属」で持つ

担当者を法人の下に直接ぶら下げる設計は単純ですが、担当者の異動や転職に対応できません。担当者と法人の間に「所属」という関係を置き、所属の開始日と終了日、役割を持たせると、次のことができるようになります。

• 担当者が異動しても、過去の所属先と、その時期の対応履歴を残せる
• 担当者が転職して別の顧客企業に移った場合も、同じ人物として関係を引き継げる
• 一つの法人に役割の違う複数の担当者がいることを表現できる

ただし、すべての顧客管理にこの構造が必要なわけではありません。担当者の異動を追う必要がなく、法人ごとの窓口が一人か二人という業務であれば、担当者を法人に直接紐づける単純な構造で十分です。必要な複雑さは、業務で何を知りたいかで決まります。

法人の階層をどう扱うか

本社と支店、親会社とグループ会社のように、法人どうしに階層がある場合は、「どの単位を取引の相手とするか」を決めます。請求先は本社、納品先は支店、というように役割によって単位が違う場合は、法人に「請求先」「納品先」などの役割を持たせるか、拠点という単位を別に設けます。グループ全体での取引額を見たい場合は、法人に親会社への参照を持たせておくと集計できます。

データの構造は、ER図（実体関連図）として図にしておくと、開発会社や社内の関係者との認識合わせがしやすくなります。

項目設計の手順

構造が決まったら、それぞれに持たせる項目を決めます。項目は多ければよいわけではありません。項目が増えるほど入力の負担が増え、空欄だらけのデータになります。

1. 顧客データを使う場面を洗い出す：営業の訪問準備、請求書の発行、メールの配信、問い合わせ対応、経営への報告など、顧客データを使う場面を一覧にします。
2. 場面ごとに必要な情報を書き出す：それぞれの場面で、どの情報がなければ困るのかを書き出します。「あれば便利」な情報と「なければ困る」情報を分けます。
3. 項目を区分に割り当てる：書き出した情報を、法人・担当者・関係・出来事のどこに持たせるかを決めます。たとえば「役職」は担当者に持たせるか所属に持たせるかで、異動の扱いが変わります。
4. 入力の責任者と時点を決める：各項目を誰が、どの時点で入力・更新するのかを決めます。入力の責任者が決まらない項目は、更新されずに古くなります。
5. 入力の形式を決める：自由記述、選択肢、日付、数値など、入力の形式を決めます。集計に使う項目は、できるだけ選択肢にします。選択肢の一覧は、マスタデータとして管理し、変更の手順を決めておきます。
6. 必須項目を最小限にする：登録の時点で必ず分かり、なければ業務が進まない項目だけを必須にします。それ以外は、後から補えるようにします。

項目設計の判断の例

最後の行のように、出来事の履歴から計算できる情報は、項目として入力させずに自動で求めるようにします。「最終接触日」や「累計取引額」を手入力にすると、更新されずに実態とずれていきます。

重複データの名寄せの考え方

顧客データの品質を最も損なうのが重複です。同じ会社や同じ人が複数件登録されていると、対応の履歴が分散し、二重に連絡してしまったり、集計の数字が実態より多くなったりします。重複したデータを見つけて一つにまとめる作業を名寄せと呼びます。

名寄せは、データを入れた後に行う掃除だと考えられがちですが、設計の段階で方針を決めておくことが大切です。決めておくべきことは次の三つです。

1. 同一と判定する基準

何が一致すれば同じ会社・同じ人とみなすかを決めます。

• 法人：法人番号が一致すれば同一とする。法人番号がない場合は、正式名称と所在地の組み合わせで判定する。名称は、法人格の表記（株式会社、(株)など）、全角・半角、空白を統一してから比較する。
• 担当者：メールアドレスが一致すれば同一の候補とする。氏名と所属法人の組み合わせ、電話番号も手がかりにする。ただし、共有のメールアドレス（代表アドレスなど）は判定に使わない。

判定の基準が強すぎると重複を見逃し、弱すぎると別の会社や人を誤ってまとめてしまいます。自動でまとめるのは確実に同一と言える場合に限り、それ以外は候補として人が確認する二段階の仕組みにするのが安全です。

2. どちらを残すか（統合のルール）

重複が見つかったとき、どちらのデータを残し、項目の値をどう統合するかを決めます。たとえば、「より新しく更新された方の値を残す」「より信頼できる入力元（契約書から登録したもの）の値を優先する」「空欄は他方の値で埋める」といったルールです。統合したときに、出来事の履歴は両方をまとめて残すようにします。

3. 重複を作らない入力の仕組み

最も効果的なのは、そもそも重複を作らないことです。新規登録の際に、名称やメールアドレスで既存のデータを検索し、似たデータがあれば表示して確認を促す仕組みを入れます。外部からデータを取り込む場合（Webフォーム、名刺管理、展示会のリスト）も、取り込みの時点で既存データとの照合を行います。

表記の統一や不要なデータの除去といったデータの整え方は、データクレンジングの考え方も参考になります。

顧客を識別するIDの持ち方

名寄せとあわせて決めておきたいのが、顧客を識別するIDの持ち方です。システム内部では、法人・担当者のそれぞれに、変わることのない一意のIDを振ります。会社名やメールアドレスは変わることがあるため、これらをIDの代わりに使うと、変更のたびに関連するデータの付け替えが必要になります。

他のシステム（会計、販売管理、メール配信、Webサービスなど）とデータを連携する場合は、相手のシステムでの顧客番号も項目として持たせ、どの顧客がどのシステムのどの番号に対応するかを管理します。名寄せで二つの顧客をまとめたときには、まとめられた側のIDと他システムの番号を、残った側に引き継ぐ記録を残しておきます。これを怠ると、連携先のシステムから届いたデータが、統合後の顧客に紐づかなくなります。

架空の例：研修会社の顧客データの整理

法人向けの研修を提供している会社を考えます。これまでは、営業担当ごとのExcelと、研修の申込みフォームから集まったデータで顧客を管理していました。顧客管理システムを作るにあたってデータを集めてみると、同じ会社が表記違いで何件も存在し、申込者が転職して別の会社から申し込んでいるケースも多くありました。また、研修の申込者（受講者）と、研修の発注を決める人事担当者が混在して管理されていました。

この会社は、データの構造を次のように整理しました。法人と担当者を分け、担当者と法人の間に所属を置いて、所属ごとに「人事担当」「受講者」「決裁者」の役割を持たせました。研修の申込みと受講は出来事として記録し、受講者が転職した場合も同じ人物として受講履歴を引き継げるようにしました。名寄せは、法人番号と正規化した名称で法人を判定し、担当者はメールアドレスを主な手がかりにしつつ、候補は営業担当が確認してからまとめる運用にしました。

この整理により、「どの会社の人事担当者に、どの研修の案内を送るべきか」「転職した過去の受講者が新しい会社で研修を検討していないか」といった、営業にとって価値のある問いに答えられるようになりました。既存データを新しい構造に移す手順は、顧客データ移行の手順：Excelや旧CRMから新システムへ移す注意点で詳しく扱っています。

設計段階で決めておくべき運用ルール

データの構造と項目が決まっても、運用のルールがなければデータの品質は保てません。設計の段階で、次のルールを決めておきます。

• 登録の権限：誰が新しい法人・担当者を登録できるか。全員が登録できる場合は、重複の確認を必須にする。
• 更新の責任：法人の情報は誰が更新するか、担当者の異動を知ったら誰が所属を更新するか。
• 削除と無効化：取引のなくなった顧客や退職した担当者を削除するのか、無効にして履歴を残すのか。原則として、削除ではなく無効化にして履歴を残す。
• 名寄せの実施：重複の候補を誰がどの頻度で確認し、まとめるか。
• 連絡の可否の管理：メール配信や電話の可否、配信停止の希望をどの項目でどう管理するか。個人情報の取り扱いについては、最新の制度を公的機関や専門家に確認する。
• 選択肢の変更：業種や役割などの選択肢を追加・変更する手順と、承認者。

これらのルールは、操作手順書と一緒にまとめ、導入時に利用者へ説明します。運用を始めた後は、月に一度程度、重複の候補の件数、必須でない重要項目の入力率、無効化されずに残っている古い担当者の数などを確認すると、データの品質が下がり始めたことに早く気づけます。品質の確認を誰の仕事にするかを決めておかないと、誰も見ないまま重複や古い情報が積み上がっていきます。顧客データは営業、サポート、経理など複数の部門が使うため、確認の担当は特定の部門に偏らせず、部門をまたいで調整できる人に任せるのが理想です。

よくある失敗とその避け方

• Excelの列をそのまま項目にする：既存の台帳の列をそのままシステムの項目にすると、一行に詰め込まれていた複数の情報（複数の担当者、複数の住所）がそのまま残ります。台帳の列を、法人・担当者・関係・出来事に分解し直します。
• 項目を増やしすぎる：「いつか使うかもしれない」項目を足していくと、入力の負担が増え、空欄だらけになります。項目ごとに使う人と場面を確認し、説明できない項目は削ります。
• 手入力の集計項目を作る：最終接触日や取引額のように、履歴から計算できる値を手入力にすると、更新されずに実態とずれます。自動で計算する設計にします。
• 名寄せを後回しにする：重複を後から片づければよいと考えてデータを入れ始めると、履歴が分散し、後からまとめる作業が膨大になります。登録時の重複確認と、名寄せの基準を最初から用意します。
• 削除で履歴を失う：取引のなくなった顧客を削除すると、過去の取引の履歴も失われます。無効化の仕組みを用意し、削除は誤登録の場合に限ります。

設計前のチェックリスト

• 自社にとっての「顧客」が、法人・個人・拠点のどの単位を指すかを決めている
• 法人・担当者・関係・出来事の区分で、データの構造を図にしている
• 担当者の異動や転職を追う必要があるかを判断している
• 顧客データを使う場面と、場面ごとに必要な情報を洗い出している
• 各項目の入力の責任者と、入力・更新の時点を決めている
• 必須項目を最小限に絞り、計算できる値は自動にしている
• 法人と担当者の同一判定の基準と、統合のルールを決めている
• 登録時の重複確認の仕組みを要件に入れている
• 削除と無効化、連絡の可否の管理のルールを決めている

よくある質問

Q. 個人の顧客と法人の顧客を同じシステムで管理できますか？

管理できます。個人の顧客を「担当者」と同じ人の情報として扱い、法人との所属がない人として持つ方法や、顧客の種別を持たせて画面を切り替える方法があります。個人の顧客が後に法人の顧客にもなる業務では、同じ人物として履歴をつなげられる構造にしておくと便利です。

Q. 名寄せは自動ですべて行えますか？

確実に同一と判定できる場合（法人番号の一致など）は自動でまとめられますが、名称の似た別会社や、同姓同名の別人を誤ってまとめるおそれがあるため、すべてを自動にするのはおすすめしません。自動でまとめる範囲と、候補を人が確認する範囲を分けて設計します。

Q. 既製のCRMを使う場合も、この設計は必要ですか？

必要です。既製のCRMにも、会社・担当者・商談などの標準の構造がありますが、自社の業務でどの情報をどこに持たせるか、必須項目や名寄せのルールをどうするかは、自社で決める必要があります。既製CRMか自社開発かの判断については、CRMを自社開発すべきか：Salesforce・HubSpotとの比較と判断軸で説明しています。

Q. 顧客データの項目は、後から追加できますか？

項目の追加自体は、多くの場合それほど難しくありません。難しいのは、法人と担当者の関係のような構造の変更です。項目は必要になってから足せばよいので最小限から始め、構造は将来の使い方を見据えて最初に決めておく、という考え方をおすすめします。

Otsumuに相談できること

顧客の数がそれほど多くなく、法人と担当者の関係が単純な業務であれば、既製のCRMや業務アプリの標準の構造を使い、この記事の項目設計の手順と名寄せの基準を社内で決めていくことで十分に整えられます。まずはチェックリストを使って、自社にとっての「顧客」の単位と必要な項目を整理してみてください。

一方で、法人の階層や担当者の異動を追う必要がある、物件や設備など顧客以外の情報との関係が複雑、複数のシステムに散らばった顧客データを統合して名寄せしたい、という場合は、データの構造の設計から外部の力を借りた方が、後からの作り直しを避けられます。

Otsumuは、顧客データを使う場面の洗い出しから一緒に行い、業務に必要な複雑さに見合ったデータの構造と、名寄せや運用のルールを設計します。そのうえで、既製のCRMを使う場合の設定方針、または自社開発や既存システムとの連携を、目的に必要な範囲に絞って支援します。詳しくはCRM・顧客管理システム開発のページをご覧ください。費用は範囲に応じて個別にお見積もりします。

顧客データが散らばっていて何から手を付ければよいか分からない段階でもご相談いただけます。30分の無料相談からご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01