snaqme Engineers Blog

おやつ体験BOX snaq.me エンジニアによる開発プロダクトブログ

11月のマイページアップデート情報

こんにちは、snaq.meでプロダクトマネージャーをしている渡邉(@nabepiyoo)です。 いつもsnaq.meをご利用いただき、ありがとうございます。

先日マイページでアップデートを行いましたのでぜひご確認ください。

リクエストページであなたにおすすめの商品が表示されるようになりました。

あなたにおすすめが表示されるようになりました。

リクエストページではあなたにおすすめの見出しで、おすすめのおやつが表示されるようになりました。

リクエスト済み一覧でラインナップに掲載されていない商品がわかりやすくなりました。

リクエスト済み一覧の表示変更

リクエストページにあるリクエスト済み一覧では、現在のラインナップに存在するものとそうでないものが紛れて表示されます。 今回のアップデートにより、現在のラインナップに掲載されていない商品は入荷予定として表示されるようになりました。

過去直近で苦手と評価したおやつをリクエストしようとすると、確認メッセージが表示されるようになりました。

過去に苦手と評価したおやつをリクエストしようとした時

過去に直近で苦手と評価したおやつをリクエストした時には、間違ったリクエストの可能性がありました。 今回のアップデートにより、一度ご確認いただいた上でリクエストするかどうか判断できるようになりました。

スナックミーではユーザの皆さんにおやつ体験をより楽しんでいただくために日々様々な改善を続けています。 プロダクトを成長させたいエンジニアを募集中です。

募集ポジション

エンジニアリングマネージャー / 株式会社スナックミー

プロダクトマネージャー / 株式会社スナックミー

ソフトウェアエンジニア Backend (lead) / 株式会社スナックミー

ソフトウェアエンジニア FrontEnd (lead) / 株式会社スナックミー

ソフトウェアエンジニア Data Engineer / 株式会社スナックミー

AWS DevDay Japan 2022 に「Amazon Pinpointを用いて、LINEとメール配信のCRM設計 」というタイトルで登壇してきました

AWS Dev Day Japan 2022 | AWSブレイクアウトセッション、B-2 「Amazon Pinpointを用いて、LINEとメール配信のCRM設計」というタイトルで登壇してきました

aws.amazon.com

運営の方々、ご覧になられ方、こちらを読んでみようと思った方々ありがとうございます。

登壇の資料

speakerdeck.com

発表の理由

背景として今年に入り CRM 担当の方が入社し、より一層CRMに力を入れるタイミングでもあったので、その取り組みや考え方などを共有できればと考えていました。

実際、CRM 担当者が入る前からCRMの基盤をアップデートの準備を進め、通知量も昨年に比べ 5倍以上 (一昨年だと20倍以上)の通知を実施しながら、チャーンは悪化せず昨年に比べ数%ほど改善(CRMだけでなくチームメンバーの取り組みでの結果)し、ストア (定期便以外での追加購入)なども2倍上げることができています。

などの背景があり、ここ数年は私自身事業フォーカスしていましたが、今年CfPを募集していることから久々に機会があればと思い、応募し無事採択されたので発表してきました。

最後に

今回の資料でなにか不明な点などあれば twitter (@miyoshihayato) までご連絡ください。

今回はCRM についてお話ししましたが、スナックミーは自社で製造や出荷・ユーザーさんに届けるためのサービスを概ね内製しています。ロジ周り開発やユーザーさんが利用するアプリケーション開発、データ基盤からMLなど全般的にエンジニアを募集しており、以下から興味あればご覧ください。直接私に DMでも構いませんのでよろしくお願いします。

engineers.snaq.me

おやつと、世界を面白く。」 一緒に面白くしたい仲間をお待ちしてます!!

meety.net

一言、二言

スタジオがすごかった (語彙力)

登壇後どうすれば良いかわからず、スッと帰路に着いたのでいろんな方に挨拶できずすいません。

マイページをアップデートしました

こんにちは、snaq.meでプロダクトマネージャーをしている渡邉(@nabepiyoo)です。 いつもsnaq.meをご利用いただき、ありがとうございます。

先日マイページでアップデートを行いましたのでぜひご確認ください。

マイページで昨日のおやつ評価ランキングを公開

毎日おやつの時間の15時にランキングが切り替わるようになっています。 ぜひランキングも楽しみながらリクエストの参考にしてみてくださいね。

昨日のおやつ評価ランキング
昨日のおやつ評価ランキング

避けたい成分を選択した時にお届けするおやつが分かりやすくなりました

