悪いデータを入れない

🌐 ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール2／6：Data Architectコース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 前へ：ガバナンスは組織に組み込んで設計する · 次へ：データを知る

このモジュールが答える問い： データをどうやってよい状態にし、その状態を保つのか？

悪いデータへの対処には2つの方法があります。入る前に止めるか、入った後で片付けるか。両方を少しずつやることになるでしょう。しかし選べるなら、私は永遠に片付け続けるための組織を作るより、問題を防ぐほうを選びます。重複、誤った識別子、欠けた情報、標準でない値、別のシステムが所有する項目をユーザーが変えること、連携がよいデータを悪いデータで上書きすること。そのすべてが誰かの片付けプロジェクトになります。ですから設計の問いは、**そもそもどんな悪いデータなら無理なく締め出せるか？**です。そして「無理なく」が大切です。答えは、システムが使えなくなるまですべての項目に鍵をかけることではないからです。

「十分によい」はビジネス上の定義

悪いデータを防ぐ前に、よいデータを定義しましょう。唯一の定義はありません。よいとは、プロセスを動かせるほど完全であること、判断できるほど正確であること、ワークロードに対して十分に新しいこと、ほかのシステムと組み合わせられるほど一貫していること、どの顧客のことかわかるほど一意であること、自動化に使えるほど標準的であること、どこから来たかがわかるほどたどれること、かもしれません。データによります。Steve Truckingが小売パートナーに請求しているなら、パートナーの法的な識別は正しくなければなりません。営業担当者が打ち合わせの後にメモを書き留めているなら、一文ごとに委員会が承認する必要はありません。「十分によい」はビジネス上の定義です。 アーキテクトはそれを測定でき、強制できるものにします。

高くつく誤りを防ぐ

すべての悪い項目が同じだけの注意に値するわけではありません。私が最も気にかけるのは、下流に結果を及ぼす誤りです。重複した顧客は、2つの営業履歴、2つのサービス履歴、2組の取引先責任者、2つの外部ID、同じ会社を同期する2つの連携、ウェアハウスとData 360の2つのバージョン、そしてやがてどちらの顧客が本物かを決めるエージェントを意味します。説明欄の誤字よりずっと高くつきます。ですから「すべての項目をどう検証するか？」から始めないでください。**どの悪いデータが、ビジネスやアーキテクチャに最も大きな問題を生むか？**から始め、そこに最も強い管理策を置きましょう。

開放するか、制限するか？

取引先の作成は典型的な例です。すべての営業担当者が取引先を作成できるべきでしょうか？　私の答えは、データを取り巻くガバナンス次第です。ほとんどの中小規模の組織では、作成の開放で問題ありません。営業担当者が見込み客に出会い、取引先を作り、仕事に取りかかる。それがCRMの目的です。重複ルール、必須の情報、スチュワードシップで品質を管理します。ガバナンスが責任あることに聞こえるからといって、重い承認プロセスを追加したりはしません。

では全体像を変えましょう。法的な顧客はERPでマスター管理され、ERPの識別子とともにSalesforceに流れ込み、ERPが権威を持っています。こうなると作成の開放は、同じ統制されたエンティティを作る方法が2つあることを意味します。ERPと営業担当者の両方が同じ会社を作ったら、どちらが勝ち、連携はどの識別子を使い、どのレコードが履歴を持つのか？　作成の開放は使いやすさの問いではなくなり、マスターデータの問いになります。取引先がERPでマスター管理されているか、ERPと同期しているなら、作成を制限しましょう。

しかし完全に締め切るのも失敗です。営業担当者がERPにいない見込み客に出会い、商談を開きたいのに、ガバナンスのモデルが「あなたに取引先はありません」と言う。そこで担当者は財務を3日待つか、商談を間違った取引先に付けるか、見込み客をメモ欄やスプレッドシートに置いておくことになります。データモデルを守って、ビジネスを傷つけたのです。

中間の道：仮のレコードタイプ

