{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.text}}
メッシュアーキテクチャが切り開く新たなデータアナリティクス～第3回データプロダクトの定義とドメインが担う役割
2022-10-10
ドメインから組織に価値を拡大していくために
前回のコラムでは近年、データ活用がドメイン単位で行われるようになった背景と、ドメインが自身で持つデータやアナリティクスを他のドメインに共有し、利用できるようにすることの便益について説明しました。
各ドメインが相互接続をしながら企業全体でアジリティの高いデータ活用を推進していくためには、各ドメインがサイロ化することなく、他のドメインが使いやすく信頼できるデータを提供していく必要があります。
第3回は、「データプロダクトの定義とドメインが担う役割」と題して、データプロダクトの特徴を改めて説明し、各ドメインが当事者意識を持ちながら組織全体で得られる価値を最大化するために担うべき責任範囲と持つべきスキル・人材について紐解いていきます。
データプロダクトの考え方
メッシュアーキテクチャではデータをプロダクト(＝製品)として捉え、ドメイン自身が提供するデータプロダクトに責任を持ちます。企業が自社の製品やサービスに細心の注意を払い、先見性を持ちながら開発・管理していくのと同じように、データプロダクトのオーナーであるドメインが自身の提供するデータプロダクトに責任を持つことは不自然なことではありません。
ここで言うデータプロダクトとは、クレンジングされたトランザクションリストや月次レポートと言った単純なものから、複雑なETLプロセスや高度な分析から得られたデータセットまで、多岐にわたります。また、データプロダクトの中にはデータ単体だけではなく、関連するメタデータ、コード、AIアルゴリズムとそのパラメータ、システム、ドメインが持つ専門知識を含みます。具体例として不正検知システム、レコメンドシステム、販売予測システムおよびそれらから得られるデータセットが代表的なデータプロダクトです。
データプロダクトは他のドメインからも利用されるため、見つけやすい、理解しやすい、アクセスしやすい、信頼性がある、セキュリティ保護されており安全であると言った特徴を兼ね備えるべきです（図1参照）。
ドメインの責任範囲
データをプロダクト(＝製品)として捉える以上、各ドメインはデータプロダクトのみならず、そのライフサイクル全般にも責任を持つ必要があります。具体的にはデータの処理・準備を実現するパイプライン・ETL機能、データおよびモデルの品質、別ドメインの利用者が使えるようなデータ提供機能(APIやデータベース)、検索性を担保するメタデータ管理(カタログ機能)、適切な権限設計によるアクセスコントロールが該当します。
データプロダクトの品質保証においては、従来のソフトウェア／ハードウェア開発における品質管理手法がそのまま適用できない点に難しさがあります。システム（ソフトウェア／ハードウェア）の品質に加えて、データの品質、モデルの品質、運用の品質まで拡張して検証する必要があり、これを各ドメイン独自の方法でやっていたのでは組織全体で安定した品質は得られません。品質評価ガイドライン・評価手法は中央が提供し、ドメインはそれに準拠する形で品質を担保していく役割分担が望ましいでしょう（図2参照）。
各ドメインに求められるスキル・人材
このようなタスクを引き受けるために、ドメインチームには、データプロダクトのライフサイクル全般を理解し品質に責任を持つ「プロダクトオーナー」、業務面でプロダクトの企画・開発を推進する「データプロダクトマネージャー」、技術面でそれを支援する「データアーキテクト」「データエンジニア」「データサイエンティスト」「データスチュワード」といったロールを配置する必要があります。従来のソフトウェアエンジニアはプロダクト開発の経験・知識を持つべきで、ビジネスアイデアの企画・構想からそれをプロダクトの実装に落とし込める、より幅広いスキルセットが求められます（図3参照）。
各ドメインにこれらのスキル・人材を配置することはメッシュアーキテクチャを実現するための必須条件と言えます。その一方で、全てのドメインが同質の人材・スキルを持つことは現実問題として困難であり、組織で標準のツールを提供する、一部は共通ガバナンスを効かせるなど、中央とドメインでのバランスの取れたロール分担やサポートを行うことが成否を握る鍵となります。
ドメイン間連携の具体例
さらに、データプロダクトの企画・開発・保守の全てを各ドメインでエンドツーエンドで運用するには多大なコストがかかります。共通化できるプロセスを各ドメインそれぞれが行っている状況は、組織全体のイノベーションの質・スピードを低下させ、新しいデータプロダクトを構築する時間を奪うことにもなり得ます。そこで必要になるのがプラットフォーム機能・ルールの共通化です。
具体例としては、在庫管理を担うドメインが提供するデータプロダクトを使い、マーケティングドメインがキャンペーンを検討する、あるいは営業ドメインが受発注を行うといったシーンの中で、各ドメインが提供するデータプロダクト開発の標準テンプレートを提供する、あるいは運用ルール設計に中央が関与する、セルフサービス型のデータインフラストラクチャーを提供するといった方法が考えられます。このように中央・ドメイン間で分散型統治の形をとることで、責任の一部を相互に負担でき、組織全体のコストを大幅に軽減できるのです。
次回は、各ドメインが自律的にデータプロダクトを開発・維持していくために中央が担うべきプラットフォームとしての機能・必要なサポート体制についての理解を深めていきます。
{{filterContent.facetedTitle}}
{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{contentList.loadingText}}
{{filterContent.facetedTitle}}
{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.text}}
{{contentList.loadingText}}
