snaqme Engineers Blog

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

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

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

オペレーションチームと協働し、効率化と属人性の排除

スナックミーでは、原材料の管理から製造、ピッキング、出荷、そしてユーザーフィードバックを活用した商品開発まで、多岐にわたる業務をシステム化しています。

最近、頼もしいメンバーが増え、オペレーションチームとの協働が活発化しました。これまでは、CTOとCOOが議論しながら決定を下し、それに基づいて動くことが多かったのですが、新たなメンバーの参加により、チーム全体で課題に取り組む体制が整いつつあります。CTOやCOOが現場に関わることで、すべてのHOWを決定することにはリスクが伴います。WHYやWHATは私の役割ですが、HOWはチームに委譲することが重要だと理解していました。しかし、それを実行することは難しかったのです。

新しい仲間が加わったことで、状況が好転し、エンジニアチームとオペレーションチームが協力し、複数のチームに分かれて課題を整理し、同じ目標に向かって進める体制が生まれました。この提案もメンバーから挙がったもので、その結果、スピード感を持ってチームとして動けるようになってきています。

もちろん、立ち上げたばかりのチームなので、最初からうまくいくとは限りません。そのため、確実にチームとしての一歩を踏み出しつつ、大胆な一歩も同時に意識して進めていきたいと考えています。

これまでは、オペレーションメンバーが安全にお客様におやつを届けるために多くの責任を負っていました。属人化された業務やスプレッドシートに蓄積されたノウハウが多く、管理対象の増加に伴い業務量も増加していました。

現在、オペレーションの既存の仕組みとシステム、そして現状の事業を見直し、質を落とさずに効率化を図る方法をオペレーションチームと一緒に模索しています。

これは、エンジニアリングで言う「技術負債」に向き合うのに近い感覚です。現在のスナックミーがあるのは、この仕組みがあってこそであり、その努力には感謝しています。しかし、時代の変化とともに、かつては最適だったやり方も今では動きにくくなってきています。そのため、現行の仕組みを見直し、スナックミーならではのオペレーションシステムを再構築することが必要です。これにより、スナックミーがさらに成長していくための基盤を整え、年末から来年2025年にかけて、良いリズムを作り、さらなる成長を加速させたいと考えています。

labs.snaq.me

まとめ

「おやつと、世界を面白く。」このモットーのもと、スナックミーは常に新しい挑戦を続けています。面白い世界を共に創造しませんか?私たちは新たな仲間を募集しています。興味のある方は、以下のリンクから詳細をご覧ください。

pitta.me

engineers.snaq.me

募集ポジション

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

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

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

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

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

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

データを活用したオペレーションのシステム化

スナックミーでは、原材料の管理から製造、ピッキング、出荷、そしてユーザーフィードバックを利用した商品開発まで、多岐にわたる業務をシステム化しています。私たちはこれを「サービス・フルサイクルエンジニアリング」と呼んでいます。現在、さらに先進的なシステム化を目指しており、物流の選定から生産までの決定をシステムに委ねることを計画しています。これにより、手動での介入を減らし、効率化を図っています。

labs.snaq.me

過去8年間で蓄積された膨大なデータを活用して、ユーザーが本当に求める商品を分析し、独自のサプライチェーンを構築することが可能です。詳細は秘密保持の必要がありますが、具体的な構想はかなり進んでおり、これを実現することで、ユーザーだけでなく社内にも大きな利益をもたらすと確信しています。

また、今後はAIの生成モデルを活用したシステムの実例を増やす計画です。

オフィス基盤の構築

スナックミーは一般消費者向けのイメージが強いかもしれませんが、最近ではオフィス向け定期便も多くの企業に導入され、運用が始まっています。これに伴い、オフィス向けの特有のシステム化を推進しています。例えば、請求書の自動送信、消費者データを基にした商品選定、サプライチェーンへの製造指示書から出荷までのプロセスです。

オフィス向けプランには、おやつ以外にもドリンク、パン、プロテインバー、ヴィーガン商品などがあります。詳しくは以下をご覧ください。

office.snaq.me

まとめ

