Snowflakeによるデータ統合と縦割り開発体制の見直し Cortex Analystの自然言語によるデータ集計・分析で 誰もがデータを利活用できる世界を実現

国内最大級の飲食店情報サイト「楽天ぐるなび」のサービス提供開始は1996年。あらゆるサービスの起点にデータがあるという認識のもと、全社的なデータ利活用促進に力を入れる上で、大きな制約になったのはサービス立ち上げから30年近くが過ぎ複雑化したデータ環境だった。その解決に向け、同社はSnowflakeにデータを一元化。併せてデータエンジニアリングとアプリエンジニアリングの両部門を統合。さらにCortex Analystによる自然言語を使ったデータ集計・分析により、誰もがデータを利活用できる環境の実現を図っている。

飲食店情報サイト「楽天ぐるなび」の開設は、インターネットが普及段階に入って間もない1996年のこと。30年近くが経った今、月間ユニークユーザー数3200万人（2023年12月時点）、総有料加盟店数4万2065店（2023年9月時点）を誇る国内最大級の飲食店情報サイトは、飲食店選びに欠かすことができない存在になっている。

だが、運営会社であるぐるなびの事業は、飲食店の検索・予約機能を提供するサイト運営だけに留まらない。お客様のスマホで注文と会計ができるモバイルオーダーシステム「ぐるなびファインオーダー」、フードホール運営をプロデュースする「ぐるなびフードホール ワイ」、通販商品を共同開発する「ぐるなびプレミアムミールキット」など、飲食店のトータルサポートに関する事業も同社の重要な柱の一つである。

さらに2024年夏より同社は生成AIを用いて技術革新・DXを実現する「ぐるなびNextプロジェクト」を本格始動。社内外における生成AI活用を通し、「次世代食体験の実現」と「圧倒的な業務効率化」を目指している。

同社のビジネスにおいて大きな役割を果たすことが期待されるのが、楽天ぐるなびサービスに関連する膨大なデータだ。だがその利活用は、必ずしもスムーズには進まなかったという。CTOの岩本 俊明氏はその理由をこう説明する。

「私たちが直面した問題は大きく三つありました。一つは、Python、SQLなどのデータエンジニアリング開発言語とTS、Go、PHPといったアプリケーション開発言語の併存です。次が、データエンジニアリング部門とアプリケーション開発部門の縦割りの組織構成です。部門を跨いだ非効率的なコミュニケーションは、生産性の低下に加え、本来の目的を満たさない内製ツールが作成される懸念にもつながっていました。最後がデータのサイロ化の問題です。これはシステム継ぎ足しを続け、30年近くにわたって運用してきた当社ならではの事情もありますが、事業部門別に個別のデータセットやBIツールを運用することで複雑化したデータ環境は、事業部門を跨ぐデータ集計、分析の大きな弊害になっていました」

また複数のBIツールの存在は、異動の都度、新たなBIツール学習コストが生じることにもつながっていたという。

「当社に限らず、データの裏付けなしに新サービスを立ち上げることは今日ではまず考えられません。逆に言うとそれはデー

タ分析を通し、誰もが新たな価値を生み出せることでもあります。コストの問題以前に当社が事業を持続する上で、誰もがデータを利活用できる環境は極めて大きな意味を持つと考えています」（岩本氏）

　同社がまず行ったのは、Snowflakeによるデータ統合だった。その狙いを開発部門 技術戦略室 Data ScienceG G長の新井 駿氏はこう説明する。

レストラン情報や予約情報、提供サービスのアクセスログなどいったんAmazon S3に集約されたデータをSnowflakeデータレイクにロードした上で、データウェアハウス（DWH）やデータマートに格納するというのが新環境の基本的な考え方になる。データレイクへのロードではSnowflakeの「テーブルスキーマの進化機能」でカラム拡張に自動対応し、DWH等への格納ではSnowflake × dbtを活用することで、データ取り込みを大幅に省力化することも注目したいポイントの一つ。システム構築及びデータ移行は2024年1月からスタートし、同年内に完了している。

