snaqme Engineers Blog

一括アサインから個別アサインへ

当時のアサインは、

精度は高い
ただし計算コストが重く
一括・バッチ処理が前提

という設計でした。

今年はこの前提を見直し、
個別アサインへと進化させています。

個別化を可能にした2つの変更

1. 独自アルゴリズムの軽量化

ロジックの責務を整理し、

計算コストの高い部分を分離
毎回フルで考えなくても成立する設計へ変更

することで、

ユーザー単位での再計算
状況に応じた柔軟なアサイン

が現実的になりました。

2. 在庫に対する考え方の変更

在庫を単なる制約条件として扱うのではなく、

減り方
滞留
回転

といった 変化のシグナルとして捉え直しました。

これにより、アサイン・在庫・製造・出荷を
一つの流れとして扱えるようになっています。

アサインを支えるオペレーション改善

アサインを止めないために、周辺の改善も進めました。

宛名出力の自動化
- 朝には宛名が出そろう状態に
アサインシステム 4.0
- 一括から個別へ
- より細かな最適化が可能に
作業報告のペーパーレス化
snaq.me office のアサインも個別アサインしロジックもほぼ毎週アップデート

いずれも派手ではありませんが、
事業開発のスピードを落とさないために効く改善です。

アサインはアルゴリズムだけでは完成しない

アサインは、

アルゴリズム
データ
オペレーション
使う人（エンジニア・非エンジニア）

が噛み合って初めて成立します。

今年は、その全体がようやく
一つのシステムとして回り始めた一年でした。

おわりに

何を作ったか以上に、
どう作るかが変わった一年でした。

非エンジニアが事業開発に入り込み
エンジニアは難所に集中し
内製の強みが最大化される

この形を前提に、アサインも、事業も、まだ進化していきます。

来年も引き続き、
スナックミーは「作りながら考え、考えながら作る」内製開発を続けていきます。

来年もよろしくお願いします。興味ある方はぜひ以下からお声がけください

pitta.me

2024-10-29

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

pitta.me

募集ポジション

2024-07-05

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

データを活用したオペレーションのシステム化
オフィス基盤の構築
まとめ

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

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

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

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

オフィス基盤の構築

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

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

office.snaq.me

まとめ

pitta.me

募集ポジション

2024-04-19

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

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

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

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

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

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

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

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

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

まとめ

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

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

meety.net

募集ポジション

2024-02-21

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

DDD 勉強会

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

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

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

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

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

speakerdeck.com

DDDとは何か

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

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

値オブジェクトについて

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

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

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

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

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

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

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

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

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

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

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

値オブジェクトとして実装すべき基準

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

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

おわりに

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

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

募集ポジション

2024-01-31

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

シンプル化の追求
- プロダクトの視点
- 開発の視点
まとめ

シンプル化の追求

プロダクトの視点

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

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

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

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

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

prtimes.jp

office.snaq.me

開発の視点

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

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

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

まとめ

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

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

meety.net

募集ポジション

2023-12-13

第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 が魅力的に感じる部分や、新鮮に感じる部分もあったので、それを忘れないよう言語化してみました！

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