はじめに

「ビッグデータ、IoT、AIを取り入れたいならデータマネジメントについて知るべき」では、データマネジメントの必要性を事例ベースで紹介しました。

この記事では、データマネジメントの中のデータクオリティについての勘所を紹介します。自社にあったデータクオリティマネジメントの助けになれば幸いです。

データクオリティとは

データクオリティは、読んで字のごとくデータの品質を指しますが、具体的には以下の評価軸から規定されます。
評価軸は書籍ごとに微妙に変化するため、その点ご注意下さい。

正確性: 入力不備や変換ミスなどが含まれていないか？
適合性: 決まりどおりの値になっているか？
完全性: 必須カラムやレコードの欠落がおこっていないか？
一貫性: データ間で矛盾が生じてしまっていないか？
一意性: 一意でなければならない値が重複していないか？
最新性: 更新頻度や時期が適正か？有効期限がきれていないか？
適時性: 期待される時刻にデータが利用可能か？

正確性

正確性は、データが現実の実体をどのくらい正しく表しているかの度合いです。

誤入力や誤集計がどのくらい起こっているかをスペルチェックや集計結果のダブルチェックで検証します。
とはいえ、データの種類によってはなにが正しいかが不明なものもあるため、完璧な正確性の検証は難しいでしょう。

適合性

適合性は、データが決まりに適合するかの度合いです。
決まりの種別は主に4つにマッピングできます。

定義: 決まった定義域におさまっているか？
- × JST時刻しか許可しないカラムにUTC時刻が混ざっている
範囲: 決まった範囲におさまっているか？
- × 1以上100未満であるべきカラムに-1が入っている
- × 2000-01-01～2018-12-31であるべきカラムに1990-06-01が入っている
- × A～Fが頭文字の単語が入るべきテーブルにYが頭文字の単語が入っている
形式: 決まった形式におさまっているか？
- × ハイフンなしの電話番号形式であるべきカラムにハイフン区切りの電話番号が入っている
- × ISO8601 RFC3339形式であるべき時刻カラムにスラッシュ区切りの時刻が入っている
マッピング
- × 名寄せ一覧に載っていない表現でデータ入力されている
- × 支店コードから支店名への変換表に載っていないデータ入力されている

適合性は、決まりに基づき正否が決まるので、バリデーションチェックで検証できます。

完全性

完全性は、データにどれだけ抜け漏れがないかの度合いです。

リレーショナルデータベースなどでは、NOT NULL制約があるため、その機能によって完全性を担保できますが、そういった機能がない場合は、入力必須のカラムにどれだけ抜けがあるかをチェックすることで検証できます。

カラムの抜け漏れチェックは割合容易ですが、レコードの欠損は正解となるデータセットとの突合を行わなければできません。大規模なデータでは、この突合自体が技術的に困難になるでしょう。

一貫性

一貫性は、どれだけデータ間に矛盾がないか度合いです。例えば、あるデータセットではAさんがx商品を12:00に購入のデータがあるのに、他のデータセットでは14:00購入になっているといった場合は矛盾があることになります。集計結果の矛盾に対しても同様です。

複数のデータセットを突合させ、どれくらい矛盾のあるデータがあるかをチェックすることで検証できます。

一貫性も、完全性と同じく、扱うデータの規模が大きくなるほど検証が困難になります。また、サイロ化したシステムのデータ統合を行おうという場合、どちらのデータを正とするかという話も合わせて発生してくるでしょう。

一意性

一意性は、一意でなければならない値が重複していないか測る度合いです。

リレーショナルデータベースなどでは、UNIQUE制約があるため、その機能によって一意性を保証できますが、そういった機能がない場合は、ユニークであるべきカラムの中にどれだけ重複する値が存在するかをチェックすることで検証できます。

適時性

適時性は、データのアクセス容易性と可用性をあわせたような度合いです。

アクセス容易性の方は、データが必要になる時刻からデータが利用可能になる時刻を引いた期間が妥当かをチェックすることで検証できます。

可用性の方は、データに関するシステムの可用性とデータ自体の可用性(例えば、データに誤りがあるとシステムが動いていてもデータを利用できない)をかけ合わせた可用性が、決められた可能性を担保できているかチェックすることで検証できます。

