「Data as a Product」について考える
この記事は10Xプロダクトアドベントカレンダーの16日目の記事になります。
今回は「Data as a Product」に関する課題について自分の考えをまとめてみました。
（写真は9月に北海道に訪れたときの小樽運河の写真です。）
はじめに
最近のデータエンジニアリング界隈ではプロダクト志向を用いて開発するためのツールやプロダクト開発組織に似せた組織構築やマネジメントに関する方法論が多く提案されています。その中でもデータのドメインに関する認知負荷を抑えるためにデータメッシュという考え方が提唱されており、4つの基本原則に則ってデータプラットフォームを構築することが述べられています。今回はこの中の一つの原則である「Data as a Product」について触れようと思います。なぜこの原則だけに触れるのかというと、データメッシュそのものを導入することは非常に敷居が高いと感じている一方で、「Data as a Product」は導入できる可能性が高く、データプラットフォームチームやデータを活用したい組織に対するリターンが大きいと考えているからです。
「Data as a Product」とは
「Data as a Product」について確認するときは以下の記事を参考にすることが多いです。これらの記事の中で「Data as a Product」はデータメッシュの基本原則の一つとして紹介されており、記事の中には次のような問題について述べられています。この問題はデータ利用者にとって高品質なデータの提供を継続できないという根本的な問題を表しています。
既存の分析データアーキテクチャの課題の一つは、品質の高いデータを発見、理解、信頼し、最終的に利用するための摩擦とコストが大きいことである。この問題に対処しなければ、データを提供する場所やチーム、ドメインの数が増えるにつれてデータメッシュとともに問題が悪化するだけである。
「Data as a Product」はプロダクト志向に基づいて各ドメインが取り扱うデータに次のような基本的な性質を持たせるように開発を行います。これ以外にもドメインデータプロダクトオーナーの役割などについても詳細に説明されています。（ここでは詳細までは割愛します。）
「Data as a Product」の課題
「Data as a Product」はデータプラットフォームチームとしては理想的な動き方であり、データを活用していく企業にとっては重要な考え方となる一方で、実態としては企業の規模や経営のデータに対する重要性の認識の違いからデータプロダクトオーナーやデータエンジニアを各チームに配置できるだけのリソースがないことが多いと思います。データエンジニアを配置できない場合はデータエンジニア以外のエンジニアが前述の原則を守る必要がありますが、次のような問題が発生します。
他の開発業務と並べたときには優先度が決めづらい
専門家ではないので学習が一定以上必要になる
ドメインデータプロダクトオーナーについてもドメインチームに所属するプロダクトオーナーやプロダクトマネージャーがその役割を担う必要が出てくるので同様の問題が発生する可能性が高いと思います。
どのように解決するのか
ここでは主に一つ目の「他の開発業務と並べたときには優先度が決めづらい」に対する取り組みについて紹介します。
ドメインデータの価値を上げる
一般的にアナリティクスやデータサイエンスを担当するチームがデータの必要性を理解していないことはないですが、ドメインチームは必ずしもそういうわけではありません。データメッシュでもイネイブリングチームがサポートを行うことを推奨していますが、どのような分析を行えばよいか、どのような指標を追跡するべきか、の全てに自力で解を出せるかはチーム構成などに大きく依存します。アナリストやデータサイエンティストと協業し、ドメインチームが必要になるデータを増やすことができればこれまでよりも需要な業務として扱ってくれるようになる可能性があります。
また、プロダクトがPMFの前後のフェーズであったり、複数のプロダクトを開発しているような企業ではダークデータ（事業にとって有効に活用できておらず、その価値が認知されていないデータ）が存在していることが多いです。これらは常に探索的な動きが必要であり、中には大きなインサイトを与えるものがあるため、アナリストやデータサイエンティストのリソースを一定以上使える状況が作れると良いと思います。（1年前の記事でもプロダクトのデータを活用できるための準備をしているということを書いていました。）
データの品質や利用状況の可視化
「プロダクト開発をして新しい機能をリリースしたときに嬉しいことは何か？」と問われれば「ユーザーが利用してくれていること」と答えるエンジニアは多いのではないでしょうか？自分もプロダクト開発をしていたときはそうでした。データも同様に利用状況を可視化してデータプラットフォームチームだけで確認するのではなく、ドメインチームと共有することでドメインチームが開発した成果物が利用されていることを認識してもらうことが重要だと思います。
また分析用途のデータは分析の目的によって必要な品質が異なり、要求される品質が高まることがドメインチームへの開発依頼につながることが多いと思います。データ品質の可視化は、利用者に対してどれくらいの品質のデータを提供しているかを可視化することで用途にフィットしたデータを利用できるようになります。また開発者に対しては、特に品質の低いデータなどをマクロに認識しやすくなるため、ボトルネックになっているデータを把握しやすくなります。
最近ではAirbnbが「Data Quality Score」というものを作ったという記事が紹介されており、品質の可視化を行おうとした背景や最終的にいくつかの指標に着地した話など参考になるものが多かったです。私が所属する10Xのデータプラットフォームチームでも品質や利用状況の可視化を絶賛進めようとしており、来年の春には何か面白い事例が紹介できるようになっているといいなと思います。
(補足) Data Platform Engineering
あるエンジニアが学習をするコストを下げるソリューションとしてPlatform Engineeringが挙げられます。最近、データエンジニア界隈では「Data Developer Platform」というサイトが話題になりましたが、Platform Engineeringで具体的にどのような方針で何をやればいいのかを考える際には非常に参考になると思います。
なぜこのサイトをここで紹介したかというと、「「Data as a Product」の課題」で紹介した課題に対してデータメッシュとは異なるアプローチを提唱しているからです。
データメッシュとData Platform Engineeringの両者に言えることですが、理論的に見るとデータプラットフォームチームにとっては理想的である一方で、実態としてはそこまでの登り方は組織のフェーズや事業の性質によって大きく異なるように思います。並べて見てみると共通していることもあるので、両者の良いところをcherry-pickしながら自分達の組織に合う方法を検証していくことが求められそうです。
おわりに
今回は「Data as a Product」についての紹介やその課題、解決するための取り組みについて紹介しました。今回紹介したものは自分も所属企業で試行錯誤しているものであり、成果が出ていると感じられるものや改善が必要だと思うものを書いてみました。企業や事業、組織構造などで様々な状態のデータプラットフォームチームが世の中にはあると思いますが、その一助になればいいなと思います。
最後に10Xではデータエンジニアやその他の職種も含め、絶賛募集中です。
カジュアル面談やご応募、お待ちしております！