データ分析基盤の他事業展開で見えた、共通ルールと現実のギャップ

はじめに

こんにちは。レバレジーズデータ戦略室、データアーキテクトグループの鵜飼です。

本ブログで何度かご紹介させていただいている「データ分析基盤再整備プロジェクト」ですが、今回はその全社展開後の「現在のデータ分析基盤の状況」についてお話しします。
特定事業に的を絞り、試行錯誤して作り上げたデータ分析基盤ですが、他の事業に横展開する中で様々なイレギュラーが発生し、理想と現実のギャップに直面しました。

「データ分析基盤再整備プロジェクト」については過去の記事がいくつかあるので、気になる方はご覧ください！

参考記事：

起きていたこと

冒頭の通り、まずは特定の事業からスモールスタートし、アーキテクチャの設計はもちろん、各データレイヤーにおける処理内容や命名規則といったルールを細かく定義しました。

それをベースに他事業への横展開を進めていたのですが、事業数が増えるにつれて以下のような課題が浮き彫りになってきました。

事業特性によるギャップ： 事業ごとに使用しているSFAツールやビジネスモデルが異なるため、既存のルールでは対応しきれないケースがありました。
各担当者間での認識・判断のずれ：弊社のデータアーキテクトグループでは、メンバーがそれぞれ特定の事業を担当し、各事業に対して実装者とレビュワーがある程度固定されています。そのため、イレギュラーが発生しても実装者と担当レビュワーの合意のみで実装が進められてしまう状況が発生していました。
スピードを優先した個別対応の増加：ビジネスサイドの要求スピードに応えるため、「今回はスピードを優先し、一旦この設計を許容しよう」といったイレギュラー対応が各所で発生していました。

こうした状況を放置すると、せっかく再整備したデータ基盤の保守性が再び低下してしまう懸念があったため、横展開における課題解決を目的としたプロジェクトを立ち上げ、社内全体の標準化に向けた取り組みを開始しました。

取り組みの体制とプロセス

新規のモニタリング環境を構築する際は、基本的に新しいアーキテクチャに乗せる方針をとっています。そのため、アーキテクトグループのメンバー全員（およびデータエンジニアの数名）は、共通して最低限のルールを理解している状態でした。

そこで今回のプロジェクトは、リアーキテクチャの設計や構築を深く経験しているメンバーが中心となって推進しつつ、個別のイレギュラー事例についてはグループ全体にヒアリングをかける形で進めていきました。

この際、「実はあの事業部では、こういう特殊なデータ構造になっていて……」といった、個別最適化されていた運用の背景や新たな事実が次々と明らかになりました（笑）

実際に議論に上がったこと

今回のプロジェクトで、特に判断に迷った具体的な「事例」を2つご紹介します。

①着地見込みをどのレイヤーで算出するか

「今月の売上着地見込み」などの算出ロジックは、事業部によって算出方法が全く異なります。例えば、目標と実績の両方がロジックに組み込まれているのかどうかで算出に適したレイヤーが変わってしまいます。既存のアーキテクチャ規約を厳格に遵守しようとすると、同じ処理を複数テーブルに書く必要があり、結果として保守運用コストを増大させてしまうというジレンマに直面しました。
現在進行形で議論中ですが、各事業の事例を洗い出して最適解を模索しています。

②「データ加工」と「ビジネスロジック」の境界線

リアーキテクチャの設計思想において、私たちは「DWH層まではシステムの構造に寄り添い、datamart層以降でデータ加工やビジネスロジックの定義を行う」という大原則を掲げていました。
しかし、同一のDWH層のテーブルを複数のdatamartで使用する際に、同じ加工を複数箇所で行うことになり、「DWH層で一段階加工を済ませておいた方が、後続の処理を1箇所にまとめられて効率的ではないか」という意見が上がりました。前述の着地ロジックの問題と同様に、ルールと保守運用コストのジレンマです。
さらに議論を難しくしたのが、「そもそも、どこからがビジネスロジックなのか」という定義の曖昧さでした。「この単純なデータクレンジングや値の置換は、はたしてビジネスロジックに該当するのか、それともシステム構造に寄り添ったデータ整備の範囲内なのか」といったグレーゾーンが発生していました。
結果として、システムで定義されている値を変えない行為（値の一部を抜き出したりJSON形式から変換したりなど）であればDWH層での処理を許可することとなりました。

おわりに

今回の取り組みを通じて、多種多様な事業特性やシステム特性が存在する環境において、すべての要件を完璧に網羅するルールをはじめから定義するのは難しいことを痛感しました。
かといって、どんなケースにも対応できるようにルールの抽象度を上げ、幅を持たせすぎてしまうと、今度は規約そのものが形骸化して守られなくなってしまいます。この「ルールの厳格さ」と「運用の柔軟さ」のバランスにおいて、いかにして最適解を見出していくかを検討していきたいです。

今後も横展開を進める中で、新たなイレギュラーは確実に発生します。だからこそ重要になるのは、問題が起きた際に個別に判断するのではなく、「イレギュラーが発生したときに即座に相談・判断ができる共通のフロー」を構築し、議論のログを一箇所に集約する仕組みです。ナレッジが一元化されていれば、メンバー間の認識のズレを防ぐことができ、「ここを参照すれば一発で判断できる」という状態を作れます。細かなルールや迷いやすいポイントを、チーム全体で都度スムーズに確認・アップデートしていける仕組みをつくっていきたいです。

弊社では事業ごとに異なるSFAツールを採用していることもあり、今後のさらなる横展開においても、さらなるイレギュラーに直面することが予想されます。ですが、今回培った議論の土台を活かし、都度チームで柔軟に向き合いながら、より強固で美しいデータ基盤を目指して頑張っていきたいと思います！