私が気に入っている中間の道はこうです。営業には特定のレコードタイプ、つまり見込み客や仮のタイプで取引先を作らせ、統制されたタイプへの変換を管理する。 営業は会社を記録して、売り始められます。レコードははっきりと、まだ権威あるシステムで確立されていないと示しています。そして管理されたプロセスがそれを変換します。財務が承認するか、連携がそれをERPに送り、ERPが既存の顧客と照合するか新しい顧客を作り、権威ある識別子を送り返します。こうしてレコードは仮 → 統制済みという境界を越えます。それは、2つのシステムがそれぞれ自分こそマスターだと信じるレコードを作るのとはまったく違います。

私が教えている仕組みはレコードタイプです。何を使うにせよ、状態をデータの中で見えるようにしましょう。レコードがどこから来たか、境界を越えたかどうか、今誰が変えてよいか、そして権威あるシステムに結びつける識別子。変換の後にしか存在しないERPの顧客IDは、何よりもはっきりした目印です。

流れごとのレコードタイプ

流れ全体を一枚の絵に載せれば、これがうまくいく理由がわかります。顧客と製品はERPから入ってきます。商談とその明細は出ていき、ERPの注文になります。では取引先は？　入ってくるものもあれば、出ていくものもあります。そこで、私がさまざまな実装で見てきたよくあるパターンが、取引先に2つのレコードタイプを置くこと、つまり向きごとに一つです。Salesの取引先はSalesforceで生まれます。営業担当者が作成し、編集し、販売し、顧客になったらERPへ送られます。ERPの取引先（私はCustomer、あるいは単にSAPと呼んだこともあります）はERPで生まれ、連携を通じて入ってきます。そのレコードタイプを作成するのは連携だけで、そのマスターデータ項目（正式名称、住所、支払条件）はユーザーには読み取り専用です。レコードタイプが、レコードがどちらへ流れるかを教えてくれるので、マスター管理の向きがレコードの上にそのまま表れます。

Click to enlarge

流れごとのレコードタイプ：Salesの取引先は出ていき、ERPの取引先は入ってきます。

それで難しいケースがなくなるわけではありません。営業担当者がSteve’s Plumbingのリードを取引開始しますが、Steve’s PlumbingはすでにERPの取引先として存在していて、なぜか重複チェックがそれを捕まえませんでした。こうなると、マージし、子レコードの親を付け替え、どのレコードを残すかを決めることになります（第6章、モジュール3）。

そして、レコードタイプそのものにこだわらないでください。普段の私は、強い理由がない限りレコードタイプを避けます。ここで使ったのは、動的フォーム以前はレコードタイプがページレイアウトを選び、一つのレイアウトでERPの項目を読み取り専用で表示していたからです。動的フォームなら、表示ルールで項目の値に応じて項目を表示・非表示にでき、特定のページで項目を読み取り専用にでき、Salesforce自身も、動的フォームによって必要なページレイアウトとレコードタイプの数が減ると述べています（Break Up Your Record Details with Dynamic Forms (opens in a new tab)、Required and Read-Only Fields in Dynamic Forms (opens in a new tab)、英語）。しかし、ページ上の読み取り専用は、そのページ上での読み取り専用にすぎません。API、データロード、連携は、まだその項目に書き込めます。本当の強制は項目レベルセキュリティか入力規則です。UIの検証はデータの検証ではありません（第3章、モジュール9）。2種類の取引先に違う選択リスト値やビジネスプロセスが必要なときには、レコードタイプは今でもその場所に値します。本当に重要なのは、レコードがどこから来たかを、何かの項目がはっきり示していることです。ERPのキーそのもの、マスターデータのフラグ、あるいはソースの選択リスト。そして、その項目で編集できるかどうかを決めましょう。

Click to enlarge

仮から統制済みへ：営業はすぐに販売を始め、レコードを統制済みにするのは権威あるプロセスだけです。

統制されたレコードを守る

