リクルートライフスタイルの技術力を追え!

第7回[データ活用編]Airレジにおけるデータ分析とその基盤

高価なPOSシステムを購入することなく、iPadにインストールするだけでお店の運営や経営改善に活用できるアプリが「Airレジ」です。さらにこのアプリでは、操作ログをはじめとする多種多様なデータを分析し、それをビジネスに役立てています。ここでは、その取り組みをリードするリクルートライフスタイルの井原真吾氏写真1⁠、そしてリクルート全体のデータ分析基盤の開発・運営に携わる前田周輝氏写真2に、どのようにデータ分析を行っているのかなどについて伺いました。

データ分析結果をもとにきめ細かくユーザをフォロー

――Airレジにおけるデータ活用の取り組みの内容を教えてください。

井原氏:リクルートライフスタイルでは、iPadで使えるPOSレジアプリである「Airレジ」を提供しています。このAirレジにおいて、データを使って顧客接点や営業活動の効率を徹底的に高めるための取り組みを進めています。

具体的には、たとえばAirレジにアカウント登録した人を毎週クラスタリングするといった施策があります。この人はいきなりAirレジを積極的に使い始めるロケットスタート型、この人はテストだけをしている、この人たちは離脱してしまいそうだ、といったように分類します。そのうえで、あるクラスタに属している人には電話でこういった内容の会話をする、あるいはデータの分析結果から離脱する可能性が何パーセント以上になった人には電話でこういうふうにフォローするというように、実際の活動内容に落とし込んでいます。こうしたデータを活用した施策をものすごく速いサイクルで実施しました。

写真1 井原真吾氏
写真1 井原真吾氏

データを分析して検討を進め、その結果を開発に落としてプロダクトに反映するといった活動は、多くの企業で取り組まれていると思います。ただ、それによって新たな機能をプロダクトに組み込んでも、競合相手にそのままマネされることも十分にあり得ますよね。それに対して私たちが取り組んでいるのは、データの分析結果から指標を作り、それをコールセンターや営業の現場と共有して顧客とのコミュニケーションを変えるといった施策です。競合相手から見ると、その施策の背景にどういったロジックがあるのかわからないし、データがどう使われているのかも見えないため、競合優位になりやすい。しかもリクルートグループの強みである営業を中心としたオペレーションの力を活かすこともできます。Airレジにおいてデータ活用を進めることにした背景には、こういった考え方がありました。

インプットと分析、アウトプットで役割を分けてチームを編成

――どのようなチーム体制でデータ分析を行っているのでしょうか。

井原氏:データの活用にはいくつかのステップがあると考えています。まず仮説を立て、その検証に必要なデータを収集し分析して指標化する。そこで仮説が間違っていないと判断できれば、分析に必要なデータを定常的に取り込めるしくみを作る。アウトプット側もしくみ化して、現場でルールを作り、それぞれの人が分析結果に基づいてアクションを起こせるようにする。データを活用するには、こういったステップが必要になると考えています。

これらのステップのうち、データサイエンティストががんばる必要があるのは、分析や指標化の部分だけだと思うんですね。一方、最初にデータを集めたり、データのインプットやアウトプットをしくみ化したりする作業はエンジニアの領域ではないでしょうか。このように、ひとくちにデータ分析といっても、それぞれのステップで求められるスキルセットは異なります。それにもかかわらず、データサイエンティストにすべてのステップを丸投げしてプロジェクトが回らなくなるというケースは珍しくありません。

そこでAirレジでは、それぞれのデータ分析の案件に迅速に対応するために、インプットと分析、アウトプットの各ステップでメンバーを分け、チームとして対応する形にしました。このように役割を分けることで、さまざまな案件に迅速に対応できるようにしています。

特にスピード感にはこだわっています。僕たちは爆速以上のスピードで動くんだという意味で「神速」という言葉をよく使っているのですが、たとえばコールセンターから「こういうデータがあれば、現場の動きを変えられる」という話があれば、翌日にはWebブラウザから参照できるように環境を整える。このように、体制を含めて現場からの要望にすばやく応えられるしくみを作っています。

データを“開発”して磨きさまざまな用途で活用する

