crm-data-governance

CRM データガバナンス

CRM のフィールドレベルのガバナンスを構築し、運用します。成果物は、日々更新されるルールブックと定例会議の運営リズムです。「ドキュメントがないからではなく、会議がないからガバナンスは失われる」（ORM Tech）という考えに基づき、次の要素で構成します。

• 管理対象フィールドのカタログと、フィールドごとに指名されたオーナー。
• フィールドごとの正本システムのマップ。書き込みの優先順位と競合ルールを定めます。
• 更新頻度とデータ鮮度に関する SLA。
• 単位工数あたりの価値で優先順位を付けた適用計画。
• フィールドの申請、承認、廃止のライフサイクル。
• これらすべてを維持するための定期的な運営サイクル。

基本原則

• すべてのフィールドではなく、収益に直結する重要なフィールドを管理します。これが最初に決めるスコープです。CRM には何百ものフィールドがあり、すべてを管理するのは不可能で、逆効果です（実務者間のコンセンサス）。references/field-ownership-and-dictionary.md にある、情報源に基づいたフィールドリストから始め、申請を通じてのみ対象を拡大します。
• フィールドごとに、氏名を指定した人間のオーナーを1人割り当てます。「チームではなく、人です」（RevBlack）。各フィールドには、データを入力する部門ではなく、データを利用する部門からオーナーを割り当てます。
• 正本システムはシステム単位やオブジェクト単位ではなく、フィールドごとに指定します。それ以外のコピーはすべて、派生データであることを明示します。タイムスタンプにかかわらず、空欄で入力済みの値を上書きしてはなりません。
• 最後の手段として、営業担当者を強制手段にしてはなりません。「営業担当者にデータ入力の責任を負わせてはいけません。報酬、目標、心理的な動機はすべて、データの管理ではなく営業活動を後押しするからです」（Jared Barol）。必須フィールドによる圧力よりも、自動化、連携による書き込み、エンリッチメント、デフォルト値を優先します。
• 継続的に運用する仕組みを設計し、運用します。オーナーシップマップ、ライフサイクル、予定された運営サイクルを伴わないクリーンアップはガバナンスではありません。クリーンアップが終わったその日から、再び劣化が始まります。
• すべてのしきい値に、その根拠を明記します。公表された企業の慣行、実務者間のコンセンサス、またはユーザー自身のデータから導き出されたもののいずれかです。「CRM データの年間30％が劣化する」「CRM データの精度はわずか40～60％」という、出典が明記されないまま流布している統計は、事実として述べてはならないと注意喚起します。代わりに、その仕組みを説明します。保存された値を取り巻く現実は変化します（人は転職し、企業は成長して社名を変更します）。また、フィールドごとの権限が定められていない複数の書き込み元による同期では、互いのデータが気付かれないまま上書きされます。ベンダーが独自に作成した複合スコアを、業界標準として示してはなりません。
• スコープの境界：レコードの重複排除とマージの仕組みは対象外です。定期的なデータ衛生チェック、ステージの終了条件、予測の信頼性、ルーティングロジックは「Reference」の関連スキルに含まれます。このスキルでは、そうした業務で使うフィールドルールを定めます。

B2B と B2C

異なる点：

• B2B は、データが少なく更新も遅い環境で運用されます。営業サイクルが長く、アカウント階層や購買委員会があり、営業担当者による入力は、デフォルトで信頼できないものとして扱います（「営業チームの誰かがデータ追加を手伝ってくれると、決して思い込んではいけません」— Stefano Mazzalai）。ガバナンスでは、1つのアカウントに書き込む複数の部門を調整します。
• B2C は、営業担当者による入力層を介さず、システムが書き込む大量のリアルタイム行動データを扱います。同意／設定に関するフィールドと保持期間は、最優先で管理すべきフィールドになります（同意ポリシーはマーケティングが、同期の信頼性はプラットフォーム運用チームが所有します。ページのクリエイティブを分散管理する場合でも、同意ロジックは一元管理します）。
• ID 解決には、B2C のチャネル横断マッチング（決定論的な完全一致識別子と確率論的な照合）に相当するものが、B2B にはありません。B2B では、ドメイン照合によってアカウントレベルで ID を解決します。