「おやつと、世界を面白く。」このモットーのもと、スナックミーは常に新しい挑戦を続けています。面白い世界を共に創造しませんか?私たちは新たな仲間を募集しています。興味のある方は、以下のリンクから詳細をご覧ください。

pitta.me

engineers.snaq.me

募集ポジション

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

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

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

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

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

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

戸惑い・不要になっているところの整理

おやつの定期便snaq.meを開始してから先月で8年が経過しました。この間、snaq.meはおやつBOXだけでなく、おつまみや焼き菓子、お茶やコーヒーなど様々な商品を取り扱う多様なコースが選択できるようになりました。また、オフラインの展開も強化し、直営店オフィス向けサービス卸事業を展開しています。

また、おやつの定期便以外にも、・卸事業・など、オンライン以外にもオフラインにも力を入れ出してます。

会社の成長と共に、スナックミーのおやつと接する機会が増えるのは嬉しいことですが、それに伴い内部の複雑性も増しています。過去8年間に蓄積されたデータを活用し、これまで手が届かなかった部分を自動化する基盤を整えることができるようになっています。昨年からはABテストを行い、多くのプロセスを自動化できる土台を築いています。最新のLLM(Large Language Models)の活用も、これからは必須となるでしょう。

この取り組みは主に社内オペレーションに関わるものですが、ユーザーが直接触れるページについても同様の取り組みを進めています。詳細は以下の記事をご覧ください。

labs.snaq.me

labs.snaq.me

長期的な視点でプロダクトを継続的に提供するためには、ただ目の前の課題に取り組むだけでなく、将来の開発優位性を意識した取り組みが必要です。即時に効果が見えなくても、1、2年後には大きな差となって現れることも多いです。

まとめ

「おやつと、世界を面白く。」このモットーのもと、スナックミーは常に新しいことに挑戦し続けています。私たちと一緒に面白い世界を創り出しませんか?

私たちは新たな仲間を募集しています。興味がある方は、以下のリンクから詳細をご覧ください。

meety.net

engineers.snaq.me

募集ポジション

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

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

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

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

第1回【DDD勉強会】を開催しました!🍫

こんにちは、エンジニアの兼崎です!

先日、第1回 ドメイン駆動設計(DDD)勉強会が開催されました。

スナックミーでは過去の開発における反省のもとDDDを導入していて、開発メンバーがしっかり設計に則って開発できるようにしたいという想いから、エンジニアのタク(@yamataku3831)が当勉強会を企画してくれました。

今回のテーマは、 「値オブジェクト」です。

(当記事は主に文章で構成しています。以下のスライドはサンプルコードもあり理解しやすいので、気になる方はぜひご覧ください💁)

speakerdeck.com

DDDとは何か

勉強会の主題である"ドメイン駆動設計(Domain Driven Design)"とは、「ドメインの知識に焦点を当てた設計手法」と紹介されていました。

少し詳しく書くとすれば、様々な解釈があると思いますが「プログラムが適用される領域を実際に利用している人たちの考え方や視点、彼らを取 り巻く環境を理解することを重視した設計手法」であると、この勉強会では説明されていました。

値オブジェクトについて

エンジニアの方は、「値」や「オブジェクト」に馴染みがあるかと思います。 値オブジェクトはこれらが組み合わさったもので、システム固有の値を表現するために定義されたオブジェクト と理解しました。

なぜ値オブジェクトを学ぶのかというと、integerやstringなどのプリミティブな値だけでシステムを構築しようとすると管理が難しくなるからです。

例えば、氏名を扱うシステムで姓だけを表示したい場合、氏名が文字列型だと姓だけを正確に取り出すことが難しくなります。 そこで氏名をオブジェクトとして定義すると、姓と名を属性として持たせることができ、管理が容易になります。

今回のスライドの文脈では、氏名はオブジェクトであり、値でもあるため、「値オブジェクト」として実装していました。

そもそも “値” が持つ性質とは何か

"値"には、以下のような性質があると紹介されていました。

  • 不変である: 値の変更を行うときには、変数の値そのものを変更するのではなく、変数の内容を入れ替えます。
  • 交換が可能である: 変数の値を変更するには、代入を利用した値の交換を行います。
  • 等価性によって比較される: 同一性ではなく、等価性によって比較されます。