顧客がERPから戻ってきたら、そのERPのID、正式名称、税務上の識別子、請求の詳細は統制された属性です。営業担当者がそれを変えるべきでしょうか？　ERPが所有しているなら、変えるべきではありません。それは、モジュール1のポリシーが強制の場所を必要としているということです。ERPのIDは読み取り専用、法的な識別は管理され、それでも営業担当者はテリトリー、関係のメモ、Salesforce独自の分類を編集できます。目指すのは触れられない取引先ではありません。Salesforceが所有するデータとSalesforceが参照するデータの間の、はっきりした線です。（第4章のerp_の接頭辞が、その線をスキーマの中で見えるようにしてくれます。）

最終的にできあがるのは、実はハイブリッドなゴールデンレコードです。ERPのマスターデータ項目が入ってきます。正式名称、請求先と出荷先の住所、支払条件。そこにSalesforceが、決して戻らない独自の項目を加えます。営業の評価、最終注文日、マーケティングが使うほとんどすべてのもの。同じ取引先に2種類の項目があり、それぞれの種類に一つの出どころがあります。

いちばん難しいのは双方向の連携です。営業担当者が、ERPの正式名称をSteve’s PlumbingからSteve’s Plumbing LLCに変えてほしいとしましょう。その同じ5分の間に、ERPの誰かがそれをSteve’s Plumbing L.L.C.に変えます。どちらの変更が勝つのでしょう？　考え方はこうです。項目がERPでマスター管理されているなら、あなたは項目を変えているのではなく、変更を依頼しているのです。 依頼が衝突したときに何が起きるかを決めましょう。ERPが勝つのか、その間に値が変わっていたら依頼を却下するのか、人が解決するまで待つのか。そして、関連する項目を一つの変更としてまとめて送るのか、一つずつ送るのかも決めましょう。第6章で衝突をさらに掘り下げます（ループと衝突）。

重複は入口で止める

重複は複利で増えます。作られる前に捕まえれば小さな問題です。2年後に、商談、ケース、取引先責任者、請求書、連携、分析が両方にぶら下がった状態で見つければ、大きな問題です。第3章のモジュール7で仕組み（一致ルール、重複ルール、一意の外部ID）を扱ったので、ここでは繰り返しません。ガバナンスの問いは、**どこで重複を防がなければならず、どこでなら許容して後で解決するか？**です。気軽なマーケティングのリードなら曖昧さとも付き合えます。金銭のトランザクションを持つ、ERPで統制された顧客ではそうはいきません。

機械が読むものを標準化する

自由記述は人にとってはすばらしく、システムが解釈しなければならないときには最悪です。ルート割り当てを動かす項目にArizona、AZ、Ariz.、Phoenix area、Southwestを入れれば、品質の問題を抱えます。値が自動化、連携、レポート、セキュリティ、割り当て、エージェントの行動を動かすなら、それがどれくらい標準的でなければならないかをよく考えましょう。すべてのテキスト項目を選択リストにするわけではありませんが、人が読む情報と機械が判断に使う情報を区別してください。後者にはより強い管理がふさわしいのです。

必須項目に偽のデータを作らせない

ある項目が重要だと判断して、必須にします。ユーザーは答えを知らず、システムは先に進ませてくれないので、N/A、Unknown、999999、test@test.comと入力します。項目は埋まっています。データはゴミです。何かを必須にする前に、ユーザーがその時点で本当にそれを知っているかを問いましょう。知らないなら、プロセスの後のほうで必須にするか、別のシステムに提供させるか、仮の状態を使うか、不明が正当な答えであるなら明示的な不明を用意しましょう。入力規則はポリシーを強制できます。知らないことを知らせることはできません。

すべてのデータの境界には品質の判断が必要

