snaqme Engineers Blog

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

第2回【社内LT会】を開催しました🎉

こんにちは。スナックミーでエンジニアをしているタク(@yamataku3831)です。

つい先日、前回に引き続き【社内LT会】を開催しました!今回は業務委託メンバーも多く参加してくれて、前回以上にワイワイしながら情報発信を行うことができました。

スナックミーらしくおやつを楽しみながら…

前回の社内LT会も盛り上がりはしたのですが、ごく一般的なLT会になってしまい、もう少しスナックミーらしさを出すことはできないかな…と思っていました。

スナックミーはおやつを取り扱っているスタートアップであるということと、そもそもアウトプットのハードルを下げるために始めた社内LT会であるということを考慮して、おやつをもぐもぐしながらリラックスした雰囲気でやってみることに!

食べながら参加というのがよかったのかはわかりませんが、前回よりも相互のコミュニケーション量が多く、終始和やかな雰囲気で会を進めることができました!この会をきっかけに、アウトプットのハードルがどんどん下がっていけば本望だなと思います。

ちなみに業務委託で手伝ってくださっている方のひとりに、マレーシアを生活の拠点とされている方がいらっしゃるのですが、マレーシアの伝統的なおやつを紹介してくださいました!

鮮やかで綺麗なニョニャクエ

「ニョニャクエ」という名前の甘いおやつで、米やタピオカ、ココナッツなどが使われているようです。カラフルな色が特徴的なのですが、花や植物などの天然色素を使って色づけしているので、体にもやさしいとのことでした。食べてみたい!

発表内容

僕の考えた管理画面とLambda の開発環境

発表者:岩田(スナックミーをしっかり支えてくれているパートナー)

岩田は約2年前から業務委託として一緒に働いているパートナーで、今日に至るまでずっとシステム開発を助けてくれています。

正社員とパートナーには、セキュリティ観点により、主に権限やデータ周りでお渡しできるものが異なります。それが理由で、パートナーにとってどうしても動作確認や開発を行いづらい部分が存在してしまいます。

そんな中、開発しやすい環境を自発的に構築していた彼が、他のパートナーも開発しやすいようにとわざわざ言語化して全体に共有してくれました。本当に感謝しています!

キーボード沼のすゝめ 〜自作キーボードの一歩手前まで〜

発表者:前田(スナックミーの頼れるフロントエンドエンジニア)

前田は自作キーボードを使って開発しているメンバーで、キーボードへの熱い想いを抱いています。先日自作したキーボードを見せてもらったのですが、とっても格好良くて、私も自作してみようかなと心が揺さぶられました(笑)

前田が作成した自作キーボード

エンジニアは1日8時間以上キーボードに触れ続けることも珍しくない職種です。体を労わることを目的としていたり、オシャレなキーボードでモチベーションを高めたり…キーボードにこだわる理由はいろいろありそうでした!

ちなみに私は前職で首から肩にかけての筋を痛めたことがあり、それがきっかけで肩が開く分離型のキーボードを使用するようになったので、キーボードへこだわる理由にかなり共感できました。

おわりに

チームメンバーが情報発信をしやすい土壌を整えていくためにも、アウトプットの練習を行う場として、これからも社内LT会を続けていきます!

今回はおやつをもぐもぐしながら開催したからか、相互のコミュニケーションも増えて、とても和やかな雰囲気で行うことができました。とはいえ、毎回何かしらアップデートできるといいなと思っているので、次回も今とは違う何かを始めたいですね。

スナックミーでは、エンジニアを積極的に探しています!この記事を読んで興味を持ってくださった方や、おやつが大好きで「おやつと世界を面白くしていきたい」とお考えの方がいらっしゃれば、ぜひ応募していただけると嬉しいです。

engineers.snaq.me

募集ポジション

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

ソフトウェアエンジニア Backend (lead) /オペレーションチーム / 株式会社スナックミー

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

第1回【社内 LT 会】を開催しました🎉

こんにちは。スナックミーでエンジニアをしているタク(@yamataku3831)です。

