飲食店向けに経営ダッシュボードを自動生成する「Airメイト」を、リクルートライフスタイルでは4人の開発チームで3カ月のうちに開発したという。このサービスがどのように作られているのかを、同社のサービス責任者が説明した。
リクルートライフスタイルが2018年春に提供開始予定の「Airメイト」は、飲食店向けに「インスタント経営ダッシュボード」を提供するクラウドサービス。BIでは当たり前のデータ入力あるいは抽出、加工など一切なしに、各店舗に関する各種経営指標をグラフィカルに可視化できる、ユニークなサービスだ。このサービスがどのように作られているのか、同社のエアレジ事業責任者、山口順通氏とエアメイトサービス責任者、甲斐駿介氏による説明に基づいて紹介する。
Airメイトは、店舗向けのBIサービス。2018年春に、飲食店および飲食店チェーンを対象として提供開始する。他の業界も将来は考えるが、飲食業で始めるのは、「課題が山積しており、また『Airレジ』のユーザーが最も多い業界だから」(山口氏)という。
このコメントからも想像できる通り、Airメイトは、Airレジのユーザー向けサービス。Airレジは無料のiPhone/iPad用 POSレジアプリで、既に31万件以上が利用しているという。注文入力はバーコード読み取りあるいはタッチでの選択により行える。レジ機能を無料で使え、レジ締めなど、売上管理に関わる作業が不要になるというのが売りだ。Airメイトはビジネスモデル的に、この無料POSレジアプリの利用によって自動的に蓄積される販売データを活用した、オプションサービスという位置付けになっている。
Airメイトが実現するBIで、データの入力や加工が不要なのはここに理由がある。Airレジからの情報により、各顧客のメニュー品目別売り上げが完全に把握できる。また、Airレジでは、リクルートライフスタイルが展開する他の関連サービスからの情報を集約、これらを連携させて自動的に分析できる。他には、「レストランボード」(空席情報と、ネットおよび電話を通じた予約を管理する台帳サービス)、Airメイトと同時発表の「Airシフト」(リクルートジョブズの「シフトボード」と連携する、シフト調整や給与計算の管理サービス)および「Airレジ ハンディ」(店員が持ち歩く各テーブルの配膳状況などの管理アプリ)などから、データを取り込むようになっている。
Airメイトでは、上記のデータを集約して自動的に分析、経営のヒントとなる指標をダッシュボードでグラフィカルに表示する。
店舗チェーンの場合、各店舗の売上目標達成率をグラフにプロットして示すことができる。売り上げに加え、人件費、原価率も確認できる。顧客については、曜日別の来客数やグループ別人数、ネット予約/電話予約/予約なし、リピーターかどうかといった種別で把握可能。各メニュー品目別の売上分析では、メニュー変更や価格変更の効果を知ることができる。さらに、ファーストドリンク提供までにかかっている時間や、店員によるおすすめの実行回数および成功率を通じ、サービスレベルをうかがい知ることができるようにしているという。
Airメイトが提供する情報の大部分は、日次で自動更新される。これに基づき、例えば店長は、当月の人件費を抑えるためのシフト調整や、接客改善などの対策がとれる。本部やオーナー、スーパーバイザーも、あらためて店舗に聞き取りをするなどなしに、それぞれの役割に基づく対策が打てるという。リクルートライフスタイルにとっては、「ホットペッパーグルメ」をはじめとしたネット広告サービスなどの利用につなげる効果もある。
Airメイトは、大まかには図のような構成で構築されている。Airメイトのサービス責任者である甲斐氏は、4人で3カ月のうちに、サービスを構築できたと話す。開発において、最も重要だと考えたのは、「数十万店舗のデータを瞬時にさばいてユーザーに届け、大量データの存在を感じさせない使い勝手を実現すること」(甲斐氏)だという。
リクルートライフスタイルでは、Airレジをはじめとしたサービスの運営拠点は、各プロダクトチームの判断に任されている。従って、単一のデータセンターやクラウドサービスに統一されているわけではなく、統一を進める動きはない。
Airメイトでは、これらのサービスのデータベースから、基本的には日次で情報を吸い上げ、Google Cloud Platform(以下、GCP)のデータウェアハウスサービスである「BigQuery」に集約するバッチパイプラインを構築している。データの変換・加工には、GCPの「Cloud Dataflow」を活用、各店舗・店舗チェーンの情報分析が即座にできるようにバッチ処理を実行している。
甲斐氏はサービス開始当初から、データウェアハウス機能でBigQueryを使うと決めていたという。これには技術的な理由と、人的な理由があったと話す。
技術的な理由としては、例えばAmazon Web Servicesの「Amazon Redshift(以下、Redshift)」の場合、まずインフラリソースを切り出して、特定構成のデータウェアハウスを構築しなればならない。しかし、Airメイトの場合、ユーザー数は将来100万件に達するかもしれない。また、扱うデータがどのように増えるかも、予測がつかない。Redshiftでは、扱うデータが増加すると、いったん構築したデータウェアハウスの構成を超えてしまう可能性がある。
一方、BigQueryでは、「特定スペックのデータウェアハウス(の箱)を構築する」という概念がない。このためいったん構築した後、データを事実上無制限に追加できる。データ量増大に伴うパフォーマンス低下も、心配する必要がない。「データウェアハウスの箱」を構築しなくてよく、設定はグラフィカルなインタフェースで実行できるため、事実上運用レスでもある。また、BigQueryの料金は、「Redshiftと比較して破格に低い」(甲斐氏)という。
ただし甲斐氏は、「最もやりたかったのは、Cloud Dataflowを使うことだった」と話す。
データ量がどれだけ増えても、データアクセスの良好なレスポンスを維持するためには、データをバッチ処理しておくのが王道のパターン。今後のサービス拡大を考えると、サービスプロダクト開発に関わる人が誰でも処理を書けるようにしておくべきだと考えた。
「Cloud Dataflowでは、数十行のPythonコードを書けば、データ処理が簡単にできる。プログラミングに詳しくなければ、SQLでもできる」
バッチ処理の数が増えても、パフォーマンスが低下しないという点も評価したという。
人的な理由としては、サービス開発に多くの人員を割くことができなかったため、当初からグーグルジャパンの協力を得て、定期的なミーティングを重ね、協力して作り上げられたことが大きかったという。
Copyright © ITmedia, Inc. All Rights Reserved.