バクラク事業におけるデータ組織とデータ基盤 2023

お世話になっております。LayerXの高際 @shun_tak と申します。現在は、データ分析組織の立ち上げに注力しています。

本記事では、バクラク事業におけるデータ組織とデータ基盤をテーマに取り扱います。データ分析における認知負荷や属人性を解消するための取り組みや、良質なデータを提供するためのデータ基盤の構築について、具体的な技術スタックを交えて解説し、最後に現在の課題と今後の展望について説明します。

また、この記事は 7月はLayerXエンジニアブログを活発にしよう月間 の2日目の記事になります。

1. データ組織について

データチームは2023年4月に設立されたばかりのチームで、

• 事業活動を深く理解した上で
• 安心安全に利用でき、認知負荷が低く、目的達成に十分な品質のデータを提供し
• データ活用を通じて組織のアジリティを高め
• より多くの人にバクラクの価値を届けきること

を目的としています。大変だー！

では、チーム設立以前はこういった活動を全くしていなかったかというと、そうではありません。

1.1. チーム設立の背景

Fact Base

バクラクは2021年1月にサービス公開し、行動指針にFact Baseを掲げる私達は、ほぼ同時にAmazon QuickSightというBIツールを使い始めました。

Metabase、Supersetも試しましたが、4月からはRedashを本格的に利用開始しました。

その後2年間、ひたすらRedashを使い倒してきました。気付けばLayerX全体で人数は40人から180人に(バクラク事業以外の人員も含む)、バクラクシリーズのプロダクトも最初の1つから6つに増えていました。

LayerXの社員数 https://note.com/t_1496/n/n876b5bef9cfd

バクラクのプロダクトと開発組織 https://speakerdeck.com/shuntak/aws-dev-day-2022-japan?slide=21

ここまで規模が拡大すると、データの認知負荷が増大し、データ分析が属人化し、以下のような問題が出てきました。

• XXという分析をしたいが、データがどこにあるか、あるのかすら分からない
• 名前が似たテーブルや、似た名前で意味の異なるカラムがたくさんあり、区別がつかない。
• データ構造が変わって微妙に異なる結果を返すようになったクエリを次々と多くの人がコピペし、意図と異なる分析が増え続ける
• MRRを表示するダッシュボードが複数あり、それぞれの数字が異なっている
• etc

問題はあるものの意思決定を歪ませるほど深刻な問題は起きておらず、現在は各チームの専門家が協力しあって何とか形を保っています。

しかし、2年後、3年後という将来を見据えると、人数が数百人、プロダクト数も10を超えるような大規模な組織になることが予想されます。

何も対策を取らなければ顕在化している問題はより深刻なものになり、次々に大きな問題が生じるでしょう。このような状況下では事実に基づく意思決定が不可能となり、勘と経験に基づいた政治的な意思決定が行われるようになるかもしれません。その結果、施策の再現性が失われ、組織文化が破壊される可能性があります。

このようなバッドシナリオを回避し、データ活用によって組織のアジリティを今以上に高めるため、データ組織を立ち上げることになりました。

1.1.1. 多少間違ったクエリでも正しい意思決定ができれば、それはとても良いこと (余談コラム)

前のセクションで、クエリのコピペ等が問題になっていると書きました。

これらの問題は、それぞれ自らデータ分析しているために生じる問題です。ある意味データの民主化ができているとも言えますし、それ自体はすばらしいことだと思います。もちろん、分析結果にズレが生じて意思決定が歪むほどになると問題ですが、この場合、それぞれ自ら分析しているため、違和感に気付いて修正することができると思います。

しかし、データ分析が億劫だから前の施策と同じパラメータを使おうとか、データ分析は全部データチームに丸投げしてしまおうとなると問題です。

私はデータの品質を100％にする必要はないと考えています。目的を達成に十分な品質があれば問題ありません。

さまざまな専門家が集まるバクラクの組織において、データが妨げにならず、むしろ爆速かつ滑らかにデータ分析でき、彼らの才能を最大限に活かせる環境を整えることが最も重要だと考えています。

