第１回ディスカッションブログ_データ品質のお悩みと解決方法を考えてみた（9/1 SnowflakeJP デタマネ UserGroup）

おはようございます！
SnowflakeのDataManagement ユーザグループメンバーの松浦です。ANAにてデータ基盤まわりの開発やプロセス整備を担当しています。

先日、「データ品質」をテーマにユーザグループの第一回勉強会を実施致しました。NTTデータの佐川さんより、現在の悩みや課題、調べたことなどを発表し、参加者でディスカッションする形式で行われました。
当日の資料はこちらです↓↓

こちらでは、その勉強会の内容を記載させていただきます。
ユーザグループについては、はじめにをご覧ください。

1. なぜデータ品質？

一般的に

データ品質とは、DMBOKv2などでも定義されている通り、「データが利用者の要求を満たすレベル」であること
データの品質が悪いと、分析結果も信用できず、活用が進まない。

最初のきっかけ

データ基盤の早期提供を優先し、ビジネス側での利用状況把握が不十分な状態で、データ取り込みを行った結果、データ品質が利用者の要望を満たせていない状態となった。

具体例

実際に利用者から指摘のあったデータに関するトラブルの具体例はこちら。

・データ遅延状況の周知遅れ
・データ型の誤りなどのデータ不正の発生
・利用者の多いデータセットの加工集計ロジックが誤っていて使えない

データパイプライン開発プロセスの見直しやDWHデータセット作成時の強化テスト観点の改善などで、品質改善に取り組んだ。
しかし、開発プロセスを中心に対策を打ってきたが、まだ利用者が使いやすいデータになってはおらず、利用者からの問い合わせが多数発生している状況😭
そもそもデータ利用者の求めていることや目的を満たせる要件を定義する必要がありそう。そして開発プロセス改善以外にも対策を打つ方法はないか？

2. 品質要件はどのように定義するのか

では、データの品質要件はいつどのように定義するべきなのか？
最初に大量に取り込んだデータの要件を後から聞いて回っていくしかないのだろうか？いずれにしても要件を聞く場合は要件を定義する観点が必要。

品質要件の軸

以下の2つの観点がありそう。

• ISO/IEC 25012の15の品質評価観点を軸に考えたが、全ての軸がヒアリング必要な内容ではなく、必要な観点を絞ってヒアリング？

• テーブルで一律ではなく、カラムごとに要件が違うとしたらカラムレベルでヒアリング？

ヒアリング方法

人力で聞きに行くのも限界があるからカタログ等にフォームを用意してもらってフィードバックサイクルを回していくしかないか？

Discussion : データ品質要件ってどうやって決めてる ?

ずばり、「ヒアリングして決める！」という回答がありましたが、実際は多くの悩みが噴出しました。

みんなの困りごと

・ユーザーが一番良いレベルをとりあえず求める
　・鮮度は早ければ早いほど、故障や欠損はゼロで頼む、みたいな要望があがってくるのが悩ましい
　・100％じゃなくていいと言ってくれる人もレアキャラでは
・ユーザーによって要件が異なる
　・とりあえずデータを入れてみていじってみたいという明確な目的(要件)を持っていないユーザーがいる
　・最初にヒアリングしても後から違うユーザーが使い始めたら要件レベルが変わる
・同じデータ（例：項目名「売上」）に対しても、部署ごとに指標が違う（ビジネスメタデータの不足により、データに一貫性が保たれない）
・ドメインナレッジがないとデータエンジニアリングとしての理解が難しい
（データベース的なチェックはできるが、ドメインナレッジがあって初めて気づける誤りはエンジニア側で気づくのは厳しい）
・使われていないものに力をかけても意味がない

みんなの対策案

・データカタログで品質を明示しておく
・品質要件のレベルを設定する（A、B、Cなど）
　・この種の依頼がきたら、ここのチェックまでは実施する
・最低ラインの品質を設定する
・品質を上げるためのパターン、手順を用意しておく
・データソースとなる基幹システムの協力・理解が必要
・トップダウン(CDO)でデータ品質に対して、提供元も含め共通認識を持つ組織文化からの改善

3. 品質要件を守るためにやっていることは

いつ汚染に気づくべき？

よくあるのは、データ利用者から指摘があって修正するというパターンだが、利用者はデータを使おうとしたタイミングでデータが汚染しているために使えないということになってしまい、対応としては遅すぎると言える。
この利用者指摘をデータ汚染検知の最後の砦とし、その前にパイプライン製造時のテストやジョブアラート、モニタリング等で検知できるようにしていきたい！
データ品質のモニタリングはまだあまりできていないのだがDataObservabilityというキーワードで、開発プロセスのテストやアラートでは防ぎきれないものを防ぐ方法として、必要性を感じ始めている。
ただ、何をモニタリングするか？要件に関わらず一律で実施すべきか？誰がやるのか？などの疑問がある。

なので、みんなで意見交換ディスカッション～

Discussion : データ品質をモニタリングする仕組みって入れてますか ?

現時点で、データ品質をモニタリングするためのソリューションを導入している方はいませんでした。一方で、データレコード数やファイルサイズ、最終更新時間などの一部の情報を取得している方はいました。

みんなの困りごと

・データが正常であるかの定義が難しい
・人力のデータ投入による不具合をなんとか正しく入力してとは言えない
・データ変更の周知もObservabilityの範囲に入るのか、ここの周知も難しい
・モニタリングするにもコストがかかる

みんなの対策案

・分かる情報だけでも可視化することに意味があるのでは
・人力データ投入時に防ぎきれないものは基盤側で防ぐ仕組みを作る
・データ変更周知はアクセス履歴から追いかける
・WHコストがかからないメタデータなら抽出できる
・最終更新日は地味に便利
・DataOpsはみんなでやらないと

さいごに

勉強会の内容は以上になります！
私のところでは、ユーザからの声をきっかけに品質を改善している現状があるので、まずはデータ品質レベルの明示やモニタリングに取り組んでいきたいと感じました！

次回の勉強会は10/6に実施予定です。⛄お楽しみに～

執筆者：松浦、北原