「データを製品として扱う」と言われても、ピンと来ないかもしれません。けれども「製品」という言葉には、業務をデータで支えるうえで重要な意味がいくつも含まれます。ドキュメント、SLA（サービスレベル合意）、サポート窓口、変更通知、利用者の声の反映。すべて、データ製品の利用者が「安心して使う」ために必要な要素です。
Data Productは、データメッシュの第2原則を支える具体的な単位で、組織が「データ提供を製品化する」プロセスでもあります。中身を整理します。
Data Productの構成要素
| 要素 | 内容 |
|---|---|
| データ本体 | テーブル、API、ストリーム |
| メタデータ | スキーマ、説明、所有者、リネージ |
| SLA | 鮮度、可用性、品質指標の約束 |
| ドキュメント | 使い方、サンプル、よくある質問 |
| サポート窓口 | SlackチャネルやJiraキュー |
| バージョン管理 | 後方互換性ルール、廃止予定通知 |
「データのテーブルを公開する」だけではData Productとは言えません。利用者が「使えるかどうか判断できる」「変更通知が届く」「壊れたときに連絡が取れる」状態まで整えて、初めて「製品」と言えます。
SLA設計：鮮度・可用性・品質
SLAはData Productの「契約」です。利用者は、これに基づいて自分のアプリやダッシュボードを設計します。
| 指標 | 定義の例 |
|---|---|
| 鮮度（Freshness） | 「日次バッチで、毎朝6時までに前日分が反映される」 |
| 可用性（Availability） | 「営業時間中、99.5%のクエリが3秒以内に応答」 |
| 品質（Quality） | 「主キーの一意性100%、null率1%未満」 |
| 変更通知（Change Notification） | 「破壊的変更は30日前にアナウンス」 |
SLAを明文化することで、Data Productの所有者は「守るべきもの」を持ち、利用者は「壊れたら相談できる窓口」を明確にします。品質運用はデータ品質ツール選定を参照してください。
ディスカバリビリティ：見つけてもらう
「製品」は使われなければ意味がありません。Data Productを利用者に見つけてもらうには、データカタログが中心的な役割を担います。
- カタログでの検索可能性：業務用語からテーブルが引ける
- ドメイン分類：「注文」「顧客」「商品」のような業務軸で整理
- タグ・分類：機密度、用途、SLAレベルなどで絞り込み
- 利用状況の可視化：「いま誰が使っているか」を表示
カタログツール（Atlan・DataHub・OpenMetadata）の選定はデータガバナンスとカタログツール選定を参照してください。Data Product運用の前提として、カタログ整備は不可欠です。
3種類のData Product
ドメイン駆動データで触れた3種類を、もう少し具体的に見ます。
| タイプ | 特徴 | SLAの傾向 |
|---|---|---|
| Source-aligned | 業務システムの直接の写像 | 鮮度重視、シンプルなスキーマ |
| Aggregate | 複数Source-alignedの統合 | 整合性重視、複雑なジョインの結果 |
| Consumer-aligned | 特定の用途に最適化 | 応答性重視、事前集計 |
多くのDataProductは「Source-aligned」から始まり、必要に応じてAggregate・Consumer-alignedが派生します。利用者の要望に応えるうちに、これらは自然に成長するでしょう。
変更管理：壊さない変更、壊す変更
製品にはバージョン管理が要ります。Data Productの典型的な変更分類は次のとおりです。
| 変更タイプ | 例 | 通知 |
|---|---|---|
| 後方互換あり（Additive） | 新カラム追加、新行追加 | 事前通知（軽微） |
| セマンティック変更 | カラム定義の意味変更 | 30日前アナウンス |
| 破壊的変更（Breaking） | カラム削除、型変更、テーブル削除 | 90日前アナウンス、移行サポート |
APIと同じ感覚で、Data Productにもバージョニング規約を持たせます。利用者は「いつまでに対応すれば良いか」「次のバージョンは何か」を明確に把握できる状態が、製品としての成熟と言えます。
「価格付け」というオプション
一部の組織は、Data Productに「内部請求（チャージバック）」の仕組みを導入します。利用部門が、利用量や利用権に応じて所有部門に内部請求します。これは強力な「製品意識」を生む反面、複雑な内部組織会計が必要です。中小規模では行いすぎないのが現実的です。
運用上のハマりどころ
- SLAが約束だけで運用されない：監視と通知の仕組みがないと、SLAは紙の上の合意に終わる。鮮度・品質の自動監視を組み込む。
- ドキュメントが古くなる：コードのコメントと同じく、ドキュメントは腐る。dbtのdescriptionとカタログを単一の真実とする運用が大事。
- 変更通知が形骸化：「30日前アナウンス」のルールがあっても、誰も読まなければ意味がない。SlackやJira等への自動通知を設計する。
- 利用者の声が届かない：所有者が利用状況を把握できないと、製品改善が止まる。利用統計と利用者ヒアリングのサイクルが要る。
まとめ
- Data Productはデータ＋メタデータ＋SLA＋ドキュメント＋サポートのパッケージ。
- SLAは「鮮度・可用性・品質・変更通知」の契約。明文化して監視と紐づける。
- ディスカバリビリティはカタログ整備が前提。利用者が見つけられない製品は使われない。
- 3種類のData Product（Source-aligned / Aggregate / Consumer-aligned）が自然に成長する。
- 変更管理（後方互換・セマンティック・破壊的）の規約と通知を組み込む。
全体像はデータメッシュ実装の現実、隣接はドメイン駆動データ・Federated Governance。Data Product運用の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. dbtモデルとData Productは同じですか？
A. 関係しますが同じではありません。dbtモデルは「変換ロジックの単位」、Data Productは「利用者向けに提供される製品の単位」です。1つのData Productが複数のdbtモデルで構成されることも、複数のData Productが同じdbtプロジェクト内に共存することもあります。「外部に見せる単位」と「内部の実装単位」を分けて考えると整理しやすいでしょう。
Q. Data Productの所有者はどう決めますか？
A. ドメインの責任者（業務マネージャー＋データエンジニア）の合議で決めるのが現実的です。「業務の意思決定者」と「技術的な実装者」がペアで所有することで、ビジネス文脈と技術品質の両方を担保します。所有者が不明確だと、SLA違反時の対応が遅れます。
Q. SLAが守れなくなったらどうする？
A. APIと同じです。インシデントとして対応し、利用者に通知し、再発防止を共有します。重要なのは「失敗を隠さない文化」で、SLA違反を恐れて目標を低くしすぎると、製品の価値が低下します。「現実的なSLA・透明性のある運用」が、Data Productの信頼を築きます。
Q. Data Productをツールで一元管理する方法は？
A. AtlanはData Productの概念を持ち、関連するテーブル・ダッシュボード・パイプラインをまとめて「製品」として扱えます。DataHubやOpenMetadataもDomain・Data Productの機能を強化中です。「Data Productの定義」を一箇所で管理し、SLAやドキュメントもそこに紐付ける運用が現実解です。詳細はデータガバナンスとカタログツール選定を参照してください。