アーカイブ動画
【LayerX】データドリブンな事業運営・開発を支えるデータ分析基盤への取り組み
株式会社LayerX
バクラク事業部 機械学習・データ部長 高際 隼氏
高際隼氏は、2018年に設立したLayerXの創業期からのメンバーだ。上場企業をはじめとする5000社以上が利用する「バクラク」事業のプロダクト開発や、マネジメントに従事。現在はデータ分析チームを牽引している。
バクラクとは、経費精算、仕訳、電子帳簿保存、法人カードの発行や管理など、各種業務の効率化とシームレス化を実現するプロダクトである。2年で5つのサービスをリリースした。
「開発スピードの速さこそがLayerXの文化であり、顧客から評価を得ている点です」（高際氏）
実際、サービスの継続率は99％以上、ITreview Grid Award 2023 Winterで最高位のLeaderを受賞。顧客から高い評価をもらうことも多い。高際氏は行動指針を紹介し、データドリブンな事業運営をする上で「Fact Base」が大きいと強調した。
「外部環境が変わり続ける中で、社内政治に頼らず意思決定するために、数字や事象などファクトに従って、柔軟に冷静に行動を起こしていく。この指針のおかげで、現在のデータ分析基盤構築業務も進めやすい雰囲気が生まれています」（高際氏）
取り組みの紹介の前にデータ分析基盤の変遷について触れた。バクラクのサービス公開直後からデータ分析を行っており、常にデータドリブンを意識しながら開発を進めてきた。当初はAWSのサービスを利用し、Amazon Aurora (データベース) にAmazon QuickSight (BIツール) でアクセスする構成としていた。
しかし、積極的にSQLを書きたいユーザーが多いといった課題もあり、BIツールのRedashを追加。さらには、SalesforceやHubSpotといったCRM/MAツールも追加し、データ連携するような構成へと変わっていく。すると、また新たな課題が生じた。
実際にデータを連携するには、手作業でデータをクレンジングする必要があったのだ。
「担当者が手作業でデータクレンジングをしていた」と、高際氏はそうした状況を打破すべくデータ分析基盤構想が立ち上がったと振り返る。当時の構成イメージ図も紹介された。
そして構想から約半年後に、trocco®、BigQuery、dbtといった各種ツールやサービスを活用したデータ分析基盤が構築される。データの流れはスライドのようにHubSpotやSalesforceといったデータソースから、trocco®経由でBigQueryにデータが集約された。
データ分析を行うユーザーはRedashなどを使い、BigQueryに保管されているデータを活用する。また、開発環境やステージング環境が導入されるといった副次的な効果もあった。
一方でこの2年の間で、プロダクトの数もメンバー数も約5倍に増えたため、データの認知負荷や属人性といった課題も増大した。
例えば、「分析に必要なデータの場所が分からない」「似たような名前のテーブルやカラムがたくさんある」「古いクエリのコピペ利用により、本来の意図とは異なる分析が行われている」「場合によっては、ダッシュボードの内容が実際とは異なる数字で示される」といった問題が挙げられた。
だが、現状では意思決定や経営に影響を及ぼすような重大な問題、レベルまでに至っていないと、高際氏は補足する。
とはいえ、今後業容が拡大することを考えると、このような状況が続くことを高際氏は危惧している。その胸の内を次のように話した。
「データの扱いが難しくなることで、一部の専門家に丸投げしてしまう。ダッシュボードの数字が正確ではなく、その不正確な数字を元に経営陣が誤った判断をしてしまう。結果、現場と経営陣の間で不信感が生まれるといったトラブルの発生が考えられます」（高際氏）
そこで高際氏は自ら立ち上がり、経営陣に現在の状況、自身が危惧している思いを伝えた。その結果、現在のデータ分析チームの発足ならびに牽引する業務を担うこととなった。そして今、さらなるデータマネジメントを推し進めている。
例えば、データ分析基盤のアップデートである。今後はRedashを廃止し、Looker Studioを導入する予定だ。また、Google スプレッドシートやGitHub、Amazon DynamoDBをデータソースとして取り込めるようにもなった。
今後の予定も含めた現状の技術スタックとして、以下が紹介された。
一方で、課題を解決しながらも、今後はデータの認知負荷を下げて、自動化したいという展望も話した。
「LLMなどの新しい技術を導入することでデータの民主化を進めつつ、ガバナンス強化においてもルールではなくシステムで制御することで、安心安全にデータにアクセス・利用できる環境を実現したいです」（高際氏）
【プレイド】マルチプロダクト開発におけるデータ分析基盤の分散と集中
株式会社プレイド
プラットフォームエンジニア 日鼻 旬氏
続いては、プレイドのサービス「KARTE」における、リアルタイム解析基盤のリニューアルプロジェクトをリードする日鼻旬氏が登壇した。
KARTEとは、Webサイトやスマホのアプリに来訪している顧客の行動を、顧客ごとにリアルタイムで解析・可視化するCX（顧客体験）プラットフォームだ。その上で、顧客一人ひとりの状況にマッチした体験や、コミュニケーションを提供するサービスである。
顧客ごとに瞬時の情報を得ているため、扱うデータ量も膨大で1秒間のトラッキング数だけでも13万4000リクエスト。これまで蓄積されたデータ量は、8ペタバイト以上にもおよぶ。
KARTEは、Web・電話・メッセージツールなどを通じて、顧客とのコミュニケーションチャネルやデータをワンストップ、リアルタイムで繋ぐことが可能なプラットフォームを目指している。
当初はWeb接客のみだったチャネルは次第にマルチ化し、以下のようにプロダクトも複数に増えていったという。
データ分析基盤の変遷についても語られた。まずはシングルプロダクト時代である。左側がユーザー、中央がKARTE、右側がクライアントであり、日鼻氏は当時を次のように語った。
「BigQueryを使いまくっていました。シンプルながらもBigQueryのパフォーマンスがよかったので、スムーズに進んでいました」（日鼻氏）
マルチプロダクトになってからの流れは、基本的には2つ。1つは、生じたイベントのデータを自分たちのプロダクト用に保管したり、カスタマイズしたりといったニーズとデータの流れだ。
もう1つは、マルチプロダクトならではの流れである、1つのイベントから複数のプロダクトにジョブを回して分析を行う「分散」だ。データ分析基盤を分散することで、開発スピードがアップするメリットもあったが、大きくは2つの課題も生じていた。
「カスタマイズ性は優れていましたが、ユーザー数やイベント量が増えると、スケールやメンテナンスといった面での不安がありました。実際、メンテナンスコストも高い状態でした」（日鼻氏）
2つ目は、データが分散していることでの課題だ。各プロダクトが別々で取り組んでいる状況が生まれてしまったことに、「もったいないと感じた」と、日鼻氏は振り返る。
そこでこれらの課題を解決すべく、マルチプロダクトでありながらもデータの取り組み部分は共通化する、新たなデータ分析基盤を構想する。日鼻氏は「集中化への揺り戻し」と表現し、実際のシステム構成図も紹介した。
似たような共通課題を複数のプロダクトで解かないように、リアルタイムのユーザーマスタを作成。各プロダクトに提供することで、フィルタリングやジョインといった作業が簡単に行えるようになった。
このような分散・集約の過程を経たことで、クライアントが見たいデータやインサイトをもたらすものは異なってはいるが、トランスフォーム・処理パターンは似ていることがわかってきた。
期間での絞り込み、ユーザー単位で統計値を出し、そのデータを元にフィルタリングするプロセスなどである。
今後の展開としては、データの集約化は最小限として仕組みを共通化していくことが挙げられた。また、各種モダンなデータプラットフォームツールも駆使することで、メタデータを簡単に取得できるなど、各人がやりたいことをスムーズに行えることである。
日鼻氏は、「ガバナンスも効いているようなデータ分析基盤にしていきたい」と、今後の展望を語り、データエンジニアとしての魅力を次のようにまとめた。
「今後もデータを価値にする技術を極めて、分散と集約のバランスを取っていきたいと考えています。いわゆるデータメッシュの考え方です。プレイドはデータが大量なので簡単ではありませんが、難しいからこそ面白いと考えています」（日鼻氏）
【マネーフォワード】マルチプロダクト環境におけるデータマネジメント
株式会社マネーフォワード
CTO室 分析基盤部 山崎 隼也氏
山崎隼也氏は、2021年にマネーフォワードに入社後、全社横断のデータ分析基盤のリプレイスプロジェクトに参画。現在は、データ分析基盤の構築に携わっている。
山崎氏は、まずデータ分析基盤をリプレイスするに至った背景、理由を紹介した。マネーフォワードでは個人・法人向けに数多くの金融系Webサービス、マルチプロダクトを提供しており、プロダクトの数は数十におよぶ。
以前は各プロダクトにレプリケーション（複製）したデータベースを用意し、マルチレプリケーション分析用のMySQLで管理。ユーザーはVDIを通じて、分析・集計業務やカスタマーサクセス業務などにデータを活用していた。
当時のデータ分析基盤にはセキュリティ面や即時連携ができるといったメリットがあった一方で、デメリットも多かったという。山崎氏は、当時を次のように振り返っている。
「データ量が膨大なため、重いという課題がありました。復旧や管理も大変で、一番きつかったのはオンプレだったことです。ハードウェアの性能限界が迫っていたので、もうこれ以上容量を増やすことは無理な状況でした」（山崎氏）
そこでデータ分析基盤のリプレイスを検討するが、以前より管理会計を目的としてBigQueryを使っていたため、すでに動作している基盤があった。そのノウハウや構成を踏襲するかたちで、BigQueryでのリプレイスを進めていく。
AWSのAuroraやEC2に保管していたプロダクトのデータベースを、データベースを移行するDMS（Database Migratio Service）で吸い上げ、まずはS3に配置した。
以降はGCPのサービス、BigQuery へのデータの移動を自動化するData Transfer Serviceを使い、GCS（Google Cloud Storage）に転送。利用者は、BigQueryを使ってGCSのデータを活用する、との構成にリプレイスされた。
しかし、新たな課題が生じた。中でも大きかったのが、プロダクトごとにAWSのアカウントを構成する「マルチアカウントアーキテクチャ」を採用、導入していた時期とバッティングしていたことだ。山崎氏は当時の様子を次のように話した。
「移行前、移行済みのプロダクトが混在していたため、自分が携わっているプロダクトはどうなのか。いつ、移行されるのか、など。多くのメンバーから問い合わせを受けることになったり、逆に聞くような状況も生まれたため、コミュニケーションのボリュームが膨大になりました」（山崎氏）
一方で、同プロジェクトは2名体制で進めていたため、マンパワーの限界があった。本来であればデータエンジニアの手を借りたかったが、簡単に集めることはできない。そこで、プロダクトサイドのメンバーからの協力を得ることを考える。
協力を得るためには、自ら動くことが重要だ。協力しやすい体制を作ることが必要だと感じた山崎氏は、Slackで専用チャンネルを作成する。さらに、メンバー探しに奔走するなどのアクションを起こした。
CTOにも状況を説明し、各プロダクトから担当者を出してほしいと依頼した。プロダクト側に配信された実際のメッセージも紹介した。
このような行動の結果、協力してくれるメンバーが集まったが、インフラまわりの知識の習熟度でばらつきが見られた。
そこで山崎氏は、ソースコードをテンプレート化し利用できる、Terraform Moduleを導入した。同ツールの導入は、山崎氏たちの運用の円滑化も考えてのことだった。さらには作業マニュアルも作成。協力者の手間を減らすために、できるだけ曖昧な部分をなくすよう心がけた。
作業マニュアルを作成したことで、プロダクト側・データ分析基盤チーム、両者がどの領域のどこまでの作業を担うのか、責任分界点も明確に分け、理解することができたと、山崎氏は成果を語った。
「大切なのは選択と集中だと実感しました。我々は何をすべきなのか、集中するための環境は、我々で整備することが重要であることも学びました」（山崎氏）
山崎氏は、データエンジニアが集中すべき業務を紹介した。今回のデータ分析基盤のリプレイスプロジェクトを通じて得た経験や学びを次のように語り、セッションをまとめた。
「すべてのプロダクトをキャッチアップすることは難しいため、協力してもらう。その代わり協力してもらうための努力は惜しまない。結果として、我々の仕事であるデータを分析可能な状態にする業務に集中できる環境を構築することが重要だと思います」（山崎氏）
primeNumberが提供するデータ分析基盤の総合支援サービス「trocco®」とは？
株式会社primeNumber
プロダクト本部 プロダクトマネージャー 佐々木 樹哉氏
今回のイベントを主催したprimeNumberは、「あらゆるデータを、ビジネスの力に変える」のビジョンを掲げ、さまざまな企業にコンサルティングやエンジニアリングサービスといった、データマネジメントの支援を行っている。
イベントのファシリテーターを務めたprimeNumberの佐々木樹哉氏から、同社が提供するデータ分析基盤の総合支援サービス「trocco®」（トロッコ）について紹介があった。
trocco®は点在するさまざまなデータを自動で統合し、データエンジニアリングにおける工数を削減するSaaSだ。データの統合以外にも、データ分析に有益な各種機能も提供する。
例えば、データ分析基盤上に存在するさまざまなデータのメタデータや統計情報を確認できるデータカタログや、分析に有用なER図やカラムリネージの表示の機能などである。
また、trocco®は期限なく無料で利用できるフリープランを提供している。フリープランのアカウント発行の申し込みをすると、1営業日以内を目途にアカウントが発行される。
【Q＆A】参加者からの質問に登壇者が回答
セッション終了後は、Q＆Aが行われた。参加者からの質問とその回答を紹介する。
Q．RedashからLooker Studioに移行した背景とは？
高際：重いクエリが実行されたりデータ量の多いダッシュボードが開かれたりするとRedashが落ちてしまうこと。バクラクの社内業務でRedashが深く組み込まれていたため、業務が止まるといった課題があったからです。また、権限管理の問題もありました。
日鼻：1日に扱うデータ量が3テラバイトといったボリュームのため、処理できるBIツールがあまりありません。そのため基本GCPのLookerで、それ以外のツールの利用はあまり聞きません。
山崎：当社もLooker Studioではなく、Lookerを使っています。ただしアナリストチームが選定しているため、詳しい理由は分かりません。
Q．ヒアリングの定性情報とデータ分析基盤の定量情報のバランスについてどのように捉えているか？
高際：顧客へのヒアリングで一定の示唆が得られるため、お客様の声は非常に大事にしています。一方で、お客様の中には従業員数十万人規模の企業もあるため、全従業員一人ひとりの行動を分析する定量評価も必要だと思っています。どちらも大事にしています。
日鼻：あくまで個人的な見解ですが、何かしら数値に落とし込み、定量で見ることを重視しています。
山崎：私も個人的な意見になりますが、それぞれデータの特性が異なるため、どちらかを信頼しすぎるのではなく、両方をバランスよく使うのがよいと考えています。
Q．既存オペレーションが稼働している状況での基盤移行で気をつけたいことは？
高際：山崎さんが話された、協力を得るために曖昧さをなくすことが学びになりましたし、この質問の答えだと思います。LayerXとしては、どちらの基盤のツールも平行して使える期間を必ず設けています。またダッシュボードを作る人を特定したり、移行を促す環境づくりを意識しています。
日鼻：元々BigQueryを中心に据えていたため、移行はあまり発生しません。ただ行うとすれば、インナーコミュニケーションで進めるのではなく、メリットを伝えドラスティックにバチッと素早く切り替えると思います。
山崎：旧環境で流れているクエリを1週間観察し、発行者を特定。新環境でもできることを直接伝えました。泥臭い活動で大変でした。
Q．マルチプロダクトにおけるデータ分析メンバーの横断も含めた担当状況について
高際：LayerXでは、仮説を持っている現場のメンバーが分析できるようにしたいと話しています。分析スキルを高めるトレーニングを行い、分析しやすい環境を整えることで、仮説と検証の距離が近くなることを目指しています。
日鼻：プレイドはまさしく分散。プロダクト側のエンジニアが見たい、分析に活用したいデータを取得し、ダッシュボードも自分で作成してくださいと伝えています。作り方などのアドバイスやフォローは、データアナリストらが行うような体制を整備しています。
山崎：我々は分析チームではなく基盤チームのため、プロダクトごとにロックインしないよう注意しています。一方で情報を共有できるよう、内製のデータカタログツールを作るなど、共有業務をドキュメントとして残し、全員が共有できるような機会を設けています。
Q．ダッシュボードの計算方法など、データに関する現場メンバーからの質問の対応
高際：4月にチームが発足したばかりで、まさにこれからという状況です。具体的には、SQLの書き方は各々がLLMなどで調べてくださいと、アナウンスしています。また、データに詳しい人を紹介するなどして、認知負荷を下げる対策を行っていく予定です。
日鼻：各自がプロダクトごとで考えてもらうことを基本としています。そして、SQLの書き方などはChatGPTなどのLLMに聞くと楽だし、積極活用してくださいと、アナウンスしています。
山崎：内製しているデータカタログの話に近いと思います。具体的には、データの定義などをYAMLファイルとしてGitHubに羅列しています。また、拡張としてBigQueryのディスクリプションに流し込むなどして、より良い環境整備に努めています。
株式会社primeNumber
https://primenumber.co.jp/
trocco®フリープランお申込みフォーム
https://trocco.io/lp/inquiry_free.html
trocco®お問い合わせ先
https://trocco.io/inquiry/new
関連するイベント
