データ品質SLAの作り方：欠損・遅延・重複の監視

データ品質SLAの作り方：欠損・遅延・重複の監視

「毎月の売上レポートの数字が担当者によって違う」「朝イチに見たいはずのダッシュボードが更新されていない」「同じ顧客がCRMに何件も登録されていて、誰に連絡済みか分からない」。こうしたトラブルは、多くの会社で「まあよくあること」として流されがちですが、その裏には必ずデータ品質SLA（品質基準）が決まっていないことが潜んでいます。システム自体は動いているのに、欠損・遅延・重複といったデータ品質の問題が放置されているために、現場では「この数字は本当に信用してよいのか」という不安を抱えたまま意思決定をしているのが実態です。

本来、データ活用やAI活用は、意思決定を速く・正確にするための取り組みです。しかしデータ品質があいまいなままだと、「レポートの数字を突き合わせる」「別システムの数字と照合する」といった無駄な作業に時間を奪われ、せっかくの投資が十分に回収できません。そこで鍵になるのがデータ品質SLA（Service Level Agreement）です。これは「どのデータを、どの程度の品質で、いつまでに提供するか」を定義し、経営と現場で合意しておくための枠組みです。

本記事では、AIやITに詳しくない経営者・マネージャーの方向けに、データ品質SLAの基本から、欠損・遅延・重複をどう定義・監視し、日々のデータ監視（モニタリング）に落とし込んでいくかまでを、できるだけ実務に即した形で解説します。「うちの会社のデータは、意思決定に使えるレベルなのか？」というモヤモヤを、少しずつ解消していくためのガイドとしてお読みください。

1. なぜ今「データ品質SLA」が経営課題になるのか

まず押さえておきたいのは、データ品質SLAが「IT部門のためのルール」ではなく、経営と現場の約束事だという点です。たとえば、次のようなシーンを想像してみてください。

• 経営会議で「新サービスの売上推移を来週までに出して」と依頼したら、担当者によって数字が違った。
• 朝の営業会議で前日までの受注状況を見たいのに、データ連携が遅れており一昨日の数字しか見られない。
• CRM上で同じ顧客が複数登録されていて、架電リストが重複だらけになっている。

こうした問題は、「システムが落ちた」という派手な障害ではありませんが、じわじわと売上機会を失わせ、現場の信頼感を削っていきます。多くの場合、原因は「誰もデータ品質の基準を決めていない」ことです。つまり、どのデータを公式とするのか、欠損や遅延、重複がどこまでなら許容されるのかといった品質のラインが曖昧なまま、なんとなく運用されているのです。

一方で、多くの企業ではインフラ側のSLA（システム稼働率99.9％など）は意識されています。サーバーが落ちたらすぐに大騒ぎになりますし、復旧手順も整備されています。しかし、システムが動いていてもデータ品質SLAが守られていなければ、「動いているけれど使えないシステム」が出来上がります。これは、見た目にはトラブルが起きていないように見えるため、かえって発見と改善が遅れがちな厄介な問題です。

特に中小企業では、担当者の異動や退職が、そのままデータの「ブラックボックス化」につながりやすくなります。数字の意味や前提を知っている人が限られているため、その人がいない日はレポートを出せない、といった事態も珍しくありません。こうした属人化から抜け出すためにも、「この売上データは朝9時までに前日分がそろっている」「この顧客リストのメールアドレス欠損率は1％未満」といったレベル感でデータ品質SLAを決めておくことが、経営課題として重要になってきています。

2. データ品質SLAの基本と押さえるべき観点

では、具体的にデータ品質SLAとは何を決めるものなのでしょうか。シンプルに言えば、「対象データ」「品質指標」「目標値（許容範囲）」「測定方法」「監視とエスカレーションのルール」を文書化したものです。その土台には、データ品質をどう捉えるかという考え方があります。

一般的にデータ品質は、次のような観点で整理されます。

• 完全性（欠損）：本来あるべき項目が欠けていないか。
• 正確性：値が現実と合っているか、桁・単位などが正しいか。
• 一貫性：システム間で矛盾した値になっていないか。
• タイムリーさ（遅延）：必要なタイミングまでにデータがそろっているか。
• ユニーク性（重複）：同じ実体が重複して登録されていないか。

このうち、本記事のテーマである欠損・遅延・重複は、比較的分かりやすく測定しやすい指標です。たとえば、売上データの必須項目（取引日、金額、顧客IDなど）について欠損率を算出したり、テーブルの最終データ日付を見てどれだけ遅延しているかを測ったり、顧客マスタで同じメールアドレス＋電話番号の組み合わせがいくつあるかを集計したり、といったイメージです。

