〈開発者ブログ 新連載〉Vol.4
～ データの可視化・分析について ～

この連載も4回目になりました。

• 第1回：Vol.1 データの可視化は〇〇〇〇
• 第2回：Vol.2 その分析に○○は含まれるか - メジャー編 -
• 第3回：Vol.3 その分析に○○は含まれるか② - ディメンション編 -

今回は一話完結で、データをとりまく課題の現在と今後を理解する上で重要なポイントを書きます。
市場にあるデータにまつわるサービスがどういう立ち位置にあり、今後どのようなサービスが台頭してくるかのヒントにもなると思っています。

対象読者はデータを扱うすべての人を想定しています。
ぜひ目を通していただければと思います。

作っても使われないダッシュボード

世の中には、せっかく作ったのに使われなくなったダッシュボードがたくさんあります。
「事業環境の変化や組織構造の改革により実態と合わなくなった」など天寿を全うしたケースもあるのですが、実際には公開してから日が浅いのに全く活用されていないダッシュボードが日々生まれています。

そういったダッシュボードが生まれてしまう背景は明確です。
「なぜかフォントが丸ゴシック」とか、「官僚パワポのようにビジーすぎる」とかそういう話ではありません。

データの品質が低い からです

バグのあるダッシュボードが活用できないのは当たり前だろう、と思った方、少し待ってください。
バグの話ではないのです。

政府CIOポータルに、データ品質管理ガイドブックというドキュメントが公開されています。

特に見てほしいのは、2.3 データの評価　という節です。
この節では、データ自体の品質をISO/IEC 25012 に沿って11の観点から評価することが記述されています。

• 1. 正確性 (Accuracy)
• 2. 完全性 (Completeness)
• 3. 一貫性 (Consistency)
• 4. 信憑性 (Credibility)
• 5. 最新性 (Currentness)
• 6. アクセシビリティ (Accessibility)
• 7. 標準適合性 (Compliance)
• 8. 機密性 (Confidentiality)
• 9. 効率性 (Efficiency)
• 10. 精度 (Precision)
• 11. 追跡可能性 (Traceability)
• 12. 理解性 (Understandability)
• 13. 可用性 (Availability)
• 14. 移植性 (Portability)
• 15. 回復性 (Recoverability)

たとえば、「4.信憑性」や「11.追跡可能性」には、 「データの出所が明示されているか」という評価項目があります。

プロジェクトの収支が確認できるダッシュボードがあったとします。売価と原価と粗利率が確認できます。
普段収支を追っている人であればまず「原価」の定義を確認したくなりますね。

「原価」という言葉であっても定義はひとつではなく、何が正解かは状況によって変わります。

これは当社に限った話ではありません。
速報が見たいのか確報が見たいのか、進捗がみたいのか着地見込みが見たいのか。
着地見込みが見たいのであれば、按分でいいのか波動を見るのか。人や状況によって正解は異なります。

データの品質は、「ロジックが正しい」という正確性だけでは担保ができないのです。

※ここでは「4.信憑性」や「11.追跡可能性」を例にとりましたが、他の観点に比べて重要という意図ではありません。
　どの観点も等しく重要な観点です。

Data Catalogからのアプローチ

Data Catalogという分類の製品にはData Lineageという機能が搭載されています。（もちろんHULFT DataCatalogにも）
データが生成されてから現在に至るまでの経路と、経路上で行われた変更を追跡するための機能です。

この機能は、上記の"原価"の例に関する問題に対するひとつの解決策です。
データ生成元からの経路と変更を追跡して示すことで、「データの出所が明示されているか」という「4.信憑性」や「11.追跡可能性」の評価項目を満たすことができます。

Data Catalogに対する世の中の認識は"データを探すための道具"というのが大多数です。
データ品質管理ガイドブックに目を通した後にその機能に目を通すと違った見方が出来るかと思います。
たとえば「1.正確性」に問題を抱えているお客様がいて、そこに対してData Catalogからアプローチすることもできるのです。

ただし、一方で覚えていてほしいのは、
「4.信憑性」の観点を満たすためのピースはData Catalogでなくても構わない、という点です。
各品質観点は社内データ基盤全体で担保できればいいという視点が重要になります。