値オブジェクトは値の性質を持つオブジェクトです。つまり、値オブジェクトを変更したい場合は属性単体での変更はせず新しい値オブジェクトを代入します。さらに比較はオブジェクト同士が持つ全ての属性を比較するメソッドを使用するように設計するとよさそうでした。

値オブジェクトを使用するメリット

値オブジェクトには以下のようなメリットがあります。

  • 表現力を増す: 値の構成や設計が明確になり、ロジックを読み取りやすくなります。
  • ロジックの分散を防ぐ: 仕様に関わる処理を値オブジェクト内に閉じ込めることで、仕様変更に伴う修正箇所が明確になります。
  • 不正な値を存在させない: 値の正当性を確認するコードを値オブジェクト内に統一することで、不正な値の存在を防ぐことができます。
  • 誤った代入を防ぐ: 値オブジェクトを使用することで、タイプ不一致エラーを検出し、予測不能なエラーを減らすことができます。

値オブジェクトとして実装すべき基準

前提として、値オブジェクトを実装する基準に正解はなく、システムのコンテキストに合わせて判断する必要があります。 とはいえ、参考になるような基準が欲しいのも事実ですよね。 今回の勉強会では以下のようなものが、基準の例として挙げられていました。

「そこにルールが存在しているか」「それ単体で取り扱いたいか」

おわりに

今回のDDD勉強会では、「値オブジェクト」について学びました。 私自身、これまで設計から考える機会はあまり無かったので、DDDという設計手法を学ぶ良い機会になっています。 今後、「このコードは値オブジェクトか?」「他に値オブジェクトとして表現できるところはないか?」という視点を持って実装できそうです😊

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

engineers.snaq.me

募集ポジション

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

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

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

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

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

シンプル化の追求

プロダクトの視点

2024年が始まりました。過去一年も様々な挑戦を経て、スナックミーはさらに成長を遂げました。多くの方にはおやつの定期便サービスとして認識されていますが、実は私たちは2022年4月から直営店の運営やナチュラルローソンをはじめとするコンビニへの卸事業、オフィス向けの定期便事業と、オンラインだけでなくオフラインでも接点を増やしています。「おやつ、と世界を面白く。」このパーパスのもと、お菓子を食べる楽しみだけでなく、ワクワクする体験を提供したいと考えています。

様々な接点を通じて、スナックミーのおやつとの出会いを豊かにし、プロダクトを通じてさらなる楽しみを提供していきたいと考えています。例えば:

  1. おやつの定期便を利用 -> 直営店の存在を知る -> 直営店を訪問 -> 好みのおやつを購入
  2. コンビニでスナックミーのおやつに出会う -> サービスを調べる -> ECサイトで購入 -> 定期便を始める
  3. 企業がおやつ定期便を利用 -> 様々なおやつと出会う -> 自宅用にも定期便を始める

など、出会いの循環を加速させるような動きを作っていきたいと考えています。

このような循環を加速させることが目標です。しかし、それには機能追加よりも大事ですが、迷いや不要な動きなどを減らすシンプル化が必要です。エンジニアチームとしても、この方針に基づき迅速に動いています。

prtimes.jp

office.snaq.me

開発の視点

プロダクトの理念をシステムにどう落とし込むかが重要です。サービス開始から9年が経過し、後回しにしていたリファクタリングや急ぎで開発した部分の再考が必要になり、開発速度の低下を感じています。過去3、4年の間には、以下のような取り組みを進めてきました。

labs.snaq.me

labs.snaq.me

小さく始めて、一歩ずつ改善を重ねることで、サービスを永続的に提供し、おやつ体験を向上させることが目標です。「サービス・フルサイクルエンジニアリング」を大切にしています。スナックミーは多様なシステムを通じてサービスを提供しており、事業の増加に伴い、システムの複雑性が増す可能性があります。それを防ぐためにも、シンプル化をテーマに選びました。シンプル化は「単純化」ではなく、「明快さ」を意味します。

