デジタルトランスフォーメーションの波の中で、データガバナンスは企業にとって無視できない重要な課題となっています。しかし、この巨大な課題に直面し、多くの企業やデータ管理者は途方に暮れています。この記事では、データガバナンスの境界に関する問題を深く掘り下げ、データ生産者、データ処理者、データ利用者という3つのステークホルダーの役割と責任、そしてデータガバナンスの2つの境界を分析します。

データガバナンスに関しては、他の人がどう感じているかは分かりませんが、私にとってはまるで巨大なモンスターに直面し、途方に暮れているような感覚です。やるべきことは山ほどあるのに、一体何をすべきなのか？まず何をすべきで、その後は何をすべきなのか？一つの行動が広範囲に影響を及ぼすような重要な局面はあるのだろうか？段階的な成果を実現するにはどうすればいいのか？プロセスを円滑に進めるにはどうすればいいのか？答えよりも疑問の方が多いように感じます。

最初に合意する必要があることについて言えば、データ ガバナンスの第一歩は、ガバナンスの対象とする必要があるものの境界を定義することだと私は個人的に考えています。

I. データの3つの参加者

データフローに応じて、データプロデューサー、データプロセッサー、データコンシューマーの 3 つの参加者が存在します。

データ生成者とは、データを生成するビジネスシステムです。データ処理者とは、データのクレンジング、モデル化、処理を実行するデータ部門であり、通常はデータプラットフォーム部門です。データ消費者とは、クレンジングおよび処理されたデータを最終的に使用する部門であり、ビジネス部門または分析部門です。

II. データガバナンスの2つの境界範囲

ここでデータ ガバナンスの境界を決定するということは、ガバナンスがデータ処理者の範囲のみを対象とすべきか、それともデータ生成者の範囲も含めるべきかを決定することを意味します。

言い換えれば、データガバナンスは、業務システムによってデータが生成された後にデータプラットフォームにインポートされたデータに対してのみ実行されるのでしょうか（つまり、データ入力後のガバナンス）？それとも、業務システムがデータを生成した時点から、データプラットフォームにインポートされる前に開始されるデータガバナンス（つまり、データ入力前のガバナンス）なのでしょうか？

名前が示すように、エンタープライズレベルのデータガバナンスには、データ入力前とデータ入力後のガバナンスが含まれます。しかし、実際には、これら2種類のガバナンスは、難易度、プロセス、そして必要なコミュニケーションの範囲において大きく異なります。データはしばしば流水に例えられますが、データ入力前のガバナンスは川の下流にあたり、上流での管理が必要となるため、その難しさは明らかです。

第一のタイプは、データ統合後のガバナンスであり、主にデータプラットフォーム（データプラットフォームが主導権を握ると仮定）が主導し、他の事業部門がサポートを提供します。第二のタイプは、統合前のデータガバナンスであり、これは真に全社的なシステムの適応と変更を必要とします。ファーウェイは、システムコンプライアンス要件を達成したと報告されています。統合前と統合後のガバナンスは、業務システムをオンラインリリースする前に、一定のデータガバナンス基準と品質要件を満たす必要があります。そうでない場合、システムの本番稼働は許可されません。

データガバナンスプロジェクトの立ち上げ当初から、「データレイクへのデータ統合前後の包括的なデータガバナンスが必要で、変革には全社的な協力が必要だ」などと謳っていては、成功する可能性は極めて低いでしょう。この段階で「データガバナンスは経営トップのプロジェクトだ」という声をよく耳にしますが、個人的には経営トップが何をどう支援していくかが重要だと考えています。盲目的に支援し、業務システムに影響が出た場合、誰が責任を負うのでしょうか。結局のところ、現状のデータガバナンスは、まだ仕上げの段階に過ぎません。

さらに、現時点では、成功への明確な道筋が完全には明らかではないように思われます。

