CRMに入れたデータが検索しても出てこない。原因は「命名規則」だった
執筆：泉 款太（株式会社SalesDock 代表取締役）累計40社以上の中小企業を支援
結論
CRMのプロパティ名は「カテゴリ_項目名_属性」の3層（例：deal_expected_amount）で統一し、内部名は英語のスネークケース、日本語は表示名に持たせます。同じ概念を部門ごとに別プロパティで作らないことと、追加を管理者に集めてプロパティ辞書に残すことが、検索や集計で「データが出てこない」状態を防ぎます。
CRM導入プロジェクトで最も地味だが、最も後から効いてくるのが「プロパティ（項目）の命名規則」だ。営業部は「初回アポ日」、マーケ部は「初回接触日」、カスタマーサクセスは「オンボーディング開始日」。同じ概念を3つの名前で呼んでいる状態でCRMに突っ込むと、プロパティが際限なく増え、誰も正しいデータがどこにあるかわからなくなる。
この記事で言う「検索しても出てこない」は、CRM上で絞り込みやレポートをかけたとき、本来ヒットするはずの顧客が抜ける状態を指す。原因の多くは、データの欠損ではなく、同じ意味の項目が複数のプロパティに分かれて入力されていることにある。以下、原因の整理、命名規則のテンプレート、避けたい5つのアンチパターン、運用ルールの順に説明する。
CRMで検索・絞り込みに出てこない原因：同じ意味の項目が複数のプロパティに分かれている
規模を問わず起こりやすいのが、営業・マーケ・CSがそれぞれ独自のExcelやスプレッドシートで顧客情報を管理しているパターン。各部門のExcelは、その部門にとって最適化されているが、用語体系がバラバラだ。
| 概念 | 営業部の呼び方 | マーケ部の呼び方 | CS部の呼び方 |
|---|---|---|---|
| 最初の接点 | 初回アポ日 | 初回接触日 | - |
| 案件の金額 | 見込み金額 | MQL金額 | 契約金額 |
| 顧客のステージ | 商談フェーズ | リードステータス | 契約ステータス |
| 失注・解約の理由 | 失注理由 | 離脱理由 | 解約理由 |
部門ごとに異なる解約理由を共通化する場合は、解約理由を集計可能な分類へ整える方法で、顧客の発言と社内分類を分けます。
営業は「初回アポ日」、マーケは「初回接触日」と、同じ意味の項目を別々に管理したままCRMへ移行すると、2つが別プロパティとして作成され、片方にしかデータが入らない。レポートはどちらを見ればよいか判断できず、集計から顧客が抜ける。この混乱は、運用が始まって集計やレポートを作る段階で表面化しやすい。
命名規則テンプレート：カテゴリ_項目名_属性
プロパティ名は「カテゴリ_項目名_属性」の3層構造で統一する。英語のスネークケース（小文字+アンダースコア）が基本。
命名規則の構造
カテゴリ（どの領域か）
lead_ / deal_ / company_ / cs_ / billing_
項目名（何のデータか）
first_contact / amount / stage / lost_reason
属性（データの性質）
_date / _amount / _status / _count / _flag / _note
命名例
lead_first_contact_date ← リードの初回接触日
deal_expected_amount ← 案件の見込み金額
deal_stage_status ← 案件のステージ
deal_lost_reason_note ← 失注理由（自由記述）
cs_onboarding_start_date ← CS開始日
cs_churn_reason_status ← 解約理由（選択式）
日本語のラベル名（CRM上の表示名）は自由に設定してよい。重要なのは、内部名（API名）が統一されていること。HubSpotの場合、プロパティの「内部名」は後から変更できないので、最初に正しく設定する必要がある。
HubSpotのプロパティ設計で避けるべき5つのアンチパターン
1. 同じ概念を複数プロパティで持つ
同じ意味の項目を部門ごとに別プロパティで作ると、データが分散して集計から漏れる。1つの概念は1つのプロパティにまとめ、内部名も表示名も1つに統一する。部門ごとの呼び方の違いは、プロパティ辞書に別名として記録する。
同じ分散は行の側でも起きて、法人格や中黒の有無で同じ会社が複数行に割れる。行が割れると議事録と案件が別の行にぶら下がるので、突合キーの決め方はNotionに顧客DBを作ったのに情報が集まらない—「同じ会社が3行ある」を直す名寄せ設計で扱っている。命名の前に、どの項目をいつ・誰が入れるかまで決める手順は、CRM構築の進め方｜導入前に作るデータ定義書の7項目で詳しく解説しています。
2. 自由記述フィールドを乱発する
「備考」「メモ」「その他」のような自由記述フィールドは便利だが、集計・分析ができない。失注理由を自由記述にすると「価格が高い」「高い」「コスト的に難しい」「予算超過」が全て別データになる。選択式にして、選択肢に「その他（自由記述）」を設けるのが正解。
3. 日本語の内部名を使う
内部名に日本語を使うと、API連携やワークフローでの参照が煩雑になり、外部ツールとの連携時に扱いづらくなりやすい。内部名は英語のスネークケースで統一し、日本語は表示名（ラベル）に持たせる。作成後に内部名は変更できないため、作成画面で内部名を確認してから保存する。
4. プロパティグループを整理しない
HubSpotはプロパティをグループ単位で管理できる。グループを使わずにプロパティを作り続けると、数が増えるほど「どこに何があるか」がわからなくなる。最低限、以下のグループ分けをしておく。
推奨プロパティグループ
- basic_info：基本情報（会社名、住所、業種等）
- lead_management：リード管理（リードソース、スコア、ステータス）
- deal_management：案件管理（フェーズ、金額、確度）
- cs_management：CS管理（契約開始日、利用状況、NPS）
- marketing_tracking：マーケ計測（流入元、キャンペーン、CV日）
- custom_scoring：カスタムスコアリング（独自の評価項目）
5. 削除せずにプロパティを増やし続ける
使われなくなったプロパティを放置すると、データ入力時に「どれに入れればいいかわからない」状態になる。四半期に1回、プロパティの利用状況を確認し、しばらく更新されていないプロパティ（90日は目安）は非表示にするか削除する。実際の更新状況はCRMの画面やレポートで確かめる必要があるため、まずプロパティの一覧を出して、各プロパティの担当者と用途を辞書と突き合わせる。
10名以上の営業チームでの運用ルール
命名規則を決めただけでは、運用は回らない。10名以上の営業チームで統一的にCRMを使い続けるには、以下の3つのルールが必要になる。
ルール1：プロパティ追加は管理者のみ
一般ユーザーにプロパティ追加権限を与えない。追加が必要な場合は、社内の専用窓口（チャットやフォーム）でリクエストし、管理者（1〜2名）が命名規則に沿って作成する。
ルール2：プロパティ辞書を維持する
全プロパティの一覧表（内部名・表示名・説明・データ型・作成者・作成日）をスプレッドシートで管理する。新規追加時に必ず辞書に追記する運用を徹底する。
ルール3：四半期に1回の棚卸し
使われていないプロパティ、重複しているプロパティ、入力率が10%以下のプロパティを洗い出す。不要なものは非表示化し、プロパティ辞書を更新する。
まとめ：命名規則は「CRMの基礎工事」
プロパティの命名規則は、CRMの設定の中で最も地味な作業だ。しかし、ここを手抜きすると、運用が進むにつれて「データがぐちゃぐちゃでレポートが信用できない」「どのプロパティを見ればいいかわからない」という状態になる。CRM導入の最初の段階で命名規則とプロパティ辞書を整備する。この「基礎工事」が、1年後のデータ活用の可否を決める。
案件管理の型｜社長が全部を見なくても営業が回る、最小の管理表
案件の項目・5つのステージ・週次レビューの進め方を1つの表にまとめ、記入例と表計算の式を付けた全12ページの資料です。特定のCRM製品には依存しません。
資料を無料でダウンロード命名を揃えたあとの運用は、CRMが使われない理由と直す順番、電話の記録など外部データとつなぐ項目の決め方はCTIとCRMのデータ連携設計も参考になります。HubSpotに限らずkintoneで案件を管理する場合は、kintone案件管理アプリの設計でも項目設計の考え方は共通です。
関連記事
よくある質問
CRM導入時にプロパティ名の命名規則を決めておかないとどうなりますか？
プロパティが増え続け、同じ意味の項目が複数存在する状態になりがちです。営業部の「初回アポ日」とマーケ部の「初回接触日」が別プロパティとして並存し、レポートや分析がまともにできなくなります。
CRMのプロパティ命名規則はどう決めればいいですか？
「カテゴリ_項目名_属性」の形式（例：lead_first_contact_date）で、英語のスネークケースに統一するのが基本です。部門横断で使える命名テンプレートを最初に作り、新しいプロパティを追加するときは必ずテンプレートに沿って命名するルールを決めておきます。
CRMプロパティ設計で避けるべきアンチパターンは何ですか？
代表的なアンチパターンは5つあります。同じ概念を複数のプロパティで持つ、自由記述フィールドの乱発、日本語の内部名、プロパティグループを整理しない、使わなくなったプロパティを削除せず増やし続ける、の5つです。これらを避けるだけでCRMの運用品質が大きく変わります。
泉 款太（いずみ かんた）
株式会社SalesDock 代表取締役
慶應義塾大学法学部卒。スタートアップ、ラクスル、リクルート（SUUMO）を経て2025年に独立。 中小企業の経営・営業・業務・データをつなぐ事業基盤の設計と実装を支援。 不動産・製造業・クリニックを中心に、累計40社以上の支援に携わる。
運営は株式会社SalesDock（大阪市中央区本町）。中小企業向けに、AI内製化（初期構築15万円＋月額10万円・90日）と、 そのあとのAI顧問（月額5万円・6ヶ月契約から）を提供しています。価格は税別です。 大阪・関西を中心に、オンラインで全国からのご相談に対応しています。
代表者情報を読む →この記事の数値について
本文中に一次資料へのリンクがある数値は、リンク先を出典としています。 リンクのない業務設計、判断基準、実務上の目安は、SalesDockが累計40社以上の支援と自社運用で得た知見を一般化したものです。 個別企業での成果を保証する数値ではなく、条件によって変わります。
CASE
実際の支援では、こう変わりました
人材紹介3ヶ月の伴走支援
サイトの文言変更を、担当者が一人で本番公開まで完了。
防災メーカー3ヶ月の伴走支援
見積書づくりで人が行うのは、粗利をどうするかの判断だけに。
外国人材の就職支援試作からの伴走支援
書類の回収・仕分けと履歴書づくりを、どこまで自動にし、どこを人が確認するかを決めて試作まで完了。