CRM Implementation Guide
CRMカスタムフィールド：追加すべきものと避けるべきもの
あるSaaS企業がHubSpot CRMを80のカスタムフィールドで立ち上げました。RevOpsのリードは、Go-live前に営業、マーケティング、経営陣からのすべての要求を満たそうとしていました。6週間後、採用率は40%でした。担当者から最も多かった不満：「案件を作成するのに10分かかる。」
22のフィールドに削減しました。1か月以内に採用率は85%に達しました。
これは珍しい話ではありません。ほとんどのCRMは、立ち上げから90日以内に肥大化します。悪意からではなく、「とりあえずフィールドを追加しよう」という文化から。すべてのフィールドにはコストがあります。担当者が入力しなければならないフィールド（摩擦）か、無視できるフィールド（ノイズ）のどちらかです。どちらも中立ではありません。
このガイドでは、導入前、導入中、導入後のすべてのフィールド要求に対する意思決定の枠組みを提供します。
ステップ1：フィールドを追加する前に3つの質問テストを適用する
すべてのフィールド要求に3つの質問をします。3つすべてにノーであれば、フィールドはCRMに入りません。
質問1：レポートを作成しますか？ このデータはダッシュボード、週次レポート、または経営層へのビューに表示されますか？このフィールドが重要な具体的なレポートを名前で挙げられない場合、おそらくCRMには必要ありません。「知れたら面白い」はレポートの要件ではありません。
質問2：セグメント分けに使いますか？ このフィールドはコンタクト、企業、または案件のフィルタリング、ソート、グルーピングに使用されますか？例：予測通話のための案件タイプ別のすべての案件のフィルタリング、マーケティングキャンペーンのためのIndustry別のコンタクトのセグメンテーション、テリトリー割り当てのための従業員数による企業のクエリ。
質問3：ワークフローやオートメーションがそれに依存しますか？ CRMのオートメーションはこのフィールドの値に基づいてトリガーされますか？例：テリトリーによるリードのルーティング（テリトリーフィールドが必要）、リードステータスが変わったときのフォローアップシーケンスの送信（リードステータスピックリストが必要）、案件がステージに入ったときのタスク作成（ステージがフィールド）。
フィールドが少なくとも1つにイエスと答えれば、CRMに場所があります。3つすべてにノーと答えれば、別の場所を提案してください：メモフィールド、外部スプレッドシート、または保存なし。
1つの例外：インテグレーションで必要なフィールド（例えば、マーケティングツールがメールパーソナライゼーション用に特定のフィールドを取得する）は内部レポートに役立たなくても許可されます。ただし、所有者が必要です。
ステップ2：適切なフィールドタイプを選択する
間違ったフィールドタイプを選ぶと、事後に修正が難しいデータ品質の問題が生じます。このテーブルを使って決定してください：
| フィールドタイプ | 使用する場合 | 使用しない場合 |
|---|---|---|
| テキスト（1行） | 固有識別子、固有名詞、ID | 集計またはグループ化するもの |
| テキスト（複数行） | 記述的なコンテキスト、ミーティングメモ、ディスカバリーのサマリー | 繰り返しパターンがあるもの |
| ピックリスト | グループ化、フィルタリング、またはトリガーに使用する値 | レコードごとに真に固有な値 |
| 数値 | 数量、カウント、測定値 | 通貨（通貨タイプを使用）、パーセンテージ |
| 通貨 | 案件金額、契約金額、MRR | 比率またはパーセンテージ |
| 日付 | クローズ日、契約開始日、最終活動日 | 期間（日付フィールドを2つ使用） |
| チェックボックス | はい/いいえのブールフラグ | 2つ以上の状態があるもの |
| ルックアップ / アソシエーション | 1つのオブジェクトを別のオブジェクトに接続する場合 | 関連レコードの名前をテキストとして保存する場合 |
| 数式 | 他のフィールドから派生した計算値 | 手動入力が必要なもの |
最も一般的な間違い：ピックリストが必要な場合にテキストフィールドを使用すること。Industryに自由入力テキストを使うと、「SaaS」、「Software as a Service」、「B2B SaaS」、「Tech」がすべて同じ意味で使われます。この4つのバリエーションがIndustryレポートを無意味にします。
有限の意味のある値セットがあるフィールド（Industry、案件タイプ、失注理由、リードソース、顧客層、地域）はピックリストであるべきで、テキストではありません。
ステップ3：必須フィールドを10以下に保つ
必須フィールドは最も速い採用を低下させる方法です。すべての必須フィールドは案件作成を遅らせるゲートです。案件を60秒以内に作成できない担当者はCRMを回避します。
誘惑はデータ品質を強制するためにすべてを必須にすることです。しかしそうは機能しません。答えを知らない必須フィールドを埋めることを強いられた担当者はランダムな値を選ぶか「不明」と入力します。悪いデータは欠損データよりも悪いです。
必須フィールドを、作成時にレコードを有用にする絶対最小限に抑えてください：
コンタクトの場合： メール（または電話番号、少なくとも1つ）、名、姓、オーナー。
案件の場合： 案件名、Pipelineステージ、クローズ日、案件金額（概算でも）、主担当コンタクト。
企業の場合： 企業名、オーナー。IndustryとサイズはEnrichmentで補完できます。
グローバルに必須にするのではなく、条件付きで追加フィールドを必須にしてください。HubSpotでは、案件が特定のステージに達したときにのみフィールドを必須にできます。Salesforceでは、別のフィールドが特定の値に設定されたときにフィールドを必須にするバリデーションルールを使用できます。グローバルな必須条件の代わりにこれらの条件付き必須条件を使用してください。
例：失注理由は、Pipelineステージが「クローズロスト」に設定されたときに必須になります。案件作成時には必須ではありません。それが正しいアプローチです。
ステップ4：初日からピックリストの衛生管理を行う
ピックリストは誰も所有していなければ時間とともに劣化します。8つのクリーンなIndustry値から始め、1年間のチェックなし追加の後には24つになります。
立ち上げ前にこれらのガバナンスルールを設定してください：
命名規則：規則を選び、適用してください。タイトルケースか文章ケース。「Financial Services」であり、「financial services」や「FinancialServices」ではありません。1人の管理者が唯一の情報源となります。
誰が値を追加できるか：Salesforceでは、ピックリスト値は管理者レベルで管理されています。担当者は追加できません。HubSpotとPipedriveでは、デフォルトはよりオープンです。これをロックしてください。定義された所有者とともにリクエストプロセスを必要にしてください。
アーカイブ vs. 削除：ピックリスト値が廃止されたとき、アーカイブしてください。削除しないでください。削除すると既存のレコードから削除されます。アーカイブすると履歴データはそのままで、値が新しいレコードに表示されなくなります。HubSpotでは「プロパティ値を無効化」です。Salesforceでは古い値を非アクティブにできます。
レビューの頻度：四半期ごとに、未使用または重複している値について各ピックリストをレビューしてください。過去6か月に0または限りなく0に近い使用回数の値はアーカイブ候補です。
ステップ5：CRMフィールドとEnrichmentフィールドの違いを理解する
これにより多くのフィールドの肥大化を節約できます。データには2種類あります：担当者だけが知っていることと、Enrichmentツールがすでに知っていること。
Enrichmentツールが知っていること（Clearbit、Apollo、ZoomInfo、6senseから）：
- 企業の従業員数
- 企業の売上規模
- 企業の資金調達ステージ
- コンタクトのLinkedURL
- 企業の本社所在地
- 技術スタック
- Industry（多くの場合）
CRMにネイティブのEnrichmentインテグレーションがある場合、これらのカスタムフィールドは必要ありません。HubSpotは特定の層でClearbitが内蔵されています。SalesforceはZoomInfoなどに接続します。Enrichmentがこれらのフィールドを自動入力すると、担当者の入力なしに一貫した清潔なデータが得られます。
担当者だけが知っていること（フィールドを構築する価値があるもの）：
- コンタクトとの関係の強さ
- 社内チャンピオンと経済的バイヤーの区別
- 顧客固有の要件や制約
- タイムライン変更の理由
- 購買委員会との次のステップ
これらが構築する価値のあるフィールドです。データベースからスクレイピングできない洞察をキャプチャします。
経験則：フィールドを構築する前に、ApolloやClearbitがすでに答えを知っているかどうかを聞いてください。はいならEnrichmentを使用してください。いいえならフィールドを構築してください。
ステップ6：四半期ごとのスケジュールで既存フィールドを監査する
ほとんどのチームはフィールドを削除しません。ただ追加し続けます。2年間稼働しているHubSpotポータルのコンタクトオブジェクトには、60から120のカスタムプロパティがあり、その多くについて誰も説明できません。
これらのステップで四半期ごとの監査を実施してください：
フィールド使用レポートを取得してください。HubSpotでは：設定 → プロパティ → オブジェクトを選択 → 「データがあるレコード数」でソート。Salesforceでは：AppExchangeのField Tripアプリまたはフィールド使用に関するカスタムレポートを使用。Pipedriveでは：サンプルをエクスポートして手動で入力率を確認。
レコードの10%未満にデータがあり、オートメーションが依存していないフィールドをフラグ立てしてください。これらが削除候補です。
フラグ立てされた各フィールドについて、それをリクエストした人に確認してください：まだこれを使っていますか？それに依存するレポートはありますか？いいえならアーカイブしてください。
保持しているが値が一貫していないフィールドのデータをクリーニングしてください。ピックリストであるべきテキストフィールドでデduplicationを実行してください。
削除したものとその理由をドキュメント化してください。6か月後に誰かが尋ねても記録があります。
フィールドの監査は地味な作業ですが、CRMがデータの不整合と無視の場所にならないようにします。
よくある失敗
「将来の」レポートのためにフィールドを構築する。 「これをいつか追跡したいかもしれない」では不十分です。使われないフィールドに2つの方法でコストを支払います：データ入力での担当者の摩擦とレコードを開くときの認知的オーバーヘッドです。
オブジェクト間でフィールドを複製する。 「リードソース」がコンタクトと案件の両方に存在し、時々一致しない場合、どちらが正しいですか？一度定義し、ルックアップを使用してください。
ピックリストが必要な場合にフリーテキスト。 上で説明しましたが、繰り返す価値があります：数えたり、グループ化したり、フィルタリングしたりすることがあるフィールドはピックリストであるべきです。テキストは記述のため、ピックリストは分類のためです。
導入中盤で必須フィールドを追加する。 Go-live後にフィールドを必須にすると、そのフィールドが欠けているすべての既存レコードでバリデーションエラーが発生します。必須フィールドはGo-live前に計画してください。
新しいフィールドを追加する前に既存のフィールドリストを確認しない。 誰も既存のものを確認しなかったために重複フィールドを作成することはよくあります。「契約署名日」を作成する前に、フィールドリストを検索してください。「クローズ日」または「契約実行」として既に存在するかもしれません。
次のステップ
立ち上げ後、30日間のフィールドフリーズを実施してください。最初の30日間は新しいカスタムフィールドを作成しません。入ってくるすべての要求はキューに入ります。30日後、一緒にキューをレビューしてください。多くの要求は自然に解決されます（フィールドは必要なかった）、一部は既存フィールドを別の方法で使うことで満たせます。そして本当に新しいフィールドが必要なのはほんの一握りです。
その後、作成したフィールドに依存するワークフローオートメーションを構築してください。それらのピックリストとトリガーは実際に何かを行う必要があります。
