はじめに

フューチャー Advent Calendar 2024の1日目です。

クリスマスおよび年末年始に向けて、みなさんもデータガバナンスを高めている最中かと思います。

大生成AI時代に突入し、ますますデータを資産化する重要度が上がっていると感じます。会社で新たにRAGが使えないか？みたいな話は週次なのか何なら毎日のように聞きます。

それら要望の実現性を上げるため、構造／非構造データをデータ基盤に取り込み、メタデータを上手く管理し、データの発見／利用の推進を加速させといったデータ基盤の構築や整備が改めて必要だと痛感している方も多いのではないでしょうか。まずはBIレポートやデータサイエンティストでデータドリブン経営／DXで業務改革を行いつつ、数年先の生成AIを活用したパラダイムシフトに備えるといった具合でしょうか。

この記事ではこれからデータ基盤を新規で構築する場合に、データガバナンスはどのレベルから整えると良いのだろうかと、考えたことをまとめていきます。立場として、データガバナンス策定を任されたメンバーとします。

データマネジメントの知識体系 "DMBOK" は取っ掛かりになるか

端的にはYes。網羅的であるため各カテゴリーの目的について抑えることはプラスだと思います。

「データマネジメント知識体系ガイド第二版」は絶版で中古市場にてプレミアが付いていましたが、なんと2024年7月に改訂版が発売されて、圧倒的に手に入れやすくなりました。

同著で紹介され、もしかするとそれ以上に有名なDAMA ホイール（画像右側の円）があります。それぞれの章の中身をデータ基盤をこれから新規で作るようなフェーズで読むと思考が迷子になりがちです。ピンと来ない部分があっても気にしないというくらいで踏み込みすぎない、というレベルが良いかもしれません。

例えば、「データ品質」はデータ基盤が構築されデータが利用され始めた時に課題になることが多いです。しかしデータ基盤の立ち上げ当初は、構築されたデータ基盤が利用されるかがまだ不透明な状態でしょう（データが取り込まれることすら不明瞭な場面もあるでしょう）。そのような場面で、データのSLI／SLOを取り決めるといった話をすると協力者も尻込みしがちです。

最初は以下のような部分を重点的に時間を投資するとよいのではないかと思います。

データアーキテクチャで青写真を描く
データセキュリティで、どのような権限モデルを描くのか（属性ベース、RBACなどの管理）
メタデータのうち、ビジネスメタデータの項目（あまり増やしすぎない）
参照データとマスターデータで、正とするマスターデータはどこから連携するか

データガバナンスを作ること自体をゴールにしない

これはあるあるですが、データガバナンスを作ろうとすると、基本的に ルールが厳しくなる方向にしかならないです。なぜなら具体的なユースケース（課題、対応策、想定される業務効果など）が不明瞭である、すなわち事業部側と役割分担（責任分界点とも言う）を詰めきれないため、リスクを共有できない以上は厳しくせざるを得ないというわけです。

最後まで軌道修正できないと以下の結果になります。

データガバナンスの考え方や実施計画は立派だが、データの利活用は進まなかった
あるいはデータガバナンスが有名無実化して、収拾がつかなくなった

データガバナンスを作る目的を忘れないようにする必要があります。おそらく、中長期的な視点で全社的（部門／部署を横断して）にデータを安全に使いやすくするために行う活動でしょう。そのため、何が何でも厳しくすればよいという訳ではありません。

これからデータ基盤を構築するという状態であれば、やってみないと分からないものは後に回すことも重要です。

例えば以下のような観点があります。

ビジネスメタデータは、「データオーナー」だけに当面は絞る
- PII（個人識別用情報）など機密情報を含むデータが当面ターゲットにいないのであれば、具体的にユースケースがあったタイミングで決める
データ利活用度が低い組織があった場合のフォローをどうするか
- BIやBigQueryなどの利用ログを収集して、可視化はできるようにしておく
- 具体的に利活用が進んでいないような部署が分かったタイミングでフォローを検討する

データアーキテクチャ

データ基盤でメインで利用するアーキテクチャなどは、言わずもがなで検討するでしょう。S3、Snowflake、BigQueryベースなどのプロダクト選定や、ETL、BIなども含みます。BIは割と揺れがちですが、レポート画面の権限制御は後から考えると面倒なので、並行して選定するといいでしょう。

データ基盤内でETL（dbtなど）をすることは多く、データリネージはかなり重要になります。おそらく、オンプレミスや、他のクラウドをまたいでトレースすることは難しいのでそのあたりの管理をどこまで行うかが、考慮ポイントになるでしょう。

データフローを調査していくと、マスターの扱いが上手くいっていない（各システムで育っていて亜種があるなど）は良く判明する課題です。マスターデータ管理（MDM）のようなサービスを合わせて導入できるかは状況次第だと思いますが、選択肢の1つとする方がよいでしょう。

データモデリング

データ基盤をこれから作るという立場だと、各システム領域のデータモデリングはとっくに終わっていると思われますので、途中から口を出すのは難しい場面が多いかと思います。

