おやつのサブスクリプションサービス「snaq.me」のサービス解約率を下げる仕組み

おやつのサブスクリプションサービス・「snaq.me」

司会者：では、続きまして、株式会社スナックミーCTO & co-founderの三好さんにご登壇いただきます。では、よろしくお願いします。

三好隼人氏（以下、三好）：これから、「AWS Step Functionsによるおかしのアサインシステム」について発表させていただきます。スナックミーの三好と申します。よろしくお願いします。

スナックミーについて簡単にご紹介させていただきたいと思います。スナックミーとは、Real Foodで作った、おいしくてカラダに優しい、一人ひとりにカスタマイズしてお届けするサブスクリプションのサービスです。よく最近耳にすると思うんですけど、B2Cの会社です。

特徴の1つとして、製造から発送の準備まで一貫して行っている点があります。

どうやってカスタマイズするかといいますと、ユーザーからフィードバック、評価やリクエストなどによって、弊社の独自のアルゴリズムによっておやつを選んでいます。

ここで1つ大事なことがあって、「サブスクにおいて大事なKPIとはなにか？」とあります。例えば売上とか粗利とか、おやつなので品質とか、いろいろあると思うんですけれども、私たちはチャーンレート（解約率）を下げることを第一に考えております。

チャーンレートが低いということは、満足度が高いと同じことが言えると思います。これを下げるためにどうしたらいいのか。アクティブユーザーを増やしたり、リクエストをしてもらったり、評価してカスタマイズの精度を上げたりというものがあると思うんですけれども、私たちは、おもしろいデータとして、リクエストという項目を見ています。

弊社には、リクエストした商品を100パーセントお届けする保証はありません。というのも、弊社はフードロスにも積極的に取り組んでおりますので、在庫過多を防ぐようにしています。

そのため、リクエストをすることによって商品が届いて、満足してもらって、もう1回リクエストをするという、このリクエスト率とアクティブユーザーを増やすことがチャーンレートを下げるんじゃないかと考えて、取り組んできました。

リクエストに応えるにはどうするかといいますと、この画像でいうと、おやつのお届けを決定する部分ですね。つまり、アサインシステムの強化と効率化が大事になってきました。

アサインシステムについては、このようになっております。とてもシンプルに、AWS Step FunctionsのフローにAWS BatchやAWS Lambdaを乗せて行っております。

複雑なアサインパターンの管理や業務の効率化に貢献

このAWS Step Functions、ここだけ覚えてもらっていただければ、本日はもういいかなと思っておりまして。なぜこのAWS Step Functionsを用いているのかといいますと、アサインパターンが複雑化している点があります。

ユーザーをクラスタリングしたアサイン方法だったり、配送パターンの増加、そして毎日のようにアサインをしているので、アサイン方法が複数あったりします。

このアサインパターンの複雑化をどう管理していこうかと考えたときに、ちょうど昨年のAWS re:Inventで、AWS Step FunctionsとAWS Batch、あと、その他7つのマネージドサービスとの連携が可能になったということで、格段にAWS StepFunctionsの利便性は上がったのかなと考えております。

上がる前、連結する前と後でどう変わったかですが、1つAWS Batchの例で挙げますと、BatchのジョブのステータスをAWS Lambdaでポーリングする必要性があります。

ですが、連携後に関しては、このようにとてもシンプルにまとめることが可能になります。このことによって、メンテをするあたりにおいても、すごくやりやすくなったかなと考えております。

また、それぞれ疎結合なので、独自のアルゴリズムを簡単に試せる仕組みになっています。時間によってはAWS Lambdaに入れ替えることも可能にしてあります。

これはWell Architectedの視点で言いますと、5つあります。それぞれ1点ずつ言っていきますと、AWS BatchとAWS Lambdaを実行時間によって使い分けたり、AWS Step Functionsで一元管理していますという点。あと、AWS IAMとAWS GuardDutyでアクセス制御やトラフィックのモニタリングをしています。そして、job間が疎結合なので、障害を極小化することが可能になっております。そして、その全体のワークフローのモニタリングをAmazon CloudWatchで行っております。

あらためて、このシンプルなアーキテクチャになりました。

ビジネス的な貢献度はどうなのかといいますと、手動の時間が週5時間削減、そしてチャーンは最大値から4パーセント削減することができました。リクエスト率やアクティブユーザーに関しては、昨年から10パーセント向上しております。また、その新しいアルゴリズムを容易に試すことができるので、さらにこのへんの数字は改善していけるのかなと考えております。

いろいろお話ししましたけれども、もう一度。AWS Step Functionsで快適なワークライフをということで、ご清聴ありがとうございました。

サービスの解約率を下げることができたロジック

司会者：三好さん、ありがとうございました。

（会場拍手）

では、審査員のみなさま、どうでしょうか？

井戸端洋彰氏（以下、井戸端）：発表ありがとうございました。質問が2つあります。1つが、ユーザーのクラスタリングやセグメントを切る条件は、誰がどうやって考えて設定しているのか。あと、これをやったことによってチャーンが下がったというロジックがちょっとまだよくわからなかったので、説明をしてもらってもいいでしょうか？

三好：この仕組みを考えたのは基本的に代表とエンジニアで、一緒に考えて実装をしております。また、オペレーションのほうでも案が出た場合は、積極的に取り入れてテストするというかたちをとっております。

井戸端：じゃあ、新しいユーザーセグメントを作りたい場合は、それを毎回AWS LambdaとかAWS Batchに実装するというかたちになるんですか？

三好：そうですね。比較的リソースの変更は簡単になるのかなと思っております。

井戸端：わかりました。次の質問は、これをやったことによるチャーンの減少のロジックがあまりよくわからなかったので、すみません。もう1回教えていただければ。

三好：1つはリクエストの対応をする仕組みを作れた点と、リクエストの対応できた点。そのアルゴリズムを最短で1日というスピードで試したりもできるので、そこによってチャーンレートを下げることができたのかなと考えております。

司会者：はい、よろしいでしょうか。では、三好さん、どうもありがとうございました。もう一度拍手をお願いいたします。

（会場拍手）