つい先日、スナックミー社では初の【社内 LT 会】を開催しました!LT とは、Lightning Talks(ライトニングトーク)という短時間で行うプレゼンテーションのこと。正社員メンバーだけでなく、業務委託の方々も参加してくれて、一緒にワイワイしながら情報発信を行うことができました。

メンバーがアウトプットしやすい土壌を作りたい!

先日 AWS Summit に参加した際は、スナックミーを知っている色んな方がブースへ立ち寄ってくださいました。スナックミーが多くの方に知られているという嬉しさがあった一方で、おやつ会社であるスナックミーがなぜ AWS Summit に出展しているのか?と聞かれることも多かったんです。

スナックミーからエンドユーザーのもとへ届くものはあくまで「おやつ」だけなので、ユーザーごとにパーソナライズされたおやつが無事届くまでの過程に使用されているテクノロジーの存在が、どうしても伝わりづらいという性質を持っています。

そういった背景もあって、スナックミーとしてエンジニアチームの存在をしっかりと発信することで、世のエンジニアにもっと興味を持ってもらいたいと思うように。とはいえ、メンバーに突然「技術発信しましょう」と言ったところで、もちろんそのハードルはかなり高く感じることでしょう。

自分も前職で上司やチームメンバーに協力してもらい、勇気づけられ、多くのハードルを乗り越えたことで、ようやくアウトプットすることができました。ですから、次は私がチームメンバーに協力して、勇気づけて、ハードルを乗り越えられるようにフォローする番。その想いで社内 LT 会を開催するに至りました。

発表内容

PC が変わっても使い慣れた Neovim で すぐに開発を始める仕組み

発表者: @yamataku3831

私は Neovim を使用して開発をしています。その運用方法を先日 Zenn で投稿したのですが、意外と多く読まれたこともあり、有益な情報になるかもと思って発表しました。

zenn.dev

ほとんどのメンバーは VSCode を使用していて、Dev Container を通じて Docker を使っていることを知りました。私の運用方法でも Docker を利用しているので、お互い共通の「重くなってしまう」という課題感があるとわかって学びになりました。

スナックミーのおやつアサインの歴史とこれから

発表者: @miyoshihayato

社外秘の情報が含まれるため、スライドを共有することができないのですが、おやつの定期便において根幹を担うシステムである「アサイン」の歴史とこれからの展望について CTO に発表していただきました。

おやつの定期便は、現在はユーザーの好みに合わせた8種類のおやつを機械学習を利用してアサイン(割り当て)しています。この方法に至るまでにどういった経緯があったのか、そして今後ユーザーの満足度を更に上げていくためにどういった展望を考えているかなどについて、チームで認識を揃える良い時間となりました。

ざっくりとした概要にはなりますが、アサインの歴史を知りたい方はぜひこちらの記事をご覧ください。

labs.snaq.me

おわりに

チームメンバーが情報発信をしやすい土壌を整えていくためにも、アウトプットの練習を行う場として、これからも社内 LT 会を続けていこうと思います!

また今回は私自身初めての企画ということもあり、バタバタしてしまって、ごく普通の LT 会になってしまいました。せっかくなので今後はスナックミーらしく、おやつをもぐもぐしながら LT 会を行ったりと、徐々にアップデートしていきたいです。

スナックミーでは、エンジニアを積極的に探しています!この記事を読んで興味を持ってくださった方や、おやつが大好きで「おやつと世界を面白くしていきたい」とお考えの方がいらっしゃれば、ぜひ応募していただけると嬉しいです。

engineers.snaq.me

募集ポジション

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

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

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

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

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

ナレッジシェア

スナックミーのエンジニアでは「サービス・フルサイクルエンジニアリング」という考えがあります。詳しくは以下をご覧ください。

labs.snaq.me

一見、範囲が広く、複雑そうに感じるかもしれません。しかし、全てを100%理解する必要はなく、意識して取り組むことが重要だと考えています。実際、エンジニアは様々なチームと連携し課題解決を行っており、各チームが解決した課題や取り組んだ事柄を隔週でシェアする会を実施しています。

このシェア会はエンジニア以外も参加しているため、深い技術的な知識を共有することよりも、各チーム間の相互理解(何に取り組んでいるのか等)を重視しています。

