こんにちは。 データ戦略室データアーキテクトグループの田代です。 本ブログでも何度か経過報告をさせていただいている「データ分析基盤再整備プロジェクト」。この度、ようやく全社規模での展開がある程度完了しました。
これまでの具体的な取り組みや、特定サービスでの先行事例については、ぜひ以下の記事や資料もあわせてご覧ください！ 見返すと壮絶なブログリレーですね。本取り組みで擦りすぎました。笑
参考記事：
- データ分析基盤再構築への道！～レバレジーズの挑戦～ - レバレジーズ データAIブログ
- データ分析基盤再整備プロジェクトの全貌 - レバレジーズ データAIブログ
- データ分析基盤再整備から1年：アーキテクチャ導入の成果と苦労 - レバレジーズ データAIブログ
- データの民主化を考える 〜正しく活用される基盤づくりとは〜 - レバレジーズ データAIブログ
- データ定義決定に向けた合意形成とシステム連携の壁 - レバレジーズ データAIブログ
- 10倍スケールを見越した データモデリングのリアーキテクチャ - Speaker Deck
今回は、プロジェクトが全社フェーズに進んだからこそ見えてきた、背景や手応え、そして泥臭い苦労話についてお伝えします。
全社展開できた理由・背景
なぜ、このタイミングで全社展開へと舵を切ったのか。そこには「確信」と「危機感」の両面がありました。
「いける」という確信の醸成
まずは1つのサービスで徹底的にモデルケースを作り込みました。その中で他のサービスでも転用できるのか？という軸で意思決定をし続けたことで、運用の見通しが立ったことが、全社展開への大きな自信となりました。
データマネジメントの負債解消
長年運用しているサービスでは、ドキュメントが古かったり、担当者の交代によって「秘伝のタレ」化したクエリが散見されたりしていました。 過去のブログで上げたモデルケースとなるサービスが「サービスのデータマネジメントが社内で1番先進的でちゃんとしている」と社内で浸透したことを「正当なきっかけ」として、他のデータマネジメントができていないサービスへの展開が容易になりました。
組織のスケールに伴う標準化の必要性
メンバーが増え、関わるサービスが多角化する中で、各所への影響範囲も広がっています。今後のさらなるサービスや組織拡大を見据えると、今のうちに基盤を標準化しておくことが、将来的な開発スピードを落とさないための必須条件でした。
展開してみて良かった点
実際に全社へ展開する中で、予想以上のポジティブな変化がありました。
1. 指標の棚卸しと可視化
BIツールの計算機能で管理されている膨大な指標を紐解いたことで、「実は似たような指標が乱立していた」といった実態を把握できました。これらを明確に定義し、GitHubで管理できるようにしました。管理できるようにすることで、知らないうちに指標が定義されていることによる間違った意思決定を防ぐことができたのかなと思います。 実際に全社展開している途中であるサービスから再構築前の環境で、あるモニタリングでは正しく見れているが、別のモニタリングとの数値があっていない事象が発生し大変な思いをしました...
2. 「日本語カラム」によるレビューが容易に実施できるように
今回、データマート層を「システム開発や分析をメイン業務としない人もわかるような表現にする」ために思い切って日本語カラムを採用しました。 その結果、エンジニアやプロダクトのシステムを深く知っているからは使いにくいと言われることもありましたが、普段分析を行う他職種の利用者からは「他の方が作成したクエリで何をしているのかがわかりやすくなった。」とコメントをいただくようになりました。 システムDBの物理名まで知らないと分析の意図が見えないと言ったことも起きにくくなり、利用者同士のコミュニケーションコストも下がっています。
3. 生成AIという強力な追い風
LLM（大規模言語モデル）の普及により、日本語化された綺麗なメタデータを持つDBは、AIにとって非常に理解しやすいものとなりました。 現在、テキストを入力するとデータマートのテーブルから必要な情報を抽出して分析してくれるツールを開発できたり、利用者にとってもワクワクする世界を見せられる環境も相まって浸透しやすい状態になっているかなと思います。 正直、このタイミングでの全社展開は「運」も味方したと感じています。
展開してみて苦労した点
もちろん、綺麗な話ばかりではありません。全社展開ならではの壁にもぶつかりました。
1.「複数選択」という名の強敵
サービスのシステム特性上、1つのカラムに複数の値が入るような複雑なテーブル設計が多く、これをどう正規化し、かつ分析しやすく保持するかにとても頭を悩ませました。
2. ワイドテーブルの功罪
「とりあえず結合を先に行って後から集約したら使いやすいだろう」と用意したワイドテーブルですが、実際に運用してみると、SQLの中身が複雑になったりして、思った以上に扱いづらい側面があることも露呈しました。
3. 定義の「考古学」作業
よかった点にも記載していますが、再構築前の環境のモニタリングやクエリを読み解くという作業は、もはや発掘調査に近いものがありました。当時の仕様を知る人を探しても、すでに退職されていた場合もあり、ゼロベースで作り直していく作業には、多大な工数を要しました。
今後の展望
今回の再整備はあくまで「土台」と考えており、さらに価値のある取り組みを行っていきたいと思います。基本的には「安全に・素早く・正確に・安く・全員に」データを提供していく環境を構築できたらと考えています。
1. 安全に = エラー率の減少
更新エラーが起きないように、起きてもすぐに対応できる体制を引き続き構築していきたいと思っています。 エラーが起きたら担当サービスではなくても対応できる体制や、エンジニアとの連携を強固にしていけたらと考えています。
2. 素早く = SQL不要の世界（text2sqlの実現）
整備した綺麗なデータマートと生成AIを組み合わせることで、SQLが書けないメンバーでも、自然言語で問いかけるだけでデータマートから示唆を得られる環境を構築したいと考えています。
3. 正確に = AIとBIツールの境目
おそらく「SQL不要の世界」が実現された時に重要とされるのが、「正確な数値を管理する」役割がBIツールの役割になると思います。そのため役割にあったBIの構築を行っていけたらと考えています。
4. 安く = 無駄なコストを削減し続け、新しいことに挑戦するコストを捻出する
何もしないと売上成長以上にコストを払うことになりかねないので、無駄なコストを落としていきながら新しいデータや取り組みにコストが使える組織体制を作っていけたらと考えています。
5. 全員に = データ利活用を推進する
データ分析基盤再整備は、あくまでもデータ利活用の土台を作ったにすぎません。今までもサービスの課題を一緒に解決することでデータ利活用は推進していましたが、より加速的に推進できる環境になったからこそ、より多くのサービスの課題を解決していきたいと考えています。
最後に
まだまだ改善できる点はたくさんあると思います。 これからも、事業の成長をデータで加速させるために、チーム一丸となって突き進んでいこうと思います！