避けたい成分を選択すると、それを考慮してお届けするおやつを選んでいます。 赤字で書かれている通り、焼き菓子については乳製品や小麦、動物性、卵などがよく使用されているため、お届けが難しくなります。

避けたい成分について
避けたい成分について

スナックミーでは日々大小様々な改善を続けています。 プロダクトを成長させたいエンジニアを募集しています。

募集ポジション

エンジニアリングマネージャー / 株式会社スナックミー

ソフトウェアエンジニア Backend (lead) / 株式会社スナックミー

ソフトウェアエンジニア FrontEnd (lead) / 株式会社スナックミー

ソフトウェアエンジニア Data Engineer / 株式会社スナックミー

スナックミーのエンジニアチームで直近動きたいこと (2022年10月)

こんにちは スナックミー CTO の三好 (@miyoshihayato) です
四半期ごとにチームに共有している直近動いていきたいことを一部変えてこちらのエンジニアブログに載せたいと思います。

エンジニアチーム内連携

当たり前のようなことを書いているかもしれません。

  • 毎週定例で進捗共有
  • リリースがあれば Slackにチャンネル共有
  • 関連するチームともアップデート状況を共有

上記のような動きを行っているが エンジニアチーム内連携 を今回のテーマにしています。

なぜ、このタイミングで当たり前のようなことをし始めたのか

  • 全社の社員数が30名ほどになり隣の人がやっていることが不透明になってきた
  • 各エンジニアが関わっているチームが様々あり、定例で共有しているがテキストベースでよく把握しにくい
  • チームにはエンジニアが概ね属しているがチーム間の架け橋になりきれてない (もっとできる)

などで簡潔いうと規模拡大による情報の不透明さを解消したい。ということになります。

弊社は製造から出荷、ユーザーさんが扱うマイページまで一貫として弊社で開発しています。エンジニアはあらゆるチームに属し、様々な観点でチームをサポートしたいと考えています。また、毎週数件システムのアップデートされ、数週間経過すると大きなアップデートもあれば、様々な検証が走ったり、可視化しているデータが増えたりしてます。このことはSlackのチャンネルに共有しつつもテキストや画像(たまに動画)ではよくわからず、社員全体にとって機会損失している部分があるのではないかと考え始めました。

エンジニアではないメンバーと会話しているとき、他のチームがどのようなことをしているのか、どういうことを大事に考えているのか知りたいという声を聞く時があります。その声を受け今年から不定期ではありますが、オンボーディングの一環としてチームの共有会を行なったりしています。この取り組みにおいて参加できるメンバーは積極的に参加してくださり、評判はよいと感じるところがあります。このような取り組みをより一層強めて、新しく入るメンバーや現メンバーがスムーズに動けるような連携をはかりたいと考えています。

その中でエンジニアチームからできることを今回ここに書かせていただきました

system sharing meeting

システムの共有会を隔週実施。こちらを新規で行う取り組みになります。 毎週 win-sessionという全社に向けて各チームの進捗共有を行っていますが、こちらはシステム関するアップデート情報をよりイメージしてもらう会になります。

目的

  • エンジニア間のシステムの共有
  • 利用される方の機能理解
  • 他チームの状況把握 (こんな取り組みしているんだなど)
  • 全体に進んでいる感をより出す

などになり、スナックミーは オペレーション(製造・出荷) 商品開発 パティシエ マーケティング デザイナー (UI/UXからパッケージまで) CS CRM バックオフィス など様々な役職がおり、それぞれが合わさってsnaq.meというサービスを展開しています。また、今年の4月から直営店オープン、ファミマ!!様、ナチュラルローソン様など含めたオフラインの展開など少しずつですが、オンラインのだったサービスからオフラインでもスナックミーの商品を手に取りやすくさせたりしてます。それらをしっかりシナジーを生みながら会社・チーム・個人と成長していくためにエンジニアがしっかりハブとなって推進できるように取り組んでいきたいと考えています。

まとめ

スナックミーは「おやつと、世界を面白く。」のもと事業を展開し、チームスナックミーとしてスナックミーに携わっているメンバーと一緒にいろんな形でフォローし合いながら目標に向かってお仕事をしています。

エンジニアは業務委託を込みで10名超えた人数で開発し、事業もオフラインなども含めて新しい取り組みも始めています。その中で少しでも興味持った方カジュアルにでもお話ししませんか?TwitterのDMの、以下のmeetyでも歓迎です。また、直接応募も受け付けています。

フロントエンド、バックエンド、データエンジニアにエンジニアリングマネージャー幅広く受け付けてます。

