「前の案件と同じ作りでいけますよね」「業種が違うので、たぶん無理です」

中心オブジェクト

BtoBは取引先（Account）＋取引先責任者（Contact）が中心。BtoCはPerson Account（個人が取引先を兼ねる）または取引先責任者単独運用が中心になる

意思決定

BtoBは複数人のDMU（意思決定者・影響者・利用者）が絡むためMEDDPICC等の項目設計が必要。BtoCは個人の即断が中心でDMU管理は不要なことが多い

リード量とサイクル

BtoBはリード数が少なく商談サイクルが長い（週〜月単位）。BtoCはリード数が多く商談サイクルが短い（分〜日単位）ため、自動化・スコアリングの比重が増す

判断基準はシンプルです。「1つの商談に何人の意思決定者が関与するか」で、BtoB/BtoCの設計思想を切り替えます。

ここで一つ、先に反論しておきます。「BtoBとBtoCの違いくらい、営業モデルを見れば最初から分かるのでは」と思うかもしれません。多くの場合はその通りです。ですが、実際には同じ企業の中に法人向けプランと個人向けプランが混在していたり、途中でPLG的な個人利用から法人契約へ転換する導線があったりします。表向きの営業モデルだけを見て設計すると、後から「この商談だけDMUが1人しかいない」といった例外に押し切られ、オブジェクト構造がなし崩しになりがちです。

判断基準は「今の組織構造」ではなく「1〜2年後にどう変わりそうか」まで確認することです。過剰設計・過小設計のどちらにも倒れないバランスを取ります。

例えば、SaaS企業の案件で「解約率が高いのに標準の商談オブジェクトだけで運用している」というケースがあります。契約・サブスクリプションオブジェクトを別途設計し、更新・アップセル・ダウングレードのライフサイクルをデータモデルに組み込まないと、NRR/GRRの算出に必要なデータがそもそも存在しない、という事態になりがちです。標準の商談オブジェクトだけでサブスクリプションビジネスを運用するのは、賃貸契約の更新履歴を持たない台帳で家賃回収を管理するようなものです。契約は一度きりの取引ではなく、続く関係だという前提がデータモデルに反映されていないと、後から見たい数字がそもそも存在しません。

目の前の案件を3軸で棚卸しするフォーマットです。

業種特有のオブジェクト（物件・求人等）は最初から作り込むべきですか

組織規模・成長フェーズの軸と合わせて判断します。スタートアップ／SMBのフェーズでは標準Objectを極力崩さずカスタムを最小限に留める方針が推奨される一方、業種特性上どうしても標準モデルでは表現できない構造（物件・求人等）は早期からカスタムObjectでの設計が必要になります

BtoBとBtoCが混在する事業では、どちらの設計方針に寄せるべきですか

「1つの商談に何人の意思決定者が関与するか」という判断基準を、事業ライン・商品ごとに個別に当てはめるのが実務的です。同一組織内でもBtoB向けとBtoC向けで商談レコードタイプを分け、それぞれに適した項目・ステージ設計を持たせることができます

急拡大期のスタートアップで、初期の簡易設計が限界を迎えたらどうすればいいですか

この時期の再設計案件は多く発生するとされています。重要なのは既存データを壊さない移行計画で、データを壊さずに段階的に権限モデル・オブジェクト構造を精緻化していくアプローチが推奨されます

今の設計は、3つの軸（BtoB/BtoC・企業規模と成長フェーズ・業界特性）のうち、どれか一つだけを見て決めていないでしょうか。前の案件のテンプレートをそのまま持ち込んでいる部分があるとしたら、それはどこで、1〜2年後にも通用する設計でしょうか。