BIツールを導入する前に、解決すべき問題がある
企業の中には、すでに大量のデータを保有しているにもかかわらず、経営やマーケティングの意思決定に十分活用できていないケースがあります。
たとえば、
* 複数のシステムにデータが分散している
* 部門ごとに同じ指標の定義が違う
* 必要なデータがそもそも取得されていない
* Excelで毎回集計している
* ダッシュボードごとに数字が異なる
* データを出すたびにエンジニアへの依頼が必要
* データ量の増加によって処理が遅くなっている
といった状態です。
このような課題に対して、いきなりBIツールを導入しても、十分な成果は得られません。
元のデータが整理されていなければ、見た目のきれいなダッシュボードを作っても、その数字を信用できないからです。
必要なのは、
**データを集める
→ 整える
→ 蓄積する
→ 指標を定義する
→ 可視化する
→ 運用する**
という一連の仕組みです。
Sekimosoft合同会社では、データレイクやDWHが未整備の状態から、複数データベースの統合、ETL、DWH、BIダッシュボード、運用コスト最適化までを一気通貫で考えるデータ分析基盤の設計を行いました。
本記事では、その考え方とシステム構成について紹介します。
> 本事例について
>
> 本記事は、Sekimosoft合同会社が複数DB環境からのデータ統合、DWH・ETL・BI活用を題材に行った、自社開発検討・アーキテクチャ設計事例です。
>
> 特定の顧客企業から受託したプロジェクトではありません。
>
> 実際の導入時には、既存システム、データ量、更新頻度、必要なKPI、セキュリティ要件、運用体制などを確認した上で個別に設計します。
企業には多くのデータが蓄積されています。
顧客情報。
契約情報。
利用履歴。
アクセスログ。
問い合わせ履歴。
売上情報。
広告データ。
サービス内の操作ログ。
しかし、データが存在しているだけでは、分析には使えません。
たとえば、同じ顧客が複数のシステムで別のIDを持っている場合があります。
あるシステムでは会社名が正式名称。
別のシステムでは略称。
別のシステムでは担当者名だけ。
この状態では、同じ顧客の情報を正しく統合できません。
また、
「売上」
「有効顧客」
「継続利用」
「コンバージョン」
といった指標の意味が、部門ごとに違うこともあります。
そのため、BI基盤を作る際には、最初にダッシュボードを作るのではなく、
データがどこにあり、どのような意味を持ち、何が不足しているか
を整理する必要があります。
添付RFIでも、複数DBの調査、不足データの特定、標準化、名寄せ、クレンジング、ETL、DWH、BI、運用最適化までを段階的に構築する構成が想定されています。
まず、データの棚卸しを行う
BIプロジェクトの最初の工程は、画面設計ではありません。
確認するのは、
* どのシステムに
* どのデータがあり
* 誰が管理し
* どの頻度で更新され
* どの程度の量があり
* 何に使われているか
です。
たとえば、
顧客データ
顧客ID、会社名、契約状況、利用プランなど。
利用データ
ログイン、機能利用、操作履歴、継続率など。
マーケティングデータ
流入元、広告、キャンペーン、問い合わせなど。
売上データ
受注、請求、入金、解約など。
システムログ
エラー、処理履歴、操作イベントなど。
これらを整理します。
その上で、
分析したいのに取得できていないデータ
も確認します。
たとえば、
「どの機能を使った顧客が継続しやすいか」
を知りたいのに、機能利用ログを記録していなければ分析できません。
つまり、BI基盤構築では、
既存データを集めるだけでなく、今後何を記録すべきかを決めること
も重要です。
分散したデータを一度整理する
複数のデータベースを直接BIツールへ接続する方法は、短期的には簡単に見えます。
しかし、システムが増えるほど問題が起きます。
* 同じ項目の名前が違う
* データ型が違う
* 時刻の基準が違う
* 更新タイミングが違う
* 削除済みデータの扱いが違う
* 同じ顧客を別のIDで管理している
この状態で直接集計すると、ダッシュボードごとに独自の修正処理が増えていきます。
その結果、
同じ会社の中で、同じ指標なのに数字が違う
という問題が起きます。
そこで、データを直接BIへ渡すのではなく、
**収集
→ 整形
→ 標準化
→ 蓄積
→ 分析**
という段階を作ります。
今回の設計では、データの流れを大きく四つに分けます。
データソース
元となるデータです。
たとえば、
* 業務データベース
* 顧客データベース
* サービス利用データ
* 操作ログ
* システムログ
* 外部サービス
などです。
収集・加工
複数のデータを取り込み、
* 抽出
* 変換
* 型の統一
* 名寄せ
* クレンジング
* 不要データの除外
を行います。
蓄積・分析基盤
加工前のデータと分析用データを保存します。
AWSを利用する場合は、
* Amazon S3
* Amazon Athena
* 必要に応じたETLサービス
などを組み合わせる構成が考えられます。
可視化
整えたデータをBIツールで可視化します。
たとえば、
* Amazon QuickSight
* その他のBIツール
などを利用します。
重要なのは、特定のサービスを使うことではありません。
役割を分け、将来変更できる構造にすること
です。
ETLは、単にデータを移動する処理ではありません。
本当に難しいのは、
異なるシステムのデータを、同じ意味で扱える状態にすること
です。
たとえば、
あるシステムでは、
active
別のシステムでは、
契約中
別のデータでは、
1
となっているかもしれません。
技術的にはすべて取り込めます。
しかし、そのままでは一つの指標として集計できません。
そこで、
* 項目名
* データ型
* ステータス
* 日付形式
* タイムゾーン
* 単位
* ID体系
を揃えます。
この工程を曖昧にすると、後から修正コストが増えます。
BI基盤で最も重要なのは、データ量ではありません。
データの意味が揃っていること
です。
データ基盤構築では、設計や開発以外にも多くの作業が発生します。
たとえば、
* 表記揺れの修正
* 重複データの整理
* 欠損値の確認
* 不正なデータの除外
* 古いコード体系の変換
* マスタの統合
です。
これらは見積もり時には見えにくいため、
隠れコスト
になりやすい部分です。
そのため、今回の設計では、データ整備を一度きりの作業として扱いません。
できるだけ、
* ルール化する
* 自動化する
* エラーを記録する
* 修正履歴を残す
* 再実行できるようにする
ことを重視します。
たとえば、会社名の表記揺れを人が毎月修正するのではなく、変換ルールやマスタを持つ。
異常データを黙って除外するのではなく、確認対象として残す。
このように、
人が毎回直さなくてもよい仕組み
を作ることが、長期的な運用コスト削減につながります。
DWHを作る目的は、データを保存することではありません。
重要なのは、
会社の中で共通して使える数字を作ること
です。
たとえば、
* 顧客数
* 新規顧客数
* 継続率
* 解約率
* 売上
* 利用率
* コンバージョン率
などです。
これらの数字を、部署ごとに別の方法で計算すると、会議のたびに、
「どちらの数字が正しいのか」
という議論が起きます。
DWHでは、
この指標は、このデータを、この条件で計算する
という基準を揃えます。
すると、マーケティング、営業、経営、開発が同じ数字を見ながら話せるようになります。
BIツールでは、簡単に多くのグラフを作れます。
しかし、グラフが多いほど意思決定が速くなるわけではありません。
最初に必要なのは、
何を判断するための画面なのか
を決めることです。
たとえば、経営者向けであれば、
* 売上
* 顧客数
* 継続率
* 主要サービス利用状況
など。
マーケティング担当者向けであれば、
* 流入
* 問い合わせ
* コンバージョン
* キャンペーン成果
など。
プロダクト担当者向けであれば、
* 機能利用
* 継続利用
* 離脱ポイント
* エラー状況
などです。
全員に同じダッシュボードを見せるのではなく、
役割ごとに、次の判断に必要な情報を見せる
ことが重要です。
データ基盤では、リアルタイム処理が高度に見えます。
しかし、すべてのデータをリアルタイム処理すると、コストと複雑さが増えます。
実際には、
準リアルタイム
* 障害状況
* 重要な操作イベント
数時間単位
* マーケティング指標
* 利用状況
日次
* 経営KPI
* 顧客分析
月次
* 長期トレンド
* 経営レポート
のように分けられます。
必要な鮮度に合わせて処理頻度を変えることで、
必要な情報速度とインフラコストを両立
できます。
BIツールの役割は、データをきれいにすることではありません。
BIは、
整理されたデータを、意思決定できる形で見せる場所
です。
たとえば、
* 主要KPI
* 前月比較
* 異常値
* セグメント比較
* 詳細分析
などを表示します。
良いダッシュボードは、数字を並べるだけではありません。
利用者が、
「何が起きているか」
「どこを見るべきか」
「次に何を調べるべきか」
を理解できる構成にします。
近年のBIツールには、
* 自然言語での質問
* 自動チャート生成
* 要約
* 異常傾向の提示
などのAI支援機能があります。
これらは有効です。
しかし、データ基盤が整っていない状態でAIを使っても、正しい分析にはなりません。
データの意味が違う。
欠損が多い。
KPI定義が揃っていない。
この状態では、AIが速く回答しても、その回答を信用できません。
順番は、
**データ品質
→ KPI定義
→ DWH
→ BI
→ AI支援分析**
です。
AIは、正しいデータ基盤の上で初めて価値を発揮します。
大規模なデータ基盤を一度に完成させようとすると、時間とコストが大きくなります。
そのため、段階的に進めます。
Phase 1：要件整理・データ基盤
最初に、
* データソース調査
* 不足データ特定
* KPI整理
* 標準化ルール
* ETL
* データ蓄積基盤
を整えます。
最初からすべてのデータを対象にする必要はありません。
重要なKPIに必要な範囲から始めます。
Phase 2：BIダッシュボード
次に、
* BI環境
* KPI可視化
* 部門別ダッシュボード
* 必要に応じたAI支援分析
を構築します。
Phase 3：運用・最適化
本番稼働後は、
* インフラコスト
* データ量
* 処理時間
* エラー
* データ整備工数
* 利用状況
を確認します。
そして、不要な処理や手作業を減らします。
複数DBと大量データがある場合、最初から全データを統合しようとすると、プロジェクトが長期化します。
そこで、
一つの重要な意思決定テーマから始める
方法が有効です。
たとえば、
* 顧客獲得
* 継続率
* サービス利用
* 売上
の中から一つを選びます。
そのKPIに必要なデータだけを集めます。
まず一つのダッシュボードを実際に使える状態にします。
その後、
* 新しいデータソース
* 新しいKPI
* 新しい部門
へ広げます。
この方が、早い段階で価値を確認できます。
今回のデータ分析基盤は、次の流れで構成します。
複数の業務データベース
＋
操作ログ・システムログ
↓
データ収集
↓
変換・標準化・名寄せ・クレンジング
↓
データレイク・DWHへ蓄積
↓
分析用データを作成
↓
BIダッシュボードで可視化
↓
AI支援による分析
↓
経営・マーケティング・業務改善へ活用
重要なのは、
BIツールだけを作らないこと
です。
元となるデータから、最終的な意思決定までを一つの流れとして設計します。
ダッシュボードを10個作る。
グラフを100個表示する。
それ自体には大きな意味はありません。
重要なのは、
* 集計時間が減ったか
* 数字の確認作業が減ったか
* 部門間の認識差が減ったか
* 意思決定が速くなったか
* 改善すべき場所を発見できたか
です。
データ基盤は、データを保存するためのシステムではありません。
意思決定を速く、正確にするための仕組み
です。
Sekimosoft合同会社は、BIツールを導入すること自体を目的にしていません。
S3。
DWH。
ETL。
QuickSight。
AI分析。
これらはすべて手段です。
重要なのは、
データによって、どの判断が変わるのか
です。
どの顧客が継続しているのか。
どこで利用者が離脱しているのか。
どの施策が成果につながっているのか。
どこに改善余地があるのか。
その判断を支えるために、
データを集め、
整え、
定義を揃え、
見えるようにします。
BI・DWH・データ分析基盤についてご相談ください
次のような課題がある場合は、ご相談ください。
* 複数のデータベースに情報が分散している
* Excelで毎回集計している
* 部門ごとに数字が異なる
* BIツールを導入したが活用できていない
* データレイクやDWHをどこから作ればよいか分からない
* AWS環境で分析基盤を構築したい
* データ標準化やクレンジングの負担を減らしたい
* ダッシュボードの運用コストを抑えたい
* AIを使った分析環境を整えたい
最初からすべてのデータを整理する必要はありません。
まず、どの判断を速くしたいのか。
そこから逆算して、必要なデータと仕組みを設計します。
Sekimosoft合同会社は、現状整理、KPI設計、データ統合、ETL、DWH、BI、運用改善までを一気通貫で支援します。