1.2. チーム構成

ここからは、もう少し具体的な話に入ります。

データチームは、バクラク事業部に所属するチームの1つです。

現在、4人で活動しており、私1人はデータをメインに活動していますが、他の3人は他の業務を主に行いながら、データチームの業務も兼務しています。

4名それぞれの兼務内容としては、

• マネージャー、アナリティクスエンジニア、セキュリティ担当者
• DevOpsマネージャー、DevOpsエンジニア、データエンジニア、CTO室、セキュリティ担当者
• BizOps、CS Ops、データアナリスト
• BizOpsマネージャー、データアナリスト、セキュリティ担当者

という感じです。みんな現場でごりごりに手を動かす人たちなので違和感なかったですが、こうして文字に起こすとマネージャー多すぎてヤバい組織ですね！そして兼務多すぎ！！！セキュリティ以外の兼務を解消しようとしたら9人必要ですね…笑

1.3. 業務内容

以下は、大まかな業務内容です。

• データ分析
• データ分析における認知負荷や属人性を解消するための業務
• 安心・安全に利用でき、適切な品質のデータを提供する基盤の開発・運用

これらの業務はそれぞれ、データアナリスト、アナリティクスエンジニア、データエンジニアが担いますが、領域を越境して業務を行う場面も多いです。

現在注力している取り組みは以下のとおりです。

• アナリストが不足している現場に入り、データ分析を支援すること
• Redashã‚’Looker Studioに移行し、ダッシュボードの利用体験とデータガバナンスの向上を図ること
• データウェアハウスへのデータ統合を進め、分析対象を拡大すること

データ統合はほぼ完了しつつあります。Redashリプレイスの最中に新たな課題が発生し、慌てて対応している状況です！

以下は、次にやりたいこと、やりたいけどなかなか手が回っていないところです。

• データカタログを導入して、データの認知負荷を下げる
• CDCによるnear real-timeなデータ転送基盤を構築し、本番データベース直接参照の代替手段を提供する
• 開発環境を整備し、データ品質と生産性を向上させる

チーム構成と合わせると業務のパツパツ感のイメージが湧いてくるでしょうか？ぜひあなた力を借してください！

2. データ基盤について

データの民主化によって全員がアナリストとなり、データ活用を推進していくことが望ましいです。しかし、そのためにはいくつもの壁があります。

個人情報が含まれていないことや、活用時の安心・安全性、なるべく最新のデータにアクセスできること、メタデータやデータマップを整備してどこにどんなデータがあるかわかりやすく整理すること、分析者が書くクエリの複雑性を下げるためのデータマートを用意すること、データ品質を担保すること、テスト可能にすることなど、良質なデータを提供するためのデータ基盤を用意する必要があります。

このような道のりはまだまだ先が長いですが、2023年6月現在のバクラクにおけるデータ基盤の現状を紹介したいと思います。

2.1. データ基盤の構成

バクラク事業におけるデータ基盤は、以下のような技術スタックで構成されています。

• Data Warehouse: BigQuery
• Extract, Load: Embulk
• Transform: dbt
• Data Pipeline: dbt, GitHub Actions, AWS Step Functions
• Data Streaming: Amazon EventBridge, Cloud Pub/Sub
• Data Catalog: OpenMetadata (これから構築・運用予定)
• Business Intelligence: Redash (廃止予定), Looker Studio, CRM Analytics (Salesforce社の製品)
• IaC: Terraform

図にするとこんな感じです。

2.1.1. データソース

プロダクトのデータはAWSにあります。Salesforce、Google Analytics、GitHubなど、SaaSのデータも収集し、データ基盤に取り込んでいます。

2.1.2. データウェアハウス

データウェアハウスとしてBigQueryを利用しています。

2.1.3. データ収集 (Extract, Load)

データの収集にはEmbulk, fluentbitを利用しています。Embulkの実行はGitHub Actionsで、fluentbitはサイドカーコンテナとしてAmazon ECS上にて実行されています。

2.1.4. データ変換 (Transform)、データパイプライン