簡単に言えば、ユーザがデータを利用したくてもできなかった期間を確認すればいいです。

データクオリティマネジメント

データクオリティSLAの定義

データクオリティマネジメントでは、上記の評価軸を念頭に、データクオリティSLA(Service Level Agreement)を定義します。DMBOKには、データクオリティSLAで定義される、データクオリティに関する運用上の統制には以下のものがあると書かれています。

合意の対象となるデータ
データの欠陥に関連するビジネス上の影響
それぞれのデータ要素に関連するデータクオリティの評価軸
バリューチェーンの各アプリケーションまたはシステム内で明確にされたそれぞれの評価軸における各データ要素の品質に対する期待
その期待を測定する方法
それぞれの測定に対する許容しきい値
許容しきい値が満たされなかった場合に通知をうける人物と問題に対して期待される解決と改善の予定と期限
解決の期限が来た場合の、上層部への上申方法および予定される報奨と罰則

評価軸の値が高ければ高いほどいいと思ってしまいがちですが、必要以上に高めようとするとコストがかさんでしまいます。ユーザのニーズを満たし無理のない基準を設定することが重要です。

また、不必要にすべてのデータに対して同じデータクオリティSLAを定義することはオススメしません。なぜならば、データは基本増えていくものなので、それに比例してデータクオリティSLAを守るコストが増大し、スケールしなくなってしまうからです。用途に応じて分類し、データクオリティSLAをそれぞれで定義すべきです。

データクオリティの不具合に対する対応

データクオリティSLAの中もしくは外で、データクオリティに不具合があった場合の対応についても定義する必要があります。つまりは、正確でなかったり、適合していなかったり、一貫していないデータが見つかった際に、それを除去するのか修正するのか、どうやって行うのかを決めるということです。

これを定義せずにいると、データクオリティの不具合が起こった際、ステークホルダーに「直せるなら直してほしいなぁ」や「そんなにコストがかかるのならしなくてもよかったのに」と言われてしまいます。ビジネス上の影響にもよるところは大きいでしょうが、定義しておくことが重要です。

もし、除去や修正の履歴は、あとからトレース可能な形にしておく必要があります。自動修正の場合でも、少なくとも除去や修正方針変更の際には、その内容を記録しておくのがいいでしょう。これは、ユーザがデータを利用した際に誤った判断を下してしまうのを防ぐためです。

また、データクオリティマネジメントは、検査と監視する人間だけでは担保できず、データ入力を行う現場の協力が重要になります。データの入力から利用までのバリューチェーンを定義した上、各項目における説明責任者と実行責任者を明確にしておくことが重要でしょう。

ビッグデータクオリティマネジメント

ビッグデータのクオリティマネジメントについてはさらに話が変わってきます。データ総研のビッグデータのクオリティマネジメントでは、以下のようなことが書かれています。

ビッグデータの多くは、マスタ的でなくイベント的な性質をもち、データクオリティを確認する手間が膨大で実施しきれません。従って、現時点では従来型のデータクオリティマネジメントは不可能と思われます。

InfomaticaやTalendなどは、ビッグデータ向けのデータクオリティ管理ツールを提供していますが、その機能のメインは適合性や一意性といった比較的検証が容易な評価軸の検証をサポートするものです。将来、機械学習などの技術により高度な正確性チェック機能もつくかもしれませんが、データクオリティを検証するためにデータプラットフォームのリソースを消費することは変わりません。ビッグデータクオリティマネジメントの場合、かけるコストの可視化も合わせて必要です。

おわりに

長くなりましたが、データクオリティの勘所を紹介しました。実際は、もっと細かな話があるのですが、書き出すと書籍を読んだほうが早くなってしまうためここまでにしました。

データセキュリティと同様にデータクオリティマネジメントも、それ単体では売上に寄与しません。ですが、誤ったデータは誤った経営判断を産みます。データ主導型の経営を目指している企業は、身の丈に合ったデータクオリティSLAを定義し、検証・監査をまず整備してみてはどうかと思います。

データマネジメントノウハウ - データクオリティ編