誰もがデータにアクセスできる環境の実現は、アクセス権限を持つユーザーだけがデータにアクセスできることと表裏一体である。データ移行にあたっては、データガバナンスも大きな課題の一つだった。開発部門 開発部 Back－office Service DevelopmentS Customer Base DevGの多積 直之氏は課題をこう説明する。

「当社では担当営業を通して加盟店様にサービスを提供している関係上、担当営業が地域の競合店のデータにアクセスできない仕組みの構築は不可欠な課題となっていました。アクセス権限のきめ細かな設定に、ロールなどデフォルト機能で対応できる点もSnowflakeの魅力でした」

Snowflakeによるデータ一元化と並行して、組織構造の見直しにも取り組んだ。縦割りで開発を行ってきたデータエンジニアリング部門とアプリ開発部門を統合し、プロジェクト単位でチームを編成する体制への移行したことはその一例である。

「双方のエンジニアがアジャイル開発の同一スプリントを協力して行うことで、部門を跨ぐ非効率的なコミュニケーションが不要になり、データの意義や本質がアプリ開発側に伝わらないまま開発がスタートするようなこともなくなりました。またSnowflake移行後は、簡易的なUI開発はデータエンジニアがStreamlit in Snowflakeで行い、APIエンドポイント開発はアプリ側エンジニアと協力して行うという分業体制をとることで、言語の壁を意識することなく開発が行えるようになりました」（岩本氏）

同社はエンジニアだけでなく、WebディレクションやUIデザインチームまで含めたクロスファンクションを推進した。その狙いを岩本氏はこう説明する。

「Webデザインではユーザーがどんな機能を多用するか知ることも大切で　　 す。以前はそうした情報を得るにはマネージャー層を経て別部門に問い合わせるほかありませんでしたが、クロスファンクション化によりこうした非効率的なコミュニケーションは不要になります」

誰もがデータを利活用できる環境を目指す上で、大きな障害になるのがコーディング知識に関する壁である。ビジネスユーザーが日常業務の一方、全社員の学習時間を確保するのはあまり現実的な選択肢ではないのが実情だ。こうした中、注目するのは、Cortex AIの新機能としてリリースされたCortex Analystの活用である。新井氏は言う。

「以前はユーザーのニーズに応じ、その都度データエンジニアが集計・分析を行ってきましたが、コストの観点からも全社的な展開が難しいのが実情でした。我々が目指すデータの民主化の推進には、自然言語でデータを集計し、分析が行える環境の実現が不可欠と考えています」

自然言語でStreamlitアプリに入力した質問をCortex Analystに転送し、AIがクエリを自動生成。Streamlitアプリがそれをデータセットに投げかけ、その結果をCortex Analystが分析し、Streamlitアプリを経由して返すというのがその基本的な考え方になる。それにより「2024年度の新宿エリアのレモンサワーの取扱い店舗数を月別に教えてください」という質問を投げることで、その答えを得ることが可能だ。

Cortex AnalystとStreamlit in Snowflakeの組み合わせにより、ビジネスユーザーの自然言語による問い合わせに応じたデータ分析を行う仕組みをいち早く構築した同社は、すでにその全社展開に向けた取り組みを開始している。Cortex Analyst導入を担当した開発部門 開発部 Back－office Service DevelopmentS Customer Base DevGの田 尚原氏はこう語る。

「今最も興味あるのはCortex Analystの進化です。それをキャッチアップして使いこなしていきたいと考えています」

さらにSnowflakeマーケットプレイスの活用も今後の課題の一つだ。岩本氏は言う。

「データ利活用を推進し、新たな価値を創造していく上では、自社データと外部データの組み合わせが大きな意味を持ちます。購入後すぐに新たなテーブルとして利用可能なSnowflakeマーケットプレイスで共有するさまざまなデータは、当社のデータに新たな付加価値を生むはずです」