プロダクトとしてのデータ（DaaP）とは
プロダクトとしてのデータ（DaaP）は、プロダクト思考をデータ マネジメントに適用する手法です。単にデータを収集することから、データを提供することへと重点が移ります。このモデルでは、データは特定の「利用者」（デベロッパー、データ サイエンティスト、アナリスト）と、その有用性に責任を持つ「プロダクト オーナー」がいる独立したアセットと見なされます。
このコンセプトは、データメッシュ アーキテクチャの基本要素です。データメッシュは、データに最も精通しているチーム（販売、在庫、物流などのドメイン）が、中央チームに依存せずに、データをキュレートして組織の他のチームに提供する責任を負うべきだと提案しています。
DaaP とデータ プロダクトの違い
これらの用語は同じ意味で使用されることが多いですが、同じフレームワークの異なる側面を表しています。
- プロダクトとしてのデータ（DaaP）は、戦略を指します。これは、データをソフトウェアと同じ厳密さで扱うという考え方です。バージョン管理、ドキュメント作成、ユーザーサポートなどのプロダクトマネジメントの原則をデータアセットに適用することを含みます。
- データ プロダクトは成果物を指します。データ プロダクトとは、特定の問題を解決するために設計された、信頼できるアクセス可能なデータの単位です。
たとえば、その戦略（DaaP）により、チームは「四半期売上高」を含む、クリーンでドキュメント化されたデータセットを構築します。アクセス制御と使用ガイドを備えたその特定のデータセットが、データ プロダクトです。
プロダクトとしてのデータの主要コンポーネント
データセットがプロダクトとして機能するには、一般的に特定のユーザビリティ基準（多くの場合、データメッシュの原則に基づく）を満たす必要があります。ストレージ バケットにファイルが存在するだけでは、プロダクトとは見なされません。主な特徴は次のとおりです。
- 検出可能: 通常は一元化されたカタログや検索エンジンを通じて、利用者がデータを簡単に見つけられる必要があります。
- アドレス指定可能: データには、デベロッパーがプログラムでアクセスできるように、一意の永続的なアドレス（URI）が必要です。
- 信頼性: データは信頼できるものである必要があります。これは、データの更新速度と精度に関するサービスレベル契約（SLA）によって担保されることが多いです。
- 自己記述的: データには、スキーマ、出所、想定される使用方法を説明するメタデータが含まれている必要があります。これにより、利用者が所有者に質問する必要性が減ります。
- 安全性: アクセス ポリシーはデータ プロダクトに直接アタッチされるため、誰がアクセスしてもセキュリティが自動的に適用されます。
- 相互運用性: データはグローバル標準に準拠し、他のドメインのデータ プロダクトと結合、分析できるようにする必要があります。
企業における DaaP のユースケース
データに対してプロダクト マインドセットを採用する目的は、多くの場合、データ プロデューサーとデータの利用者間の摩擦を減らすことです。
1. 統合された顧客プロファイル
マーケティング チームとサポートチームは、多くの場合、さまざまなソース（ウェブログ、CRM、取引履歴）からのデータを必要とします。各チームが独自の抽出パイプラインを構築する代わりに、中央の「顧客ドメイン」チームが、検証済みの単一の「顧客プロファイル」データ プロダクトをリリースできます。アプリを構築するデベロッパーは、この標準プロダクトに登録することで、会社全体で一貫性を確保できます。
2. サプライ チェーンの可視性
物流では、在庫レベルに関するデータは急速に変動することがよくあります。「リアルタイム在庫」データ プロダクトを使用すると、下流のチーム（ウェブサイトのフロントエンドや調達チームなど）は、基盤となる倉庫管理システムの複雑さを理解する必要なく、正確な在庫レベルをクエリできます。
3. 機械学習を加速
データ サイエンティストは、モデルをトレーニングする前に、データのクリーンアップにかなりの時間を費やしています。「Feature Store」データ プロダクトは、ユーザーの離脱リスクや平均購入額など、事前に計算、検証された特徴を提供します。これにより、データ サイエンティストはクリーンアップ フェーズをスキップして、モデル アーキテクチャに専念できます。
DaaP を導入するメリット
プロダクトベースのマインドセットに移行するには労力がかかりますが、技術チームと組織全体にいくつかの構造的なメリットをもたらす可能性があります。
データ品質の向上
データ品質の向上
データ プロダクトにはオーナーと SLA が割り当てられているため、エラーに対する説明責任が明確になります。これにより、所有者のいない「データダンプ」と比較して、よりクリーンで信頼性の高いデータセットにつながるのが一般的です。
開発期間の短縮
開発期間の短縮
デベロッパーは、データの検索やわかりにくい列名の解読に費やす時間を減らすことができます。セルフサービスによるアクセスと明確なドキュメントにより、データをより迅速にアプリケーションに統合できます。
ボトルネックの削減
ボトルネックの削減
データの所有権をドメインチームに分散することで、組織は単一の中央データチームによるボトルネックを解消できます。これにより、複数のチームがデータ プロダクトを並行して構築、公開できるようになります。
ガバナンスの明確化
ガバナンスの明確化
セキュリティとアクセス ポリシーはプロダクト レベルで定義されます。これにより、誰がどのデータにアクセスできるかを監査しやすくなり、正規ユーザーのアクセスを妨げることなくコンプライアンスを確保できます。
Google Cloud を使用した DaaP の実装
DaaP をより深く理解するために、Knowledge Catalog（旧 Dataplex）と BigQuery を技術的な基盤として使用して、DaaP の理論的なコンセプトを実際に実装する方法を説明します。
シナリオ: デベロッパーはレコメンデーション システムを構築する必要があり、ユーザーの視聴履歴に関する信頼できるデータセットを必要としています。
ステップ 1: 調査（カタログ）
DaaP 環境では、デベロッパーは手動で問い合わせる必要はありません。デベロッパーは、データから AI へのガバナンスの中央プラットフォームとして機能する Knowledge Catalog を使用しています。カタログで「ユーザー ページビュー」を検索すると、ecommerce-user-activity という名前の登録済みアセットが見つかります。これにより、検出可能要件が満たされます。
ステップ 2: 評価（メタデータ）
コードを書く前に、デベロッパーはエントリを確認します。エントリは次のように表示されます。
- スキーマ: 定義された列（user_id、item_id、timestamp など）。
- リネージ: データの出所を示す情報。
- 品質指標: 定義された品質ルールを 99.9% の行が満たしていることを確認する自動スキャン（Knowledge Catalog AutoDQ など）によって生成されるスコア。これにより、信頼できる自己記述型の要件が満たされます。
ステップ 3: アクセス（セキュリティ）
デベロッパーはカタログ インターフェースを通じてアクセスをリクエストします。データオーナー（特定のドメインチーム）がリクエストを承認し、その特定のリソースに対する「データ閲覧者」ロールを付与します。これにより、安全要件が満たされます。
ステップ 4: 使用（統合）
アクセス権が付与されると、デベロッパーは BigQuery でデータプロダクトに直接クエリを実行できます。
- SQL
データはプロダクトとして扱われるため、デベロッパーはスキーマが安定していること（またはバージョン変更の通知を受けること）を前提として、アプリケーションを確実に実行できます。
クイック スタート: データ プロダクトの構築を始める
アドホックなデータ作成からマネージド データ プロダクトの構築への移行を検討しているデベロッパー向けに、Knowledge Catalog はアセットのパッケージ化、管理、共有を行う専用のサービスを提供しています。次のワークフローは、マネージド ライフサイクルの基本となる手順を示しています。
- アセットの特定とキュレート: 特定のユーザーのニーズを解決する技術リソース（BigQuery テーブル、承認済みビュー、AI モデルなど）を選択します。これらのアセットは Knowledge Catalog に登録する必要があります。
- データ プロダクトの作成: Knowledge Catalog コンソールを使用して、新しいデータ プロダクト リソースを作成します。これは、キュレーションされたアセットを 1 つのユニットにパッケージ化して、検出と共有を可能にする論理コンテナとして機能します。
- ビジネス コンテキスト（アスペクト）のアタッチ: アスペクトをアタッチして、メタデータでプロダクトを拡充します。データ プロダクト テンプレートを使用して、プロダクト名、ビジネス上の目的、所有権、想定される使用方法を定義し、利用者にとって自己記述可能なプロダクトとします。
- ガバナンスとアクセスの定義: プロダクトの承認ワークフローと必要なロールを設定します。これにより、アクセス リクエストを一元的に管理でき、承認されたユーザーのみがプロダクトを購読してクエリを実行できるようにします。
- 公開と共有: 一度公開されると、データ プロダクトは AI のカタログで検出可能になります。利用者は、プロダクトを検索し、ドキュメントと品質指標を確認して、アクセスをリクエストすることで、BigQuery で直接データのクエリを実行できます。
関連プロダクトとソリューション
Google Cloud 上でプロダクトとしてのデータの技術的な側面を実装する際に、よく使用されるツールは以下になります。
参考情報
- データメッシュとは: この記事では、プロダクトとしてのデータ手法を支えるデータメッシュ アーキテクチャの概要を説明します
- Knowledge Catalog のドキュメント: これらの技術ガイドでは、Google Cloud コンソール内でユニバーサル カタログを構成する方法について詳細な手順が説明されています
- Knowledge Catalog を使用してデータ プロダクトを構築する: データ プロダクトを構築する方法をステップごとの手順で説明する技術ガイド
- BigQuery Sharing のドキュメント: 組織の境界を越えてデータアセットを安全に共有できるデータ エクスチェンジ プラットフォーム
開始にあたりサポートが必要な場合
お問い合わせ信頼できるパートナーと連携する
パートナーを探すもっと見る
すべてのプロダクトを見る
