HubSpotプロパティ設計の作り方｜作りすぎを防ぐ作成基準と棚卸しのルール

プロパティが増え続けるのは、作る基準がないから

プロパティの乱立は担当者の不注意で起きるのではありません。作るときの基準と、減らす仕組みのどちらもないことで起きます。

プロパティが増える経緯は、たいてい次のどれかです。

• フォームに新しい質問を足すために、その質問専用のプロパティを作る
• 営業から「この情報を残したい」と言われ、テキスト型で作る
• ウェビナーや展示会のたびに「◯◯参加」という項目を作る
• 連携ツールを入れたときに、プロパティが自動で追加される
• 担当者が代わり、前任者の項目の意味が分からないので作り直す

5つの経緯は、どれもその場では合理的です。問題は、作るときに「これで何を判断するのか」を問わず、作ったあとに「まだ使っているか」を確認しないことにあります。

プロパティが多すぎると何が壊れるか

作ること自体に費用はかかりませんが、負担は後から来ます。第一に、入力する人が迷います。項目が並ぶほど営業はどこに何を書けばよいか分からなくなり、結局どれも埋めなくなります。第二に、数字が合わなくなります。同じ意味の項目が複数あると、どれを条件にしたかで件数が変わります。第三に、引き継げなくなります。作った本人しか意味を知らない項目は、担当者が代わると誰も触れなくなり、次の担当者がまた新しく作ります。

値の表記ゆれや重複レコードが目立つポータルでは、先にデータ整備で値をそろえてから、プロパティの棚卸しに入ります。導入直後でプロパティがまだ少ないなら、初期設定のチェックリストを進めるのと同時に作成基準を決めておくと、増える前に止められます。

フォームを作るときは、フォームの項目を既存のプロパティに接続する手順に沿って、フィールドの編集パネルから新しいプロパティを作らないようにします。

作る前に答える3つの問い

新しいプロパティを作る前に「何を判断するか」「どこで使うか」「誰がいつ入れるか」を一文ずつ書いてください。書けないなら、まだ作る段階ではありません。

問い1：そのプロパティで何を判断するか

たとえば「導入予定時期」を作りたいという要望があったとします。判断が「インサイドセールスが3か月以内の案件を優先して架電する」と書けるなら、作る理由があります。判断が決まっているので、選択肢も「3か月以内」「半年以内」「1年以内」「未定」のように、行動が変わる単位で切れます。

「念のため聞いておきたい」「あると便利そう」という理由は、判断ではありません。判断が書けない値は、集めても誰も見ない値です。

問い2：どのレポート・リスト・ワークフローで使うか

判断が書けても、それを実行する場所が決まっていなければ使われません。「導入予定時期が3か月以内のリスト」「獲得経路別の商談化率レポートの軸」「値が変わったら担当者に通知するワークフロー」のように、使う場所を具体的に1つ以上挙げてもらいます。

レポートの軸として使うなら、先にレポートの形を決め、そこからプロパティを逆算するのが正しい順番です。会議でどの数字を見るかがまだ決まっていなければ、プロパティより先にレポートで見る指標を決めます。

問い3：誰が、いつ値を入れるか

最も抜けやすいのがこの問いです。フォームで聞くのか、営業が商談後に入れるのか、ワークフローで自動的に入れるのか、連携ツールから同期されるのか。入力者とタイミングが決まっていないプロパティは、作った週だけ埋まり、その後は空欄のまま残ります。

あわせて、誰がプロパティを作成できるかの権限も決めます。全員が作成できる状態のままでは、どれだけ基準を決めても守られません。作成できる人を管理者数名に絞り、ほかの人は申請する運用にするのが現実的です。

標準プロパティと既存プロパティを先に確認する

新しく作る前に、HubSpotに最初からある標準プロパティと、社内の誰かがすでに作ったプロパティに同じ役割のものがないかを確認します。重複の大半は、この確認を飛ばすことで生まれます。

HubSpotには、コンタクト・会社・取引のそれぞれに多くの標準プロパティが用意されています。ライフサイクルステージ、リードステータス、役職、業種、従業員数、流入経路を自動で記録する項目などは、BtoBで必要な情報の多くをすでにカバーしています。同じ意味のカスタムプロパティを作ると、どちらの値を正とするかという問題を自分で抱え込むことになります。

自動で記録される値を、手入力で作り直さない