データ品質SLAを設計する際には、まず「どのデータにSLAを設定するか」を決めることが重要です。すべてのデータに一律の基準を決めようとすると、途端に話が大きくなり、前に進まなくなります。おすすめは、経営に直結する次のようなデータからスタートすることです。

• 売上データ（会計・販売管理・サブスク課金など）
• リード／問い合わせデータ（マーケ・インサイドセールス）
• 顧客マスタ（BtoBなら企業と担当者、BtoCなら会員情報）

これらは、どの会社でも「数字が狂うと困る」領域であり、同時にデータ監視の効果が見えやすい対象です。対象データが決まったら、「欠損率◯％以下」「更新遅延◯分以内」「重複率◯％以下」といった目標値を決めます。このとき、いきなり理想論で決めるのではなく、現在の実態をざっくり測ってから、「まずは現状より少し良いライン」を現実的な基準として設定するのがポイントです。

また、SLAとして定めるには、測定方法もセットで決める必要があります。「なんとなく欠損が多い気がする」「最近はデータの遅れをよく見る」といった感覚ではなく、「日次バッチ完了後にSQLで欠損率を計算する」「ダッシュボードで最終更新日時を一覧表示する」といった、具体的なデータ監視のプロセスに落とし込むことで、初めてSLAとして機能するようになります。

3. 欠損・遅延・重複が生むリスクと“目に見えない損失”

ここからは、欠損・遅延・重複が現場にどのような影響を与えるのかを、もう少し具体的に見ていきます。これをイメージできると、「どの程度の品質を求めるべきか」の感覚がぐっと掴みやすくなります。

まず欠損です。たとえば、リード情報のメールアドレスや電話番号が抜けていると、せっかく広告費をかけて獲得した見込み顧客に連絡ができません。営業担当者が手作業で補完しようとしても、時間がかかる上にミスも増えます。また、売上データで部門コードや商品カテゴリが欠損していると、「どの部門が儲かっているのか」「どの商品群が成長しているのか」が正しく見えず、投資判断を誤るリスクが高まります。欠損は、システムが止まるような派手な障害ではありませんが、静かにデータ活用の精度を削っていく存在です。

次に遅延です。データの遅れは、意思決定の遅れに直結します。売上や受注のデータが1日遅れて連携されるだけで、「キャンペーンの途中で打ち手を変える」「在庫が危なくなる前に仕入れを調整する」といった機動的な動きが取りづらくなります。特にオンラインビジネスやサブスクリプションモデルでは、リアルタイムに近いデータ監視が価値を生むケースが多く、「翌営業日9時までに前日分のデータをそろえる」といったSLAを決めておかないと、細かな機会損失が積み重なってしまいます。

そして重複です。顧客マスタの重複は、顧客体験に直接ダメージを与えます。同じ顧客に二重に電話をかけてしまう、すでに解約した顧客に継続案内のDMを送ってしまう、請求データが二重になり二重請求を起こしてしまう、といった事態は、短期的にはクレームとして、長期的には信頼の低下として跳ね返ってきます。重複をゼロにすることは難しくても、「重複率◯％を超えたらマスタ統合タスクを実施する」といった基準を持っておくことで、被害を最小限に抑えることができます。

このように、欠損・遅延・重複は、それぞれ異なる形で業務や顧客体験に影響を与えます。データ品質SLAの議論では、「どの問題が自社にとって最も痛いか」「その痛みをどこまで許容するか」を具体的なエピソードとセットで話すと、現場と経営の認識が揃いやすくなります。

4. データ品質SLA設計のステップと、現実的なデータ監視のやり方

ここからは、実際にデータ品質SLAをゼロから作り、日々の運用に落とし込むステップを見ていきます。「立派なドキュメントを作ること」が目的ではなく、「現場で使えるルールと仕組み」にすることがゴールです。

ステップ1：守るべき業務と対象データを決める 最初にやるべきことは、「どの業務を守るためのSLAなのか」を明確にすることです。売上集計、請求処理、営業案件管理、リード評価など、自社で絶対に間違えたくない業務を書き出し、その業務で使っているデータテーブルやExcelファイルを洗い出します。この段階では、「何が困るのか」を現場にヒアリングすることが重要です。「この数字がズレると部門間で揉める」「このデータが遅れるとクレーム対応が後手に回る」といった具体的な困りごとを聞いておくと、後のSLA設定の軸になります。

ステップ2：品質指標と目標値（サービスレベル）を決める 次に、対象データごとにどの品質指標を見るかを決めます。欠損率、更新遅延時間、重複率などを候補として挙げ、それぞれについて「今の実態」と「目指すライン」を決めます。いきなり「欠損率0％」のような理想値を掲げるのではなく、まずは簡単なSQLや集計で現状値を調べ、「現状5％なので、まずは3％未満を目指す」といった現実的な目標値を設定すると、現場も納得しやすくなります。

