指標の定義とデータの管理

「今月の売上」を聞いたら、営業部と経理部で違う数字が出てきた――これはデータ基盤でとてもよくある問題です。税込か税抜か、キャンセル・返品を引くか、計上は注文日か出荷日か。定義がそろっていないと、会議が「どちらの数字が正しいか」の議論で終わってしまいます。

セマンティックレイヤーは、指標（売上・アクティブユーザー数など）の定義を1か所のコードで管理し、BI ツールや SQL、スプレッドシートなど、どこから使っても同じ計算で数字が出るようにする層です。dbt のセマンティックレイヤー、Looker の LookML などがあります。たとえば「売上＝ステータスが paid と shipped の注文の税抜金額の合計。日付は注文日」と一度だけ定義し、各ダッシュボードはそれを呼び出すだけにします。

道具を入れるだけでは定義はそろいません。指標ごとに持ち主（決める人）を決め、定義を文章でも残し、変えるときは告知する、という運用が先です。まずは利用の多い 10個ほどの指標から始めるのが現実的です。

指標の定義は、計算式だけでなく「何を含み、何を除くか」「どの日付で数えるか」まで書いて、初めて数字がそろいます。

データカタログは、どんなテーブルがあり、各列が何を意味し、誰が持ち主で、どれくらい新しく、どこから作られているか（リネージ）を検索できる目録です。利用者が「このテーブルを使っていいのか」を自分で判断できるようになり、データのチームへの同じ質問が減ります。

カタログは、説明が空っぽだと使われなくなります。dbt の YAML に書いた説明を自動で取り込むなど、コードと一緒に説明を書く仕組みにすると、古くなりにくくなります。よく使われるテーブルから説明を埋めます。

「このテーブルの数字がおかしい」と言われたとき、誰が直すのかが決まっていないと、問い合わせがデータのチームに集まり続けます。データにも持ち主を決めます。

持ち主はカタログや dbt の YAML（meta の owner など）に書いておき、テストの失敗の通知もその持ち主に届くようにします。

データメッシュは、データの提供を中央の1チームに集めず、そのデータに詳しい業務のチームが「データプロダクト」として提供する、という組織の考え方です。

データプロダクトは、他のチームがそのまま使えるように、説明・品質の約束・持ち主・権限まで含めて提供されるデータのことです。どの組織の形でも、「使う人のための製品として、データを作る」という考え方は役に立ちます。