よくあるのが、「流入元」というカスタムプロパティを作って手で選ぶ運用です。サイト経由の流入はHubSpotが自動で記録する項目があるため、手入力版を作ると値が食い違います。手入力が必要なのは展示会や紹介のように自動では取れない経路だけで、その場合も「オフライン経路の詳細」のように役割を分けて持ちます。

標準にあるが、選択肢が自社に合わない場合

業種がその典型です。標準の選択肢が自社の顧客の分け方と一致しないなら、カスタムの業種を作る判断はありえます。ただしその場合は、標準側の業種をフォームやレコード画面から外し、どちらを使うのかを説明欄に明記します。標準とカスタムの両方に値が入り続ける状態が、最も集計を狂わせます。標準プロパティは選択肢の編集に制約がある場合もあるため、変えられる範囲を確認してから判断してください。

部署ごとの重複は、言い換えで検索して見つける

マーケが「業種」、営業が「業界」、カスタマーサクセスが「顧客業種」を作る。名前が違うため、作る側は重複に気づきません。作成前に、ラベルの言い換え（業種・業界・分野、従業員数・社員数・規模など）で既存プロパティを検索する手順を申請に含めておくと、ほとんどの重複は防げます。

1社に複数件ある情報は、プロパティで持たない

会社に「契約プラン」を持たせたいが、1社が複数の契約を持っている。「導入製品」を複数選択で持たせたが、製品ごとに開始日が違う。こうした1対多の情報をプロパティで無理に表現すると、「契約プラン1」「契約プラン2」のような連番のプロパティが生まれます。

1対多の情報は、プロパティの設計ではなく、データの持ち方そのものの問題です。連番のプロパティを作りたくなったら、カスタムオブジェクトを作るべきかの判断軸に沿って検討してください。

型の選び方｜集計できない値は判断に使えない

迷ったら選択式にしてください。自由記述の値はレポートで集計できず、リストの条件にも使いにくいため、判断の材料になりません。

プロパティの型は、値の入れ方ではなく、値をどう使うかで決めます。作成前の問い2で使う場所が決まっていれば、型はほぼ自動的に決まります。

自由記述を避ける理由

業種を自由記述にすると、「IT」「IT・通信」「情報通信業」「SaaS」「ソフトウェア」が同じ意味の別の値として並びます。後から揃える作業は膨大で、入口が自由記述のままなら翌月には元に戻ります。

表記ゆれより大きな問題は、集計できない値は判断に使えないことです。「製造業からの商談化率」を出したくても、製造業のレコードを条件で拾えなければ、その数字は出せません。

自由記述を残してよいのは、判断に使わない情報だけ

自由記述をすべて禁止する必要はありません。商談の経緯、顧客が使った言葉、選択肢に当てはまらない事情などは、テキストで残す価値があります。原則は、判断に使う値は選択式、判断の背景は自由記述、と役割を分けることです。

失注理由であれば、大分類をドロップダウンで持ち、詳細をテキストで補う形になります。大分類の切り方は、営業会議で行う失注分析の単位に合わせます。

数値で持つか、範囲の選択肢で持つか

従業員数や予算は、数値で持つか「50名以下」「51〜300名」「301名以上」のような範囲の選択肢で持つかで迷います。判断軸は、値がどう入ってくるかです。

連携や営業の確認で正確な数が入るなら数値で持ち、区分はリストの条件で切ります。フォームで本人に聞くなら範囲の選択肢が向きます。両方の経路があるなら、数値を正とし、範囲はワークフローで自動的に入れると二重入力を避けられます。

型は後から変えにくいと考える

型を変えると、既存の値が新しい型に合わずに失われたり、そのプロパティを参照しているレポートやワークフローの条件が崩れたりするおそれがあります。テキストで運用してきた項目をドロップダウンに変えるには、既存の値を選択肢に寄せる作業が先に必要です。型は作成時に決め切るものとして扱ってください。

日付の型で抽出が楽になる例として、予算期や契約更新時期を日付項目で持つ例があります。自由記述では抽出できない時期の情報を、一覧で引けるようになります。

選択肢の設計｜網羅より、判断が変わる単位で切る

選択肢は、起こりうるすべてを並べるものではありません。その値によって次の行動やレポートの見え方が変わる単位でだけ分けます。

網羅しすぎない

業種の選択肢を公的な分類どおりに数十個並べると、入力に時間がかかり、レポートでは件数の少ない行が並んで読めなくなります。施策が実際に変わるのは、ICPに合う数業種とそれ以外という会社がほとんどです。マーケ責任者が月次レポートで業種別の商談化率を見る場面を想定すると、一画面で行を見比べられる数に収まっているかが目安になります。選択肢の数は、レポートにしたときに一目で比較できるかを基準に決め、細かく分けたくなったら、その区分で施策を変える予定があるかを確認してください。

