最近、中学受験の算数の図形問題がYoutube のオススメにどんどん出てくるので、その度に手を止めて考えてます。うまく解けると気持ちいいです。
図形問題は苦手だったのですが少しずつコツを掴み始めていて、補助線をうまく引いて角度や面積を求められると気持ちいいですね。代数だと複雑な関数の積分を求めるのに近いというか、ある程度の基本的なパターンは覚えておきながらどれが当てはまるかを試行錯誤する感覚です。
今日は組織がデータメッシュに到達するまでの流れを独自の観点で解説している記事を紹介します。
もくじ:
How Shadow Data Teams Are Creating Massive Data Debt
この記事では"Shadow data teams" という独自の概念を提唱していて、いくつかの記事を経て最終的には Data Mesh の解説まで行うそうです。著者の Diogo Silva Santos 氏は現在、the Western Europe Leader for Data & AI at Fujitsu も勤めているようで、LinkedIn を見るとデータ領域において幅広く活動されているようでした。
Shadow data teamが生まれる経緯
データがそこまで大量ではなかったころ、以下の点について考えるだけでデータの民主化は達成できていました:
- データプロフェッショナルの雇用。今のデータスタックに長けているだけでなく、将来現れる技術にも対応できる人材。
- データスタック。データライフサイクルが取り込み、保存、提供、データ利用までうまく回っている状態。
- Cスイート（経営層）の支援。
しかし技術革新が進み、データ活用プロセスにおける複雑性が増してきます:
- ビッグデータ時代の到来
- データソースの増加
- 潜在的なユースケースの増加
- 様々なデータ利用者の登場
一方で以下の項目については今も変わらず必要であり、重要性が増してきています:
- データ関連人材の協力関係
- ソフトウェアエンジニアがデータを生成するが、データ提供をするインセンティブが無く分析サイクルからは外れている
- データサイエンティストはビジネス層に近く、急かされることが多いため信頼に欠くデータを利用せざるを得ないケースがある
- データエンジニアは中間に位置し、板挟みにあう
- ビジネスコンテキストの理解
- より早くデータからインサイトを得なければならない
このような問題が徐々に蓄積され、"Shadow data team" が生まれる結果となってしまいます。
Shadow data team とは？
組織におけるデータチームは、中央集権型・分散型(Data Meshへつながる)、そして "Shadow data team" の3つに分けることが出来ます。Shadow data team は簡潔に言えば「データ活用のサイクルが短いのにデータガバナンスが低い」チームです。上記記事ではこの "Shadow data team" が今最も発生しやすいチームであり、その理由を簡単な時系列に沿って説明しています:
- ビジネスによって新たなデータ機能あるいは製品のためのリクエストが発生する
- データサイエンティストはリクエストを精査。その結果、必要なデータが利用不可能であるか、もしくは予想されるスキーマで利用不可能であることを発見する
- データサイエンティストは、データエンジニアに新たなデータパイプラインを要求する
- データエンジニアたちは日頃から膨大なリクエストを抱えており、このリクエストを解決するのに数週間から数ヶ月を要してしまうことを伝える
- データサイエンティストはビジネス層からのプレッシャーを感じており、データエンジニアの作業を待たずにデータソース等に直接アクセスし、プロダクション基準やCI/CDのベストプラクティスに従わず、明確な所有権がないSQLあるいはdbtパイプラインを作成する
- データサイエンティストはこのプロセスに慣れてしまい、結果として組織内で大量のデータ負債を生み出すことになる
この5番目は dbt という具体的なツール名まで挙げて説明されているのが興味深いです。
dbt はこの5番目の内容の通り、データサイエンティストが SQL だけを利用して自らデータパイプライン構築ができることを強みにしています。これがデータサイエンティストの悩みを解決するけれども、組織全体で見ると新たなデータ負債を生んでしまうため、"Shadow data team" につながるという指摘です。ただ dbt は分かりやすさのために紹介されているだけで、データサイエンティストが時間に追われて既存のデータパイプラインを使わずにデータ生成しているケースはよくあることだと思います。
データ負債が増大していく
この結果生まれるデータ負債には、次のようなものが挙げられます:
- 一貫性がなく信頼性の低いデータ
- 高いメンテナンスコスト
- データに関する問題のトラブルシューティングが難しくなる
- 生成されたデータに対して誰が責任を負うのかを決めるのが難しい
- 信頼性の低い機械学習モデル
- 保守されていないパイプライン、テーブル、重複したデータに関連する追加費用
- レイクとデータウェアハウスの操作がより複雑になる
一方データエンジニアチームはというと、データサイエンティストが独自のプロセスでデータ活用をし始めるとデータエンジニアの必要性が薄れてきて、チームとしての信頼性が失われていきます。dbt はアナリティクスエンジニアという言葉を提唱していますが、データサイエンティストの職責がデータエンジニア側に拡大し、その拡大部分がアナリティクスエンジニアと呼ばれているのだろうと理解しています。
このまま月日が経つとデータ負債はどんどん増えていきます。もし経営層や責任者が組織体制を立て直そうとしても、ビジネス層のメンバーはデータサイエンティストによる素早いデータ活用サイクルに慣れてしまっているため、立て直しは非常に困難です。
この続きは著者の Diogo Silva Santos の新たな投稿待ちとなりますが、「データ負債についてのさらなる解説」、「データウェアハウスが最も重要なデータ資産であること」、そして「データメッシュの紹介」と続くようです。
感想
この記事で紹介されている "Shadow data team" へつながる流れは私も感じたことがあります。標準プロセスを重視したいデータエンジニアと、ビジネス層に急かされ自分たちだけでデータ活用を進めてしまうデータサイエンティストという構図は多くの組織で見られるのではないでしょうか。
営業担当者と開発者に置き換えても似たような話はできますが、営業担当者だけで製品開発を進めることができません。一方でデータエンジニア／データサイエンティストのケースだとデータサイエンティストだけでデータ活用サイクルを進めてしまえる点が状況をより複雑にしている気がしました。
続く記事が出たら、またまとめてみます。