――分析の元になるデータは、どのように集められているのでしょうか。

前田氏:「Capture EveryThing」というプロジェクトで、データから新しい価値を生み出すために、従来型のデータベースに記録されているPOSっぽいトランザクションデータだけでなく、構造化されていないデータも扱いましょうというプロジェクトが走っていたんです。そこでカラムとかも決めずに、まさにスキーマレスでまずぶち込んでしまえと。分析を行う後工程で加工に苦しむかもしれないと思いつつ、まずデータを失うことなくすべて取得することから始めました。

写真2 前田周輝氏
写真2 前田周輝氏

データを使う人が近くにいるし、僕自身も分析を行うので、データがどのように利用されるのかも見えてきました。そこで基本的には「Capture EveryThing」なのですが、もうちょっと後工程を意識したオブジェクトを設計する形に変わってきている状態です。

また私たちのチームは、リクルートライフスタイルの全体的なリアルタイムデータ分析のための基盤を開発しています。そこでもAirレジのデータ分析チームと同様に、インプットと分析、アウトプットのそれぞれの役割を持つメンバーが集まり、1つのチームとして活動しています。これにより、たとえばマシンラーニングをやっている人にこうやってデータを渡せば、そのあとのデータ加工がスムーズに進められるといった対応がやりやすくなり、スピードや精度も上がっています。

その中で意識しているのは「ワンソース・マルチユース」です。プロジェクトのデータを資産と考えた場合、捨てるなんてあり得ない。また、データが置きっぱなしだと劣化していくので、データ開発という考え方を入れてデータをしっかり磨く。そうすると資産としての価値が向上するので、価値が上がったデータを活用する場所を増やしましょうと。これがワンソース・マルチユースの基本的な考え方です。

井原氏:データの種類も非常に多かったのは、このプロジェクトの特徴的な部分かもしれません。定性的なアンケートの結果から、コールセンターがどのユーザに対して、何月何日何時何分に何分くらい電話をかけたのか、そのときどういった内容を話したのかといったことまでデータとして記録しています。場合によっては、それに形態素解析をかけて分析するといったことも行いました。まさに操作ログのようなわかりやすいビッグデータから、アンケート結果のような定性的なデータまで、本当に幅広いデータを利用しています。

データ分析でわかった意外な“落とし穴”

――幅広いデータがあることで可能になった分析としては、具体的にどういったものがありますか。

井原氏:わかりやすい事例でおもしろかったのは、ユーザがどの部分の操作でつまずいているのかを調査したときです。コールセンターからユーザに電話をかけたとき、どういった内容の話をすると僕たちが望んでいる指標が上がるのかを調査したんですね。ユーザがAirレジを使い始めるとき、メニューの登録などの作業に結構時間がかかるので、そこで最初につまずく人が多いだろうという仮説を持っていたんです図1⁠。

しかし実態はそうではなかった。実は、コールセンターから電話をかけて話した内容で最も指標が上がったのはiPad自体の設定だったんですね。つまり、Airレジの世界に入る前の、iPadの設定で詰まっている方が多くて、そこをフォローしたほうが指標が上がるということがわかりました。そこでマニュアルを見直して、iPadの設定自体から説明するようにしました。

このように自分たちの思い込みを解消することにもデータ分析は役立ちますが、そのためには複数のデータを合わせて見ていく必要があります。お話した事例であれば、僕らが望むような行動をユーザがしているかどうかを示す操作ログのデータと、コールセンターがユーザとどのような会話をしたのかという記録が結び付かないと分析できません。そのため、さまざまな情報を集めていくことが重要だということです。

図1 Airレジのメニュー登録画面
図1 Airレジのメニュー登録画面
最初、このメニュー登録でつまずくユーザが多いと考えていたが、実際にユーザが手間取っていたのはiOSの設定だった

Google Cloud PlatformのBigQueryを積極的に活用

――分析のために利用するデータは、どのようなシステムで収集しているのでしょうか。