Netflixの「フルサイクルエンジニアリング」に”リアル”を加えたスナックミーの「サービス・フルサイクルエンジニアリング」について

まとめ

シンプル化は四半期の目標に留まらず、常に意識すべきことです。スナックミーのエンジニアリングガイドラインには「Scale Out」という考えがあります。これは、会社、チーム、個人の成長に不可欠なマインドセットです。シンプル化を通じて、より良いサービスを提供し続けることが私たちの目標です。今四半期はこのテーマを特に強調しています。

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

meety.net

engineers.snaq.me

募集ポジション

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

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

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

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

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

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

つい先日、5回目の【社内LT会】を開催しました!今回もスナックミーの業務委託メンバーである“ぱーとなー”も多く参加してくれて、ワイワイしながら情報発信を行うことができました。

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

今回もまたマレーシアを生活の拠点としている “ぱーとなー” が、現地で売られていたおやつを紹介してくださいました!

マレーシアのポテトのスナック菓子

Salted Egg Yolk Potato Crisps」というポテトのスナック菓子で、卵黄とチリパウダーがコーティングされている、やみつきになるお菓子とのことでした!さらに全て手作りで作られているらしく、商品によってちょっと違いがあったりするみたいです。なんだかちょっと心まで温かくなるようなお菓子ですね。食べてみたい!

発表内容

ボックスバランス

発表者:野澤

野澤 - 発表資料の一部切り抜き

野澤は主にデータ基盤構築やデータ分析を担当してくれているインターンメンバーです。最近はユーザーの「飽き」に対して改善できないかと、弊社のエンジニアである兼崎と二人三脚で日々様々なアプローチで分析・仮説・検証を繰り返してくれています。

解約時の「飽き」コメントが気になったことをきっかけに、チャーンユーザーとアクティブユーザーのボックス内容に違いがあるのではないかと SHAP 分析したところ、「8つのおやつのうち、”とあるカテゴリのおやつ” がひとつ入っていると飽きにくい」という考察を得られたとのこと。

そして、上記の仮説を検証するためにボックスに含まれる “とあるカテゴリのおやつ” の割合で A/B テストを行なったところ、ボックスに “とあるカテゴリのおやつ” がひとつ入っているとチャーンレートが低くなるという結果を得られました!

これまでカテゴリによるボックスバランスの調整を行ったことがなかったこともあり、この検証結果は今後の仮説検証を推進する大きな一歩となりました。インターンメンバーの活躍がきっかけで、今後のユーザー満足度に大きな影響を与えそうな、そんなワクワクする発表内容でした!

Rails 経験者が FastAPI 本を読んで感じたこと

発表者:タク

speakerdeck.com

私は前職で Ruby on Rails を使って6年間開発をしてきました。弊社も同じフレームワークで実装しているシステムもあるのですが、FastAPI での開発がメインになりつつあるため、エンジニア採用を担当する身として自社の技術に関して、キャッチアップしておきたいなと思うようになりました。

そこで「動かして学ぶ!Python FastAPI 開発入門」を手に取り、実際に手を動かしながら勉強しました。これまでサーバーサイドは Ruby on Rails でしか開発したことがなかったので、FastAPI が魅力的に感じる部分や、新鮮に感じる部分もあったので、それを忘れないよう言語化してみました!

スライドもありますが、テックブログにも文章でまとめていますので、興味のある方は併せてご覧ください。

labs.snaq.me

おわりに

今回で5回目の社内LT会でしたが、社会人がいる前で初めて発表してくれたインターンのメンバーも、みんなからのポジティブなフィードバックが嬉しかったのか、とっても嬉しそうな笑顔を見せてくれました。

チームメンバーが情報発信をしやすい土壌を整えたくて始めた社内 LT 会なので、メンバーのそういった嬉しそうな笑顔を見るととっても嬉しく感じます。これからもこの活動は続けていこうと思います!

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

engineers.snaq.me

募集ポジション

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

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

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

FastAPI 0.100 (Pydantic v2)にアップグレードしました

こんにちは スナックミー CTO の三好 (@miyoshihayato) です

はじめに

スナックミーはマイページのAPI開発をFastAPIで開発し、フロントはReactで開発しています。