ステップ3：データ監視方法と判定ロジックを設計する 品質指標と目標値が決まったら、次はデータ監視の設計です。たとえば、「日次バッチ終了後に売上テーブルの必須項目のNULL率を集計する」「顧客マスタでメールアドレス＋電話番号ごとに件数を数え、2件以上あれば重複候補とする」といったロジックを決めます。既存のBIツールやスプレッドシートを使っても構いませんし、小さなスクリプトでも十分です。大事なのは、「誰が、いつ、何を実行して、どこで結果を見るか」が明確になっていることです。

ステップ4：アラートとエスカレーションルールを決める データ監視の結果を、どう現場に伝えるかも重要です。たとえば、「警告レベル」と「重大レベル」の二段階でしきい値を決め、重大レベルを超えた場合のみSlackやメールで即時通知し、警告レベルは週次レポートで共有する、といった運用が考えられます。通知先も、「一次対応はデータ担当者」「業務影響が大きい場合は部門長にエスカレーション」といった流れをあらかじめ決めておくことで、SLA違反が起きたときに慌てずに済みます。

ステップ5：定期レビューでデータ品質SLAを育てる 最後に、四半期や半期ごとにデータ品質SLAとデータ監視の結果を振り返る場を設けます。「この指標は意味が薄かった」「このデータはもう少し厳しい基準にしても良さそうだ」といった気づきを反映し、SLAと監視項目を調整していきます。こうして少しずつ自社にフィットしたSLAに育てていくことで、「作って終わりのルール」ではなく、「現場で活きる仕組み」として機能させることができます。

5. スモールスタートの進め方と、「データ品質文化」を育てるポイント

ここまで読むと、「かなり大掛かりなプロジェクトになりそうだ」と感じられたかもしれません。しかし、実務上うまくいく会社は、例外なくスモールスタートから始めています。大切なのは、いきなり全社のデータ品質SLAを作ろうとしないことです。

おすすめは、「3か月でひと山超える」イメージで進めることです。

• 1か月目（重要データの特定）：売上・リード・顧客など、インパクトの大きいデータに絞って棚卸しを行い、「この業務で数字が狂うと困る」という重要データを特定します。
• 2か月目（現状把握）：簡易なデータ監視を始めます。SQLやスプレッドシートで欠損率・遅延時間・重複件数を集計し、現状の実態を知ることから始めます。
• 3か月目（基準策定と見える化）：得られた知見をもとにSLA文書を整え、主要な品質指標をダッシュボード化します。毎月の会議で「今月はSLAを守れているか」を確認できる状態を目指します。

ここまで来ると、「数字の妥当性を前提に議論できる」という意味で、経営にとって大きな安心材料になります。

こうしたステップを踏むことで、データ品質SLAは単なるルールではなく、「うちの会社は数字に強い」という自信につながっていきます。システムやツールの入れ替えがあっても、「求めるデータ品質と監視のあり方」が社内に共有されていれば、新しい仕組みにスムーズに移行できます。長期的には、AIによる自動レポートや高度な分析に進むための、強固な土台にもなっていきます。

6. まとめ：データ品質SLAで「数字に強い会社」へ

本記事では、欠損・遅延・重複という身近な問題から出発しながら、データ品質SLAの考え方と実務への落とし込み方を見てきました。改めてポイントを整理すると、次のようになります。

• データ品質の問題は「サイレント障害」であり、放置すると売上機会・信頼・現場の時間を少しずつ奪っていく。
• データ品質SLAは、「どのデータを、どの程度の品質で、いつまでに提供するか」という経営と現場の約束事である。
• 欠損率・遅延時間・重複率などの指標を定め、シンプルなデータ監視から始めることで、現状把握と改善が進みやすくなる。
• いきなり完璧を目指さず、重要データに絞ってスモールスタートし、定期レビューでSLAを育てていくことが現実的な進め方である。

重要なのは、「データ品質SLAを作ること」そのものではなく、そのプロセスを通じて「どの数字を公式とみなすのか」「どの程度の品質なら意思決定に使えるのか」を、経営と現場が共有していくことです。その結果として、「数字に振り回されない」「根拠のある意思決定ができる」組織文化が育っていきます。

自社だけで進めるのが難しい場合は、外部パートナーとともにデータ棚卸しやSLA設計ワークショップを行うのも有効です。第三者が入ることで、社内の「あたりまえ」に埋もれていた前提やリスクが可視化され、より実態に即したデータ品質SLAとデータ監視の仕組みを設計しやすくなります。いずれにせよ、最初の一歩は小さくて構いません。まずは一つの業務、一つのデータセットから、「この数字なら信じて良い」と言える状態を一緒に作っていきましょう。