先日のAWS re:Inventで発表されたAmazon DataZoneというData Catalogのサービスがあります。
このサービスでは"Publish/subscribe workflow with access management."というコンポーネントで
「8)機密性（Confidentiality）」の品質観点にData Catalogからアプローチしており驚きました。

ではData Catalogでは今後「8)機密性（Confidentiality）」へのアプローチが必須になるかというと、そうではありません。
この「8)機密性（Confidentiality）」はDWHのロール設計や動的マスクで制御することが一般的です。
そして、多くの場合それで別に構わないのです。

繰り返しになりますが、社内データ基盤全体で品質を担保するという視点が重要です。

お客様がBest of Breedで社内データ基盤のピースを選定した結果、全体を見渡した時に担保できない品質観点が出てくる。
そういった隙間を誰が埋めていくかと考えると、当社のやることはたくさんありそうです。

ここからはデータの品質を確保するための考え方と具体的な対処例について触れたいと思います。

他責だから問題ない!?

たとえば、インターフェース元システムの事由によりダッシュボードへ反映した数値に誤りが出てしまった。
あるいは、社内データ基盤の障害によってダッシュボードへ最新の数値の反映が遅れている。

こういうときに調査をして他責だとわかればほっとしますよね。

しかし、データエンジニアリングにおいてはそういうわけにはいきません。
データの品質の劣化はユーザーインターフェースであるダッシュボードなどを通じてユーザーの前に顕在化します。
つまり、誰のせいであっても信用を落として使われなくなってしまうのはダッシュボードです。

機械学習であっても同様で、どんなにそのモデルが素晴らしくても結果がおかしければ評価されません。
原因が例え他ベンダーが開発したソースシステムのバグであってもです。

データエンジニアリングは出てきた結果で評価されてしまうのです。

データエンジニアは社内データ基盤の出口である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を観測しています。

実際にモニタリングして評価した結果をどのようにユーザーにフィードバックするか、という点は
「ダッシュボード上にお知らせ用の掲示部を用意し、データの品質で問題があればメッセージを表示しておく」
などのアプローチが良いかなと思います。
専用のポータルなどに自動掲示する仕組みなども使われます。

ここまで大がかりでなくても、

• データ更新日時の表示
• データの出典の明記/計算ロジックの解説ページの用意

くらいはダッシュボード単体で実装できるため、ダッシュボードを作るときはやっておいた方が良い内容と言えます。

Data Validation Tool（DVT）という製品群

こういった観測と評価の領域ではData Validation Tool（DVT）という分類の製品・サービスが生まれ始めています。
私の周囲では使っている例を聞いたことはありませんが、今後名前を聞く機会が増えていくと思います。

特に以下のような評価観点はある程度ルールベースで判定可能ですから、ツールの利用も進んでいくのではないかと思います。

• 1. 正確性 (Accuracy)
• 2. 完全性 (Completeness)
• 3. 一貫性 (Consistency)
• 7. 標準適合性 (Compliance)
• 10. 精度 (Precision)

最後に

ここまでデータ品質の課題とその対処について説明をしてきました。
このような課題が顕在化しているということは、データ活用の成熟度がある程度高まっている状態とも言えます。
また、課題に気付いていてもどう対処すべきかわかりかねているというケースも多いかと推測します。

そういった場合にこの記事が何かのヒントになればと幸いです。

データの品質管理ガイドブックについては、以下の記載があります。

データの品質は継続的なモニタリングが重要だということが説かれています。
この記事も当然それを念頭に書いてきているのですが、重要な言及であるため最後に掲載しました。

データエンジニアリングという活動は、企業活動が続く限り続いていきます。
企業活動を続けていれば外的内的問わず事業環境は変化しますから、データの中身も変化し、その読み解き方も変えていくことが必要です。
データエンジニアリングはいまやSaaSなどと並んで最もDevOps的な仕組みとマインドが要求される領域ではないでしょうか。

そんな中でデータの品質を継続的にモニタリング・評価できる仕組みはDevOpsにおけるCI/CDのような根幹をなす仕組みとなっていくと思われます。

ここまで読んでいただいた方は、データをめぐる現状と今後について少し見通せるようになったのではないでしょうか。
長文を最後まで読んでいただきありがとうございました。
次はまた少しテーマを変えて書こうと思っています。

TOPへ