**両者に共通する点：**フィールドごとの正本システムの指定、空欄で入力済みの値を上書きしないこと、エンリッチメントのリスク分類、「最終確認日時」と「最終更新日時」を区別することです。この共通性は、一般的な表現の情報源から論理的に導いたものであり、公表された主張ではありません。成果物にもその旨を明記します。

インタビュー

何かを設計する前に質問してください。1メッセージにつき1つ質問し、可能であれば選択式にします。すでに回答済みの項目は省略してください。

• どの CRM を使っていますか。また、マーケティングオートメーション、請求、製品データベース、データ拡充プロバイダー、サポートデスク、データウェアハウスなど、ほかにどのシステムから CRM にデータを書き込んでいますか？
• 対象となるオブジェクトのフィールド一覧をエクスポートできますか（または、こちらから照会できるようにできますか）？中核オブジェクトごとのカスタムフィールドは、およそいくつありますか？
• 現在、どのフィールドが予測、ルーティング、報酬、経営レポートに使われていますか？（これを基に、ガバナンス対象を定めます。）
• どのような症状が課題になっていますか？システム間でフィールドの内容が食い違う、値がいつの間にか元に戻る、データが古い、フィールドが増えすぎている、誰が何を管理しているのかわからない、といったことはありますか？
• 現在、データオペレーションは誰が担当していますか？専任の RevOps、CRM 管理者、IT、または担当者なしですか？
• フィールドのドキュメントや辞書はありますか？ある場合、どこに保管されていますか？
• CRM にデータを書き込んでいるデータ拡充プロバイダーはどれですか？また、どのフィールドに書き込んでいますか？
• B2B、B2C、またはその両方ですか？対象となる同意やデータ保護に関する義務はありますか？
• 既存のガバナンス会議体はありますか？現在、新しいフィールドは誰が承認していますか？
• 通常の営業サイクルの長さとレコード数はどのくらいですか？（SLA としきい値の調整に使います。）
• 監査、取締役会への報告サイクル、CRM 移行、または現在誰も信頼していない予測など、いつまでに導入する必要がありますか？
• 今日誤っているフィールドを一度だけ修正したいですか？それとも、フィールドが追加されても機能し続ける、継続的に強化されるガバナンスシステムが必要ですか？
• 工数の上限はどのくらいですか？今四半期に管理者が使える時間、統合エンジニアリングの対応能力の有無、営業部門が別の方法で回避し始めるまでに許容できる負担はどの程度ですか？

最後の3項目によって、Workflow のステップ4と6における選択肢の順序が決まります。そのため、何かを設計する前に質問してください。

• 厳格な期限がある場合は、設定だけで実施できる段階（制限付き選択リスト、デフォルト値、定期的な取得、拡充のみ）を優先し、条件付き検証とリアルタイムのプッシュは削除せず、次のサイクルに回します。
• 継続的な強化が必須の場合は、役割ごとの権限、条件付きのステージ到達時必須化、ライフサイクルと運用頻度そのものを優先し、ルールを作らず症状を修正するだけのデフォルト値は優先度を下げます。
• 統合エンジニアリングの対応能力がない場合は、リアルタイムのプッシュを選択肢から完全に除外します。
• 営業部門がすでに必須フィールドに強く反発している場合は、担当者が入力するフィールドの必須化を選択肢から完全に除外します。

選択肢を除外した場合は、そのすべてを仕様書に記録してください。リストの末尾に除外済みとして置いた選択肢も、次のエスカレーション時にスコープとして再浮上することがあります。

ワークフロー

1. インタビューを実施し、スコープの境界を確認します（フィールドのルールが対象です。重複排除、データ品質の一括チェック、ステージ設計は対象外です）。

2. ガバナンス対象を定めます。references/field-ownership-and-dictionary.md にある収益上重要なリストから始め、予測、ルーティング、報酬、レポートに使われるすべてのフィールドを追加し、意図的に上限を設けます。