「その他」は、選択肢を見直すための入り口にする

「その他」を置かないと、入力する人は近いものを無理に選び、データが静かに歪みます。一方で「その他」が多くなると、分類として機能しなくなります。

「その他」は置いたうえで、選ばれた場合に詳細を書くテキスト欄と組み合わせます。棚卸しのたびに「その他」の割合と詳細の中身を確認し、同じ内容が繰り返し出てきたら、それを選択肢に昇格させる候補にします。

「未確認」と空欄を分ける

空欄は、まだ聞いていないのか、聞いたが相手が答えなかったのかを区別できません。インサイドセールスが確認済みかどうかで次の行動が変わる項目では、「未確認」「回答なし」を選択肢として持つと、空欄の意味を「未着手」に限定できます。すべての項目に必要なわけではなく、確認の有無で行動が変わる項目にだけ使います。

あとから選択肢を変えるときの過去データ

運用を続けると、選択肢を変えたくなる時期は必ず来ます。選択肢を変えるときは、変更の種類によって過去データへの影響が違います。

• 表記だけを変える：HubSpotの選択肢は、画面に表示するラベルと内部で保持する値が分かれています。ラベルだけを変えるなら、既存レコードも新しい表記で表示されます。
• 選択肢を統合する：統合される側の値を持つレコードを先に一括で更新し、そのあとで選択肢を外します。選択肢を外しても、既存レコードの値が自動で書き換わるわけではありません。
• 意味を変える：検討時期の区切りを3か月から6か月に変えるような変更です。同じ選択肢名のまま定義だけを変えると、変更前と変更後の値が混ざり、期間をまたいだ比較ができなくなります。新しい選択肢を作り、旧選択肢は名前に「旧」と付けて新規入力で使わない形にし、変更日を説明欄に記録します。

ワークフローやリストの条件は選択肢の値で動いているため、統合や削除の前には、その値を条件にしているワークフローやリストがないかも確認します。

命名規則とグループ分け｜作った本人がいなくても意味が分かるようにする

プロパティの名前と説明欄は、作った人が異動や退職でいなくなったあとに読まれるものです。ラベル、内部名、説明欄、グループの4つをルール化します。

ラベルは、用途と単位まで読める名前にする

「ステータス」「区分」「フラグ」は、作った瞬間は意味が分かっても、半年後には分かりません。何のステータスか、誰にとっての区分かをラベルに入れます。数値なら「年間予算（万円）」「従業員数（名）」のように単位まで書きます。

「営業用ステータス2」「新・業種」のように番号や新旧を付けた名前は、重複を作った痕跡です。付けたくなったら、既存のほうを先に見直してください。

内部名は作成後に変えられないので、規則を先に決める

ラベルとは別に、連携やAPI、エクスポートしたデータの列名で使われる内部名があります。内部名は作成後に変更できません。そのため、英小文字とアンダースコアの組み合わせなど、社内の規則を先に決めておきます。部署や用途を表す接頭辞を付ける方式がよく使われますが、大事なのは形式の優劣ではなく、一度決めた規則を全員が守ることです。

説明欄に、目的・使う場所・入力元・作成者を書く

プロパティの説明欄は空のままにされがちですが、最も手間が少なく作れる引き継ぎ資料です。作成申請で書いた内容を、そのまま説明欄に転記すれば十分です。

説明欄に残した記録は、担当者が代わるときにそのまま引き継ぎ資料の一部になり、後任が資料をゼロから作らずに済みます。

グループは、値の入り方で分ける

プロパティグループは、部署名で分けるより、値の入り方や用途で分けたほうが迷いません。「フォームで取得」「営業が入力」「自動計算・連携」「廃止予定」のように分けておくと、営業がレコード画面で見るべき項目がはっきりし、棚卸しで廃止候補を集める場所もできます。部署で分けると、複数の部署が使う項目の置き場所で必ず迷います。

入力の責任者と入力タイミングを決める

プロパティの品質は、型や名前よりも「誰が、いつ値を入れるか」で決まります。入力元は、1つのプロパティにつき原則1つに決めてください。

値が入る経路は、大きく分けて4つです。

入力元が複数あると、値の正しさを誰も保証できない