悪いデータの源は人だけではありません。連携はもっと速く悪いデータを生みます。小売パートナーの積荷目録が数百行で届きます。いくつかは郵便番号が無効で、2つほどは知らない物流センターの名前があり、2つは同じ注文番号を繰り返しています。どうなるでしょう？　ファイル全体を拒否する？　よい行を受け付けて、悪い行を返す？　全部ロードして後で片付ける？　例外を隔離する？　誰に知らせ、パートナーは何が失敗したのかをどう知るのか？　普遍的な答えはありませんが、答えはなければなりません。第4章で、すべての矢印には仕組みが必要だと言いました。それに加えましょう。すべてのデータの境界には品質の判断が必要です。 何を受け付け、拒否し、隔離するのか、そして誰がその例外を所有するのか。

Click to enlarge

すべてのデータの境界には品質の判断が必要です。

過去のデータは違う

RouteDeskにはSteve Truckingの8年分の履歴があり、その品質は物流センターによってばらばらです。移す前に、8年分すべてを今日の基準まできれいにすべきでしょうか？　おそらく自動的にそうすべきではありません。それは何のためか：日々の業務、参照、クレーム、レポート、傾向分析？　そのすべてがSalesforceにある必要があるのか、一部はほかの場所に置いておけるのか？　移行の章で深く扱います。ガバナンスとしてのポイントは、履歴は自動的に有効なデータと同じ基準を必要とするわけではないということです。それに基づいて判断を下すなら、品質は重要です。参照のために持っておくなら、別の基準で十分かもしれません。過去をきれいにするのに大金をかける前に、目的を知りましょう。

誰かが行動を起こすものを測る

ガバナンスは決して終わらないので、品質が落ちてきたときにそれが見える必要があります。重複率の上昇、隔離されるレコードの増加、連携での拒否の増加、プレースホルダーの値の広がり、迂回の依頼の増加、もう突き合わない数字のレポート。しかし、150個の指標を作って143個を無視するのはやめましょう。Steve Truckingなら、有効なパートナーの参照番号のない配送、使える住所のない配送、繰り返される注文番号、拒否されたパートナーのメッセージ、仮の状態で止まっている取引先かもしれません。緑の丸だらけのダッシュボードは、データがよいことを意味しません。誰かが行動を起こす覚悟のあるものを測りましょう。

試験の先へ：AIが変えること。 悪いデータは、ますます悪い行動になっていきます。人なら電話をかける前に電話番号がおかしいと気づくかもしれませんが、エージェントは渡された値をそのまま使います。重複した顧客、古いステータス、偽の必須の値、誤った識別子は、そのまま間違ったメッセージや間違った更新になります。それは防ぐことの価値を高めます。スチュワードシップの必要をなくしはしません。

ここでアーキテクトが決めること

• どの品質の失敗が、予防の管理策を正当化するほどの害をもたらすか。
• 統制されたレコードを、自由に作らせるのか、権威あるシステムだけに作らせるのか、それとも仮から統制済みへの道を通すのか。
• どの属性をSalesforceが所有し、どの属性を参照するだけか。
• チェックに失敗した受信データに何が起きるか（受け付け、拒否、隔離）、そして誰がその例外を所有するか。
• スチュワードが綻びに気づけるように、どの品質の兆候を測るか。

すべての悪いレコードを防ぐことは決してできません。仕事は完璧なデータではなく、避けられる悪いデータが高くつくデータになるのを防ぐことです。2年分の履歴を持つ前に重複を止めましょう。10個の連携が間違った識別子に依存する前に識別子を守りましょう。営業に見込み客を作らせつつ、それが統制された顧客になるまでは、そうであるふりをしないでください。そして悪いものがすり抜けたときには、誰かがそれを見て、所有し、直せるようにしておきましょう。

さらに学ぶ

• Salesforceヘルプ、Things to Know About Duplicate Rules (opens in a new tab)（英語）、2026-10-14確認。
• Salesforceヘルプ、Break Up Your Record Details with Dynamic Forms (opens in a new tab)とRequired and Read-Only Fields in Dynamic Forms (opens in a new tab)（英語）、2026-10-14確認。