ガバナンスは組織に組み込んで設計する
ほかに 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)
モジュール1／6：Data Architectコース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 次へ：悪いデータを入れない
このモジュールが答える問い： データガバナンスはアーキテクトにとって何を意味し、誰が何をするのか？
データガバナンスと聞くと、人は会議を思い浮かべます。委員会、ポリシー、標準、データについて誰が何をすべきかを説明した文書。どれもガバナンスプログラムの一部かもしれません。アーキテクトとして私が関心を持っているのは、別の問いです。そのポリシーはどこで強制されているのか？
ポリシーが、ある項目を変えられるのは財務だけだと言っているなら、何がそれを強制しているのか？ ERPが正式な顧客レコードを所有していると言っているなら、Salesforceの誰かがそれを変えるのを何が止めているのか？ クルーが受取人の住所を見られるのは自分の停車地について、その日だけだと言っているなら、何が実際にそれを真実にしているのか？ これを7年間保持すると言っているなら、7年後に何がそれをアーカイブしたり削除したりするのか？ 強制する場所のないポリシーは、ほとんど願望です。 そうした判断がシステムに組み込まれたとき、ガバナンスはアーキテクチャになります。
ガバナンスは決して終わらない
Section titled “ガバナンスは決して終わらない ”早めにはっきりさせておきましょう。ガバナンスは終わらせるものではありません。 私はそれが満ち引きを繰り返すのを見てきました。会社がデータ品質に本気で注意を向けると、よくなります。注意がほかへ移ると、品質は落ちます。新しい連携が稼働する、事業部門がプロセスを変える、誰かがファイルをインポートする、会社が別の会社を買収する、エージェントがレコードを書き始める。そのたびに問題は変わります。目標は、すべてのレコードが永遠に完璧であるという幻の状態ではありません。データをビジネスにとって十分に信頼できる状態に保ち、最悪の悪いデータを締め出すことです。それは続いていく仕事です。
Salesforceがほぼ単独で立っているなら、ガバナンスとは一か所でデータをきれいにすることです。第4章の全体像の一つのノードであるなら、より難しく、より必要になります。今や顧客はSalesforce、ERP、ウェアハウス、パートナーのシステム、Data 360にいます。誰が所有しているのか？ 誰が変えられるのか？ どのコピーが権威あるもので、どの属性が動いてよく、どれくらいの期間保持され、間違っていたら誰が責任を持つのか？ それらは設定の問いではありません。設定になるガバナンスの問いです。
レコード所有者はデータオーナーではない
Section titled “レコード所有者はデータオーナーではない ”所有者という言葉から始めましょう。Salesforceがこれをややこしくしているからです。取引先を開くと、所有者が表示されます。たとえば営業担当者です。その担当者が顧客データを所有しているのでしょうか？ 必ずしもそうではありません。Salesforceでは、所有者を持つオブジェクトのレコードはユーザーかキューが所有し、所有者はフルアクセスを持ち、ロール階層と共有ルールを通じて割り当てと共有を決めます（Sharing and Record Access Features (opens in a new tab)、英語）。それがレコードの所有、つまりプラットフォームの仕組みです。
データオーナーは別のものです。ビジネス資産としてのデータに責任を持つ人や部門です。財務が顧客の法的な情報を、オペレーションが配送ステータスを、人事が従業員データを所有しているかもしれません。Salesforceにはそれを記録する場所まであります。各項目のデータ所有者（Data Owner）という分類項目です（Data Classification Metadata Fields (opens in a new tab)、英語）。
Steve Truckingでは、小売パートナーの取引先は、そのパートナーを担当する営業責任者が所有しているかもしれません。しかしパートナーの法的な識別は財務が統制し、財務ERPでマスター管理されています。営業、サービス、オペレーション、パートナーポータルのすべてがその取引先を必要としますが、財務がいったん確定させたパートナーの法的な識別を営業責任者が変えてよいという意味にはなりません。所有者項目を見て、データの所有の問題を解決したと思い込むチームを見てきました。解決していません。レコードの割り当ては、ビジネス上の責任ではありません。
オーナー、スチュワード、カストディアン
Section titled “オーナー、スチュワード、カストディアン ”ガバナンスの3つの役割、3つの別々の仕事です。
データオーナーはポリシーを決める。 そのデータが何を意味するか、誰が作成し変更してよいか、どれくらい正確でなければならないか、どれくらいの期間保持するか、誰が見てよいか、どのシステムが権威を持つか、間違っていたら何が起きるか。オーナーがそれに答えます。アーキテクトがその答えを発明すべきではありません。それは私の最も強い立場の一つです。オーナーがポリシーを決め、アーキテクトがそれを強制する。 財務が、顧客が有効になったら正式名称はERPのプロセスを通じてしか変えられないと言うなら、それはガバナンスの判断です。それを機械的に真実にするのが私の仕事です。
データスチュワードはそれを機能させ続ける。 スチュワードはデータの日々の健全性の近くにいます。品質の兆候を見張り、重複を調べ、例外を解決し、修正を調整し、定義を維持し、悪いデータを生み続けるプロセスを見つけます。スチュワードにはさらに2つの仕事があります。ある項目が何を意味するか、誰が所有するか、誰が見てよいかについて2つのチームの意見が分かれたとき、スチュワードはその争いをオーナーのもとに持ち込み、決定が実行されるまで見届けます。そしてスチュワードはデータリテラシーを育てます。データを入力し使う人たちが、それが何を意味し、なぜルールが存在するのかを理解できるよう手助けするのです。スチュワードには、組織図の上の名前以上のものが必要です。時間、可視性、プロセス、そして問題を直させる権限です。そうでなければ「データスチュワード」は誰かの8番目の責任になり、四半期に一度しか見られなくなります。
カストディアンはシステムを運用する。 管理者、プラットフォームチーム、セキュリティチーム。データを保存し処理するテクノロジーを運用している人たちです。オーナーがこのロールだけが見てよいと言い、カストディアンがそれを実現する管理策を運用します。名前よりも、それぞれの責任をはっきりさせることのほうが重要であり、小さな組織では一人が2つの役割を兼ねることもあります。
プログラムをどう運営するか
Section titled “プログラムをどう運営するか ”ガバナンスのプログラムには、たいてい3つの形があります。集中型： 一つのチームが、すべての領域のポリシーと標準を書きます。一貫していますが、ボトルネックになることがあり、実際に仕事をしている人たちから遠くなります。連邦型（分散型）：財務、営業、オペレーションといった各領域が、いくつかの共有ルールの範囲内で自分のデータを統制します。仕事に近いのですが、領域の間で定義がずれていきます。ハイブリッド型： 小さな中央チームが標準と共有の定義を所有し、領域のオーナーとスチュワードが自分たちのデータを運用します。私が見てきたほとんどの企業は、最終的にハイブリッドのどこかに落ち着きます。アーキテクトにとって、この形は一つの実際的な問いに答えます。私が強制する前に誰がポリシーを承認し、共有の定義はどこにあるのか？
試験に出やすい知識。 ガバナンスのプログラムを運営する3つの方法、集中型、連邦型（分散型）、ハイブリッド型と、それぞれが、誰がポリシーを決め、共有の定義がどこにあるかについて何を意味するかを知っておきましょう。
RACIにその場所を勝ち取らせる
Section titled “RACIにその場所を勝ち取らせる ”RACI（Responsible：実行責任者、Accountable：説明責任者、Consulted：相談先、Informed：報告先）は役に立ちます。ただし、ガバナンスが「必要としている」から作る巨大なスプレッドシートではいけません。私はそれにアーキテクチャの問いに答えてほしいのです。まずは第4章の3つの問い（分類の背後にある4つの問い）からです。データはどこで作成され、どこで編集され、どこで参照されるのか？ それはしばしば別々のシステムです。製品を例にとりましょう。ERPが作成し、Salesforceが参照し、ポータルが表示し、ウェアハウスが分析します。そこでビジネスが「有効な製品」の意味を変えます。その変更はどこから始まり、誰が承認し、どう広がり、どのコピーが読み取り専用なのか？ 答えられないなら、まだガバナンスはありません。あるのはコピーです。よいRACIは、まさにその曖昧さをあらわにします。
ガバナンスは機械的にならなければならない
Section titled “ガバナンスは機械的にならなければならない ”ビジネスが、顧客の正式名称を変えられるのは財務だけだと言います。アーキテクチャの答えが「トレーニングで扱います」であってほしくはありません。トレーニングは役に立ちますが、強制ではありません。項目レベルのアクセスかもしれませんし、入力規則、連携だけが書き込む項目、あるいは直接編集ではなく管理されたプロセスかもしれません。仕組みは要件によりますが、何かが必要です。
| ガバナンスのポリシー | 決めるオーナー | 考えられる強制の場所 |
|---|---|---|
| ERPが顧客の法的な識別を所有する | 財務 | 連携だけが書き込む項目、権限、入力規則 |
| 必要のある人だけが個人データを見る | プライバシー、セキュリティ | 共有、権限、項目アクセス |
| 顧客の識別子は一意である | ビジネスオーナー | 一意の外部ID、重複ルール |
| 統制されたレコードは手作業で作らない | データオーナー | 権限、自動化、連携 |
| 機密データには決められた保持期間がある | プライバシー、法務 | 保持または削除のプロセス |
| 重要な変更は証明できなければならない | コンプライアンス | 項目履歴、監査証跡 |
| データの出どころが識別できる状態を保つ | データオーナー | ソース項目、系統のメタデータ |
考えられる強制の場所と言っているのは意図的です。これは機能を選ぶための表ではありません。考える順序です。ポリシーは何か、誰が所有しているか、そしてアーキテクチャの中の何がそれを真実にするのか？
オーナーがポリシーを決め、アーキテクトがそれを強制する。
善い振る舞いに頼らない
Section titled “善い振る舞いに頼らない ”「ERPの顧客IDは決して変えないこと」。誰もが知っています。誰かが変えてしまうまでは。うっかり、データロードで、自動化で、連携で、エージェントで。それを変えると企業のデータが損なわれるなら、「どうか変えないでください」は管理策ではありません。管理策を作りましょう。信頼しつつ検証する。人、連携、自動化、AIはみな間違いを犯します。ですからアーキテクチャは、いずれ何かがポリシーの禁じていることをしようとすると想定すべきです。そのとき何が起きるのか？
ガバナンスはシステムの境界を越える
Section titled “ガバナンスはシステムの境界を越える ”全体像に戻りましょう。ERPが顧客を所有し、Salesforce、ウェアハウス、顧客データプラットフォームがコピーを持ち、パートナーがその一部を受け取ります。ポリシーはどのシステムに適用されるのでしょう？ すべてです。Salesforceが正式名称の変更を正しくブロックしても、連携が下流のシステムにそれを上書きさせてしまうかもしれません。Salesforceが個人データを削除しても、ウェアハウスにはまだ残っているかもしれません。Salesforceで機密に分類された項目が、別の場所の分類されていないテキスト項目に着地するかもしれません。データが組織の端で止まらない以上、ガバナンスも組織の端で止まれません。だから第4章が先に来たのです。全体像は、ガバナンスがどこまで届かなければならないかを教えてくれます。
すべてではなく、十分に統制する
Section titled “すべてではなく、十分に統制する ”反対の失敗も同じくらい現実的です。ガバナンスが重要だと気づき、すべてを締め付けます。誰も作成できず、すべての変更に承認が要る。データは統制されていて、誰も仕事ができません。ガバナンスとは、データに適切な管理をすることです。あるものには厳しく、あるものには軽く。自由に作成できるレコードもあれば、承認が必要なレコードもあり、ほとんど誰でも編集できる項目もあれば、連携だけが編集できる項目もあります。次のモジュールで、まさにそれを実践的に扱います。
そしてガバナンスは決して終わらないので、強制にはフィードバックが必要です。重複は増えていないか？ 必須項目がゴミで埋まっていないか？ 連携が失敗していないか、ユーザーが回避策を見つけていないか、例外が増えていないか、スチュワードが一日中一つの問題に費やしていないか？ そうした兆候が、設計が機能しているかどうかを教えてくれます。そしてときには、管理策やポリシーを変える必要があることも。
試験の先へ：AIが変えること。 ガバナンスには新しい利用者がいます。エージェントです。何を使ってよいか、何のために使ってよいかを決めるのはやはりデータオーナーで、それを強制できるようにするのはやはりアーキテクトです。変わるのは速さと規模です。エージェントは統制されたデータを人よりはるかに速く読み、組み合わせ、それに基づいて行動します。ですから、文書の中にしか存在しないポリシーは、さらに守ってくれなくなります。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 重要なデータ領域のそれぞれに誰が責任を持ち、それがレコードの所有とどう違うか。
- 誰がデータのスチュワードを務め、誰がカストディアンとしてそれを運用するか。
- 重要なデータが、全体像のどこで作成され、編集され、参照され、マスター管理されているか。
- 重要なポリシーのそれぞれを、どの強制の場所が機械的に真実にするか。
- ガバナンスが機能しているのか、それとも綻び始めているのかを、アーキテクチャがどう示すか。
ガバナンスの要件を聞くと、私はそれを翻訳します。「これはERPが所有している」「これを見られるのはこの人たちだけ」「誰がこれを変えたかを証明する必要がある」「これを7年間保持する」。そのたびに、強制の場所を見せてほしいと言います。アーキテクトはポリシーを決めません。それを強制するシステムを設計するのです。そこでガバナンスは文書であることをやめ、アーキテクチャになります。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Sharing and Record Access Features (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Data Classification Metadata Fields (opens in a new tab)（英語）、2026-10-14確認。