オーナーがポリシーを決め、アーキテクトがそれを強制する
ほかに 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)
Data Architectコース第5章、第1部：データアーキテクトになる。前へ：企業のデータを理解する。
「データガバナンス」と言うと、人は会議を思い浮かべます。委員会、ポリシー、誰も読まない文書。私は毎回、別の問いを立てます。そのポリシーはどこで強制されているのか？
ポリシーが、顧客の正式名称を変えられるのは財務だけだと言っているなら、ほかの誰かが変えるのを何が止めているのか？ クルーが受取人の住所を見られるのは自分の停車地について、その日だけだと言っているなら、何がそれを真実にしているのか？ これを7年間保持すると言っているなら、7年後に何がそれを削除するのか？ 強制する場所のないポリシーは、ほとんど願望です。私の立場はシンプルです。オーナーがポリシーを決め、アーキテクトがそれを強制する。 データオーナーが決めます。アーキテクトが設計したシステムが、それを機械的に真実にするのです。
そして、終わることは期待しないでください。ガバナンスは決して終わらない。 満ち引きを繰り返しながら、最悪の悪いデータを締め出し続けます。Salesforceが単独で立っているならシンプルで、第4章で描いた全体像の一つのノードであるときには、より難しく、より必要になります。だからあの章が先に来たのです。全体像は、ガバナンスがどこまで届かなければならないかを教えてくれます。
画像はAIで生成しました。
この章の立場
Section titled “この章の立場 ”- 会社の働き方に合わせてプログラムを運営する： 集中型、連邦型、ハイブリッド型。アーキテクトは、誰がポリシーを承認するのかを知っておく必要があります。
- レコード所有者はデータオーナーではない。 所有者項目は割り当てとアクセスを決めます。データについての責任はビジネスにあります。
- 作成を開放するか制限するかは、データを取り巻くガバナンス次第。 ほとんどの中小規模の組織では開放で問題ありません。取引先がERPでマスター管理されているか、ERPと同期しているなら制限します。中間の道は、管理された変換で正式なものになる、仮のレコードタイプです。
- ERPが項目をマスター管理しているなら、あなたはそれを変えているのではなく、変更を依頼しているのです。 ゴールデンレコードはハイブリッドです。ERPのマスター項目は入ってきて、Salesforce独自の項目は決して戻らず、双方向の流れには衝突のルールが必要です。
- すべての項目ではなく、機密の項目を分類する。 広く文書化し、意図して分類し、ビジネスメタデータと技術メタデータの両方を保ちましょう。
- 規制を教える。 多くのアーキテクトは自分の地域の外の法律を聞いたこともありませんが、そうした法律がシステムの設計を形づくります。
- 標準の同意モデルを使う。 できる限り、作り直すのではなく。
- 忘れられる権利のためには、まず個人データがどこへ行くかを管理する。 削除はまれで、難しいものです。個人データが着地する場所が少なくなるように設計し、それから期限が来る前にすべてのコピーを探し出しましょう。項目履歴、アーカイブ、分析用のコピー、検索インデックス、エージェントとの会話。
- 保存時の暗号化のような主要な規制要件には、Shieldが答えになる。 そのトレードオフに向けて設計しましょう。
- 規制対象ならField Audit Trail。 標準の項目履歴がデフォルトです。
- 必要になる前にEvent Monitoringを設定し、 イベントをSplunkのようなリポジトリに流し込む。問題にぶつかってから、記録していなかったことに気づくのではいけません。
統制されたデータのライフサイクル
Section titled “統制されたデータのライフサイクル ”データの一生にわたる7つの問い。ツールはポリシーを支えますが、ポリシーを定義するのではありません。
この章の道筋
Section titled “この章の道筋 ”6つのモジュールがあり、それぞれ単独でも読めます。
- ガバナンスは組織に組み込んで設計する。 オーナー、スチュワード、カストディアン。集中型、連邦型、ハイブリッド型。レコード所有者とデータオーナーの違い。すべてのポリシーを強制する場所に変えること。
- 悪いデータを入れない。 ビジネス上の定義としての「十分によい」。作成の開放か制限か、仮のレコード、そして流れごとのレコードタイプ。ハイブリッドなゴールデンレコードと双方向の連携。すべてのデータの境界での品質の判断。
- データを知る：辞書、系統、分類。 ビジネスメタデータと技術メタデータ。それが何を意味し、どこから来て、どう扱われなければならないか。そして強制のない分類が飾りである理由。
- プライバシー法が設計を形づくる。 知っておくべき法律と、それらに共通するもの（権利、移転、侵害の通知、説明責任）、そして法律より長生きする問い。匿名化と仮名化の違い。コンプライアンスは製品ではない。
- 同意と忘れられる権利。 データとしての同意、標準の同意モデル、すべての請求にかかる期限、そして最初の請求が届く前に消去を設計すること。
- 保護し、保持し、証明する。 暗号化のトレードオフ、サンドボックス、保持、項目履歴とField Audit Trail、そして必要になる前に設定するEvent Monitoring。
読み終えたら、章の学習ガイドで理解度を確認しましょう。試験のためのチェックリスト、試験の先にある習慣、覚えておきたい用語、そしていくつかの問いがあります。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 重要なデータ領域のそれぞれを誰が所有するか。 そして、それぞれのオーナーのポリシーを何が強制するか。
- どんな悪いデータを締め出すか。 そして何を捕まえ、隔離し、後で直すか。
- どの項目が機密か。 そしてその分類が何を変えるか。
- 個人データがどこへ行くか。 何に使ってよいか、そしてすべてのコピーからどう消すか。
- データとその履歴をどれくらいの期間保持するか。 そして何が起きたかを証明するどんな証拠があるか。
この章はアーキテクチャのガイダンスであり、法的助言ではありません。 どの法律が適用され、それが何を求めるかを決めるのは法務とコンプライアンスのチームです。アーキテクトはその要件を設計に翻訳します。
試験の先へ： ガバナンスには新しい利用者、エージェントがいます。分類がエージェントが何を取得してよいかを決め、同意がデータを何に使ってよいかを決め、系統と監査はエージェントが何を言い、何をしたかにまで届かなければなりません。各モジュールの最後で、ライフサイクルのその部分についてAIが何を変えるかを扱います。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Data Classification Metadata Fields (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Understand the Salesforce Consent Data Model (opens in a new tab)（英語）、2026-10-14確認。
- Regulation (EU) 2016/679（GDPR） (opens in a new tab)、EUR-Lex、2026-10-14確認。
次へ： マスターデータとID