Medium でとても目を惹くタイトルの記事を見つけました。"High-Performance Data Teams Don’t Care About Data Quality", 和訳するなら「ハイパフォーマンスなデータチームは、データ品質を気にかけない」というところでしょうか。
データ品質は DMBOK でも大きな軸の一つになっていて、色んな文脈でデータ品質は重要だという話がされています。それにも関わらず、データ品質を気にかけないデータチームとはどんなチームなんでしょうか。
High-Performance Data Teams Don’t Care About Data Quality
記事はこちら:
High-Performing Software Teams
2014年に State of DevOps ハイパフォーマンスなソフトウェアチームについての研究が 2014 年に発行され、さらにこの研究に携わったメンバーにより、2018年に Accelerate という書籍が出版されました。その中の重要なトピックに、4つのキーメトリクス(four key metrics)があります:
- lead time（機能開発してからリリースまでの時間）
- deployment frequency（デプロイ頻度）
- mean time to restore (MTTR)（平均復旧時間）
- change failure percentage（機能劣化につながった変更率）
4つのキーメトリクスをデータチームに適用 (code + data)
筆者はこの4つのキーメトリクスがソフトウェアだけでなく、データにも適用できると主張します。この4つのキーメトリクスの改善に重きを置くことで、結果としてデータ品質の高いデータ基盤が構築できます。
この4つのキーメトリクスを改善するためには、データならではの難しさがあります。記事中では4つのキーメトリクスごとにデータ基盤における取り組みのポイントが紹介されています。
例えば4番目の「機能劣化につながった変更率」について。ソフトウェアアプリケーションとは違ってデータ基盤に関する問題は、(1)コードのバグ (2)データのバグ (3)どちらも影響するバグ の3種類があり、機能劣化が起こりやすくなっています。これはデータ基盤を運用している方なら、日々のデータやBIアプリケーションに関する問い合わせ頻度を思い浮かべれば納得するのではないでしょうか。ステージング環境にはテストデータしか入っておらず、本番にリリースするまでデータパイプラインが本当に正しく動作するかが分からない…という環境は少なくないのではないかと思います。
この4番目のメトリクスへの対策として、「本番と同じデータをステージングへ用意する」「データ変換に対してA/Bデプロイメントを行う」「新しいデータに対してもA/Bデプロイメントを行う」などが紹介されており、他のメトリクスに対しても合計で9つの対策が言及されています。
データ品質を上げるのは手段 -> 目的は機能(データ)劣化の防止
冒頭のデータ品質についてですが、これは恐らく4番目の「機能劣化につながった変更率」に関わるものかと思います。データ品質を上げようと考えるのではなく、その先の目的である機能（データ）劣化を防ぐことに着目して改善を続けることで、結果としてデータ品質の改善につなげようということのようです。
4つのキーメトリクスは以下のページで簡易チェックをすることができ、業界ごとの平均値と比較して良いか悪いかを確認することができました（以下の画像は適当に入力したものです）。平均値はデータの文脈にそのまま当てはめてよいものかは分かりませんが、開発チームの振り返りなどに使って、以前と比べてチームの特性がどう変化するかを追うとよさそうです。