データ変換、データパイプラインにはdbt (Data Build Tool) を利用しています。

また、データパイプラインを構成する要素として、GitHub ActionsとAWS Step Functionsも重要な役割を果たしています。プルリクエストの作成やマージをトリガーに、自動化されたワークフローを実行します。

2.1.5. ビジネスインテリジェンスツール

RedashからLooker Studioに移行中。

2.1.6. データアクティベーション (リバースETL)

データウェアハウスのデータをdbtで適切に変換し、Embulkを介してSalesforceやデータベース等に連携しています。

2.1.7. データカタログ

現時点では、dbtから自動生成したドキュメントがある程度です。

今後OpenMetadataを導入予定です。

2.1.8. 開発環境

バクラクのデータ基盤には、データ基盤開発者用の開発環境、データ分析者用のステージング環境、本番環境の3環境が用意されています。

2.1.9. 構成管理

インフラの構成管理にterraformを利用しています。

2.1.10. ちなみに過去の構成

参考までに、この形になる以前の構成はこちらのイベントでお話させていただきました。

speakerdeck.com

3. 課題と今後の展望

アーキテクチャ図でデータ基盤を見ると整っているように見えるかもしれませんが、データ基盤は徹底的に使い倒し、組織に100%浸透させることで真価を発揮します。

dbtを導入したものの、分析者の認知負荷を下げる充実したデータマートが全然揃っていません。同じ名前のKPIなのに結果がズレることがあります。dbtを使うハードルが高く、データマート整備だけでなくドキュメントの整備にもひと手間かかる状況で、情報やノウハウが属人化してしまっています。

データ収集は、1日1回や1時間に1回などのペースで実施されており、障害対応時に本番データベースに直接アクセスすることを許してしまっています。Salesforce周りのデータをステージング環境でdbt buildしたとき、SalesforceのSandbox環境と本番環境の差異によってビルドが失敗することがあります。

他にも多くの課題があります。まだ組織の箱ができただけで、まだ何も成し遂げていません。

今後の展望としては

• データの認知負荷を継続的に下げ続けること（人手に頼りすぎず自動化すること）
• 属人化した情報やノウハウを組織の知識として共有すること
• 必要十分なデータ品質を保つこと（過剰にすることはないこと）
• 安心安全にデータを利用できるようにすること
• これらを実現するために必要な基盤を整えること

これらを2年ほどかけて実現し、500人や1000人の組織に耐えうるようにし、むしろ組織のアジリティを高めることに貢献したいと考えています。

4. 登壇情報

7月には2件、データ関連のイベントに登壇いたします。

2023年7月11日には、「バクラクのデータドリブンな事業運営・爆速開発を支えるデータ分析基盤のこれまで・現在・これから」というテーマでお話します。LayerX以外には、プレイドさん、マネーフォワードさんという、LayerXよりも先のステージの会社さんから事例をお話いただきます。LayerXとしても非常に参考になるだろうと思い、今から楽しみにしています！

techplay.jp

2023年7月25日には、「がむしゃら系キャリアの探索と挑戦、ときどき葛藤の日々について」というテーマでお話します。私はずっとプロダクト開発をしてきた人間で、他の登壇者とはちょっと違う観点からお話できると思っています。

tech-track.connpass.com

ぜひご参加ください！

5. 採用情報

やるべきことはたくさんあります。データチームを作ったからこそ、やるべきことの解像度が上がったとも言えます。しかし、全員兼務のたった4人ではできることはほんのわずかです。あなたの力が必要です！

データアナリスト、アナリティクスエンジニア、データエンジニア、データサイエンティスト、機械学習エンジニア、MLOpsエンジニア、データに関わるありとあらゆる職種がオープンしています。ぜひ、カジュアル面談からお申し込みいただけると嬉しいです！

jobs.layerx.co.jp

求人票はこちらです。

【バクラク】データエンジニア / 株式会社LayerX

【バクラク】アナリティクスエンジニア / 株式会社LayerX

【バクラク】データアナリスト / 株式会社LayerX