今回はこれに加え、技術面の共有をより強化することを目指しています。これまで社内LTやハッカソンのような活動はほとんど行ってきませんでしたが、チームや会社のスケールアップに伴い、ナレッジの共有は互いのスキルアップに繋がると考えています。

一人では学べる範囲が限られていますが、多くのメンバーがいることで知識を増やすことが可能であり、これに取り組みたいと思っています。また、この取り組みは個人の成長を促すだけでなく、他のメンバーを支援できる範囲を広げ、これまで取り組めていなかった課題も解決できると考えています。

そのため、今回のテーマとしてナレッジシェアを掲げました。

仲間集め

「仲間集め」は前回のブログでも触れましたが、非常に重要なことなので今回も取り上げます。これは今後も続けて共有したいと考えています。

興味がある方は、ぜひカジュアルでお気軽にお話しいただければと思います。

倍速

「倍速」は会社全体の四半期のテーマでもあり、重要なポイントであるため、エンジニアチームの直近の取り組みたいこととしても掲げました。

倍速とは、名前の通り、通常の2倍のスピードで物事を行うことです。例えば、MTGの時間を1時間から30分に短縮したり、PRを出す時間を半分にしたり、施策のアイデアを通常の2倍出したりなど、さまざまな形での取り組みが考えられます。重要なのは、意識的に取り組む ことです。意識的に取り組むことで、クオリティを下げずに短時間でアウトプットすることが可能になります。この感覚を得るだけでも、仕事への取り組み方が1段階、または2段階向上すると思います。時間を有意義に使うことで、自己投資やリアーキテクトへの時間、他のメンバーが困っていることへのフォローなど、さまざまな事柄に取り組むことができます。

まとめ

以上が、エンジニアチームが直近で取り組みたい3つのテーマです。 常にエンジニアの仲間を探しています。エンジニアはあらゆる面でチーム力の底上げに貢献したいと考えています(PM、バックエンド、フロントエンド、データエンジニアなど)。

興味がある方は、ぜひカジュアル面談でお話ししましょう。

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

youtrust.jp

engineers.snaq.me

募集ポジション

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

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

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

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

新サービスのフロントエンド技術選定

はじめに

はじめまして、スナックミーでフロントエンドエンジニアをやっている前田です。
入社3年目にして初のブログ投稿なので、緊張しています。

さて、今回は新規サービス立ち上げに際し0⇒1で技術選定に取り組む機会があったため、その経緯をブログとして記録に残したいと思います。
弊社では定期便の会員様向けに、お届け内容を設定できるマイページを提供しています。またオンラインストアでは、定期便でお届けしているおやつの大袋や、期間限定の特別なおやつ、ドリンクなど、おいしい商品を幅広く販売中です。
その中でも特に根強い人気を誇る商品『CLR BAR』と『good JerQy』を定期便としてお届けするサービスを、今回新しく開発することになりました。

UI ライブラリ・フレームワークについて

昨今では ReactVue.jsSvelteSolidJSAstro など、数多くの UI ライブラリやフレームワークが台頭してきていますが、その中でも snaq.me のマイページでは React を使用しています。ほかのライブラリに依存した要件がなく、特に不満もないので React を選びました。

また、ほぼパーソナライズ情報しか表示しない会員向けページが主コンテンツであり SSR や SSG のメリットをあまり受けられないと判断し、SPA で構築しています。
今となっては Next.js (SSG) は利用しても良かったかもしれないと考えていますが、本プロジェクトの着手時には App Router がまだ stable になっておらず、 Static export も未実装だったため React + React Router を使用しました。

アーキテクチャについて

bulletproof-react を参考にしました。弊社ではライブラリ周りに違いがある(CRA を使っていないなど)ためやや改造していますが、概ね同じ構成となっています。
features によるドメインの分類を行わず、src 直下の各ディレクトリに追加していくほうがシンプルな設計ではあるので、リリース初期は作業ペースが安定するのでは?という先入観を持っていましたが、サービスのドメインを分析して整理していくやりかたは、むしろ最初からやっておくべき工夫だと考えています。

