フレームワーク活用ガイドひとことで言うと#
データの**鮮度（いつまでに届くか）・可用性（どれくらい止まらないか）・品質（どれくらい正確か）**について、データ提供チームと利用チームの間で具体的な数値目標を合意する仕組み。SaaSのSLAと同じ発想で、「データに対する約束」を明文化することで、期待のズレによる摩擦をなくす。
押さえておきたい用語#
- SLA（Service Level Agreement）
- サービス提供者と利用者の間で交わす品質保証の合意文書。データ領域では、データの鮮度・可用性・品質の数値目標を指す。
- SLO（Service Level Objective）
- SLA を達成するために内部で設定する運用目標。SLA より厳しめに設定し、SLA 違反を未然に防ぐバッファとする。
- 鮮度SLA（Freshness SLA）
- データが指定時刻までに更新されることを保証する合意。例: 「売上データは毎朝8時までに更新」。
- 可用性SLA（Availability SLA）
- データウェアハウスやダッシュボードが利用可能な状態を維持する割合。例: 「月間稼働率99.5%以上」。
- 品質SLA（Quality SLA）
- データの正確性・完全性が一定基準を満たすことを保証する合意。例: 「欠損率0.1%以下、金額誤差率0.01%以下」。
データSLAの全体像#
こんな悩みに効く#
- 「データまだ来てないんだけど」と毎朝のように催促される
- データチームと事業部門で「いつまでに届くか」の認識がズレている
- データの遅延や欠損の許容範囲が決まっておらず、全件が緊急扱いになる
- データチームのリソースが障害対応に引っ張られ、改善が進まない
基本の使い方#
データSLAは提供者が一方的に決めるものではない。利用チームの実際のニーズを把握する。
- 各ダッシュボード・レポートの利用者に「何時までにデータが必要か」をヒアリング
- 「絶対に遅延してはいけない」のか「1時間遅れまでなら許容できる」のかを明確にする
- 品質について「多少の欠損は許容」か「1件の誤りも許されない」かを確認
- 全データを最高レベルにするのは非現実的。優先順位をつけるためのヒアリングである
約束できないSLAを設定しても意味がない。まず現状を知る。
- 過去3か月のパイプライン完了時刻を集計し、鮮度の実績値を算出
- データウェアハウスの稼働率ログから可用性の実績値を確認
- dbt testsやデータ品質チェックの合格率から品質の実績値を把握
- 実績値に対して10〜20%のバッファを持たせた値がSLAの候補になる
SLAは口約束ではなく文書にする。シンプルなフォーマットで十分。
- 対象データセット: どのテーブル・ダッシュボードが対象か
- 鮮度SLA: 「毎朝○時までに更新完了」
- 可用性SLA: 「月間稼働率○○%以上」
- 品質SLA: 「欠損率○○%以下、誤差率○○%以下」
- SLO（内部目標）: SLAより厳しめの数値を設定し、SLA違反を未然に防ぐ
- 違反時の対応: SLA違反が発生した場合の通知先・エスカレーションフロー
- 合意者: データチームのリーダーと利用チームのリーダーが署名
SLAは設定して終わりではなく、達成率を継続的に可視化する。
- SLA達成率を日次・週次・月次でダッシュボードに表示
- SLO違反時にSlackやPagerDutyでアラートを自動発火
- 四半期に1回、利用チームとSLAの見直しミーティングを実施
- 継続的にSLAを達成している場合は目標を引き上げ、未達が続く場合は原因を分析して改善策を打つ
具体例#
従業員200名のSaaS企業。CEOが毎朝9時に確認する経営ダッシュボードのデータ更新が、月に4〜5回は9時に間に合わず、そのたびにSlackで「データまだ？」と催促が飛んでいた。データチーム4名は毎朝ヒヤヒヤしながら出社していた。
ヒアリング結果:
- CEO: 「9時の経営会議までにデータが揃っていれば十分。8時半でいい」
- CFO: 「月次決算データは翌営業日15時までに確定していれば問題ない」
- マーケ部長: 「広告レポートは10時でも許容できる」
設定したSLA:
| データセット | 鮮度SLA | 可用性SLA | 品質SLA |
|---|---|---|---|
| 経営ダッシュボード | 毎朝8:30 | 月間99% | 売上誤差0.1%以下 |
| 月次決算データ | 翌営業日15:00 | 月間99.5% | 金額誤差0.01%以下 |
| 広告レポート | 毎朝10:00 | 月間95% | 欠損率1%以下 |
内部SLO（バッファ付き）:
- 経営ダッシュボード: 毎朝8:00までに更新完了（SLAの30分前）
- Airflowの開始時刻を5:00→4:30に前倒し
3か月後の成果:
- 経営ダッシュボードの鮮度SLA達成率: 100%（遅延クレームゼロ）
- データチームの「朝の緊急対応」時間: 月12時間 → 月1時間
- CEO からのコメント: 「データのことを気にしなくてよくなった。これが当たり前であるべき」
従業員400名の人材系企業。データプラットフォームチーム5名が社内の全部門にデータを提供しているが、「データがいつ届くか分からない」「品質が安定しない」という不満が蓄積し、一部の部門は独自にスプレッドシートで数字を管理し始めていた。
現状調査:
- 分析チームへのアンケートで「データプラットフォームを信頼しているか」の回答: 5点満点で2.3
- 主要パイプラインの過去3か月の遅延率: 18%（月平均5.4回）
- データ品質テストの合格率: 91%
SLA導入のプロセス:
- 全部門の利用者にヒアリングし、12のデータセットについてSLAを設定
- ティア分け: Tier 1（課金・法定報告）3件、Tier 2（KPIダッシュボード）5件、Tier 3（探索用）4件
- Tier 1のSLO違反にはオンコール対応、Tier 2はSlack通知、Tier 3は翌営業日対応と段階を分けた
- 月次で「SLA達成率レポート」を全社に公開
6か月後の成果:
- Tier 1 SLA達成率: 99.2%（当初82%）
- Tier 2 SLA達成率: 96.8%（当初78%）
- 信頼度アンケート: 2.3 → 4.1
- 独自スプレッドシートでの管理: 5部門 → 1部門（残り1部門も移行計画中）
- データチームへの「データおかしくない？」問い合わせ: 月32件 → 月8件
従業員60名のアドテック企業。広告主50社にレポートデータを提供しているが、データ遅延が原因でクレームが月3〜4件発生していた。営業チームは「いつデータが届くか」を答えられず、広告主からの信頼が低下していた。
外部向けデータSLAの設計:
- 広告主との契約書にデータSLAの項目を追加
- 鮮度SLA: 「広告配信データは翌日12時までにレポート画面に反映」
- 品質SLA: 「インプレッション数の誤差率±2%以内」
- 可用性SLA: 「レポート画面の月間稼働率99%以上」
- SLA違反時の対応: 24時間以内に原因報告、3営業日以内に改善計画を提示
内部での対応策:
- 内部SLO: レポート反映を翌日10時（SLAの2時間前）に設定
- 外部データソース（広告プラットフォーム各社）からのデータ取得を22時→20時に前倒し
- 外部データソースの障害を検知した場合、広告主に自動メールで事前通知する仕組みを構築
導入1年後の成果:
- データ遅延クレーム: 月3〜4件 → 月0.3件（年間4件）
- SLA達成率: 鮮度97.8%、品質99.2%、可用性99.5%
- 広告主の契約更新率: 72% → 89%
- 営業チームのコメント: 「SLAがあることで『うちのデータは信頼できます』と自信を持って言える」
やりがちな失敗パターン#
- 利用者にヒアリングせずSLAを決める — データチームが勝手に「毎朝7時」と設定しても、利用者が実際に見るのは10時かもしれない。過剰なSLAはチームを疲弊させるだけ
- 全データに同じSLAを適用する — 課金データと探索用ログに同じ品質基準を課すと、リソースが分散して重要なデータの品質も守れなくなる。ティア分けが前提
- SLAを設定したが監視していない — 達成率を追跡しなければSLAは形骸化する。自動監視とダッシュボードは導入とセットで整備する
- SLAを固定して見直さない — ビジネス要件は変わる。四半期に1回は利用チームと見直し、不要になったSLAは廃止し、新たに必要なSLAを追加する
まとめ#
データSLAは、データの鮮度・可用性・品質について提供者と利用者が「数値で合意する」ことで、期待のズレによる摩擦を解消する仕組みである。ポイントは利用者のニーズから逆算すること。「技術的に可能な最速」ではなく「業務に必要十分な水準」をSLAとし、内部SLOでバッファを持たせれば、チームは無理なく約束を守れる。SLAの達成率を可視化して共有することが、データチームの信頼を組織全体に広げる最短の道になる。