前田氏:データを集めるために使っているのはおもにFluentdで、そこからクラウド環境に投げています。クラウドはAmazon Web Services(AWS)とGoogle Cloud Platform(GCP)を併用していますが、最近はGCPを使うことが多いですね。FluentdからGCPのPub/Subに入り、そこからDataproc(Spark)でリアルタイム演算や機械学習をした結果をBigTableに入れています。最終的にはレコメンドAPIや収益予測APIといったマイクロサービスとして施策に利用されます図2⁠。

それぞれのクラウドには強みと弱みがあるので、違いを確認しながら使い分けています。たとえば、BigQueryはRedshiftに比べて大容量をさばけるけど、Updateが使えなかったり、一方でRedshiftはストリーミング的な書き込みが弱かったり。課金方式も大きく異なるため一長一短があります。

図2 システム構成図
図2 システム構成図

2つのクラウドサービスを使い分ける意義

――複数のクラウドを使い分けるのは、運用負担も大きいのではないかと思いますが、そのあたりはどのように考えていますか。

前田氏:たしかに負担は大きいです。ただ、昔のように役割の明確なソリューションを組み合わせて、かぶりなくアーキテクトできる時代ではなくなったと考えています。たくさんのツールがあり、それぞれに得意分野がある、しかもスイートスポットが結構小さい。アーキテクトとしてそれを見極め、レベルを上げていくことを考えたとき、1つの環境だけしか触っていないことのリスクは大きい。またディザスタリカバリのように、データを分散することで得られる価値もあります。その両方の視点から、クラウドを使い分けているのが現状です。

それと、これから期待しているのがGCPコミュニティの盛り上がりです。AWSコミュニティの活動は活発ですが、GCP界隈も盛り上がりつつあります。実際、AWSをやっていたエンジニアがGCPにコンバートするケースもありますし、ベンチャー企業がいきなりGCPを選ぶ例もあります。そういったエッジの効いたエンジニアとミートアップできる。私たちは、このような視点でもクラウドサービスをチェックしています。

これからのチャレンジはリアルタイムなデータ活用

――リクルートライフスタイル社内では、現場の方々もデータ解析ソフトのTableauを使ってデータ分析を行っていると伺いました。Tableauを使いこなすのはなかなかハードルが高いと思うのですが、どのようなブレークスルーがあったのでしょうか。

前田氏:もともと、ビッグデータを民主化しようというプロジェクトがあり、そこには意志決定のスピードを上げたいという思いがありました。ただし、BIツールを入れて「セルフでやってください」だけでは何も変わりません。BI用に最適化されたデータモデルを開発したことと、小さな成功体験を積み重ねること。この2つがブレークスルーのポイントだったと思います。事業ドメインごとにデータを開発し、Tableauを使って従来とは異なるスピード感と高度な分析を1つずつ実現していく中で、気が付いたらフォロワーが増えて社内に浸透していったというイメージです写真3⁠。

写真3 Tableauの画面
写真3 Tableauの画面
「ビッグデータを民主化」するために使われている「Tableau⁠⁠。前田氏はTableauのユーザ会で会長も務めている
――最後に、今後のチャレンジで検討しているものがあれば教えてください。

前田氏:今まさにチャレンジしようと考えているのが、リアルタイムなデータの活用です。リアルタイムのデータ分析は技術的な難易度が高くて、これまであまりチャレンジできていなかったんですね。しかし、生み出されたばかりのデータは、その下流が四則演算だけといったような簡易ロジックでも有益な結果を生み出せることが見えてきました。このようにリアルタイムデータが非常におもしろいことがわかってきたので、そのためにも低いレイテンシでデータを取得する、そのための技術力を磨いているところです。

井原氏:以前のデータ分析は、レコメンドやメールマーケティングなど、実装する先がわかりやすいシステムで、これをやればよいというのも明確でした。しかし今は活用先が多様化して、さまざまな分野でデータ分析が行われるようになりつつあります。このようにニーズが広くなれば、データ開発のためのROI(Return On Investment、投資収益率)もどんどん低減していくんですね。それによって成果が生まれれば、データエンジニアリングにリソースを投入していくことができます。そのため、データを分析して活用する、その領域をどう広げていくかが重要なところだと感じています。

画像

おすすめ記事

記事・ニュース一覧