3. フィールドごとに所有者を割り当てます。消費者を所有者とする原則に基づいて1名を指名し、標準の分担には機能別 RACI を使用します（同じリファレンスを参照）。

4. フィールドごとのシステム・オブ・レコード・マップを作成します。各ガバナンス対象フィールドについて、正規システム、書き込みの優先順位、複製パターン、リスク階層を含むデータ拡充の書き込み戦略、競合解決の階層を定めます。references/system-of-record-rules.md を参照してください。このステップには優先順位を付ける選択肢が2つあり、どちらもリファレンスではなく、このステップ内で決定します。

   • レプリケーション、効率性：scheduled pull > reconciliation-only > real-time push。管理対象の各フィールドは、鮮度 SLA が求める頻度での定期プルをデフォルトにします。古い同期サイクルによってレポートではなくアクションが変わる場合に限り、フィールドをリアルタイムプッシュに引き上げます。この順序では、リアルタイムプッシュは最も優れた鮮度と最も低い比率を理由に後回しになります。優先度を下げる場合は仕様書に明記し、イベントバスまたは iPaaS がすでに稼働していて、対象フィールドを追加しても追加コストが発生しない場合は、順序を逆転させます。
   • エンリッチメント、効率性：augment > append > overwrite。管理対象のセット全体でデフォルトを augment にします。プロバイダーが定義上の正当な情報源であり、保存値に検証スタンプがない場合に限り、overwrite に切り替えます。同じ理由で、overwrite もこの順序では後回しになります。また、すでに誤っている値を修正できる唯一のモードです。

   リファレンスには、両方の順序の価値、労力、コンプライアンスコストの各軸、同順位の扱い、そして選択肢を優先度の引き下げではなく除外する制約が記載されています。マップを作成する前に、Interview で明らかになったチームの状況に基づいて両方を再ランク付けしてください。

5. フィールドカテゴリごとに更新 SLA を設定し、トリガーに基づく再検証で最終検証日時を追跡する仕組みを設計します - references/freshness-slas.md。各 SLA の出典をタグ付けします。

6. references/enforcement-menu.md からフィールドごとの適用方法を選び、軽さではなく、労力あたりの価値で順位付けします。

   • 効率性：picklist > conditional-required > defaults > permissions > layout > hard-required。最初の段階では、制限付きピックリストとデフォルトを基本とします。既知の移行時点で意思決定が参照するフィールドは、ステージごとの条件付き必須に引き上げます。
   • ロールごとの権限とハード必須は、この順序では後回しになります。どちらも安価な段階では得られない実質的な価値をもたらしますが、効率性を重視した各段階では優先順位が下がります。管理対象フィールドに2人の入力者がいて、システム・オブ・レコードとしての指定を無視している場合は、すぐに権限を強化します。値がないレコードでは判断できない場合に限り、ハード必須にします。
   • ハード必須をデフォルトにしてはいけません。安価な段階だけを選び続けるプログラムでは、誰も信頼しないフィールドが辞書に蓄積されます。

7. ライフサイクルと運用頻度を確立します。入力時の質問セット、承認・却下基準、廃止プロセス、評議会のメンバー構成、会議の頻度、意思決定権を定めます - references/field-lifecycle.md。

8. 作業用デフォルト列セット（所有権の参照先）を使って辞書をまとめます。稼働中の CRM を直接クエリできる場合は、そのメタデータから初期行を生成します。それ以外の場合は、ユーザーのエクスポートデータから作成し、未検証の行にその旨を記します。

9. references/worked-examples.md の該当する例を参考に、成果物（出力形式）をセクションごとに提示してユーザーの確認を得ます。

10. 合格基準を確認し、満たすまで反復します。実行環境に永続メモリがある場合は、管理対象フィールドの一覧、所有権マップ、システム・オブ・レコードに関する決定を保存し、定期レビューや紛争解決でそれらを起点にできるようにします。それ以外の場合は、辞書自体が永続的な成果物です。ユーザーに、そのように扱うよう伝えてください。

出力形式

すべての基準行に出典タグを付けます。