おやつと、世界を面白く。」 一緒に面白くしたい仲間をお待ちしてます!!

meety.net

engineers.snaq.me

募集ポジション

エンジニアリングマネージャー / 株式会社スナックミー

ソフトウェアエンジニア Backend (lead) / 株式会社スナックミー

ソフトウェアエンジニア FrontEnd (lead) / 株式会社スナックミー

ソフトウェアエンジニア Data Engineer / 株式会社スナックミー

NG登録が60個までできるようになりました

こんにちは、snaq.meでプロダクトマネージャーをしている渡邉(@nabepiyoo)です。 いつもsnaq.meをご利用いただき、ありがとうございます。

先日マイページで見えないアップデートを行いましたのでぜひご確認ください。

マイページでNG登録数の上限を拡大

NGリスト画面

この度60個までNG登録できるようになりました。

「マイページ」では届けてほしくないおやつがあれば、NG登録することができます。 リクエストページで該当商品の画像をタップし、最下部の「NG登録する」をタップすると可能です。

ぜひNG登録も上手にご活用いただいて、おやつ体験をお楽しみください。

MVPから始めるデータ基盤の構築 ~AWS MWAAを利用した安定運用に至るまで~

こんにちは、スナックミーでデータエンジニアをしている加藤です。

スナックミーではここ最近、データ利用に対する注目度が高まってきています。 それに伴い構築を開始したデータ基盤が安定運用できるようになってきたので、今回はこのデータ基盤について構築当初から安定運用までを振り返ってみたいと思います。

データ基盤の重要性

簡単にデータ基盤について書いておきます。

意思決定のための分析や現状をモニターするためなど、様々なデータ利用の用途に対応するためには利用しやすい形でデータが整備されている必要があります。

整備がなされていないと、どうやって目的のデータを取得して良いかわからなかったり、データを取得したいのにクエリが重すぎてかけることが実質不可能になってしまったり、データ利用の効率や広がりに悪影響しかありません。

そうしたデータの効率的な利用や整備されたデータの蓄積・管理のためには、ある程度コストを投下してデータ基盤を構築することが重要になると考えています。

構築前: 整備されていなかった状態

かなり簡略化していますが、構築前は以下のような構造になっており、下に挙げるようないくつかの問題が発生していました。

重たいクエリ・取得できないデータ

弊社ではデータの社内での可視化にRedashをメインに使用していました。 そしてRedashのデータソースとして主に、本番DBとして稼働しているAuroraとログ系などを集積しているS3をAthena経由でクエリできるようにしているものがありました。

そのため、Auroraに対してクエリをかける場合はものによってはクエリが重く負荷をかけてしまったり、Athenaの場合は元がログなどの非常に大量のデータであるため重すぎてRedashで可視化することが難しかったりしていました。

業務アプリ用DBと分析用DBの違い

次にデータを分析しようとなった場合の必要なデータの形式の違いの問題もありました。

例えば以下の画像のようなユーザーの会員ステータスを管理するテーブルがあった場合、アプリケーションのDBでは今の状態が分かることが重要で過去データは特に必要にならないケースも多いです。 大して、例えばユーザーの会員動向を分析しようとする場合にはそうしたステータスデータもヒストリカルにログデータとして扱いたいことが多々あります。

もちろん、アプリケーションDBにおいてもログのような形を取って最新のものだけ扱ったり、別途履歴テーブルを用意したりすれば解決するかもしれませんが、必要に迫られる頻度が少ないデータソースについてはそうした対策を取っておらず、分析的に扱いづらいデータがいくつもありました。

独自に集計されたスプレッドシートの山

上の構成図のところでスプレッドシートが登場していることに気づいた人もいるかもしれません。 スプレッドシート、便利ですよね。扱いも簡単だし、共有もすぐにできるし。

けれど、多重参照や複雑な関数の入れ子が発生すると途端に職人技が必要になるものへと変貌します。

弊社でも、Redashからダウンロードしたデータをスプレッドシートで再集計して管理する、などといったことが行われていました。

結果的に、同じようなデータがやや異なる集計ロジックによって重複してしまったり、値を定数で入れてしまったために元の値がなんなのか分からなくなってしまったりということが発生していました。

ローカルを交えたMVP的な動き

さてここからは実際に構築へ向けて動き出してからの話になります。

しかしながら、どんなアーキテクチャにするのか?どの技術リソースを使うのか?テーブル構造はどんな戦略でいくのか?などなど、考慮すべきことがたくさんあります。 加えて、構築に時間はかかるけれどデータを利用したい側の需要は待ってくれません。構築に時間をかけるほどに本番DBに負荷はかかり続け、スプレッドシートは量産されていきます。さらには社内的な理解を得るためにも早急にMVP的なものを作って動かしていく必要があると感じていました。

