筆者がスタートアップの「データ何でもチーム」をやってきた中で、考えてきて実践してきたことを吐き出します
ポエムです

data as a product

データメッシュを実現する文脈の中で、「それぞれのドメインに分散されたチームが自身の提供するデータセットに対してproduct thinkingを適用するべきだ」とする考えが生まれてきた。

For a distributed data platform to be successful, domain data teams must apply product thinking with similar rigor to the datasets that they provide; considering their data assets as their products and the rest of the organization's data scientists, ML and data engineers as their customers*1.

（筆者日本語訳）分散データプラットフォームが成功するためには、ドメインごとに配置されたデータチームが自身の提供するデータセットに対してプロダクトシンキングを適用しなければならない。データアセットをプロダクトとして捉え、組織内の他のデータサイエンティストや機械学習エンジニア、データエンジニアを顧客とみなすのである。

この考え方を「data as a product」といい、平たく言えば「データセットをプロダクトとみなし、プロダクトマネジメントをやっていこう」と主張する考え方である。国内の大規模エンタープライズの中でデータメッシュを実現できている企業は聞いたことがない2024年2月現在だが、データメッシュの文脈から外れたとしても、「data as a product」の考え方は有効である*2と僕は考えている。

社内データ基盤 as a product

実際にデータの利用者の立場になって考えてみると、データセットそのものに対してProduct Thinkingを適用するだけではデータの利用者に対して価値を提供することはできないことに気づく。データセットは重要な要素だが、データの利用者は「自分のビジネスに役立つインサイトが欲しい」のであり、「データが欲しい」わけではないからだ。

インターフェースを入り口とし、インサイトを出口とする一連のユーザー体験の中で、データの利用者は価値を得る。この価値を最大化することが、社内データ基盤のプロダクトマネジメントの役割である。大事な事だから繰り返すが、「データを提供すること」は手段であって目的ではない。目的は「ビジネスインサイトの提供」である。

たとえば、BIツールのユーザー発行プロセスが面倒であり、結果的に社内の誰も使えない状態になっているのなら、ユーザー発行プロセス自体を自動化し、オンボーディング体験をよくする事も必要となる。データに触れるインターフェースを入り口とするなら、入り口に至るまでの段階がボトルネックになっている状態を解消することは責務の範囲内になる。

別の例として、「苦労して作ったが、使われていないダッシュボード」があるとしよう。ダッシュボードはプロダクトを構成する一つの機能と捉えられる。このダッシュボードは「利用数が少ないが、プロダクトの方向性と一致する」分類の技術的負債*3であり、優先度が低い場合は削除、優先度が高い場合はUX自体のアップデートが必要となる。プロダクトなので当然技術的負債もあり、社内データ基盤で実現したいゴールと現状から負債を分類し、アプローチする事も責務の範囲内である。

この「インターフェースを入り口とし、ビジネスインサイトを出口とする」一連のユーザー体験を最大化することを目的に、プロダクトマネジメントっぽくやっていくことが、「社内データ基盤 as a Product」の考え方である。

実践してきたこと

上記のような考え方をもとに今まで仕事してきたが、実際にやっていたことは一般的なプロダクトマネジメントの教科書に書いていることばかりであった。曖昧な状況をクリアにし、明瞭なコミュニケーションをとり、ユーザーに価値を届けるためにいろんなことをやってきた。たとえば以下のようなことである：

ユーザーのニーズ調査

ヒアリングやエスノグラフィの手法を使ってユーザーのニーズを調べる
実践テクニックだが、ダッシュボードのニーズを調べるならホワイトボードにグラフをラフに書いて「あなたが欲しいのはこんな感じですか？」と聞くとスムーズである。詳しくはこちら

contradiction29.hatenablog.com

ビジネスインパクトを基準にした優先順位策定

データ基盤を運営していく上では、「アドホックなデータ抽出で済ませるか、ダッシュボード化するか」が判断の分かれ目になることが多い。後者はテーブルの作成が必要になる場合も多く、アナリティクスエンジニアリングの領域も絡んでくるためである。
この場合は「ビジネスインパクト」なんて難しい言葉を使わずに、「他の場面でも使用するイメージが想定できるか」を基準にしてダッシュボード化するか、しないかの判断をしていた。「ビジネスインパクト＝PDCAサイクルを回す時間を削減できる程度」として捉え、多くのユーザーに使われるならそれだけ削減できる時間も長くなる＝ビジネスインパクトがあるよね、とする考え方である。

品質

当然であるが、データの品質がおかしくなることはある。
特に手入力のデータをソースとするデータセットは被ってはいけないIDが被ったりすることが多いので、適宜dbtのtestを組んだりして品質担保をしたりする。

ユーザーに価値を提供する手段の選択

ユーザーにデータを提供する手段は複数あり、それぞれに得意不得意がある
- ダッシュボード
  - 自動で更新することが可能
  - SQLで完結する範囲内ならなんでもでき、チーム内でも使えるメンバーが多い
  - 柔軟性に欠ける
- Streamlit
  - 自動で更新することが可能
  - 動的にSQLを生成し、インタラクティブなダッシュボードを作成することができる。ダッシュボードを補完するツールとして利用可能
  - ダッシュボードよりは作成に時間がかかり、管理もダッシュボードと比較すれば面倒ではある
- Slack API
  - 自動でプッシュ型の通知をすることが可能
  - オペレーショナルアナリティクスの場面で役に立つ。ユーザーに一方的にデータを送りつけることができるため、物忘れの防止に役立つ。
  - 複雑なデータは送れない
- Google SpreadSheetのIMPORTDATA関数の利用
  - AWS Lambdaの関数URL機能とGoogle SpreadSheetのIMPORTDATA関数を使えば、スプレッドシートに直接データを吐き出すことができる
  - 営業やカスタマーサクセスチームの定常レポートなど、定型的な業務を効率化するために利用できる
- アドホック抽出対応
  - プログラム化されていない分析を提供することが可能
  - 最も柔軟なデータ提供の形
  - 人的リソースの制約の影響を受ける
実務では手段Aを指定されても最適なのは手段Bだよね、みたいに提案しにいく事も多く、複数の提供手段の得手不得手を理解し、最適なデータ提供の手段を考えるのはパズルのようで面白い