「検討時期」をフォームで聞き、営業も更新し、ワークフローも書き換える。こうなると、いまの値がいつ誰によって入ったのか分からず、レポートの数字を誰も説明できません。入力元を複数にするなら、「最初はフォーム、商談後は営業が上書きする」のように順番と優先を決めます。もう一つの方法は、「フォーム回答時の検討時期」と「営業確認後の検討時期」を別のプロパティとして持つことです。似たプロパティを増やしているように見えますが、入力元と意味が違うため重複ではありません。

フォームのためにプロパティを作らない

フォームを作るたびに質問を足し、その質問のためにプロパティを作ると、1回きりの施策でしか値が入らない項目が溜まっていきます。フォームの項目は既存のプロパティから選ぶのが原則で、新しい質問が必要なら3つの問いを通してから作ります。そもそもフォームの項目を増やすべきかは、問い合わせフォームの入力項目の設計で先に判断してください。

営業に入力を頼む項目は、業務の場面と結びつける

営業の手入力に頼る項目は、「気づいたときに入れてください」では入りません。初回商談の直後、見積もりを出す前など、具体的な業務の場面と結びつけ、その場面で入れる項目を少数に絞ります。入力すると営業自身の仕事が楽になる設計にしない限り、入力率は上がりません。営業が入力を後回しにし続けるなら、項目を足す前にCRMを入力される設計に変えるところから見直します。

ワークフローで入れる値は、手で入れさせない

日付の記録や区分の判定のように、条件から自動で決まる値はワークフローに任せます。手入力も許すと、ワークフローが入れたのか人が書き換えたのか区別できなくなります。自動で入る項目は「自動計算・連携」グループに置き、営業が編集する項目としては見せないのが安全です。値を入れるワークフローはワークフローの設計ルールに沿って作り、どのプロパティを書き換えるかをプロパティの説明欄にも書いておきます。

入力元が混在していて、どのプロパティから手を付けるべきか判断がつかない場合は、現在のプロパティ一覧を見ながら整理する相談も受けています。

外部ツールと同期するプロパティは、入力の責任者に加えて、同期の向きと値が食い違ったときの優先側も説明欄に書いておきます。

定期的な棚卸しと、減らす判断

作成の基準を決めても、使われなくなるプロパティは必ず出ます。半期に一度は利用状況を確認し、残す・統合する・入力を止める・削除するのいずれかに振り分けます。

棚卸しの対象は、値ではなくプロパティそのものです。入っている値の表記ゆれを直す作業とは分けて考えます。半期末にHubSpotの管理者がプロパティ一覧を用意し、マーケと営業の責任者と一緒に振り分けを決める進め方が現実的です。

使われていないプロパティの見つけ方

• 値が入っている割合：値が入っていることを条件にしたビューやリストで件数を数え、全体に対する割合を見ます。ほぼ空なら、入力元が機能していないか、そもそも不要です。
• 値の偏り：1つの選択肢に大半が集中している、「その他」が多いなど、判断に使えない分布になっていないかを見ます。
• 最近の入力：直近に作られたレコードに値が入っていなければ、入力の経路が止まっています。
• 利用箇所：レポート、リスト、ワークフロー、フォームで参照されているかを見ます。HubSpotではプロパティの設定画面でCRM内の利用箇所を確認できますが、外部の連携ツールや手元のスプレッドシートでの参照までは分からないため、別に確認が必要です。
• 説明欄：目的や作成者が書かれていないものは、まず作成者を探して目的を確認します。

いきなり削除せず、入力を止める期間を置く

使われていないように見えても、外部の連携や誰かのスプレッドシートが参照していることがあります。まず新規入力を止めて廃止予定グループに移し、次の棚卸しまで問題が出なければ削除する2段階にすると事故が減ります。削除前には値をエクスポートして保存します。HubSpotでは、ワークフローやフォームで使われているプロパティは参照を外すまで削除（アーカイブ）できません。アーカイブしたプロパティは90日以内なら復元できますが、90日を過ぎると完全に削除され、スーパー管理者はそれより前に完全削除することもできるため、復元を当てにした削除はしないでください。

頻度は、作成の審査があるかどうかで変わる

作成申請の運用が回っていれば、棚卸しは半期に一度で足ります。誰でも自由に作れる状態が続いていたなら、最初の1回は全件を見て、作成権限の見直しをセットで行います。入口が開いたままでは、棚卸しを繰り返しても数は減りません。

やらない判断｜作らないプロパティを決める

プロパティ設計の成否は、何を作るかより何を作らないかで決まります。次の4つは、要望が出ても原則として作りません。

