フレームワーク活用ガイドひとことで言うと#
「売上とは何か」「アクティブユーザーの定義は何か」といった指標の計算ロジックを1箇所で定義し、すべてのBI・レポート・ダッシュボードがその定義を参照する仕組み。同じ指標なのにツールごとに数字が違う問題を根本から解消する。
押さえておきたい用語#
- メトリクス（Metrics）
- ビジネスの状態を数値で表す指標のこと。売上、DAU、解約率、LTVなどが代表例。
- セマンティックレイヤー（Semantic Layer）
- 物理的なデータベースとBIツールの間に置く意味の翻訳層を指す。テーブル名やカラム名をビジネス用語に変換し、計算ロジックを集約する。
- ディメンション（Dimension）
- メトリクスを切り口で分解するための属性である。地域・期間・顧客セグメント・商品カテゴリなどが該当する。
- Single Source of Truth（SSOT）
- 指標の定義が唯一の正しい情報源から提供されている状態。メトリクスレイヤーが目指すゴール。
メトリクスレイヤーの全体像#
こんな悩みに効く#
- 経営会議で「この売上の数字、どっちが正しいの？」と毎回議論になる
- 同じKPIなのにダッシュボードとExcelレポートで数字が違う
- 新しい指標を追加するたびに、複数のBIツールに同じ定義を手動で設定している
基本の使い方#
組織で使われている指標をすべてリストアップし、定義のバラつきを可視化する。
やること:
- 各チーム・ダッシュボード・レポートで使われている指標名を収集
- 同じ名前の指標が異なる定義で計算されていないかを確認
- 定義の違いがビジネス判断にどの程度影響しているかを評価
よくある発見:
- 「売上」の定義が営業部（受注ベース）と経理部（検収ベース）で異なる
- 「アクティブユーザー」のカウント期間がチームごとに7日/28日/30日と違う
- 「解約率」の分母が契約者数なのかアクティブユーザー数なのか曖昧
棚卸しの結果をもとに、1つの指標に1つの定義を確定させる。
定義すべき項目:
- 名前: 日本語名と英語名（例: 月次売上 / Monthly Revenue）
- 計算式: SQL等で厳密に記述（例:
SUM(amount) WHERE status = 'completed' AND refund = FALSE） - ディメンション: どの切り口で分解可能か（地域 / 月 / 商品カテゴリ）
- 粒度: 日次・週次・月次のどれをデフォルトにするか
- オーナー: 定義の変更権限を持つ人
合意形成は経営企画・データチーム・業務部門の3者で行う。
合意した定義をコードとして一元管理する。
代表的なツール:
- dbt Metrics: dbtプロジェクト内でYAMLとして指標を定義
- Cube.js: セマンティックレイヤーを提供するヘッドレスBIエンジン
- LookML（Looker）: Lookerのモデリング言語で指標を定義
- MetricFlow: dbt Labsが開発したメトリクス定義フレームワーク
コードで管理することで、バージョン管理・レビュー・テストが可能になる。
既存のダッシュボードやレポートが直接SQLを書いている箇所を、メトリクスレイヤーの参照に切り替える。
移行の進め方:
- 新規ダッシュボードは必ずメトリクスレイヤー経由で作成
- 既存ダッシュボードは利用頻度の高いものから段階的に移行
- 移行完了後、旧定義のSQLを廃止
最終的に「指標の定義を変えたいときは、メトリクスレイヤーの1箇所を変えれば全ツールに反映される」状態を目指す。
具体例#
状況: 従業員200名のBtoB SaaS。毎月の経営会議で「MRR（月次経常収益）」の数字がダッシュボード・財務レポート・営業レポートの3箇所で異なり、冒頭30分が「どの数字が正しいか」の議論に費やされていた。
定義の違い:
- ダッシュボード: 当月の請求額合計（年額プランを12分割していない）
- 財務レポート: 発生主義で按分した金額
- 営業レポート: 受注ベース（未請求の新規契約を含む）
メトリクスレイヤーで統一した定義:
- MRR =
SUM(月額換算請求額)WHEREstatus IN ('active', 'trialing')ANDbilling_date <= 月末 - 年額プランは12分割して月額換算
- 解約済み・未開始の契約は除外
dbt Metricsで定義し、Looker・Notion・Slackボットのすべてが同じ定義を参照する構成に変更。経営会議の冒頭30分の「数字合わせ」が消え、その時間が戦略議論に充てられるようになった。
状況: 全国120店舗を展開する小売チェーン。各エリアマネージャーが独自のExcelで店舗KPIを集計しており、計算ロジックが5パターン存在していた。
問題の具体例:
- 「客単価」の分母が、あるエリアは来店客数、別のエリアはレジ通過客数
- 「在庫回転率」の期間が30日と90日で混在
- 本部が各エリアの数字を突合するのに毎月40時間を消費
メトリクスレイヤー（Cube.js）で28指標の定義を統一し、各店舗のPOSデータから自動計算する仕組みを構築。エリアマネージャーはダッシュボードを見るだけで、自分の担当店舗のKPIを正確に把握できる状態に。本部の月次集計作業40時間がゼロになった。「数字を作る作業」が消えたことで、初めて「数字を使う議論」に時間を割けるようになった。
状況: 学生数1.2万人の私立大学。研究推進室が各学部の研究実績を評価するために指標を集計しているが、学部ごとに「研究生産性」の定義が異なり、ランキングへの不満が毎年噴出していた。
定義のバラつき:
- 工学部: 査読付き論文数 / 教員数
- 人文学部: 著書・紀要含む全出版物数 / 教員数
- 医学部: インパクトファクター加重論文数 / 教員数
メトリクスレイヤーで3階層の指標を定義:
- 共通指標: 査読付き論文数（全学部同一基準）
- 分野別指標: 学部の特性に合わせた補正指標
- 総合スコア: 共通指標70% + 分野別指標30%の加重平均
定義をGitHubで公開し、各学部からのフィードバックをプルリクエストで受け付ける運用にした。「なぜこの数字なのか」に対してコードで根拠を示せるようになり、不満件数が年間15件から2件に減少。
やりがちな失敗パターン#
- 定義の合意を技術チームだけで進める — 指標の定義はビジネス判断に直結する。経営層や業務部門を巻き込まずに決めると、後から「この定義では使えない」と差し戻される
- すべての指標を一度に移行しようとする — 組織の指標は数百に及ぶことがある。まずは経営会議で使う上位10指標から着手し、成功体験を作ってから拡大する
- メトリクスレイヤーを導入しても旧ルートを残す — BIツールで直接SQLを書ける状態を放置すると、レイヤーを迂回する人が出て統一が崩れる。段階的に旧ルートを閉じる計画を立てる
まとめ#
メトリクスレイヤーは、指標の計算ロジックを1箇所で定義し、全ツールが参照する仕組み。「同じ名前なのに数字が違う」問題を根本から解消し、組織全体の意思決定を同じ土台に揃える。まずは経営会議で議論になる主要KPIの定義を統一し、コードで一元管理するところから始めるのが着実な進め方になる。