はじめに
過去にデータの可視化をポイントに３つの記事を書いてきました。
1.データの可視化は健康診断
2.「はじめての分析」で見落としがちなポイント
3.「はじめての分析」で見落としがちなポイント②
可視化というのは1回限りの取り組みではなく、継続的な取り組みになっていきます。
今回はデータエンジニアリングの観点から、データの可視化・利活用を継続的に実施していくために重要なポイントであるデータの品質に関しての記事を書こうと思います。
作っても使われないダッシュボード
世の中には、せっかく作ったのに使われなくなったダッシュボードがたくさんあります。
「事業環境の変化や組織構造の改革により実態と合わなくなった」など天寿を全うしたケースもあるのですが、
実際には公開してから日が浅いのに全く活用されていないダッシュボードが日々生まれています。
そういったダッシュボードが生まれてしまう背景は明確です。
「なぜかフォントが丸ゴシック」とか、「官僚パワポのようにビジーすぎる」とかそういう話ではありません。
データの品質が低いからです
バグのあるダッシュボードが活用できないのは当たり前だろう、と思った方、少し待ってください。
バグの話ではないのです。
データの品質とは
政府CIOポータルに、データ品質管理ガイドブックというドキュメントが公開されています。
特に見てほしいのは、2.3 データの評価 という節です。
この節では、データ自体の品質をISO/IEC 25012 に沿って11の観点から評価することが記述されています。
- 正確性 (Accuracy)
- 完全性 (Completeness)
- 一貫性 (Consistency)
- 信憑性 (Credibility)
- 最新性 (Currentness)
- アクセシビリティ (Accessibility)
- 標準適合性 (Compliance)
- 機密性 (Confidentiality)
- 効率性 (Efficiency)
- 精度 (Precision)
- 追跡可能性 (Traceability)
- 理解性 (Understandability)
- 可用性 (Availability)
- 移植性 (Portability)
- 回復性 (Recoverability)
たとえば、「4.信憑性」や「11.追跡可能性」には、 「データの出所が明示されているか」という評価項目があります。
「原価」という項目を思い浮かべてください。
「原価」は、多くの業種業態において、定義がひとつではなく、何を正解とするかが状況によって変わってくる言葉です。
「月中はみなし原価で計算をして、月次が締まったら確定原価に置き換える」のようなオペレーションはよくあると思います。
速報が見たいのか確報が見たいのか、進捗がみたいのか着地見込みが見たいのか。
着地見込みが見たいのであれば、按分でいいのか波動を見るのか。人や状況によって正解は異なります。
売上原価なのか仕入原価なのかといった、もっと根本的な話が登場する場面もあるでしょう。
データの品質は、「ロジックが正しい」という正確性だけでは担保ができないのです。
※ここでは「4.信憑性」や「11.追跡可能性」を例にとりましたが、他の観点に比べて重要という意図ではありません。どの観点も等しく重要な観点です。
この例は「誰にとっても正しい定義をしなさい」という話ではありません。
まずは「こういう定義の"原価"を使って、このダッシュボードは作られていますよ」というのを利用者から見てわかるようにするのがスタートです。
Data Catalogからのアプローチ
Data Catalogという分類の製品にはData Lineageという機能が搭載されています。
（私が所属するセゾン情報システムズの製品であるHULFT Data Catalogにも実装がされています）
これはデータが生成されてから現在に至るまでの経路と、経路上で行われた変更を追跡するための機能です。
この機能は、上記の"原価"の例に関する問題に対するひとつの解決策です。
データ生成元からの経路と変更を追跡して示すことで、「データの出所が明示されているか」という「4.信憑性」や「11.追跡可能性」の評価項目を満たすことができます。
Data Catalogに対する世の中の認識は"データを探すための道具"というのが大多数です。
データ品質管理ガイドブックに目を通した後にその機能に目を通すと違った見方が出来るかと思います。
ただし、一方で覚えていてほしいのは、
「4.信憑性」の観点を満たすためのピースはData Catalogでなくても構わない、という点です。
各品質観点はデータ分析基盤全体で担保できればいいという視点が重要になります。
たとえばパブリッククラウドで提供されているData Catalogサービスの中には、「8)機密性（Confidentiality）」の品質観点にData Catalogからアプローチしているサービスがあります。
ではData Catalogでは今後「8)機密性（Confidentiality）」へのアプローチが必須になるかというと、そうではありません。
この「8)機密性（Confidentiality）」は分析基盤の入り口での匿名化や、DWHのロール設計や動的マスクで制御することが一般的です。
そして、多くの場合それで別に構わないのです。
繰り返しになりますが、データ分析基盤全体で品質を担保するという視点が重要です。
データの品質を確保するために
ここからはデータの品質を確保するための考え方と具体的な対処例について触れたいと思います。
他責だから問題ない!?
たとえば、インターフェース元システムの事由によりダッシュボードへ反映した数値に誤りが出てしまった。
あるいは、データ分析基盤の障害によってダッシュボードへ最新の数値の反映が遅れている。
あなたがダッシュボードの開発エンジニアだったと仮定して、一般的なエンタープライズ向けシステム開発であれば、こういうときに調査をして他責だとわかればほっとしますよね。
しかし、データエンジニアリングにおいてはそういうわけにはいきません。
データの品質の劣化はユーザーインターフェースであるダッシュボードなどを通じてユーザーの前に顕在化します。
つまり、誰のせいであっても信用を落として使われなくなってしまうのはダッシュボードです。
機械学習であっても同様で、どんなにそのモデルが素晴らしくても結果がおかしければ評価されません。
原因が例え他ベンダーが開発したソースシステムのバグであってもです。
データエンジニアリングは出てきた結果で評価されてしまうのです。
データエンジニアはデータ分析基盤の出口であるBIや機械学習の結果に対する品質だけを意識するのではなく、
その過程、経路についても目を光らせる必要があります。
いくら「他責だから」と言っても、空しく響くだけなのです。
ResilienceとObservability
クラウドの世界で浸透している対障害の考え方にレジリエンスの追求というのがあります。
障害を起こさないようにするのではなく、障害が起きることを念頭に回復性や適応性を持たせる設計にという考え方です。
そのために重要なのはObservability(可観測性)、「いつ、何が、どこで起こっているのかを観測可能に保つ」です。
この考え方はデータにも適用できます。
つまり、データの品質低下を発生させないのではなく、発生することを念頭に回復性や適応性をいかに持たせるかという発想です。
直感に反するかもしれませんが、「いま、このダッシュボードを見ないで」とか「いまこのデータは分析に使わないで」と書いてあれば、ダッシュボードやデータに対する信頼性は低下しません。
これらを踏まえると、データ品質確保のアプローチは、
「データがいまどういう状態にあるかをモニタリングして、必要に応じてユーザーにお知らせする」
ことが中心となります。
そのためにはデータにおけるObservabilityが何かを考えることが重要です。
データにおけるObservability(可観測性)
データにおけるObservabilityについては、5 Pillars of Data Observabilityという記事が私の考え方に近いです。
抜粋すると5つの柱は以下です。
・Freshness
・Distribution
・Volume
・Schema
・Lineage
これらをモニタリングして、先述の11の観点からデータの品質を評価する、と解釈をしています。
たとえばデータ分析基盤において頻発するインシデントとして、DWHへのデータ格納が完了する前にBIの更新が始まってしまうというものがあります。
これはBI更新のタイミングでFreshnessをモニタリングして、データ品質管理ガイドブックにおける「5.最新性」を評価することで検知をすることができます。
TableauやPowerBIにはデータドリブンアラート（データアラート）の機能がありますから、これはBI単独でも実装可能です。
ソースシステムの障害でデータが欠落がした場合は、DistributionやVolumeをモニタリングして、「2.完全性」を評価することで検知できます。
これは私のチームが過去に実装した事例でいうと、ETLでモニタリング専用のパイプラインを作ってDWHを観測しています。
実際にモニタリングして評価した結果をどのようにユーザーにフィードバックするか、という点は
「ダッシュボード上にお知らせ用の掲示部を用意し、データの品質で問題があればメッセージを表示しておく」
などのアプローチが良いかなと思います。
専用のポータルなどに自動掲示する仕組みなども使われます。
ここまで大がかりでなくても、
・データ更新日時の明記
・データの出典の明記/計算ロジックの解説ページの用意
くらいはダッシュボード単体で実装できるため、ダッシュボードを作るときはやっておいた方が良い内容と言えます。
おわりに
ここまでデータ品質の課題とその対処について説明をしてきました。
このような課題が顕在化しているということは、データ活用の成熟度がある程度高まっている状態とも言えます。
また、課題に気付いていてもどう対処すべきかわかりかねているというケースも多いかと推測します。
そういった場合にこの記事が何かのヒントになればと幸いです。
データの品質管理ガイドブックについては、以下の記載があります。
データ自体の評価は評価時点でのスナップショットにすぎず、品質
の良いデータであり続けるためには、継続的にデータが更新される必要があり
ます。ある時、品質の良いデータを提供したとしても、その後データの品質が
下がってしまっては意味がありません。そのため、データの品質を繰り返し確
認することが重要になります。
データの品質は継続的なモニタリングが重要だということが説かれています。
この記事も当然それを念頭に書いてきているのですが、重要な言及であるため最後に掲載しました。
データエンジニアリングという活動は、企業活動が続く限り続いていきます。
企業活動を続けていれば外的内的問わず事業環境は変化しますから、データの中身も変化し、その読み解き方も変えていくことが必要です。
データエンジニアリングはいまやSaaSなどと並んで最もDevOps的な仕組みとマインドが要求される領域ではないでしょうか。
そんな中でデータの品質を継続的にモニタリング・評価できる仕組みはDevOpsにおけるCI/CDのような根幹をなす仕組みとなっていくと思われます。