「あとで使うかもしれない」で作らない

使う予定のないプロパティは、入力画面を長くし、引き継ぎで説明できない項目を残します。過去分の値がないことを心配する声もありますが、使い道が決まる前に集めた値は入力の基準が揃っておらず、あとで使おうとしても信用できないことがほとんどです。必要になったときに作れば間に合います。

部署ごとに似たプロパティを作らない

マーケと営業で定義が違うからと別々に作るのは、定義の違いを解消せずに先送りすることです。定義を揃えられるなら1つにまとめます。本当に違うなら、違いをラベルと説明欄で明示した別のプロパティにします。

1回きりの施策のためにプロパティを作らない

「9月ウェビナー参加」「展示会A来場」のようなプロパティを施策ごとに作ると、半年で数十個になります。参加者の記録はリストやキャンペーンの機能、あるいは「参加したイベント」のように繰り返し使える1つの項目で扱い、施策ごとの新規作成はしません。

判断に使う情報を備考欄に書かせない

項目を作らない代わりに備考欄へ何でも書いてもらう運用は、プロパティを増やさずに済むように見えて、集計できない情報を溜めるだけです。判断に使う情報であれば、3つの問いを通して選択式のプロパティにします。

厳密な審査が向かない段階もある

一方で、HubSpotを入れたばかりで利用者が1〜2名、レコードもまだ少ない段階なら、申請や承認の手続きまで整えるのは過剰です。この段階では、3つの問いの答えを作成者が自分で説明欄に書くことだけを守れば足ります。利用者が増え、部署をまたいで使い始めた時点で、作成権限の絞り込みと棚卸しを加えてください。

作成ルールと棚卸しの仕組みを自社の体制に合わせて決めたい場合は、プロパティ設計の見直しについての相談も承っています。

見積金額や値引き率を取引のプロパティとして新しく作る前に、見積書の金額や値引きを商品項目で持つ方法で足りないかを確認します。

まとめ

プロパティ設計とは、項目を作る技術ではなく、作らない基準と減らす仕組みを持つことです。

次にやることは2つです。新しいプロパティの作成を申請制にし、「何を判断するか」「どこで使うか」「誰がいつ入れるか」を書けないものは作らないこと。そして半期に一度、利用箇所と入力率を見て、残す・統合する・入力を止める・削除するに振り分け、その結果を作成の基準に戻すことです。利用者が1〜2名の段階なら、申請制の代わりに、説明欄へ3つの答えを書くことだけを守れば足ります。

よくある質問（FAQ）

カスタムプロパティは何個まで作ってよいですか。

作成できる上限はHubSpotの契約プランによって決まっており、仕様が変わることもあるため、最新の上限は公式情報で確認してください。実務で問題になるのは上限より運用で、3つの問いに答えられるものだけを作り、半期ごとに棚卸しするほうが数は自然に抑えられます。

プロパティの内部名はあとから変更できますか。

作成後は変更できません。ラベルはあとから変えられますが、内部名は連携やAPI、エクスポートしたデータの列名などで使われ続けます。作成前に社内の命名規則を決めておくことが、最も確実な対策です。

ドロップダウンの選択肢を途中で変えると、過去のデータはどうなりますか。

表記だけの変更なら、ラベルと内部の値が分かれているため、既存レコードも新しい表記で表示されます。統合や削除では既存レコードの値は自動で書き換わらないため、先に対象レコードを一括更新してから選択肢を外します。選択肢の意味を変える場合は、新しい選択肢を作って旧選択肢を新規入力で使わない形にし、過去の値と混ざらないようにしてください。

同じ情報は、コンタクトと会社のどちらに持たせるべきですか。

その値が人に固有か、会社に固有かで決めます。業種や従業員数は会社、役職や検討時期はコンタクトに持たせるのが基本です。両方に同じプロパティを作ると、どちらを正とするかを決めない限り値が食い違います。会社の値をコンタクトのリストで使いたい場合も、コンタクト側に複製する前に、会社の値を条件として使えないかを確認してください。

すでにプロパティが数百あります。どこから手を付ければよいですか。

最初に作成権限を絞り、これ以上増えない状態を作ります。次に、レポート・リスト・ワークフロー・フォームで使われているプロパティを残すものとして確定させ、それ以外を値の入っている割合が低い順に確認します。削除から始めず、まず新規入力を止めて廃止予定のグループに移し、次の棚卸しで問題がなければ削除する、という2段階で進めてください。