データエンジニアリングとドメイン駆動設計

Data Engineering Study #36「"良いデータモデル"は、どこから生まれるのか」で発表した資料です。

概要

①非集中型データアーキテクチャ「データメッシュ」
②なぜ非集中型を採用するか？
③非集中型にした場合、全体最適をどうするか？

Transcript

1. Data Engineering Study #36「"良いデータモデル"は、どこから生まれるのか」 データエンジニアリングと ドメイン駆動設計 2026年7月22日 有限会社システム設計 増田 亨
2. 自己紹介 著書(2017) ＊１ 増田 亨（masuda220） 専門領域 訳書(2024) • 業務系アプリケーションの開発 ＊2 最近の仕事 • 大きな泥団子退治のお手伝い • エンジニアの設計スキル向上のお手伝い *1 増田 亨(2017) 『現場で役立つシステム設計の原則』技術評論社 *2 Vlad Khononov(著) 増田 亨、綿引 琢磨(訳) 2024 『ドメイン駆動設計をはじめよう』オライリージャパン 2
3. お話しする内容 ① 非集中型データアーキテクチャ「データメッシュ」 ② なぜ非集中型を採用するか？ ③ 非集中型にした場合、全体最適をどうするか？ 3
4. 非集中型データアーキテクチャ ①データメッシュ 4
5. 第１６章 データメッシュ 16.1 分析系データモデルと業務系データモデル 事実テーブル/特性テーブル/分析系モデル 16.2 分析系データの管理基盤 データウェアハウス/データレイク/ データウェアハウスとデータレイクの課題 16.3 データメッシュ データを業務の視点で分解する/データをプロダクトと 考える/自律性を高める/エコシステムを構築する/ データメッシュとドメイン駆動設計を組み合わせる 5
6. データエンジニアリングライフサイクル データ生成 データソース 業務プロセス実行系の アプリケーション データ提供 データ利用 データの抽出 モデルの変換 利用者への提供 意思決定支援 機械学習 業務プロセス実行系に フィードバック 6
7. データメッシュのデータ管理モデル 業務プロセス実行系の アプリケーション開発チームA 業務プロセス実行系の アプリケーション開発チームB データ利用 データ利用 データ生成 データ提供 データ プロダ クト データ プロダ クト データ生成 データ提供 データ所有権を分散し、データプロダクトを相互に提供する 7
8. データメッシュ 販売促進 生成 入荷物流 生成 利用 提供 利用 提供 商談 生成 注文処理 生成 利用 提供 利用 提供 顧客 サポート 生成 出荷物流 生成 利用 データ プロダ クト 提供 利用 提供 業務単位の開発チームがデータを所有しデータプロダクトを提供 8
9. データプロダクトを提供する • ビジネス上の特定の課題を解決するために、データを パッケージ化する • 商品のように、商品内容の説明、取り扱い方法、品質 保証、アフターサービスを提供する • データソースのアプリケーション開発チームが、所有 するデータを使って、他チームのニーズに合わせたプ ロダクト（データパッケージ）を提供する 9
10. ②なぜ非集中型を採用するのか？ 10
11. 非集中型のデータメッシュを採用する理由 ① 目的適合性の向上 ② 発展性の向上 ③ 安全性の向上 11
12. 目的適合性の向上 • データソースの業務活動に精通し、データの正しい意 味を熟知するチームが、データの提供に責任を持つ • データを利用したい業務分野のニーズを深く理解して いる開発チームが、分析用データのニーズをデータ ソースを所有するチームに提示する • ソースデータの意味と特性を理解した提供側チームと データの利用目的を深く理解した利用側チームが意図 を伝達し合うことで、高度なデータ活用ができる 12
13. 発展性の向上 • 提供するデータの品質保証レベルがあがる • データソースのデータモデルは、提供するデータパッ ケージとは独立して進化可能 • 提供するデータパッケージのデータモデルは、データ ソースのデータモデルとは独立して進化可能 • 提供と利用の組み合わせの変更が柔軟で、データの活 用方法を発展させやすい 13
14. 安全性の向上 • データ管理の境界を明確に定義できる • データ管理の責任はデータ提供側が持つ • 境界をまたぐデータ移動をより安全により適切に制御 できる 14
15. ③非集中型と全体最適化 15
16. 非集中型にした場合、全体最適をどうするか？ • 目指す方向の一致と設計判断の一貫性 • 効率化（ムリ・ムダ・ムラの検知と除去） 16
17. 目指す方向の一致と設計判断の一貫性 • 事業目的適合性に焦点を合わせる • より具体的には事業活動を構成するさまざまな業務領 域を、競争優位を生み出す中核の業務領域と、他社と 同じでよい一般の業務領域に分類する • 中核の業務領域は独自モデルとその実装を探究しつづ ける • 一般の業務領域は、一般モデルをそのまま流用し、実 装はできるだけ簡略に済ませる 17
18. ソフトウェアの実装と 事業戦略を結びつける さまざまな経験則 18
19. どうやって事業戦略と結びつけるか？ ソフトウェア開発の対象業務を２つの軸で４分類して、 カテゴリーごとに適切な設計方針を選ぶ 横軸：競合他社との差別化への影響度 縦軸：業務ロジックの複雑さ（開発の難易度） 19
20. 他社と同じ 自社独自 一般の 業務領域 中核の 業務領域 一般 または 補完 補完的な 業務領域 業務ロジック の複雑さ 競合他社との差別化 20
21. 他社と同じ 自社独自 一般の 業務領域 中核の 業務領域 一般 または 補完 補完的な 業務領域 業務ロジック の複雑さ 変更容易性の 改善に継続的に 取り組む 競合他社との差別化 21
22. 模倣または 購入を検討 他社と同じ 自社独自 一般の 業務領域 中核の 業務領域 一般 または 補完 補完的な 業務領域 業務ロジック の複雑さ 簡略に 済ませる 競合他社との差別化 22
23. 業務領域のカテゴリーと開発方針 中核 一般 補完 競争優位性 ◎ × 〇 複雑さ ◎ ◦ × 変化 ◎ × △ 内製開発 模倣または 購入 CRUD/ETL機能 簡易開発 開発方針 23
24. 効率化(ムリ・ムダ・ムラの検知と除去) • データプロダクトの企画と実装で、事業目的適合性を 評価して優先順位を決め、設計判断する • チームAとチームBが話し合う過程で、事業目的適合性 をどう捉えているかを言語化し、チームの判断と行動 の事業目的適合性をあげていく • 中核は発展性に価値 継続的に学習し育成する • 一般はできるだけ簡略にすませることに価値 • 事業目的から外れる企画はやらない決断 24
25. 技術課題を効率的かつ効果的に解決 • データエンジニアリングの実践コミュニティを立ち上 げ、継続的に活動する • データエンジニアリングの課題解決に必要な知識と技 能を継続的に学習するための自発的なコミュニティ • 組織や役職からは独立した、技術者の学習共同体 • 現場のリアルな課題感、課題解決の経験談（成功と失 敗）をざっくばらんに話し合える場を定期的に持つ 25
26. ボトムアップを効果的に促進する • 競争優位性（顧客が自社の製品を選ぶ理由）は、どこ にあり、どうやればその優位性を維持・強化できるか を、全社的に問い続け、立場や経験の違いによる異な る見方を積極的に持ち寄ることで、方向性を創発する • 組織や役職から離れた学習共同体の活動を組織として 支援する • こういうやり方が、中央集権的なルール作りとその徹 底よりも、効率的で効果的 26