スタイルについて

snaq.me のマイページでは styled-components を使用していますが、 使用するタグに頓着しづらい傾向がある点などに以前から課題を感じていたため、別のライブラリも使用することに。
styled-components を使用する上での課題は、命名規則や Tagged Templates の使用禁止などによって回避可能ではありますが、vanilla-extract など className でスタイルを適用するライブラリを使えば自然と解決できそうです。

しかし、今回はこのような制約があります。

  • リリースまでの期間がややタイトである
  • リリース初期は CSS を書く時間がどうしても増えがちだが、 Object Style だと'" の分、ややタイピング量が増えてしまう
  • CSS の細かな調整が必要な UI があまりない

結果として「スピード優先!細かなスタイルにはこだわらないでいい」ということで、UI コンポーネントライブラリである Chakra UI を使用することになりました。どの UI コンポーネントライブラリを使用するかという議論については、チームメンバーの経験から「キャッチアップの工数が低いもの」という観点で選んでいます。

また、Chakra UI を使用した場合は以下のような課題もあるため、今後の成長に合わせて設計変更や移行を検討したいと考えています。

  • やや型が弱い
    • mb="15" など存在しない値を指定しても静的なエラーが出ない
    • テーマのカスタマイズが補完されない(colors にブランドカラーを追加したときなど)
  • バンドルサイズが大きい
  • JSX がスタイルの指定で膨らむ
    • 適宜コンポーネントを分けていれば私は気にならないのですが、気になる方もいるようなのでメンバー構成の変動に合わせて検討

状態管理

snaq.me のマイページでは Redux を使用しています。大規模なサービスでは多くのグローバルステートが必要となり、それらを管理する目的としてなら Redux はいい選択肢です。
しかし、 新サービスは機能要件的にあまり多くのグローバルステートを必要としないため、より小さい構成で始められる Recoil と Jotai のどちらを使うかという検討を行いました。

ファーストリリース時の機能要件的にはどちらでも(もしくはどちらも使わず Context AP でも)満たすことが可能ですが、結論としては、下記の理由により Jotai を選択しました。

機能要件的にどちらも満たせるとはいえ、 Recoil にも多くの integration が存在し、人気のあるライブラリです。
今後、サービスが成長していくにつれ移行が必要になる可能性は十分にあると考えています。そのため、Jotai を各コンポーネントなどで直接参照せず、カスタム Hook などを経由して値の取得・設定をするようにしています。

テスト

主に VitestReact Testing Library を使用しています。
API 疎通が必要な箇所については、MSWAPI レスポンスをモックしています。

また、E2E テストとして Playwright を導入し、いくつかの画面で動かせる状態にはしていますが、CI などの運用フローに含めるところまで成熟させられていないのが現状です。
E2E テストを安定させるためには API のモッキングが必要となりますが、通常の UI 実装のための vite のサーバープロセスと、 MSW で API がモックされたサーバプロセスの二つを用意する必要があり、開発端末のスペック的に両方を起動し続けることが難しかったことが要因です。

Playwright でも Component Test が試験的に導入されつつありますが、その用途であれば React Testing Library によるユニットテストのほうが高速に動作するため、今は Vitest と React Testing Library に主軸を置いています。

その他細かなライブラリ

  • Vite
    • snaq.me のマイページでは webpack を使用していますが、コードベースが巨大になった影響でファイル保存時の CPU やメモリ負荷が高いため、ノーバンドルツールを選択しました。
  • axios
    • interceptors でリクエストに認証情報を付与するほか、500レスポンスを検知して通知するために使用しています。axios 自体があまり型が強くない点と、axios をラップした関数を作成しているため、fetch に戻すことも検討中です。
  • neverthrow
    • 主にAPI エラーをハンドリングするために使用しています。
  • React Router v6
  • dtsgenerator
    • API が OpenAPI を出力してくれるので、それを型定義に変換するために使用しています。
    • OpenAPI を axios や fetch のラッパーなどに変換してくれるツールも存在しますが、弊社では OpenAPI から型情報だけを得たかったので dtsgenerator を選択しました。

