はじめに
こんにちは。
レバレジーズデータ戦略室、データアーキテクトグループの鵜飼です。
今回は、1年前に私が投稿した記事『データ分析基盤再整備プロジェクトの全貌』のその後についてお話をできればと思います。
データ分析基盤を再構築していく中で、前回の記事から変わった点や、新しいアーキテクチャを導入して良かったこと・大変だったこと等を共有できればと思いますので、これからデータ分析基盤の再構築を検討している方の参考になれば幸いです！
前回の記事から変わったこと
実装をしていく中で、想定していたアーキテクチャでは要望を実現できないことが何度かあり、都度アーキテクチャの変更を検討しながらデータ分析基盤を再整備していったので、前回記載した内容からの変更点についてご紹介できればと思います。
プロジェクトの概要や詳細なアーキテクチャの説明は、前回の記事をご覧いただけますと幸いです。
connection_to層の追加
セマンティックレイヤーとBIツールの間に新たに層を追加し、このレイヤーのことをconnection_to層と命名しました。
役割として、BIツールで可視化を行うためにセマンティックレイヤーのデータを絞り込むことで、サービス登録日のような特定の基準となる日付やKPIのグループ別にデータを分割しています。
以前は基準日別にセマンティックレイヤー層に複数テーブルが存在していたのですが、同じKPIについて複数テーブルで計算してしまっていたので、KPI定義に変更があった際に改修コストがかかったり、改修漏れが起こるリスクがありました。
また、基準日別でテーブルを作成していても、データ量が多すぎてTableauにデータ接続できない問題もあったため、KPIをグループ化して基準日とあわせて分割しています。
KPIを定義し計算を行う役割はセマンティックレイヤーに一任することで、改修コストを下げ、KPI定義が確実に統一されることを実現しています。
シングルシステムDWHのワイドテーブル作成を任意化
レバレジーズでは事業毎に異なるSFAツールを使用しており、システムのDB構造によってはレコード数が爆増してしまう等、ワイドテーブルを作成することでのデメリットが発生する事業も複数あったため、本ルールは任意となりました。
本アーキテクチャを導入して良かったこと
KPI定義の統一ができた
当初の目的通り、KPI定義を一箇所にまとめたことでKPI定義の認識が揃い、数値のずれが大幅に減少しました。
まだ独自でモニタリングを作成している人も多くおり、Tableauとの差分について問い合わせが来ることもありますが、データ分析基盤再整備前よりは確実に減少していますし、データ定義が一覧で見れるKPI定義一覧を作成したことでどちらが正かがはっきりしていているため、関係各所に確認する必要がないことも大きなメリットです。
モニタリング納品スピードの大幅改善
モニタリングに使用する基本的なデータソースをすべて活用しやすい形でTableauにデータソース接続できている状況なので、依頼をもらってから数日でモニタリングを納品することができるようになりました。
事業側と要件をすり合わせ、datamartにビジネスロジックを組み込んだカラムを追加さえすれば、セマンティックレイヤー以降は比較的単純な作業なので、サービスのドメイン知識が深くないメンバーへの業務切り出しもできています。
複雑な依存関係が解消された
各層での役割を明確化したことでテーブル間の依存関係が整理されているため、システムのDB定義に変更があった際の影響範囲調査や改修が容易になりました。
逆に大変だったこと、これから頑張りたいこと
層ごとの責任範囲の徹底
予算データを過去実績に応じてグループ毎に按分する計算等、事業特有の複雑な計算ロジックが出てきたときに、どの層で計算を行うべきかを都度考える必要がありました。
当初決めた層ごとの役割に反して実装したくなることが何度もありました（笑）
現場浸透
これまで馴染みのなかった役割の層ができたことや、層によっては現場に公開されていないものもあったことにより、一時的にデータ利用者にとって一定の混乱は生じてしまったかと思います。
また、依然としてデータ定義書を確認せず独自のロジックでdatamartからKPI集計を行っている人もいて、Tableauとの数値差異に関する問い合わせは完全には解消できていない状況です。
いずれも私の周知不足かとは思いますので、これから浸透のために取り組んでいきたいと考えています。
KPI定義の保守運用
データ定義については、変更があった際に随時ご連絡いただき都度修正を行っておりますが、現場からの連絡が漏れてしまった場合は定義変更を検知できない状態となっています。
定期的に全体を見直すフローを構築し、整合性の担保と運用の安定化を図っていきたいと考えています。
おわりに
実際に実装を進めていく中で、アーキテクチャ設計時点で考慮できなかった壁に何度もぶつかり、試行錯誤しながらルールを定めていけたのは、大変でもありつつとても貴重な経験でした。
現在、レバレジーズの他事業においても同一のアーキテクチャでデータ分析基盤再整備を進めていますが、事業ごとに使用するSFAツールが異なっていたり、事業特有の複雑な計算ロジックが存在するため、より汎用性の高いアーキテクチャの検討・整備を進めていければと思っています。
