先月まではレポートが正しく機能していたはずです。計算式は誰も変更しておらず、ワークフローもエラーなく実行されているのに、ダッシュボードの数値がどうも間違っているように見えます。
そこで遡って追跡していくと、最終的に何が変わったのかがわかります。新しいカテゴリ値が追加されたのにマッピングされていなかった、あるソースの到着が遅れた、あるいは数か月間問題なく機能していた結合が突然余分な行を生成し始めた、といったケースです。
定期的な分析をしばらく担当してきた方なら、こうした流れはよくご存じでしょう。問題の発見には多少の調査が必要かもしれませんが、さらに厄介なのは、以前にも似たような問題を解決したことがあると気づくことです。しかも、その問題を検出できたはずのチェックは、いまだに自分の頭の中にしかありません。
そうした知見をより多くプロセスに組み込むことで、レポートを出す直前になって慌ててワークフローを遡るのではなく、問題を早期に発見できるようにする必要があります。
まず、このレポートで満たすべき条件を明確にします
レポーティングにおけるデータ品質は、データに何を求めるかという点から始まります。同じデータセットでも、ある分析には問題なく使用できても、別の分析には適さない場合があるため、「良質なデータ」の普遍的なチェックリストだけでは限界があります。
Gartnerが指摘するように、「データ品質ツールは単独で存在するものではありません」。重要なのは、必要な分析やレポーティング業務をそれらがどれだけ適切にサポートできるかということです。
毎月の財務レポートを例に挙げると、チェック項目は非常に具体的なものになるでしょう。
- 想定されるすべてのソースファイルが届いていますか？
- 抽出データには、レポート期間全体が含まれていますか？
- 合計値は、想定している基準値と一致していますか？
- マッピングされていない新しいコストセンターはありませんか？
- データは引き続き想定どおりの粒度（例：請求書1件につき1行）になっていますか？
ワークフローが変われば、それに応じてチェック内容も変わります。顧客セグメンテーションのワークフローでは、エンティティの重複やマッチングの品質がはるかに重要になる場合があります。運用ダッシュボードの場合、より重要なのは、今日のデータが想定したタイミングで届いているかどうかかもしれません。
そのため、「クリーンなデータ」はあまり有益なゴールとは言えません。日付の形式が正しくても、実際には間違った月のデータである可能性があります。また、2つのソーステーブルはそれぞれ問題ないように見えても、それらを結合した途端に重複が発生することもあります。
データ品質プロセスは、おそらくすでに実践されています
同じレポートをしばらく作成している方なら、それを「データ品質プロセス」と明確に意識することなく、さまざまなチェックを積み重ねてきたのではないでしょうか。ワークフローに組み込まれているものもあれば、Excelで行うものもあります。また、3回前のレポートサイクルでソースに予想外の問題があったため、それ以来覚えていて確認しているものもあります。
一方、チームの別のメンバーは、過去に問題を経験したことから、まったく別の問題に注意を払っているかもしれません。やがて、プロセスはワークフローに組み込まれているチェックと、担当者が別途確認することになっているチェックとに分かれていきます。データが変化し、新たな問題が発生するにつれて、チェック項目も増えていきます。
すべての判断をソフトウェアに任せる必要はありません。重要なのは、繰り返し行っているチェックをより多くプロセスに組み込み、新しいデータが届いたときにも確実に実行されるようにすることです。
プロファイリングを活用すれば、根拠のないルールを作成せずに済みます
例えば、欠損値がどの程度に達したらフィールドにフラグを立てるべきかを判断しようとしているとします。フィールドが通常どのような状態にあるかを把握していれば、閾値はより意味のあるものになります。データの完全性が99.9％から94％に低下した場合と、もともと常に90％前後で推移しているフィールドとでは、その意味合いは大きく異なります。
一意性についても、同じようなことが起こります。請求書IDに一意性を求める前に、その段階でワークフローが請求書1件につき1行になっていることを確認してください。そうしないと、チェックが頻繁に作動しすぎて、誰も注意を払わなくなる可能性があります。
プラットフォームを比較する際は、データプロファイリングによって、ルールの背景にあるコンテキストをどれだけ迅速に把握できるかを確認してください。6か月後でも、なぜ設定されたのか誰も覚えていない数値を引き継ぐのではなく、自分や別のアナリストがその閾値が存在する理由を把握できるようにしておくべきです。
多くの場合、残す価値のあるチェックはすでに行っているものです
レポートを配信する前に、頭の中で確認しているチェック項目があるのではないでしょうか。例えば、当月分のデータが含まれているかを必ず確認したり、以前に行が増えたことがあるため、再確認すべき結合が1つあると把握していたりするかもしれません。
そうしたチェックは、特にその背景にビジネス上の理由がある場合、繰り返し実行できるデータ検証に組み込む価値があります。「このフィールドはNullにできません」でも役立ちますが、「売上レポートを出す前に、すべての有効な店舗に地域を設定する必要があります」とすれば、次の担当者にも、このチェックが存在する理由と、何を防ぐためのものなのかが伝わります。
データ品質チェックの失敗はほんの始まりに過ぎません
例えば、午後遅くになって完全性チェックが赤く表示されたとします。問題を検知できたのは良いことですが、次は何が起きたのかを突き止める必要があります。数件のレコードが欠落しているだけかもしれませんし、データの大部分が欠落しているかもしれません。いずれにせよ、問題がソースで発生したのか、それともワークフローのどこかで発生したのかを把握する必要があります。
プラットフォームから「品質チェックに失敗しました」という情報しか得られないのであれば、結局は自分で原因を突き止める作業が必要です。プラットフォームを比較する際は、チェックが失敗したときに、その原因となったレコードへどれだけ迅速にたどり着けるかに注目してください。レポートの提出期限まであと1時間という状況では、洗練されたステータス画面よりも、そこへたどり着くまでの手順の方がはるかに重要です。
例えば、30件ほどのトランザクションが、有効なマッピングがないまま処理されたとします。次のステップが、それらのレコードをエクスポートし、別の場所で修正してからレポートワークフローに戻すことであれば、問題は特定できても、対処がそれほど容易になったとは言言えません。
別のチームがその判断を担当している場合は、引き継ぐことが適切なケースもあります。しかし、ビジネスロジックを自分たちのチームが管理している場合は、ワークフローを離れることなく、どこまで調査やその後の対応ができるかを確認してください。
次に何を行うかは、何が失敗したかによって異なります
「問題のあるデータを見つける」というのは簡単そうに聞こえますが、実際の例外に直面すると、そう単純ではありません。例えば、マッピングテーブルに一致する項目がない新しい製品コードが現れることがあります。どのレコードが影響を受けているかは確認できますが、その製品がコンシューマー、エンタープライズ、あるいはビジネス部門が昨日新たに作成したカテゴリのどれに属するのかを、プラットフォームが判断することはできません。
一方、すでに対応方法が決まっているため、より簡単に解決できる問題もあります。ソースから「N.Y.」と「New York」が混在して送られてきても、標準表記について全員の合意が得られていれば、データクレンジングによって、毎月確認し直すことなく同じ修正を適用できます。
そのため、プラットフォームを比較する際に「問題のあるデータを自動的に修正できるか」という基準だけで評価しても、あまり有益ではありません。対応方法がすでに決まっている問題もあれば、引き続き人の判断が必要な問題もあります。また、重要なソースが欠落している場合は、それ以上処理を進める前にレポートを停止するのが適切な対応となることもあります。
どの種類の問題が何を意味するのかを判断するのは、依然として自分たちです。プラットフォームに求めたいのは、すでに決めた対応を簡単に繰り返し実行できる仕組みです。
すでによく知っているワークフローを使ってプラットフォームを比較
機能比較表を見ると、実際には大きく異なるデータ品質プラットフォームでも、不思議なほど似て見えることがあります。プロファイリング、ルール、監視、自動化など、ほとんどのベンダーは各項目に該当する機能を提示できますが、そのリストを見ても、金曜日の午後に数値が一致しなかったときに実際にどう対応できるのかまではわかりません。
代わりに、実際のワークフローを評価に使用してください。できればチームがよく理解しており、これまでにいくつか問題を経験してきたワークフローが理想的です。手作業での照合が今でも必要なレポートや、誰もが念のため再確認しているステップがあるレポートの方が、問題のない完璧なデモデータよりも、はるかに多くのことがわかります。単にデモ用に用意された例だけでなく、チームが通常の業務で扱っているような作業を、プラットフォームがどのように処理するのかを確認できます。
レポートが実際に依存しているルールをテストします
普段頼りにしているチェックは、単純なフィールドレベルの検証だけでは済まないことがほとんどです。例えば、今月取引のあったすべての店舗に地域が割り当てられていることを確認する必要があるかもしれません。あるいは、これまでの経験から注意が必要だとわかっている、時折余分な行を生成する結合があるかもしれません。ルールには、フィールドが基本的な技術チェックに合格するかどうかだけでなく、レポートの数値を狂わせる可能性のある事象を反映させる必要があります。
チームが実際の業務で頼りにしているルールを使用してください。それらのルールを作成しにくかったり、他のアナリストにとって理解しにくかったりする場合は、注意が必要です。プラットフォームが簡単なチェックしかうまく処理できない場合、重要なチェックは、結局またスプレッドシートや誰かの公開前の確認作業に戻ってしまいがちです。
明確で再利用可能なチェックは、引き継ぎも容易にします。ワークフローを引き継ぐアナリストは、レポートで「時々起こる」あらゆることについて30分かけて説明を受けなくても、何に注意すべきかを把握できます。
意図的に問題を発生させ、プラットフォームがどのように動作するかを確認します
データが少し乱れた状態の方が、より多くのことがデモによって判明します。ワークフローに必要だとわかっている入力をあえて省いたり、既存のロジックに一致しない値を入れたりします。以前に結合で問題が発生したことがある場合は、同じような重複行が発生するテストケースを使用してください。
次に、その問題を追跡し、失敗したチェックから原因となったレコードまで、どれだけ迅速にたどり着けるかを確認してください。また、何が問題だったかに応じて、ワークフローが異なる対応をとれるかどうかも確認する必要があります。例えば、ソースが欠落している場合は処理を停止し、一致するかどうかが不確かな場合は確認に回す、といった対応です。
準備されたデモデータを使えば、ほとんどのものがスムーズに見えてしまいます。意図どおりに動作しないテストケースを使うことで、実際のデータで同じことが起きたときに、そのプラットフォームを使うとどのようになるのかを、より具体的に把握できます。
データ品質の問題がレポーティングで発生しやすい箇所
データレポーティングの段階に入る頃には、誰かがその出力結果を使おうとしており、その時点で品質上の問題は無視しにくくなります。
最新のレポーティング期間のデータが欠落していても、ダッシュボード自体は問題なく更新されることがあります。これは、可視化が指示されたとおりに動作している一方で、ワークフロー側では想定していたデータが届いているかどうかを確認していないためです。
結合でも、同じような問題が起こることがあります。2つの入力はそれぞれ単体では問題なく見えても、その間の関係性が変わると、下流で突然余分な行が発生することがあります。請求書1件につき1行であることを想定している場合は、結合の直後にそれを確認する方が、両方のソーステーブルが問題なく見えることだけを確認するよりも、はるかに有益です。
データ自体はまったく正しくても、レポーティングロジックがこれまで扱ったことのない値である場合もあります。例えば、現在のレポーティングカテゴリのどれにも該当しない新しい販売チャネルが追加されることがあります。その値が間違っているわけではなく、レポートを完成させる前に、どのように扱うかを判断する必要があるだけです。
専用のデータ品質プラットフォームやデータオブザーバビリティプラットフォームの方が適している場合
場合によっては、単一のレポーティングワークフローが正常に実行できるかどうかよりも、さらに大きな課題に対応する必要があります。チームが大規模なデータ資産全体の品質を監視する必要がある場合や、データエンジニアリングに近い領域での監視が必要な場合は、専用のデータ品質プラットフォームやデータオブザーバビリティプラットフォームの方が適している可能性があります。
一方で、チェックが失敗した後の対応に多くの手間がかかっているのであれば、その後に何ができるのかを詳しく確認してください。影響を受けたレコードまでたどり着き、問題に対処し、データを別のプロセスに渡すことなくワークフローを継続できるかどうかを確認する必要があります。
これらは異なるニーズです。エンタープライズ全体にわたる広範な監視が優先事項であれば、その観点から評価してください。チームがレポーティングワークフロー内で失敗したチェックの原因追跡に多くの時間を費やしているのであれば、ワークフローを分断することなく、どれだけ簡単に問題に対処できるかをより重視してください。
連携された分析ワークフローが実際にどのように機能するかを確認する
例えば、週次の在庫レポートで、あるサプライヤーがワークフローでこれまで扱ったことのないステータス値を送信し始めたとします。レポート自体は引き続き実行されるかもしれませんが、出力を完成させる前に、それらのレコードをどのように扱うかを判断する必要があります。
そのようなケースでプラットフォームをテストする場合は、ワークフロー全体を通して予期しない値を追跡してください。調査を別のプロセスとして切り離すことなく、影響を受けたレコードまでたどり着けるようにする必要があります。適切な処理方法がすでに決まっている場合は、そのロジックをワークフロー内に保持しておくことで、翌週に同じ修正を繰り返す必要がなくなります。
まだ答えが決まっていない場合は、ワークフロー側で無理に判断させるべきではありません。レポートの処理を先に進める前に、それらのレコードをレビューする必要がある場合もあります。
ここで重要なのは、問題を発見してから、実際に有効な対応を取れるようになるまでの距離です。連携されたワークフローでは、途中でプロセスをつなぎ直す必要なく、その一連の流れをたどりやすくする必要があります。
Alteryx Oneがこのようなレポーティングワークフローにどのように対応するかを確認したい場合は、Alteryx Oneをご覧ください。
まずは、チームがよく知っているレポートから始めましょう
社内で最大規模のワークフローから始める必要はないでしょう。チームが問題の起こりやすい箇所を把握している定期レポートを選び、過去に問題が発生したことをきっかけに追加されたチェックについて考えてみてください。
今でも、誰かが覚えていることに依存しているチェックはどれですか？繰り返し発生している修正事項はどれですか？明日重大な問題が発生した場合、ワークフローはそれを検知して停止できますか？それとも、誰かが気づくまで処理を続けてしまいますか？
こうした問いは、一般的な機能チェックリストよりも、データ品質プラットフォームを評価するうえではるかに有効です。目指すべきなのは、依然として人の判断が必要な部分まで自動化しようとするのではなく、チームがすでに頼りにしているチェックを、より簡単に繰り返せるようにすることです。
このアプローチを実際に試してみたい場合は、チームが熟知している定期レポートを使って、Alteryx Oneの無料トライアルを始めてみてください。