おわりに

というわけで、新しくリリースされたサービスはこちらです。
私の推しは『good JerQy』の黒糖醤油味ですが、他フレーバーも『CLR BAR』もおいしいので、ぜひお試しください!
またスナックミーはエンジニアも積極的に募集していますので、興味のある方はぜひ応募していただけると嬉しいです!

engineers.snaq.me

募集ポジション

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

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

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

CLR BAR

clrbar.com

https://portal.snaq.me/checkout/flavor-select?brand=clrbar

good JerQy

goodjq.com

https://portal.snaq.me/checkout/flavor-select?brand=jq

【Vimmer の Webエンジニアが TypeScript で Neovim プラグインを作った話】をイベントで発表してきました!

こんにちは。スナックミーでエンジニアをしているタク(@yamataku3831)です。

このたび6月21日に、クラスメソッド株式会社のオフィスで開催されたイベントにて、LT登壇の機会をいただきました。

connpass.com

250人のエンジニアが参加する中、今回お話しさせていただいたテーマは【Vimmer の Webエンジニアが TypeScript で Neovim プラグインを作った話】。この記事では、発表時に使用したスライドもご共有しつつ、私が TypeScript で Neovim プラグインを作るに至った背景をご紹介します。

スナックミーの世界観あふれるマイページは TypeScript で作られている

スナックミーでは「おやつの定期便」だけでなく、ECストアでも楽しいおやつ時間を体験することができます。特にサービスとユーザーの大切な接点であるマイページは、ナチュラル/ポップテイストのソーシャルゲームを彷彿とさせるような、ワクワク感にあふれたデザインになっているのが特徴的です。

マイページの画面

アニメーションやマイクロインタラクションが豊富に使われているのですが、実は TypeScript がベースになった React で開発されています。私は前職でも React や React Native を使っていたので、TypeScript は親しみ深い言語のひとつと言えます。

Web アプリケーションを Neovim で開発していた自分に訪れた転機

前職の上司の影響もあって、私はエンジニアとしてのキャリアをスタートした頃から Neovim を使っていました。Vim Script や Lua は設定ファイルを書く程度しか使ったことがなく、プラグイン開発は考えたこともありませんでした。

ところが、2021年7月に Denops という Vim/Neovim のエコシステムが vim-jp から正式リリースされ、JavaScript や TypeScript を用いてプラグインを開発できるようになりました。Denops の存在を知ったことをきっかけに Vim/Neovim プラグインを作ってみたくなった気持ちが再燃し、使い慣れた TypeScript でプラグインを開発してみることに…

これが Neovim プラグインを開発するに至った背景です。Denops とは何か?どういうメリットがあるのか?どのように作るのか?などは発表資料にまとめていますので、気になる方はぜひご覧になってください。

おわりに

楽しいおやつ時間を想起させるような、スナックミーならではのワクワクに満ちたマイページ。そういった世界観をフロントエンドエンジニアが具現化できている要因のひとつに、FastAPI に mypy を利用して型を指定したり、自動テストを実装したりして、必要なデータを安定的に提供する基盤を構築しているということが挙げられます。

弊社ならではの世界観を実装面からしっかり支えていただけるバックエンドエンジニアの方も、積極的に募集しています!この記事を読んで興味を持ってくださった方や、おやつが大好きで「おやつと世界を面白くしていきたい」とお考えの方がいらっしゃれば、ぜひ応募していただけると嬉しいです。

engineers.snaq.me

募集ポジション

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

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

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

スナックミーにおける技術選定の歴史と今後の技術的挑戦について

こんにちは。スナックミーでエンジニアをしているタク(@yamataku3831)です。

3月30日に開催された、株式会社サーキュレーション主催のオンラインイベント【CTO meetup】にて、Ubie 株式会社のエンジニアの方と一緒にスナックミーの CTO が登壇しました!

flxy.jp

今回は「流行りだけでは決めない自組織に求められる最適な技術とは?」というテーマについて、以下のようなことについて発表しました。

  • スナックミーにおける技術選定の歴史について
  • どのような考えを軸に技術選定を行ってきたか
  • そのうえで今後技術的にどういった挑戦をしていきたいか