CRM FIELD GOVERNANCE SPEC - <company>, <date>
Scope            : objects in scope; governed-field count vs total field count;
                   motion (B2B / B2C / both); options deleted by the user's
                   constraints, and which constraint deleted each
Ownership map    : field -> named owner (a person) + owning function
System of record : field -> authoritative system, write precedence, replication
                   pattern, enrichment strategy + risk tier, conflict rule
Freshness SLAs   : field/category -> refresh cadence, re-verification triggers,
                   last-verified tracking plan
Enforcement      : field -> mechanism + why it beat the rung below it +
                   rollout note
Dictionary       : column set, initial rows, dictionary-vs-live-CRM
                   reconciliation plan
Lifecycle        : intake form, approval/rejection criteria, deprecation
                   process, utilization-review threshold
Cadence          : council membership, weekly/monthly/quarterly rhythm,
                   decision rights, escalation path
Metrics          : baseline values captured, KPI targets, first review date

合格基準

• 管理対象の各フィールドには、次の項目が設定されています。
  • 個人名が明記された単独のオーナー（チーム名は不可）。
  • 唯一の正本システム。
  • そのフィールドに関わるすべての同期について、書き込みの優先順位と競合時のルールが明示されていること。
  • 更新 SLA、または明示的なイベント駆動の指定。
  • 少なくとも1つの強制適用の仕組み。
  • データ辞書の項目。
• 管理対象のフィールドに、優先する書き込み元が定められていないまま複数の書き込み元が存在することはありません。また、エンリッチメントが ID フィールドや下流処理のトリガーフィールドに自動適用されることはありません。
• データ辞書の抜き取り確認：管理対象のフィールドを10〜15件抽出し、稼働中の CRM と照合します（型、選択肢の値、必須かどうか、説明の有無）。一致率は少なくとも95%とします。これは、公開されている基準ではなく、ユーザー自身のデータの不整合状況に基づいて厳格化するための実務上の目安です。
• カレンダーに定例会議が登録され、出席者が個人名で指定され、意思決定権限が文書化されていること。ポリシー文書だけでは、定義上、この基準を満たしません。

4つすべてを満たすまで反復します。この実行中に稼働中の CRM を検証できない場合は、抜き取り確認を保留と記録し、最初の評議会の議題に設定します。

よくある失敗パターン

欠陥	結果	対策
フィールドのオーナーがチーム（「RevOps が担当」）	誰も責任を負わず、問題が無視されたり、システム間で重複して発生したりする	フィールドごとに個人を1名指定し、データ辞書に氏名を明記する
すべてのフィールドを管理対象にする	労力が分散し、管理が実行不能として放棄される	収益に直結するフィールド群を管理し、受付プロセスを通じてのみ対象を拡大する
何でも必須にする反射的な対応	「該当なし」や不適切な入力がチェックを通過し、定着が崩れる	効率性の順序に従って進める：まず選択リストとデフォルト値を設定し、その後、条件付き検証を行ってから必須にする
エンリッチメントによる検証済みの値の上書き	信頼できるデータが気付かれないまま破壊される	原則として追加・補完する。上書きは、エンリッチメントが指定された権威ある情報源である場合に限る。すべての書き込みをリスク別に分類する
フィールドごとの権限がない双方向同期	値が頻繁に揺れ、気付かれないまま上書きされ、「データが間違っている」というエスカレーションが発生する	フィールドごとに正本システムを定め、最終同期以降の競合を検出する
一度限りのクリーンアップをガバナンスと取り違える	すぐにデータの劣化が再開する	ライフサイクルと定例会議を設ける。クリーンアップはシステムの成果物であり、システムそのものではない
開催されない評議会	ポリシーが陳腐化し、リクエストが受付プロセスを迂回する	意思決定権限を持つ週次のトリアージを設定する。会議自体が仕組みとなる
IT にガバナンスを割り当てる	ビジネス部門が定義を信頼しなくなる	RevOps が責任を持つ。データ管理はビジネス上の役割である
孤立した単発フィールド	フィールドが乱立し、重複が増え、属人的な知識に依存する	重複確認を伴う受付、利用状況のレビュー、廃止候補の管理を行う
「営業担当者がより多くのフィールドに入力した」ことを成功指標にする	入力率は上がっても、正確性は下がる	競合率、データの古さ、検証済みのカバレッジで測定する