そこで、以下のような構成でMVPとして、速さ優先で実稼働させることを意識しました。

Redashから各人が各々データを引き出していたところを、RedashAPI経由でローカルPCでデータを取得し、加工・整理してからスプレッドシートAPIスプレッドシートに格納しています。そしてこれを早朝などにバッチ処理として実行し、最終的なデータの可視化にはGoogle DataPortalを利用しました。これにより、データをグラフィカルにダッシュボードとしてモニターすることができるようになりました。

またスプレッドシートに再格納する際、データウェアハウス・データマートとしての区別・構造を意識してデータ整備も併せて行なっていたため、分析用途で大規模なデータを取得する場合にも役立つことがありました。

そして何より、この形で爆速でMVPとして動き始めることができたことで、データ利用者側の需要やどういう可視化が必要とされていて、そのためにはどのようなテーブル構造が適しているのかなど、利用面の調査を兼ねることができたのが大きかったです。時間をかけて基盤を作っても誰にも使われないのでは意味がありませんからね。

当然いくつも問題点はあって

  • 結局本番DBには接続してしまっている
    • これについては、この処理の実行を早朝にすることで、ひとまず常時負荷がかかる状態は回避することにしました。
  • スプレッドシートの増加
    • スプレッドシートの数だけ見ればそうなんですが、ロジックによって管理されているのでどのデータソースからどのシートへとデータ挿入されているのかが追えるという点でそこまで大きな問題ではないと考えていました。
  • セキュリティ面
    • これが一番ですね。ローカルPCでゴニョゴニョしてしまっている点については、いったん仕方ないと受け入れて目をつぶることにしました。

AWS MWAAを活用したデータ基盤の構築

そんなこんなでMVPの運用をしてイメージを固めつつ、実際の基盤構築を並走して行いました。 見出しにもある通り、ワークフローエンジンにはAirflow (AWS MWAA) を利用し、ウェアハウス製品にはBigQueryを利用することに決めました。

MWAAを選んだ理由としては、初期のキャッチアップコストはかかるものの拡張性が高く、データのやりとりに関する管理がしやすいことが最大の利点でした。また弊社ではほとんどのリソースがAWS上に存在しているので、MWAAを利用すれば種々のサービスとの接続がしやすいことも魅力でした。

ウェアハウスについても今となってはRedshift serverlessが候補に上がりますが、当時はコスト的にBigQuery一択だった感じですね。

少し記事が長くなってしまったので、構築の困った点やポイントなどはまた記事を分けて書こうと思いますが、現在は以下のような構成になっています。

課題を解決した点は以下です。 - 本番DBからは夜間バッチでBigQueryにデータをコピーし、後続ではコピーされたBigQueryからデータを取得するようにしているので、本番DBには負荷がかからなくなった - ログ系など、S3に大量に収集されていた非定型含むデータもAWS Lambdaでの処理を挟むことで扱いやすくなった - データマートの整備によって、各人ごとにバラバラだった集計処理を一元化した - Redashでのアクセスについても、重たいクエリであってもウェアハウスに対してであればデータが取得しやすくなった

などです。加えて開発面で言えば

  • SQLによる処理について、コードを全て一元管理できるようになった
  • データウェアハウス、データマートの拡張については、非常に簡単に行えるようになった
  • 全体を一つのワークフローで管理するようになったことで、これまで一切考慮できていなかった冪等性やリトライ、エラー検知がやりやすくなった

基盤管理しているデータは日に日に増えており、今では5つのチーム (5つのダッシュボード)、約300テーブルほどのデータマートが運用されています。

データが扱いやすくなったことで、各チームのMTGで必ずダッシュボードを見る習慣をつけてもらったり、そこから現状の把握や次の施策への考察が生まれたりなど、より良い循環が生まれていると感じています。

今後もさらにデータ基盤を拡張させていき、データ利用を促進していきたいと思っています。

最後に

今回はデータ基盤の構築について振り返ってみました。 記事中でも書きましたが、現状動いているデータ基盤については別に記事を書いて詳細を説明していこうと考えています。

データ周りの業務はうまく各チームと連携できれば、実際の意思決定と密接に関わることができるので非常にやりがいを感じられる分野です。

スナックミーではデータ周りの開発業務を担当してくれるデータエンジニア募集しています! 興味があればぜひお話しを聞きにきてください!

meety.net

engineers.snaq.me

