データプロダクトとは、利用者に価値を提供する、品質保証・ドキュメント・SLAが備わったデータの提供単位です。「テーブルを作って共有する」という従来のアプローチとの最大の違いは、データを使う人の視点から設計され、継続的にメンテナンスされる「サービス」として扱われる点にあります。本記事では、データプロダクトの定義、5原則、具体例、設計・構築方法、成熟度モデルを解説します。
データプロダクトとは何か――「テーブル」ではなく「サービス」として提供する
ソフトウェアプロダクトにはREADME、バージョニング、API仕様、サポート窓口があります。データプロダクトも同様の思想でデータを提供します。単なるテーブルとの違いは「オーナーシップの明確化」と「品質の継続的な保証」にあります。データプロダクトには、誰がこのデータに責任を持ち、どのような品質が保証され、どのSLAで提供されるかが明記されています。
従来の「テーブルを作って共有する」アプローチでは、データを使う人が品質やスキーマ変更のリスクを自分で吸収しなければなりませんでした。データプロダクトはその責任をデータの提供者(プロデューサー)側に移転します。これはA-05 データメッシュの中核概念「Data as a Product」に由来しており、データメッシュの実装単位でもあります。ただし、データプロダクトの考え方はデータメッシュを採用していない組織にも有効に適用できます。
データプロダクトの5原則
【データプロダクトの5原則】
[データプロダクト]
|
+---------+---------+---------+---------+
| | | | |
v v v v v
[発見可能] [アドレス [信頼可能] [自己記述 [相互運用
可能] 的] 可能]
カタログ 一意の 品質保証 ドキュメ 標準形式
検索 URL/ID SLA ント完備 互換性原則1：発見可能(Discoverable)
データプロダクトはデータカタログに登録され、キーワード検索やタグで見つかる状態にあります。「こんなデータがあることすら知らなかった」という状況をなくすのが第一歩です。A-08 データカタログがこの発見可能性を実現する主要な場所です。データプロダクトの名前・説明・タグ・オーナー情報がカタログに登録されていることが必須条件です。
原則2：アドレス可能(Addressable)
一意のエンドポイント(テーブルパス、APIエンドポイント、S3パスなど)でアクセスできることを指します。「どこにアクセスすれば使えるか」が明確で、バージョンが変わっても過去バージョンへのアクセスが保証されます。Gitのコミットハッシュのように、特定の状態のデータに確実に到達できる仕組みが理想的です。
原則3：信頼可能(Trustworthy)
品質テスト・SLAが保証されており、利用者がデータを信頼して意思決定に使えます。NOT NULL・ユニーク制約・値の範囲チェックなどの品質テストが自動実行され、データの鮮度(Freshness)が監視されています。信頼可能性はA-16 データコントラクトによって形式的に保証されます。
原則4：自己記述的(Self-describing)
スキーマ・ビジネス上の意味・利用方法・制約がドキュメント化されており、外部のドキュメントを参照しなくてもデータの意味が理解できます。「このorder_amountは税抜き金額か税込みか」「キャンセル済み注文を含むか」といった疑問がデータそのものへのアクセスで解決できる状態です。dbtのschema.ymlやデータカタログのメタデータがこの機能を担います。
原則5：相互運用可能(Interoperable)
他のデータプロダクトと組み合わせて使えます。標準的なデータ形式・共通の識別子・標準化されたスキーマ命名規則を採用することで、複数のデータプロダクトを横断した分析が可能になります。たとえば、顧客IDが全データプロダクトで同じフォーマットであれば、顧客360ビューの構築が格段に容易になります。
| 原則 | 概要 | 実現手段 | チェック項目 |
|---|---|---|---|
| 発見可能(Discoverable) | カタログで検索・発見できる | データカタログ登録・タグ付け | カタログにプロダクト情報があるか |
| アドレス可能(Addressable) | 一意のエンドポイントでアクセスできる | 明確なスキーマパス・バージョニング | アクセス先URLが不変か |
| 信頼可能(Trustworthy) | 品質テスト・SLAが保証されている | dbt tests・データコントラクト・監視 | テスト合格率・SLA達成率 |
| 自己記述的(Self-describing) | スキーマ・意味がドキュメント化されている | dbt schema.yml・カタログ記述 | 全カラムに説明があるか |
| 相互運用可能(Interoperable) | 他プロダクトと組み合わせて使える | 共通識別子・標準形式採用 | 共通キーで結合できるか |
データプロダクトの具体例
例1：顧客360ビュー(統合顧客プロファイル)。CRM・注文DB・サポートチケットなど複数ソースから顧客情報を統合したデータプロダクトです。全社のあらゆる分析・ML・BI利用の基盤となる最重要プロダクトの一つです。5原則の観点では、カタログへの登録(発見可能)、一意のcustomer_idによるアドレス指定(アドレス可能)、日次の品質テストとFreshness監視(信頼可能)、全カラムの定義(自己記述的)、全社の標準customer_idとの互換性(相互運用可能)が揃っています。
例2：売上ダッシュボード用マートテーブル。経営レポートの基盤となるファクトテーブルで、BIツールが直接参照します。毎日朝8時までに前日分が更新完了するSLA、NOT NULL・値の正値チェック・前日比異常検知が担保された信頼可能なデータプロダクトです。ダッシュボード作成者が「このテーブルのorder_amountは信頼できる」と確信して使える状態がゴールです。
例3：MLモデル用特徴量テーブル。購買予測や離反予測などのMLモデルが学習・推論に使う特徴量を一元管理するテーブルです。Feature Storeとしての役割を担い、複数のMLモデルが同じ特徴量を再利用できる(相互運用可能)設計が重要です。特徴量の計算ロジックが変わった際のバージョニングと影響管理が運用の要となります。
データプロダクト vs データセット vs データパイプライン
混同されやすい3つの概念を整理します。データプロダクトはデータセットとデータパイプラインの「上位概念」ではなく、それらを含んだ「利用者向けのパッケージ」として捉えると理解しやすいでしょう。
| 概念 | 定義 | 品質保証 | ドキュメント | SLA | オーナー | 利用者向けか |
|---|---|---|---|---|---|---|
| データセット | データの集合体 | なし〜任意 | 任意 | なし | 不明確 | △ |
| データパイプライン | データ変換・移送の処理 | 処理ロジック単位 | コード内コメント | 処理時間の保証 | エンジニア | ✗(内部実装) |
| データプロダクト | 利用者に価値を提供するデータ単位 | 明示・継続保証 | 必須 | 明示 | 明確 | ○ |
データプロダクトの設計・構築方法
データプロダクトの設計は「利用者の視点から逆算する」のが原則です。以下の5ステップで進めます。
- 利用者(コンシューマー)のニーズを定義する：誰がどのような用途でこのデータを使うかを明確にします。BIツールかMLか、分析用か本番システム向けかによって必要な品質・鮮度・形式が変わります。
- スキーマとデータコントラクトを設計する：利用者のニーズに基づいてスキーマを設計し、A-16 データコントラクトとして形式化します。カラム定義・品質ルール・SLA・オーナー情報をコントラクトに明記します。
- 品質テストとSLAを定義する：NOT NULL・ユニーク・値の範囲チェックをdbt testsで実装します。Freshness監視とアラートを設定し、SLA違反を自動検知できる体制を整えます。
- ドキュメントとカタログ登録を行う：全カラムにビジネス上の説明を付与し、データカタログに登録します。dbtのschema.ymlをデータカタログに連携させると、コードとドキュメントの一元管理が実現します。
- フィードバックループを設計する：利用者からの問い合わせ窓口、利用状況のモニタリング(クエリ頻度・利用チーム数)、定期的な見直しサイクルを設計します。利用されないデータプロダクトは廃止の判断も必要です。
# dbt model定義 + schema.yml の例(ドキュメント・テスト・contract付き)
models:
- name: customer_360
description: "顧客360ビュー。1行=1顧客。メール確認済みのみ。"
config:
contract:
enforced: true
meta:
owner: "customer-data-team@example.com"
update_frequency: "daily"
sla: "毎日8時までに前日分更新完了"
tier: "tier1"
columns:
- name: customer_id
description: "顧客ID(サロゲートキー)"
data_type: integer
constraints:
- type: not_null
- type: unique
tests: [unique, not_null]
- name: email
description: "メールアドレス(確認済みのみ)"
data_type: varchar
constraints:
- type: not_nullデータプロダクトの運用と成熟度
データプロダクトは一度作ったら終わりではなく、継続的に成熟させていくものです。3段階の成熟度モデルを参考に、段階的に品質を高めます。
| レベル | 特徴 | 必要な仕組み | 推奨ツール |
|---|---|---|---|
| Level 1：基本提供 | テーブル＋基本ドキュメント。利用可能だが品質保証は限定的 | schema.yml・カタログ登録 | dbt docs・データカタログ |
| Level 2：品質保証 | 品質テスト＋SLA＋コントラクト。信頼して使える状態 | dbt tests・監視アラート・コントラクト | dbt・Elementary・Monte Carlo |
| Level 3：フィードバック最適化 | 利用状況分析＋フィードバック収集＋バージョニング。利用者主導で進化 | 利用ログ分析・バージョン管理・廃止プロセス | データカタログ(Atlan等)・メタデータ管理基盤 |
まとめ――データプロダクトは「利用者目線」のデータ提供
- データプロダクトとは品質保証・ドキュメント・SLAを備えた「利用者に価値を提供するデータの提供単位」です。
- 5原則(発見可能・アドレス可能・信頼可能・自己記述的・相互運用可能)が評価基準となります。
- データセットやパイプラインとの違いは、利用者向けの品質保証とオーナーシップの明確化にあります。
- 設計は利用者のニーズ定義から始め、コントラクト・品質テスト・ドキュメント・フィードバックの順で構築します。
- 成熟度はLevel 1→3で段階的に高め、利用されないプロダクトは廃止の判断も含めた継続的な運用が必要です。
次のステップとして、A-05 データメッシュ、A-16 データコントラクトをご参照ください。DE-STKでは、データプロダクトの設計から品質保証体制の構築まで支援しています。
よくある質問(FAQ)
Q. データプロダクトとデータセットの違いは何ですか?
データセットはデータの集合体に過ぎませんが、データプロダクトはそれに品質保証、ドキュメント、SLA、オーナーシップを加えた「利用者に価値を提供する単位」です。データセットは内部実装の一部であることが多いのに対し、データプロダクトは利用者に向けて明示的に提供・サポートされるものです。責任の所在と品質の継続的な保証がデータプロダクトを定義する核心です。
Q. データプロダクトの5原則とは何ですか?
発見可能(Discoverable)、アドレス可能(Addressable)、信頼可能(Trustworthy)、自己記述的(Self-describing)、相互運用可能(Interoperable)の5つです。これらはZhamak Dehghaniがデータメッシュの文脈で提唱したフレームワークで、データを真に「プロダクト」として扱うための基準を定義しています。現実の実装では、Level 1(基本ドキュメント)からLevel 3(フィードバック最適化)へ段階的に5原則を満たしていくアプローチが一般的です。
Q. データプロダクトを導入するにはデータメッシュが必須ですか?
いいえ。データメッシュはデータプロダクトを組織的に推進するフレームワークですが、中央集権型のデータ組織でも「データをプロダクトとして扱う」考え方は有効に適用できます。たとえば、データエンジニアリングチームが社内のBIチームやMLチーム向けに品質保証されたデータプロダクトを提供するモデルは、データメッシュ抜きでも実践できます。まず重要なデータから試験的にデータプロダクト化してみることをおすすめします。