ドメイン起点でのデータ分析基盤設計フレームワーク：第一弾

本記事では、読者として「データ分析基盤の構築に関わるPM」を想定し、「ドメイン起点によるデータ分析基盤の設計」を提案します。また、ソフトウェアエンジニアリングにおけるドメイン駆動設計（後述）を、データエンジニアリングの世界に輸入することを試みます。
それにより、アナリストとエンジニアの間で生じるコミュニケーションエラーや認識齟齬を軽減し、プロジェクトを推進できることが期待されます。

仮にあなたが、データ分析基盤構築のPMを任されたとしても、初動で何をすべきか、関係部署とどのように調整を進めるべきかの指針が得られるでしょう。

また、本記事は三部作を予定しており、第二、第三部は順次掲載する予定です。

目次

1．ドメイン駆動設計
2．問題提起
2-1．認識齟齬が生まれる原因
2-2．エンジニア、アナリストから見た現状の課題
3．前提
3-1．データ分析基盤とは何か
3-2．データ分析基盤はなぜ必要なのか
3-3．データ分析基盤を何に使うか
3-3．具体的にはどんな感じで分析しているの
4．新しいフレームワークの提案

1．ドメイン駆動設計

私は前職で、ドメイン駆動設計（Domain Driven Design、DDD）をベースに開発をしていました。DDDは「開発のやり方を、業務の関心事（ドメイン）起点にする」という思想を持つ開発手法で、プロジェクトと組織を長期的な成長体質に変化させます。
本記事では、DDDの考え方を用いて、アナリストとエンジニアの間で生じるコミュニケーションエラーや認識齟齬を減らし、互いの目的や立場を踏まえた上で、本当に必要なものを作り上げていくための方法論を提示します。

2．問題提起

データ分析基盤を作る上で、それぞれ担当者間のコミュニケーションエラーは許されません。担当者間でのコミュニケーションエラーは、必要なソフトウェアの実現を妨げ、その改修には途方もない労力が費やされ、ソフトウェアの品質や振る舞いに直結します。
しかし、コミュニケーションエラーの要因は、至るところに転がっています。

2-1．認識齟齬が生まれる原因

なぜ、コミュニケーションエラーが起きてしまうのでしょうか。
大きく分けて次の2つの要因があると考えます。

2-1-1．目的・役割の違い

当たり前のことですが、担当者ぞれぞれの目的・役割が違います。
それぞれが関心対象にマッチした独自の言語やフレームを使って仕事を進めます。
また、それぞれが異なる価値観で仕事をするため、他領域の仕事への理解は難しいでしょう。
その結果、「わからないことは全部担当者へ」のように他領域への干渉を避けようとすることも少なくありません。
エンジニアは、アナリストがどんな分析をやろうとしているかを深く知ろうとは思いませんし、アナリストも同様でしょう。

しかし、これがコミュニケーションエラーを引き起こす可能性を孕んでいるのです。
一方の要求や、願いを正しく汲み取ろうとしないことは、本当に必要だったものを作る上での障害になり得ます。

2-1-2．共通言語がないこと

目的・役割の違いと似ていますが、アナリストとエンジニアが独自言語やフレームを用いてコミュニケーションするコストは小さくありません。 日本語話者と英語話者がそれぞれの言語で会話をすることが難しいように、コードをベースとして会話するエンジニアと、分析用語をベースとして会話するアナリストのコミュニケーションコストは非常に大きいです。

上記のような常態化したコミュニケーションエラーが、本当に必要だったものを作ることを阻害するのは明らかです。担当者が協力して一つの必要なものを作る必要があるのに、それぞれが話し合う術を持たないことは、非常に危険なことです。

2-2．アナリスト、エンジニアから見た現状の課題

実際の現場では、どのような問題が生じているのでしょうか。
アナリスト・エンジニアの抱える課題を見てみましょう。

2-2-1．アナリスト: 望ましくないものが出来上がってしまっている

・データの散在
企業の規模に関わらず、この時代でデータが爆発増加し、データの種類も数多く派生したことによって、データは取ってきているが、いろんなところに散らかしていて、データ統合しようとしても、整理するのにかなり工数かかってしまい、分析するより基盤が整えられてない企業さんが多く見られます。

・データの分断
データの散在の話と同じく、基盤が整えられていない話ですが、すべてのデータを膨大な工数をかけて整理したところ、そもそも取ってきているデータが各自のルールで取得してきているので、データ型が異なったり、データを統合する共通のキーもないというデータが分断されていることがあります。

・属人化
よく聞く話で、特定のデータ（ex．会員情報）を使うには、セキュリティの関係で専門部署に依頼しないといけません。その部署も人のリソースの関係で、依頼したデータ抽出がなかなか返って来ず、分析が進みません。