おやつの出荷作業の歴史

snaq.meでは一人ひとりの嗜好に合わせて8種類のおやつをお届けしています。

パーソナライズ = 自分好みのおやつをセレクトしてくれる

と感じれる一方

  1. 選ぶのが難しそう
  2. 出荷作業が面倒臭そう
  3. 作るのが大変そう

など裏側のオペレーションは思っているよりタフな仕事が多いです

1~3において全て内製してシステムを開発し、今回は 2 の 「出荷作業が面倒臭そう」という観点について遍歴を書いていきたいと思います。

サービス当初 2016年3月 ~

サービス当初はお届け後に評価はできることを最低スコープとして考えいたため、

  • 商品
  • 配送商品

を登録できる基幹システムは最低限構築していました。登録できる後に行うことフローとしておやつをピッキング(出荷作業)になります。当時のピッキング

  • ロケーションID不使用 (どの場所にどのおやつがあるかという住所のようなもの)
  • 机におやつを広げ基幹システムと照らし合わせながら一つひとつ目視しながらピッキング

というフローでやっていたので、数十BOX発送準備するだけでも1日かかっていました。

ロケーションID・短冊時代

全て手動で行っていた当初から少しずつシステム化していきましたが、ピッキングに関してはまだ手動になります。その中でも進化したところが、基幹システムと照らし合わせながらピッキングしていた時代から短冊を片手にピッキングする時代へと変化しました。

この短冊には

  • 最低限のユーザー情報
  • アサイン(商品を選ぶところ)情報
  • ロケーションID
  • メモなど

が記入された短冊を用意してました。

このことにより、ピッキングの効率は少し上がり、ミスも少し減ってきましたが、まだまだアナログ感満載でした。というのも短冊と宛名ラベルの一致が必須だったため、目視の作業は変わらず心理的安全性は決して高いものではありませんでした

音声ピッキング時代

上記のようなピッキング作業では効率の部分やミス、作業自体の難易度から音声ピッキングの導入の話が社内で上がってきました。

音声ピッキングとは

個々のバーコードを読み込むことでユーザー毎にどの商品を選ぶか音声を流しピッキングしていくこと

このことにより、音声に従っていくので、ピッキングミスがほぼなくなり、初めの方でも数時間でピッキングの概要を掴めるようになります。

音声ピッキング導入により1日で出荷できる数を数千個まで上げることが可能になりました。

音声ピッキングの他のメリットは

  • 在庫をリアルタイムで把握可能
  • 欠品商品の把握
  • 個別に同梱資料を振り分けられる

などになります。

複数在庫エリア時代

ありがたくもユーザー数が増えてくると1箇所の在庫スペースだとどうしても捌ける数にも限界があります。理由は物理的なスペース、1人あたりの出荷効率から1箇所で出荷できる数に限度があるため、一人当たりの対応数はある閾値で下り坂になります。そうなると用途などに分けてピッキングすることが必要でした。

そこで運用し始めたのが複数在庫エリアになります。

詳しいことは以下をご覧ください

labs.snaq.me

まとめ

ピッキング作業は手動から音声ピッキングへ社内で開発し進化を進めています。

オペレーションチームと日々関わると、オペレーションチームはどうやって効率を上げ、無駄なコストはないか、ミスなき運用はできないのかなど考えているのでシステム作る側もその思考についていくのに必死になる時があります。というのも改善をエンジニア同様日々繰り返しているので今日話した仕様は来週になるとアップデートしていたりします。そのため、日々のコミュニケーションを大事にしないとすれ違う物を作りかねないのです。そのくらいスピード持ちながら、考えています。 また、オペレーションチームは上記外にユーザーさんのことを考え仕事をしています。どうやったらオペレーションの観点から体験向上に繋がるのか、こういう取り組みをすると喜ぶのかなどの視点も持ちながら行っています。

オペレーションとエンジニアではいい意味で異なるところがあります。例えば、オペレーションはおやつというリアル目に見えるもの扱い、エンジニアはコードやデータを扱うのでどうしてもアプローチが異なる場合が多くあります。その中で、しっかりスクラムを組みそれぞれの強み活かしながら開発していくことでこのピッキングシステム以外にもさまざまな物をオペレーションと開発しています。

まだまだ、道半ばですがオペレーションチームと一緒におやつと面白くしていきませんか? 少しでも興味を持った方はぜひ一度カジュアルにもお話ししましょうー

弊社では 「おやつと、世界を面白く。」 一緒に面白くしたい仲間をお待ちしてます!!

meety.net

engineers.snaq.me