少しメタデータの章と被りますが、同じ項目を指すカラム名が、システムごとにバラバラだと面倒です。データ基盤連携時に項目変換をすれば良いという話もありますが、微妙に工数がかかるのと、データ基盤で分析しているデータサイエンティストが、データオーナーに質問する場合、名称に揺れがあると問い合わせコストも増大します。

以下のような辞書を用意するという地道な対応になると思います。

システム設計向けの業務用語集
論物変換辞書（日本語→物理名のマッピング）

これはメタデータの領域になりますが、同時にバリュードメイン（型ドメイン）のような、定義域も設定するとなお良いです。そのカラムが取りうる型／桁／精度／範囲などを示すものです。

一般的にパッケージやSaaSが入っていることが当たり前なので、カラムの論理名／物理名が調整効かない場合が大多数だと思いますが、競争領域では内製化の流れもありスクラッチでシステムを構築している組織も多いでしょう。そういったところだけでも、各種名称やバリュードメインを定義すると、後々のデータ利活用が楽になります。自戒でもありますがデータ基盤構築とは関係なく、少しずつやれる範囲で進めていきたいところです。

運用フローを決めるのはデータガバナンスチーム？

データガバナンスと、データマネジメントは一般的に別物です。

▼https://jp.drinet.co.jp/blog/datamanagement/data_governance_3minutes より引用

データ総研さんの上図のように、方針策定し、具体的なプロセスはデータマネジメント側で行いそれを監視することが一般的な解釈だと思います。

一方で、データガバナンス側が方針だけ立てて、具体的なところ全てをデータマネジメント側で対応することは、実用面だと非現実的になりがちです。例えば、ガバナンスの方針（ガイドライン）は立てたけど、対応の優先度は下げられるなどです。

そのため、方針に準拠した運用ルール（運用フローや簡単な手順書）まではデータガバナンス側で作るなど、ある程度の踏み込みは必要です。運用フローをデータマネジメントチーム側とすり合わせることで、現場で使えるデータガバナンスなのかどうかも気がつくことができます。データの利活用を安全に進めるという目標のため、なるべくヘルシーな協力体制を築きたいものです。

アーキテクチャ方針にデータガバナンスチームが入るべき？

具体的なシステム構築におけるアーキテクチャ設計（例えば、サービス設計／機能配置／同期非同期、PushPull／開発言語フレームワークライブラリ／テスト計画など）は、データガバナンスは関係ないので、責務的に異なるで良いと思います。

しかし、セキュリティ面での権限設定（アクセス制御）などは、もろに設計に影響するところです。データストレージとオペレーションも、バックアップ・リストアなどに影響があります。メタデータの自動連携などもそうでしょう。

つまり、データガバナンスの方針は、システム要求として表現されることがあります。場合によっては追加の機能開発になります（例えば、最小権限の原則を守っていない、過剰な権限を持つユーザーを検知するバッチ処理を作るなど）。

そのため、データガバナンスは、完全にデータ基盤のアーキテクチャが固まったタイミングで行うと、後からひっくり返せない可能性があります。逆に具体的なアーキテクチャイメージ無しでデータガバナンス観点の方針を出すと、これってどう実現するんだ？といった飛び道具的な要件が出てくることもあります。立派なデータガバナンスを考えたが、実現できなければ意味が無いわけで、実効性を持たせるためにはアーキテクトと良く相談することは必須でしょう。

データ品質は後回しにしてよいの？本当に？

データ基盤に連携される各データ種別が、どの程度のデータ信頼性を持つべきかの要件を握るのは、BIなど利活用側です。例えば経営管理のようなざっくりとした（？）集計で事足りる場合は相応になりますし、より細かい粒度で出力したレポートで取引先と重要な契約をする場合は、高い信頼性が必要です。

全てのデータ種別が一律同じレベルを求めるわけではないので、利用者側の要望も汲み取り、ケースバイケースで取り決めていくしか無いでしょう。

また、一般的に、データ基盤構築で最初に取り込むのは、すでに稼働済みのシステムからI/Fデータをもらって取り込むことが多いと思われるので、最低限の品質は担保されているのでは？と思います。

低品質なデータが存在することにより、誤った意思決定が行われてしまうことはもちろん、データ基盤を構築する本来の意図と本意ではないので是正が必要ですが、過剰に品質チェックすること自体のコストも馬鹿にできません。ユースケースを見極めるため、利用実体をモニタリングしたり、定期的にヒアリングするような体制を整えていきましょう。

まとめ

11月頃に公開された某社のレポートで、生成AIで業務効率を相当引き上げているが、まだ上手く活用できていない会社がある。理由として、「データガバナンスやデータ基盤が整っていないこと、人材育成が間に合っていないこと」の2点が挙げられていました。

この記事にも記載したように、データ基盤は、データガバナンス観点で設計構築が進むことは一般的になっているように感じます。一方でシステム構築においてはまだまだなように感じます。

データガバナンスの考えを持つことで、データを資産として活用しやすくできると思います。

それは今後の企業の成長性に大きく影響すると思います。皆さまのますますの発展を願っています。最後まで読んでいただき、ありがとうございました。