DXの一丁目一番地「データ整備」、JDSCが実際に整備してみた
アドベントカレンダー日程表
こちら日程表になります。他記事にも飛べますのでぜひご覧くださいませ！
昨今話題のDX。まずは「データ整備を」というけれど、「データを分析・活用しやすい形にする」とか聞くけれど、具体的にどんなことをするの？と思う方も多いのではないでしょうか。今回は、JDSCが実際にクライアントのデータを統合した事例を基に、何をやったのかを紹介します。
前提
今回紹介する事例の概要
データ整備の目的：顧客獲得のためのデジマ効率化
ソリューション：顧客データ統合基盤、デジマ支援機能の構築
ユーザー：某企業のマーケティング担当者、顧客応対担当者
顧客：某企業のサービス利用者、および利用可能性のあるリード顧客
この記事で分かること
「データ整備をしよう！」と決まったら、まず何から取り掛かればよいか
データが整備されるまで、何が・どのような順序で進んでいくのか
この記事では触れないこと
データ統合基盤等のアーキテクチャや実装上のTips
※本件はGCPのサービスをベースに構成しています。技術詳細については、別記事をお待ちください！
データ整備のステップ
Step1. ユーザーストーリーマップによる要件の具体化
まずはじめに、対象ユーザーは誰なのか、何をしたいのか、を具体的にする必要があります。いわゆる要求分析です。
今回は、要求分析でよく用いられる「ユーザーストーリーマップ」のフレームを使って、クライアントのユーザーと一緒にやりたいことを洗い出すところからスタートしました。デジタルマーケティングの効率化ということで、シーンをPDCAサイクルをベースに定義し、それを軸に整理をしていきました。
Step2. 顧客獲得ファネル・KPIの定義
次に、やりたいことをデータを使ってどう実現するか？をより具体的にしていきます。
マーケティングの対象となる顧客が、ゴールである「顧客獲得」に向けてどのような動きをするのか、それはどのような指標（KPI）で測定できるか、をスプレッドシートで整理しました。
ここまで書いてみると、どんなデータを対象として整備すればよいかが分かってきます。整理したKPIを測定するためには、どんなデータが必要か？を、システム→テーブル→カラムのレベルで特定していきます。
Step3. アウトプットの画面イメージ作成
Step2で定義した獲得ファネルとKPIを、実際に業務で利用する際にどのような形や色で画面表示させたいか、イメージを膨らませていきます。
この事例では、BIツールとしてOSSのMetabaseを採用しました。画面イメージは、早々に開発用Metabaseを構築してしまって、サンプルデータを繋ぎこんでデモ画面をつくり、それを見ながらクライアントと議論して要件を固めていきました。クライアントと対峙するPMの方は、BIツールに関してはエンジニア任せにせず自分で操作できたほうが要件の議論がスムーズ化と思います。無償版Metabaseですが、今回の分析・可視化系の要件は概ね満たすことができました。
データ統合基盤に各システムから連携されているデータを使用しているので、各データのソース（どのシステムのものか）や鮮度（連携頻度に応じて決まる）について、この段階ですり合わせておく必要があります。特に、従来のOLTP（OnLine Transaction Processing）の業務システムに慣れ親しんでいるユーザーは、データがリアルタイムではないという点をイメージしづらい場合があるので、注意が必要です。
Step4. 分析用テーブル・クエリ設計
要件が固まったら、データ統合基盤の主役であるテーブル・クエリ設計に入ります。本件では、以下3種類のテーブル・クエリを構築しました。（図4参照）
①元データと同じスキーマのテーブル
基本的に、全てのベースとして元データの構造をそのまま取り込んだテーブルを用意します。日次連携することにしたので、日々のデータが蓄積していくようにしました。
要件の大部分は、これらを顧客ID等のキーを使って紐づけることで実現できます。
②元データを加工した分析テーブル
アプリケーションが生成するトランザクションデータと、分析の際に知りたい情報は異なっている場合も多いです。要件の中には、元データをそのまま使用できないものもあります。そういうものは、データ統合基盤の中でデータを加工し、分析目的のテーブル（分析テーブル）を作成しました。
通常のトランザクションデータでは表現できないものとしては、例えば以下のようなケースがあります。
● ある特定の時点の顧客や事業の状態を表すもの（ある日時点の、その瞬間のアクティブな顧客数 等）
● 複数の情報から、ある特定のルールで「正」の情報を一意に決めるもの（ある顧客の興味のあるサービスが複数登録されている場合、どれをその顧客のセグメンテーションに利用するか？等）
これは、データを意味のある形に整える、まさに「整備」の作業です。「このようなデータは、こういう意味と見做す」といったデータの意味づけ定義をしっかり行うことが重要になります。
③上記①②のテーブルを参照するビュー
最終的に、ユーザーに利用される形に最も近いテーブルをビューとして作成します。ビューは、テーブルと違って常に最新の情報を、クエリに従って表示できます。
ビューには、Step2や3で必要となったデータ項目が全て含まれている必要があります。Step3で触れたMetabaseに繋いだのは、③のみです。
Step.5 実装とチューニング
設計に従って実装し、画面に表示してみると、想定とは違う見え方になることもあります。例えば、以下のような変更要望は頻出です。
過去履歴は5年分表示したいと思っていたが、実装してみたら履歴が多すぎて画面が見づらくなってしまった。表示対象を絞りたい
業務シミュレーションをしてみたら、分析テーブルを作成して表現したデータについて、別の項目を使った方が理にかなっていると気が付いた。「●●日付」ではなく、同じテーブルの「▲▲日付」を基に加工したい。
こういうデータは、業務上のローカルルールで設定したダミーコードなので、分析対象から除外したい。
特に、まだ現行業務がデータに基づくかたちになっていない場合は、実際にモノが出来上がってみないと本当の要件が定まらないことも多々あります。実装後に変更が入ることを前提に開発した方がいいです。
おわりに
データと向き合う仕事をしていると、データ活用をするには「自社のデータは汚い・足りない」と感じる場面が多くあると思います。しかし、そもそもOLTPはアプリケーションが動くための/動いた結果のデータであって、ビジネスにそのまま利用することは想定されていないので、そう感じて当然かもしれません。
逆に、データをきれいにしようとして、アプリ開発においてデータ分析を意識しすぎると、アプリケーションの使いやすさや運用保守性を犠牲にしてしまうリスクがあります。データが足りないとか汚いとかいう理由で、アプリ側を改修することは必ずしも最適解にはならないと考えますので、慎重に検討したいところです。
データが汚い・足りない状況でこそ、ひと手間かけてデータ統合基盤をつくるメリットが大きいです。データ統合基盤（OLAP：Online Analytical Processing）を、上記の5Stepで目的に合わせて構築できれば、各段にデータが活きるようになり、進化していき、DXの世界に進んでいきます。元データをキレイにするよりも、あるものを整備することから始めてみては如何でしょうか。