詳しくは FastAPIについての採用背景

labs.snaq.me

フロントの取り組み

labs.snaq.me

こちらをご覧ください。

背景・課題

以前は、品質とスピードの間にトレードオフがあるという思い込みにより、プロダクト開発を進めていました。その結果、アップグレードへの対応力が低く、アップグレード作業には多大な労力が必要でした。

上記込みで様々な課題を解決するために 2021年にPHPからFastAPIのリプレイスすると決めて動き始めました。 課題は先ほどのFastAPIの採用背景をご覧ください。要約すると以下が要因になります。

* 高学習コスト
* コードの質
* 心理的安全性

今年7月、FastAPIのアップグレードが発表され、これを機に変更容易性を意識したアップグレードに取り組みました。(今は 2023/12/7 現在 0.104.1 が動いてます)

FastAPIの対応

主に対応したところのリスト 主に Pydantic V2に関するアップグレードがメイン

  • dict() から model_dump() への移行
  • __root__ から RootModel への移行
  • __fields__ から model_fields への移行
  • class Config から model_config = ConfigDict() への移行
  • @validation から @field_validator@model_validator への移行
  • Optional の挙動の整理
  • Fieldexampleexamples への変更
  • deprecatedjson_schema_extra への変更

非推奨から推奨方法へ

  • dict() から model_dump()
  • __root__ から RootModel
  • __fields__ から model_fields
  • class Config から model_config = ConfigDict()

必須対応

  • Optional の挙動の整理
  • Fieldexampleexamples への変更
  • deprecatedjson_schema_extra への変更

Optional 挙動の整理

v1

class UserName(BaseModel):
    name: Optional[str] = Field(title="ユーザー名", example="須那田 クミ子")

以前は、nameがNoneの場合、Noneとして扱われましたが、v2ではエラーになるため、以下のようにFieldにNoneを宣言する必要があります。

v2

class UserName(BaseModel):
    name: Optional[str] = Field(None, title="ユーザー名", example="須那田 クミ子")

Fieldの仕様変更

  • example から examples
  • deprecated から json_schema_extra

v1

class UserName(BaseModel):
    name: Optional[str] = Field(
        None,
        title="ユーザー名",
        example="須那田 クミ子",
        deprecated=True
    )

v2では、exampleexamples に変更し、deprecatedjson_schema_extra で表現します。

v2

class UserName(BaseModel):
    name: Optional[str] = Field(
        None,
        title="ユーザー名",
        examples=["須那田 クミ子"],
        json_schema_extra={"deprecated": True}
    )

Python 3.11の対応

Python 3.11へのアップデートは、Pythonのバージョンを3.8から3.11にすることによるもので、主に以下の点に対応しました。

  • Dict, List, Optional, Tuple, Union の基本廃止
  • インポート量の削減
  • コードのシンプル化

3.8

class SnaqmeInfo:
    def __init__(self) -> None:
        self.__name = str
        self.__items: List[Dict[str, int]] = []
        self.__status: Optional[Union[int, List[int]]] = None

3.11

class SnaqmeInfo:
    def __init__(self) -> None:
        self.__name = str
        self.__items: list[dict[str, int]] = []
        self.__status: int | list[int] | None = None

まとめ

今回のアップグレードは、時間的にも問題的にもスムーズに本番環境へデプロイできました。時間は合計で10時間ほどで20時間はかかってないと思います。 その成功要因としては、

  • テストのカバレッジが高い(95%以上)
  • ステージング環境での事前テスト
  • 異常検知システムの有効活用

などが挙げられます。新しい取り組みではなく、基本をしっかり押さえることがスケールアップにおいて重要であると改めて実感しました。弊社は全てを完璧に押さえることは難しいかもしれませんが、常に意識して取り組むことで、現状と将来への最善のバランスを図りながら、チームとしての開発を進めていきたいと考えています。

また、Pydantic V2へのアップグレードにより、型の取り扱いがより厳密になったと感じています。これにより、以前は曖昧だった部分をより明示的に表現しやすくなったという印象を持っています。

engineers.snaq.me

募集ポジション

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

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

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