KPI

• 以下を追跡します。
  • 全フィールドではなく、ガバナンス対象フィールドの入力率。
  • フィールドの利用状況：単に値が入力されているかではなく、レポートや自動化で利用されているか。
  • 鮮度の分布：フィールドごとの最終確認からの経過時間。
  • 同期実行ごとのシステム間の競合率。
  • 検証失敗率。急増した場合は、制御の強化を喜ぶ前に、でたらめな値を入力して回避する方法が使われていないか確認します。
  • フィールド申請の承認所要時間。現場での目標は、申請から公開まで1週間未満です。
  • カスタムフィールド数の推移。申請受付体制が整えば、横ばいになるはずです。
• 「営業担当者がより多くのフィールドに入力した」ことを成功として報告してはいけません。ゲートによってでたらめな値の入力を強いられると、入力率が上がる一方で正確性は低下します。
• ディクショナリの抜き取り確認を四半期ごとに再実施します。ずれが拡大している場合は、照合のループが機能していません。

呼び出し例

• 「CRMでは従業員数が1つの値、請求システムでは別の値、マーケティングオートメーションではさらに別の値になっています。フィールドごとに、どのシステムを優先するか決めてください。」
• 「誰でもカスタムフィールドを追加でき、取引先オブジェクトにはすでに400個あります。フィールド申請プロセスとオーナーシップモデルを整備してください。」
• 「予測に依存するフィールドのデータディクショナリと更新SLAを作成してください。半数は古くなっていて、誰もオーナーになっていません。」

参考資料

• ガバナンス対象の範囲設定、オーナーの割り当て、ディクショナリの作成時は、references/field-ownership-and-dictionary.mdを参照してください。オーナーシップモデル、収益にとって重要なフィールドの一覧、実務で使える既定の列セット、ずれの制御について説明しています。
• システム間の権限をマッピングする際は、references/system-of-record-rules.mdを参照してください。フィールドごとの指定、書き込みの優先順位、価値・工数・コンプライアンスの各軸で順位付けされた複製とエンリッチメントの選択肢、エンリッチメントのリスクレベル、値の揺れの検出について説明しています。
• 更新頻度を設定する際は、references/freshness-slas.mdを参照してください。出典付きの更新頻度表、最終確認日時と最終更新日時の違い、再確認のトリガーについて説明しています。
• 適用方法を選ぶ際は、references/enforcement-menu.mdを参照してください。効率性、価値、工数、コンプライアンスコストで順位付けされた6つの方法、選択リストのガバナンス、必須化が逆効果になるケース、ベンダーに関する任意の注記について説明しています。
• 申請受付、廃止、評議会の体制を整える際は、references/field-lifecycle.mdを参照してください。質問項目、承認基準、頻度、意思決定権について説明しています。
• 成果物の作成時は、references/worked-examples.mdを参照してください。適切なガバナンス仕様の例と、不適切な例を5つのフィールドで紹介しています。
• 定期的な古い商談の一括確認と完全性監査については、mbfinotti/revops-skills@sales-pipeline-hygieneを参照してください。このスキルで一度定義した内容を、毎週確実に適用します。
• ステージの終了基準の設計については、mbfinotti/revops-skills@pipeline-stage-definition-auditを参照してください。ステージフィールドは、ガバナンス対象の選択リストとしてのみここに登場します。
• ガバナンス対象フィールドに基づく予測の信頼性については、mbfinotti/revops-skills@sales-forecast-diagnosticを参照してください。
• ガバナンス対象のルーティングフィールドを使用するルーティングロジックについては、mbfinotti/revops-skills@lead-routingを参照してください。
• 会社レベルのデータガバナンスとチーム間のデータ契約については、mbfinotti/revops-skills@revenue-data-governance-strategyを参照してください。このスキルの対象はCRMのフィールドレベルです。