「これも見たい」「あの数値出して」のリクエストがエンジニアに集中して、本来の仕事ができないチームをよく見ます。セルフサービスBIで、現場が自分で作れる状態にすると、エンジニアの工数も現場の意思決定スピードも両方上がります。
セルフサービス化の3要件
- 1正しいデータ：マスタデータ・指標定義が一元化されている
- 2安全なアクセス：見ていい範囲が制限されている（行レベル・列レベル）
- 3直感的なツール：ドラッグ&ドロップで使える
セマンティック層を整える
現場が自由にクエリを書くと、「売上の定義が10通りある」状態になりがち。 の `semantic_models` や Looker の LookML で、指標の単一定義を維持します。
dbt semantic_models の例
YAML
# models/marts/finance/_finance_metrics.ymlsemantic_models: - name: orders model: ref('fct_orders') entities: - name: order type: primary measures: - name: gross_revenue agg: sum expr: amount - name: net_revenue agg: sum expr: amount - refund_amountmetrics: - name: monthly_revenue type: simple type_params: measure: net_revenueツール選択：Looker vs Sigma vs
セルフサービス BI の選択肢
| ツール | セマンティック層 | 学習コスト | 向く規模 |
|---|---|---|---|
| Looker | LookML（強力） | 高（1〜3 ヶ月） | 中〜大企業 |
| Sigma | Excel ライク + dbt 連携 | 低（数日） | 中堅 |
| Looker Studio | なし（直接 ） | 極低（即日） | 小〜中 |
| Data Source | 中（2〜4 週間） | 全規模 | |
| Metabase / Superset（） | あり | 中 | コスト重視 |
セルフサービス化のフェーズ移行
- 1フェーズ 1：エンジニア専属の集計依頼受付（ボトルネック）
- 2フェーズ 2：dbt の mart 層整備、ビジネス用語で集計済みテーブルを公開
- 3フェーズ 3： ツールでドラッグ＆ドロップ可能、エンジニアは「 ガーディアン」に
- 4フェーズ 4：データプロダクトオーナー制度、各部署の達人が周辺を支援
ふくふく経験則
フェーズ 2 までは確実にやる。フェーズ 3 以降は組織の文化次第で、押し付けると形骸化する。まずは「分析依頼の半分が現場で解決」を目標にすると進めやすい。
ふくふくの進め方
「現場が自分でデータを見られるようにしたい」というご相談には、dbt mart 層の設計（1〜2 ヶ月）→ BI ツール選定・導入 → 現場研修で 3〜6 ヶ月のロードマップ。「依頼数が半減」「意思決定スピードが 2 倍」を共通の目標に。
次回予告
EP.09 は、データ品質。テストが通っても本当の品質ではありません。「使えるデータ」と「使えないデータ」を分ける運用設計を共有します。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。