指標の定義を一箇所に置くということ

「今月の売上はいくらか」という問いに、営業部門と経理部門が別の数字を出す。どちらも間違っていない。返品をいつ差し引くか、契約日と検収日のどちらを計上日とするか、前提が違うだけである。問題は、その前提がどこにも書かれていないことにある。

定義が散らばる仕組み

指標の定義は、通常、それを使う場所に埋め込まれる。BI ツールのクエリに、表計算のセルに、レポート生成スクリプトに。それぞれが独立に書かれ、独立に修正される。

この構成では、定義の変更が全箇所に伝播しない。返品の扱いを変えたとき、更新されるのは変更者が知っている場所だけである。知らない場所は古い定義のまま動き続け、二つの数字が並存する。

一箇所に置くという発想

Looker が導入した LookML は、指標とディメンションの定義をコードとして記述し、BI 画面のクエリはその定義を参照して生成される、という構成をとった。定義はバージョン管理され、変更履歴が残る。

その後、dbt Labs のセマンティックレイヤー（MetricFlow）など、BI ツールから独立した層として指標定義を保持し、複数のツールへ供給する実装が現れた。Airbnb が自社の指標基盤 Minerva について公開した技術情報も、同じ問題意識を共有している。単一の定義から、複数の消費者へ。

この層が提供するのは、次の三つである。

• 指標の定義（計算式、フィルタ、粒度）
• 定義の版管理と変更履歴
• 消費者側からの一貫した参照経路

新しくない問題

Ralph Kimball が提唱した適合ディメンション（conformed dimensions）は、複数のデータマートが同じディメンションを共有することで、部門をまたいだ集計の整合を保つ設計である。1990年代から2000年代にかけて確立したこの考え方は、いま「セマンティックレイヤー」と呼ばれているものと、目的においてほぼ一致する。

異なるのは、実装が置かれる層である。Kimball の時代にはデータウェアハウスのスキーマとして表現されたものが、いまは計算エンジンから分離された定義層として表現されている。分離によって、複数のクエリエンジンに対して同じ定義を適用できるようになった。

反論：合意のほうが難しい

技術的な構成が整っても、導入が進まない事例は多い。理由は単純で、「売上とは何か」を一つに決めるという作業が、部門間の権限に触れるからである。

営業部門の数字が経理の定義に置き換えられれば、営業の実績は下がって見える。この変更は技術的には一行の修正だが、組織的には交渉である。セマンティックレイヤーの導入プロジェクトが遅延するとき、遅延しているのはたいてい実装ではなく合意である。

一方で、この事情は導入を退ける理由にはならない。定義が散らばっている状態では、交渉すら発生しない。数字が食い違っていることに誰も気づかないまま、それぞれの部門がそれぞれの数字で意思決定を続ける。定義層は、対立を生むのではなく、既に存在していた対立を可視化する。

契約としての定義

指標の定義を単一の場所に置き、版管理し、参照経路を固定する。この構成は、API 契約の管理と構造が同じである。提供側が定義を変えれば、参照側の振る舞いが変わる。だから変更には調整が要る。

違いは、API の場合には呼び出しが失敗して異常が可視化されるのに対し、指標定義の場合は数字が静かに変わるだけだという点にある。壊れたことに気づけない変更は、壊れないことより危険である。

したがって定義層に必要なのは、定義そのものだけではない。定義が変わったときに、どの画面とどのレポートが影響を受けるかを示す依存グラフである。それがなければ、一箇所に集めたことの利点の半分は失われる。ここでも問題は、可視化の手前の工程に戻ってくる。