もちろん、これはリーダーシップのサポートが不要という意味ではありません。データガバナンスプロセスにおいて、リーダーシップのサポートは不可欠な条件だと私は個人的に考えています（場所と人材については後ほど説明します）。むしろ、明確な道筋が確立された後にのみ、リーダーシップのサポートを確保できるということです。リーダーシップは、人材、資金、時間を提供し、期待値をコントロールする必要があります。

ほとんどの場合、サポートには条件が付いてきます。サポートを受けるには、成功へのわずかな希望が見える必要があります。

III. データがレイクに導入される前にデータ ガバナンスを実行する必要がありますか?

では、データがレイクに転送される前にデータガバナンスを行うべきではないということでしょうか？いいえ、そうではありません。まずはデータがレイクに転送された後にデータガバナンスを実施し、その後、問題解決型およびシナリオ主導型のアプローチを通じて、転送前のデータガバナンスを段階的に導入することで、ビジネスオペレーションに影響を与え、グローバルなデータガバナンスを実現していきます。

問題駆動型アプローチは理解しやすいものです。データの不整合、定義の不一致、値の不整合などを発見するアプローチで、多くの場合、特定のシステムからのデータに頻繁に発生する異常が原因となります。こうした問題を発見することで、データプラットフォームにデータをインポートする前に、ビジネスシステム内のデータガバナンスを強化できます。エラーのあるデータを使用することで、ソースシステムのデータ品質を向上させることができます。

もちろん、このプロセスには監視およびサポートツールが必要です。これらのツールは、手動操作やその後のパフォーマンス追跡に頼るのではなく、ビジネスシステムが関連する監視ルールを柔軟に設定できるようにする必要があります。これにはツールの準備も含まれます。さらに、ツールに加えて、その実装を確実にするためのポリシーガイドラインも必要です。最後に、この問題に対応し、責任を負うための適切な組織リソースが必要です。

もう一つのアプローチはシナリオ駆動型です。重要なシナリオとして、用語に一貫性がなく、同じ指標に対して人によって異なる評価基準を提示する企業などが挙げられます。あるいは、人事情報や住所といった重要なマスターデータがシステム間で容易に統合できない場合もあります。このような場合、特定のシナリオを用いて異なる組織の担当者を調整し、同じ基準を遵守させ、ツールを用いて用語を統一することができます。例えば、社内の異なるシステム間で住所データを統合したり、ECIF（経済的に解釈できる情報フレームワーク）を構築して、異なるシステムから収集された人事データの一貫性を確保したりすることができます。

これらのシナリオ駆動型ガバナンスアプローチはいずれも、比較的大規模なシステムエンジニアリングプロジェクトです。例えば、前述のECIFは、ユーザーマスターデータを統合するために使用される独立したシステムです。

この段階的なアプローチは、データがレイクに転送される前にビジネス オペレーションに影響を与え、システム データ ガバナンスの目標を達成するために使用されます。

さらに、データ入力後のガバナンスを実施するもう一つの理由は、データプラットフォーム部門と業務オペレーション部門間のコミュニケーションと信頼関係を強化することです。これにより、業務オペレーション部門は実行されているタスクを理解し、タスクが任意または抵抗感を抱くことなく、行動を通じて影響を与えることができます。

IV. 要約

この章では、主にデータガバナンスにおいて最初に取り組むべき課題、すなわちデータガバナンスの境界について、私の個人的な理解に基づき議論します。まずは、データがデータレイクに入った後のガバナンスに重点を置き、その後、問題主導型およびシナリオ主導型のアプローチを通じて、データ入力前まで継続的にガバナンスを実施することで、グローバルガバナンスを実現します。

データガバナンスの境界を明確化した上で、その内容を掘り下げる前に、まずデータ管理とデータガバナンスの違いを明確にしておきましょう。これら2つの概念の明確な意味を定義することで、データガバナンスがまさに概念であることをより深く理解できるようになります。