・スピーディーに分析を開始できない
属人化の話と繋がっていますが、分析はいくつの仮設を立てた上でデータで検証するので、1回のデータ抽出だと分析結果を見い出せるかというと基本的には無理なので、スピーディーに仮設→データ抽出→検証というサイクルができないと、アナリストにとって、かなり苦痛です。

2-2-2．エンジニア: 何を作れば良いかわからない

・アナリストからの要求通りにシステムを作ったが、何度も追加実装を依頼される。
・アナリストがどんなものを作って欲しいかが、イメージできない。
・そのため、正常に動作するが、本当に正しいソフトウェアなのかどうかわからない。
・様々な制約（セキュリティ上、ゼロから作り直しになる等）が原因で、そもそも実装不可能な依頼を受けることがある。

3．前提

3-1．データ分析基盤とは何か

そもそも、データ分析基盤を使ったデータ分析とは何なのでしょうか。
一般的な、データベースを用いたソフトウェアと違うのでしょうか。

3-1-1．一般的なソフトウェアと、データ分析基盤の違い

データエンジニアリングは専ら、ビジネスサイドがデータドリブンな意思決定をする事を目的に、データ分析基盤を設計することを仕事としているため、プロダクト開発をユーザー起点で設計するソフトウェアエンジニアリングとは性質が異なります。
また、一般的なソフトウェアは、ユーザーアクションによりデータを操作（CRUD、新規追加・読み取り・更新・削除）するが、データ分析においてはデータの参照（読み取り）のみであるため、前提となる考え方は大きく異なります。

3-2．データ分析基盤は、なぜ必要なのか

そもそもデータ分析基盤はなぜ必要なのでしょうか？
一言でいうと、企業の競争力が優位に立てるように支えるためであり、膨大なデータを経営判断や新たな価値創造につながる情報として生み出すことにあります。

今までの「調達」、「製造」、「在庫」、「販売」のようなトラディショナルビッグデータに、消費者に関わる「ユーザー属性」、「アクセスログ」、「SNSデータ」などのエマージングビッグデータを加え、マーケティング全体最適化や顧客個別最適化に向けて、一貫性、正確性、安全性、適時性、有効性を持ったデータ分析基盤が必要となります。

3-3．データ分析基盤を、何に使うか

上記のようなデータ基盤が出来上がったら、どう活用すれば良いでしょう。筆者がいままで多く経験しているのは下記の3点になります。

①課題の発見
事業や各部門で立てたKGIやKPIに対して、現状は目標に対してどうなっていて、どのようなトレンドがあって、目標達成への阻害要因（ボトルネック）は何かのように課題の発見にデータ分析基盤を使います。経営陣に報告する事業部門の数値レポートをイメージしていただけるとわかりやすいかもしれません。

②施策のPDCA
・Plan：施策を実施する前に目標を立てるには、過去の施策データをもとに算出
・Do：ターゲットユーザーにアプローチするために、ターゲットにあった顧客情報の抽出
・Check：施策の良し悪しとその要因、または施策シナリオとの乖離などの検証
・Action：改善案の実施に当たる、必要とされるデータの抽出

③未来の予測
自社の過去データに市場のトレンドや天気、位置情報などの外部データに加えて、「1年後にどのような商品が売れて、どのようなニーズがあるのか？」など情報を効果的に分析し活用することで、未来をある程度予測することができるようになると、業務の効率やビジネスのスタイルそのものも大きく変化する可能性があります。日本ではまだそのような事例が少ないですが、これから3〜5年は予測の精度が高まる期待はできると思われます。

3-4．実務におけるデータ分析の流れ

アクセス解析を例としてユーザー分析の流れを図示しました。
Google Analytics（以下、GA）等を用いて、データ分析をする場合は、基本的なデータ分析のためのコンソール画面は、Google側のサイトから閲覧可能ですが、企業のもつ属性情報などを紐づけて分析したい場合は、必要に応じてデータ整形を行ったり、DB/DWHに対して会員情報の突合を行う必要があります。
図2-データ分析の流れは、時系列順に、データ取得からデータ分析までの流れを表現したものです。

図1-データ分析の流れ

4．新しいフレームワークの提案

本記事では、上記の課題を解決するため、次のようなフレームワークを提案します。役割ごとに、誰とどのようにコミュニケーションしていくべきか、その際にはどんなドキュメントが必要なのかを、ドメイン起点で表現しました。二部以降では、図2-データ分析基盤における設計の流れをベースに理想的なコミュニケーションと資料の作り方について説明します。

図2-データ分析基盤における設計の流れ

最後に、第二弾では提案したいフレームワークに登場する人物をイメージしやすくするために、詳しく説明し、第三弾では我々が提案したいフレームワークを活用できるように、詳細内容と活用方法を説明していきます。
次回の投稿をお楽しみに。

参考

・cf．[ドメイン駆動設計によるシステム開発 生産ラインのイノベーション]
・『エリック・エヴァンスのドメイン駆動設計』, エリック・エヴァンス, 翔泳社, 2013. Accessed 18 January 2022.