楽楽クラウド拡大を支えるラクス内データ分析基盤の真価──管理会計領域から始めるAIとデータの民主化
業務システム部が創るデータ活用の未来――BigQueryからAIエージェント検証まで
ラクスは、事業拡大にともなって複数のSaaS提供が進むなか、部門ごとに分散したデータの集約と現場での活用を課題としてきた。従来は、各部門が基幹システムから必要なデータを個別に取得し、スプレッドシートやBIツールで加工・集計する運用となり、手間もかかり属人化の問題もあったという。そこで同社は、2021年全社データ分析基盤「RaDAP(Rakus Data Analytics Platform)」の構築に着手。BigQueryを中核に、データを収集・加工するパイプラインやメタデータ、アクセス制御の仕組みを整備してきた。手作業の削減から管理会計の分析高度化へと活用範囲を広げ、AIを利用した分析支援も検証している。同社の業務システム部はRaDAPの整備をどう進め、どのように現場と協働してデータ活用を定着させようとしているのか。
複数SaaS展開で高まったデータ統合の必要性
「楽楽精算」や「楽楽明細」など、企業のバックオフィス業務を支援するクラウドサービスを提供するラクスは、事業が拡大する中で、2021年ごろから全社的なデータ活用基盤の必要性を感じていたという。当時は各事業部門で基幹システムから必要なデータを個別に取得し、スプレッドシートやBIツールで加工・集計する運用が行われていた。こうした作業は担当者ごとの知識や手順に依存しやすく、データ加工のロジックも部門内に閉じがちである。全社で共通の数値を確認する際には、データの定義や集計方法をすり合わせる必要があり、意思決定に必要な情報を得るまでに時間を要する場面もあったという。
こうした中、個別のプロダクトを軸に営業活動や顧客支援を行う「ベストオブブリード戦略」をもとに事業を展開してきた同社は、2025年から1社の顧客企業に対して複数のSaaSサービスを展開する「マルチプロダクト戦略」を掲げ、取り組みを進めてきた。
戦略の転換にともない、サービス単位のデータ分析に加え、顧客単位で社内横断的にデータを把握する必要性が高まっていたという。コーポレートIT統括部 業務システム部の部長を務める小林侑太氏は、マルチプロダクト戦略を開始した当時の問題意識を次のように振り返る。
「ラクスのサービスを継続利用いただく企業が増えていくなかで、従来と同じやり方を続けていては、顧客の増加に比例して社内の人員も増やしつづけなければならなくなる。全社としての生産性を向上させるためには、日々のデータ活用業務そのものを自動化・効率化することが不可欠でした」(小林氏)
データにまつわる課題は定常的な集計業務の負荷だけではなかった。顧客企業に複数のサービスを提案・提供するためには、商談履歴、カスタマーサポートへの問い合わせ履歴、各サービスの利用状況などを横断して把握する必要がある。しかし、これらのデータはプロダクトや部門ごとに管理されており、営業やカスタマーサクセス部門が顧客の状況を一元的に捉えることは容易ではなかった。
「1社に対して複数のサービスを提供するためには、顧客にまつわるあらゆるデータが1ヵ所に集約されていなければなりません。人が判断するにせよ、将来的にAIが判断するにせよ、データを統合的に扱える基盤の存在は、事業戦略上なくてはならない前提条件でした」(小林氏)
こうした課題を踏まえ、同社は2021年、定常業務の効率化と顧客データの横断活用を目的に、全社データ分析基盤「RaDAP(Rakus Data Analytics Platform)」の構築に着手した。
BigQueryを中核に据えた「RaDAP」のアーキテクチャ
ラクスは、自社SaaSのサービス提供基盤ではオンプレミス環境を採用してきたが、RaDAPを構築するにあたっては、Google Cloudを基盤として選定。基盤のアーキテクチャ設計と運用を主導するデータ活用推進課の岩崎浩太郎氏は、Google Cloudを採用した背景を次のように説明する。
「データ基盤の中心となるデータウェアハウスには、コストパフォーマンスに優れ、スモールスタートが可能なGoogle CloudのBigQueryを選定しました。また、社内で既にGoogle Workspaceを全社導入していたため、Googleアカウントと連携したアクセス制御やセキュリティ統制を進めやすい点も、選定理由の一つでした」(岩崎氏)
データソースからの抽出処理にあたっては、Google Compute Engine(GCE)上でスクラッチ開発した軽量なプログラムを主に利用している。コストを抑えながら処理を細かく制御する狙いだ。一方で、接続先や運用規模に応じて、データ連携ツール「Airbyte」の検証・併用も進めている。
抽出した生データはBigQueryへ直接ロードせず、いったんGoogle Cloud Storage(GCS)に保存する。抽出処理と後続の変換・加工処理を疎結合にする設計だ。
岩崎氏は、「BigQueryへ直接書き込まずにオブジェクトストレージを挟む疎結合な構成にすることで、後続の処理でシステム障害や仕様変更が発生した場合でも、データソースへ再アクセスすることなく、保存済みのデータを使って再処理できるようにしています」と説明する。
ストレージに保存したデータの変換・加工には、BigQueryと連携するGoogle CloudのDataformを採用。データ変換処理の記述・管理に用いるオープンソースのフレームワーク「dbt」なども選択肢にあったが、追加のツール導入・運用を抑えつつ、SQLベースでデータ変換処理の依存関係や実行スケジュールを管理できる点を選定理由の一つとした。
また、M&Aなどにより異なるクラウド基盤を利用する企業がグループに加わる可能性も見据え、AWSなどを含むマルチクラウド環境との連携や、将来のデータ統合に備えた基盤設計を進めている。岩崎氏は「M&Aなどによってグループ運営形態に変化があった場合でも、データを迅速に統合・連携できるようにApache Icebergなどの技術検証を進めています。特定の製品に過度に依存するのではなく、必要なタイミングでコンポーネントを入れ替えられる“コンポーザブルな基盤構造”を意識しています」と語る。
この記事は参考になりましたか?
- DB Press連載記事一覧
-
- 楽楽クラウド拡大を支えるラクス内データ分析基盤の真価──管理会計領域から始めるAIとデータ...
- Honda/三菱UFJ信託銀行が挑む、“統治”と“俊敏性”を共存させたSnowflake基...
- AIだけに投資しても成果はでない──投資成果の格差はなぜ生まれるのか? 実態調査が浮き彫り...
- この記事の著者
-
谷川 耕一(タニカワ コウイチ)
EnterpriseZine/DB Online チーフキュレーターかつてAI、エキスパートシステムが流行っていたころに、開発エンジニアとしてIT業界に。その後UNIXの専門雑誌の編集者を経て、外資系ソフトウェアベンダーの製品マーケティング、広告、広報などの業務を経験。現在はフリーランスのITジャーナリスト...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
この記事は参考になりましたか?
この記事をシェア