今回はこちらの内容にフォーカスを当て、イベントでは伝えきれなかった部分も合わせてご紹介します。

スナックミーにおける技術選定の歴史を振り返る

スナックミーをローンチしてから、今年で7年が経ちました。これまでどのように技術選定を行ってきたかを【プロダクトの立ち上げ時期】【仮説検証スピードを重視していた時期】【システムの安定性を考え始める時期】の3パートに分けてお話しします。

プロダクトの立ち上げ時期

プロダクトの立ち上げ時期は、何度もピボットを繰り返していたこともあり「いかに早く事業としてローンチできるか」をもっとも重要視していました。そのためモダンな技術よりも、とにかく自分が使い慣れた技術を使って開発していたんです。

CTO が前職で使い慣れていた PHP のマイナーなフレームワークを使って、さまざまなプロダクトの開発を繰り返し…おやつの定期便の原型となるプロダクトを、2週間という短い期間でリリースさせることができました。

一方で、例えばインターネットで検索しても情報があまり出てこない…といったマイナーなフレームワークならではのつらさも感じるように。CTO 以外のエンジニアに開発を依頼しづらいため、これが今後チームを大きくする際の足枷になるかもしれず、看過できない課題として認識していました。

仮説検証スピードを重視していた時期

「おやつの定期便」をローンチしてから1年が過ぎた頃から、仮説検証スピードを上げていくために、一緒に開発に取り組んでくれるエンジニアを探し始めました。当時のエンジニア市場には Ruby on Rails を使った開発経験を持つ方が多かったため、このタイミングで Ruby on Rails をメインとした開発に切り替えました。

Ruby on Rails はコミュニティやドキュメントが充実していたこともあり、複数人での開発が可能です。おかげで以前よりスピーディーに開発できるようになりました。一方で、Ruby on Rails だけで開発すると、メモリ不足やタイムアウトでエラーになってしまう処理も見つかりました。

その処理が実行されるタイミングでのみ EC2 インスタンスを変更することもできますが、あまり現実的な対応ではありませんよね…(笑) そこで、機械学習でも書いていた Python を使い、処理を Lambda に切り出すといった開発も始めました。

システムの安定性を考え始める時期

ユーザー数が拡大してきた2020年くらいから、サービスをより安定的に稼働させることについても考え始めるようになりました。

立ち上げ時期から PHP で開発していた API の機能ですが、自動テストを実装していなかったことも一因となり、開発効率には課題がありました。ここまでの技術選定によって Python を使った開発の比率が高まっていたため、これを機に FastAPI を使ったリプレイスへ踏み切ることに。

安定性担保のために自動テストを実装し、mypy を利用して型を使うようにすることで、より安全で効率のいい開発が可能になりました。またさらなる効率向上を狙い、DDD を取り入れました。

どういった軸で技術選定を行ってきたのか?

ここまでお話ししてきた、スナックミーにおける技術選定の歴史。その裏側にあった3つの重要な判断軸をご紹介します。

  • 解決したいコアな技術は何か

これをもって「技術的に何を実現したいか」を優先して考えるようにしています。例えば、マイナーなフレームワークで実装された API を FastAPI でリプレイスした事例について。もちろん他にもいくつか選択肢がありますが、技術的に実現したいのは API のリプレイスであるため、結果として API に特化した技術を選択しました。

  • プロダクトの負を解決するために重要な選択肢であるか

「プロダクトとしてどういった課題を解決していきたいか」も優先して考えるようにしています。スナックミーの「おやつの定期便」でお届けする8種類のおやつは、ユーザーごとにパーソナライズされています。しかし、人の手でユーザーひとりずつに適したおやつを選定するのには限界があるため、機械学習を取り入れて Python という開発言語を選択しました。

  • コミュニティが活発か

上記の軸をもとに調査すると、複数の技術が候補としてピックアップされます。その中でどれを選ぶか、その最後の後押しとして「コミュニティが活発か」という軸も持つようにしています。例えば最新のコミットがいつ行われているかであったり、ドキュメントが充実しているか、スターの数がどれくらいあるかなどの情報を参照します。

今後取り組んでいきたい技術的挑戦

先述したような歴史を経たうえで、現在はかつてと比べるとそれなりにモダンな環境で開発を行えています。とはいえ、これからも技術的に挑戦していきたい領域があります。

  • 肥大化した現システムからの脱却

ユーザーが拡大し始めた2019年頃、システムの安定性に目を向け始めたものの、やはりプロダクトを作り込むことを重視していました。テストの必要性などは理解しつつも、当時 TDD に精通したメンバーがスナックミーに在籍しておらず、安定性にコミットすることが難しい状況だったのです。

その結果システムが大きくなりすぎてしまい、影響範囲が見えづらくなってしまったり、不要な機能が削除できずに残ってしまっていたりといった支障が発生。こういった背景があり、肥大化した現システムを丸ごとリプレイスしたいという考えに至りました。

この肥大化したシステムは、サービスの根幹を成すコアな部分を担っています。将来を見据えても大きなインパクトを与えられるはずなので、積極的に挑戦していきたいと考えています。

  • Lambda を含めた開発効率の向上

これによりサーバー管理の手間がなくなることで、コア業務にリソースをより注力できるようになりますし、機能(関数)ごとにメモリを設定できるなど、フレキシブルな開発に繋がるメリットがあります。

ただ、そういったメリットはありつつも、まだまだ満足できる開発効率ではないとも感じています。例えば、テストに関するベストプラクティスが確立されておらず、手動での動作確認に頼ってしまっている部分などもあるのです。

Lambda がベースとなった機能の開発効率を上げていくことは、いい意味でも試行錯誤できる状況だと感じているので、積極的に挑戦していく価値がありますね。

スナックミーが提供しているメインサービスといえば「おやつの定期便」。その定期便がユーザーに届くまでにさまざまなドメインが乱立しています。

例えば、ユーザーとの接点である「マイページ」、定期便に入るおやつを作るための「製造管理」、おやつの在庫が必要十分であるかを担保するための「在庫管理」、定期便に入るおやつを選定する「パーソナライズ」、選定されたおやつを正確に箱に詰めていくピッキング、ユーザーに届けるための「配送」などがあります。多岐にわたる作業を経て、ユーザーに定期便が届くわけです。

ローンチ当初は創業者3人だけで運用していたので、3人に最適化されたシステムを作っていました。そして時が経ち、人が増え…組織としての分業化が進む中で、その3人仕様のシステムが原因となり、たびたび不要なコミュニケーションが発生してしまうように。

組織体制に合うシステムアーキテクチャにしていくためにも、それぞれのドメインをいつでも切り出して開発できるよう、モジューラモノリスを意識して開発していこうと思っています。

おわりに

スナックミーは Lambda などの AWS サービスを開発に活用したり、「おやつの定期便」のパーソナライズに機械学習を使ったりするので、徐々に Python で開発する場面が増えてきました。モダンな開発環境になりつつありますが、プロダクトとして解決したい課題技術的に実現したいことのバランスを調整して、技術を採択しているという背景があります。

その一方で、まだまだ技術的に課題に感じている部分があるのも事実。スナックミーでは、これから私たちと一緒に挑戦してくださる方を探しています!

この記事を読んで興味を持ってくださった方や、おやつが大好きで「おやつと世界を面白くしていきたい」とお考えの方がいらっしゃれば、ぜひ応募していただけると嬉しいです。

engineers.snaq.me

募集ポジション

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

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

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

スナックミーの取り組みを【AWS Summit Tokyo 2023】で紹介してきました!

こんにちは。スナックミーでエンジニアをしているタク(@yamataku3831)です。

AWS について学べる日本最大級のイベント【AWS Summit Tokyo】が、4月20日(木)・21日(金)の2日間にわたり開催されました。実に4年ぶりとなるオフライン開催ということで、会場である幕張メッセに延べ35,000人が集う大規模なイベントとなったようです。

スポンサーとして Datadog や MongoDB Inc.、クラスメソッド株式会社といった名だたる企業がソリューション展示を行っていました。そんな中、スナックミーも「スタートアップ特別展示ブース」にて、我が社のソリューションを展示させていただきました。

嬉しいことに、弊社のおやつ体験サービスをご存知の方にも多く立ち寄っていただけたのですが「なぜ出展しているのか?」「スナックミーのサービスのどこに AWS が使用されているのか?」と尋ねられる場面もしばしば。

そこで今回は、スナックミーが【AWS Summit Tokyo】に参加させていただくようになった背景や、サービスのどの部分に AWS を使用しているのかについてご紹介しようと思います。

AWS 主催イベントとはこんなご縁が…

弊社 CTO の三好は、AWS 主催のイベントに何度も登壇させていただいております。その繋がりもあって、今回の【AWS Summit Tokyo 2023】でもブース展示の枠をいただくことができました。

2018年に開催された、スタートアップのためのコンペティション【Startup Architecture of the year】に登壇したことをきっかけに、翌年も同じく【Startup Architecture of the year】に登壇したり、【AWS Summit tokyo 2019】にブース展示をしたりと、皆さまの前でお話しする機会を度々いただけるように。

speakerdeck.com

speakerdeck.com

さらに、各社の優れたアーキテクチャを集めた【This is My Architecture】にも2019年に選出され、スナックミーのシステムアーキテクチャが世界に公開されました。

youtu.be

動画で紹介されているアーキテクチャは、現在もスナックミーの CRM を支える基盤となっていて、入社してまもない私もあまりストレスを感じることなく開発に取り組めています。

こういった貴重な関わりがあったこともあり、ありがたいことに現在もなお AWS 関連のイベントに参加させていただくことがあります。

Amazon MWAA を使用した機械学習用データの生成

今回の【AWS Summit Tokyo】においてどういった内容でブースに出させていただいたか、その概要をご紹介します。ミニステージへの登壇時に使用したスライドをアップロードしているので、詳しく知りたい方はぜひ以下のスライドをご覧ください。

speakerdeck.com

スナックミーは「おやつの定期便」という、毎回8種類のおやつをユーザーにお届けする定期便サービスを提供しています。常に100種類以上のラインナップを揃えているおやつの中から8種類を、ユーザーによってまったく異なる組み合わせで選定するのです。もちろんそうなると、おやつの選定を人間の力だけで行うことは難しいため、ここに機械学習を用いています。

では、実際にどういったデータを学習させているかというと、以下のようなものが挙げられます。

  • 届いたおやつに対するフィードバック
  • 好き/嫌いやアレルギーなどの登録
  • 食べたいおやつのリクエスト など…

上記のような情報を生データのまま学習させようとしても、あまり効率がよくありません。そこで効率よく学習させるために、弊社では大まかに以下のような工程でデータを加工しています。

上記のようなデータ加工処理を、 Amazon MWAA(Managed Workflows for Apache Airflow)を使用して一元管理。いわゆるデータパイプライン的に使用しています。

例えば、データ加工処理を連ねている途中で処理が失敗してしまった場合、処理がどこまで成功していて、どこから失敗したのかを、管理画面上ですぐに把握することができるというメリットがあります。

また AWS のマネージドオーケストレーションサービスでもあるので、運用が容易であるという点もメリットのひとつです。

上記のようなメリットから、弊社では Amazon MWAA を機械学習のデータセット作成に使用しています。

おわりに

今回ご紹介したように、弊社では AWS Lambda や AWS Step Functions 、Amazon Pinpoint を使用して CRM のユーザー通知配信機能を追加したり、Amazon MWAA を使用しておやつ選定で使用する機械学習のデータセットを作成したりと、AWS のサービスを数多く利用しながら日々プロダクト開発をしています。

これまで AWS を活用して開発してきた方は、きっとその経験を活かすことができる環境だと思います。また AWS にご興味があり、AWS を使って開発をしていきたいと考えている方や、おやつが大好きでおやつと世界を面白くしていきたい方にとっても挑戦しがいのある環境であることは間違いありません。ぜひ応募していただけると嬉しいです!

engineers.snaq.me

募集ポジション

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

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

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