スナックミーの取り組みを【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

さらに、各社の優れたアーキテクチャを集めた【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 / 株式会社スナックミー

2023-04-26

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

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

中期目線の意識強化 (中期ありきの短期を忘れない)
既存の既存(経験含む)活かした、開発のアップデート
仲間集め
まとめ

中期目線の意識強化 (中期ありきの短期を忘れない)

四半期ごとに個人ミッションに対しての目標を設定している中で、目標の達成に向かうことは大事ですが、ミッションのことを忘れないように動きたいと考えてます。

取り組み方次第で

目の前のことだけにコミット
中長期に意識しすぎる

この両方あると思いますが、それぞれが均衡状態 (片方によらないイメージ)になることを意識し、行動していきたい。
私は中長期のことに意識しすぎでたまにやるべきことが進まなくなるケースがあるので、意識的に前に進めることを意識してます。一方、目の前のことにコミットしすぎると、気づくと違う方向に進む場合があるので、向かいたい・向かうベき方向を意識しながら開発を進める。

既存の既存(経験含む)活かした、開発のアップデート

先月の3月でスナックミーサービスをリリースして丸7年経ちました。7年経つと技術の進歩、スタートアップ特有の技術負債が存在し、これらに向き合い改善・改良が必要になってくると思います。また、昨今 ChatGPT筆頭に「Generative AI」が新しい概念・仕組みとしていろんなサービスが誕生し様々な危機感を私自身感じています。危機感と同時にワクワクさもあるので、決してネガティブでなくポジティブです。

実際にマイページ ( ユーザさんが使うページ)のAPIも2年ほど前からリプレイスを始め、リプレイス以前はプロダクトを作ることにフォーカスしすぎて複雑化(スパゲッティ状態)が進み、テストもなかった状態でした。そういう状況からFastAPIを取り入れたことで以下の課題をクリアにできてます

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

詳しくは以下をご覧ください labs.snaq.me

TypeScript化を数年前から進めていたり、まだ公開できませんが他のことも進め、過去の経験を活かしながらプロダクトを進めてます。長期に渡りプロダクトを成長させながら技術的課題・負債にも取り組んでいけるような組織により一層強めていきたいと考えてます。

仲間集め

ありがたくも毎月いろんな職種でメンバーが入社をしてくれてます。そこでエンジニアもより一層仲間を増やしたいと考えてます。ここ(直近動きたいこと)に書くことは初めてですが、大事なことなので共有させてもらいました。
弊社はおやつの原料の発注から製造、出荷からデザイン、マーケ含めあらゆることを内製で手掛けながらスナックミーを作り上げてます。弊社にはチームスナックミーという風土があるのですが、名の通りみんなでスナックミーを創り上げていることを毎日のように感じてます。

そのため弊社の人事やEMに頼りっきりになるわけではなく、みんなで一緒に働きたい仲間を増やしていこうと考えてます

一部ですが、以下に取り組みを共有します

labs.snaq.me

まとめ

チームスナックミーとしてエンジニアがあらゆる面でチーム力の底上げに貢献していきたいと考えています。

また、バックエンド、フロントエンド、データエンジニアなど絶賛幅広く受け付けてます。

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

meety.net

engineers.snaq.me

募集ポジション

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

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

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

2023-03-14

プロダクトマネジメントはPMだけの仕事ではない。すべてのエンジニアが持つべきPM視点について

こんにちは。snaq.meでプロダクトマネージャーをしている渡邉(@nabepiyoo)です。

プロダクトマネージャーたるもの日々プロダクト開発をうまく進めたいと考えていて、どういうビジョンを持って、どうやって目標達成するか、そのために優先順位をどうするべきかみたいなことを考えています。

そして、デザイナー・エンジニアの協力がないと良いプロダクトはできないと考えており、PM視点を持ったエンジニアってすごく良いなと思ったので、エンジニアのスキルをちょっと向上させるかもしれないPM視点について書いてみようと思います。

スナックミーでは「何を作るかをエンジニアも考える」文化がある

一般的なエンジニアの主な業務や役割はこのようなものかと思います。

1.  設計: 新しい製品やシステムの設計、機能、性能などを決定します。
この業務は、製品やシステムの要件を分析し、それに基づいて設計を行います。

2. 開発: 設計に基づいて、製品やシステムを開発するためのコードの作成、テスト、デバッグなどを行います。
この業務は、プログラミングやハードウェア開発に携わるエンジニアが行います。

3. テスト: 開発された製品やシステムをテストし、品質、機能、性能などが要件を満たしていることを確認します。
この業務は、品質保証エンジニアやテストエンジニアが行います。

4. メンテナンス: 製品やシステムを維持管理し、必要に応じて修正やアップデートを行います。
この業務は、メンテナンスエンジニアが行います。

5. サポート: ユーザーからの問い合わせや問題に対応し、解決策を提供します。
この業務は、サポートエンジニアが行います。

6. プロジェクト管理: プロジェクトの計画、予算、リスク管理、チームの指導などを行います。
この業務は、プロジェクトマネージャーが行います。

組織の規模や文化によってどこまで誰がやるかを明確に分けているところもありますよね。上の切り方だとスナックミーでは1.〜4.は一通り個人で担当しているかと思います。 5はカスタマーサポートチームからシステムについての問い合わせがあれば対応しています。

また、スナックミーにはエンジニアがWeb開発以外のすべての工程に関わる「サービス・フルサイクルエンジニアリング」という考えがあります。

labs.snaq.me

プロダクトマネージャーがリサーチした結果や社内の業務担当者からどんな課題があるか、解決策のたたきを持ってきて、デザイナー・エンジニアも含めて何をどう作るかということを考えています。

PM視点を持たないエンジニアによる開発の弊害

ここではPM視点を持たないエンジニアによる開発の弊害について考えていきたいと思います。

局所最適になりがち

1箇所で解決できる機能を作れた場合でも、他の影響箇所ではすごく開発が大変になってしまったり、そもそも解決できなかったり、実は他にもそれを使い回せるところがあった、ということが考えられます。

技術的な側面だけでなく、スケジュール的にいつまでにここまでは進めていないといけないという感覚を持っているのかどうかということも大事な点です。

プロダクト開発はアウトカム思考で行うため、物ができたら完成ではありません。1回出してみて反応が悪ければ別バージョンを試すということも可能性として考えた上で行動する必要があります。そのため、夏休みの宿題を最終日に提出するパターンでバージョン1を最終日に出しても確度が低いものであれば失敗するケースもあるので、早めに出して様子を見る必要性もあります。

これは個人的な感覚ですが、全体を俯瞰できるようになると、物事が面白く見えてきます。弊社の場合、ユーザが利用するマイページだけでなく、おやつの製造〜出荷、おやつの選定、CRMなども自社システムなので、ここは大丈夫？ここは大丈夫？といくつも考える必要があります。もちろん各所理解している人がいるので確認することは可能です。

開発で無駄な手戻りが出てくる可能性がある

前述した1箇所で解決できる機能を作っていたら実は他にもそれを使い回せるところがあった、などもそうですが、リーンスタートアップの観点でMVPを作るということが考えられます。初めから大きく作ると大きく手戻りが発生する可能性がありますが、作る前にまず一番先に検証すべき仮説は何なのか、どうやってジャッジするのか、そのために何を作れば良いのかと逆算で考えていくことで、リスクは最小化した上で良いプロダクトを作ることができるようになります。

自ら事業をドライブしている感覚が少なくなる

何を作るか自ら考えていない場合、事業の成長に貢献できていると感じられるでしょうか？開発の優先順位を簡単にできそうだからという理由で決めていないでしょうか？事業インパクトが低いところを先に解決して、結果的に事業があまり成長していないということにならないでしょうか？

スナックミーではエンジニアがどのようにPM視点を持って開発しているか

ここではスナックミーで行っているPM目線を持つための取り組みについてお伝えしていきます。

事例紹介

VOCやテスト結果を共有

私のチームでは毎週火曜日にMTGを行っており、そこで解決策のたたき付きでユーザからのフィードバックを共有し、どうやって解決しようかと話し合っています。

※ たたきの部分については非公開にさせていただきました。

テスト結果についても同様で、何かA/Bテストを実施した場合、MTGの際に数値の振り返りもしています。

一喜一憂することなく、どういう結果になって、その結果になった理由はなんだろうねと話し合っています。

施策のシミュレーションをする

これは私が行っている作業ですが、数値を見ながら期待効果、開発工数、確度でシミュレーションしています。RICEやICEと考えは近いですね。期待効果についてはアクセスログを見たり、GAを見たりしながら数値を拾っていき、不明点に関しては変数を置いて計算しています。

メリット

複数の視点で考えると考慮漏れも減らせる
当事者意識ができる
フィードバックがもらえると喜び、やりがいにつながる

このようにメリットがあり、議論の価値があるかと思っています。

また、これに関して先日嬉しかった出来事がありました。

以前同じように議論していた内容の1つに、snaq.meのストアで売り切れの商品が多くて困っているというユーザの声がありました。

売り切れの商品はたしかに場所を占有してしまうのですが、こんな商品があったんだと気づいてもらえる機会にもしたいと考えており、ただ単純に売り切れを非表示にするという選択が良いとは考えていませんでした。

そこで考えたのが販売中のみ表示するオプションでした。

ユーザの皆さんからいただいているアンケートも読んでいて、機能リリース後に「今回追加された機能の中で個人的に一番嬉しかったのは販売中のみ表示の機能でした。」という声もいただいて、すごく嬉しかったのを覚えています。

デメリット

システム規模によっては考えるべきことが広範囲になる。
プロジェクトの目標や優先順位を過度に優先するため、技術的な問題や改善点が見逃される可能性がある。
具体的な技術的問題について語ることができなくなり、開発チームとのコミュニケーションが困難になる可能性がある。
時間や予算の制限を過度に重視するため、開発チームのクオリティーや効率性に影響を与える可能性がある。
プロジェクトの成果物が、技術的な観点から不十分である可能性がある。
開発チームのモチベーションが低下し、生産性が下がる可能性がある。
デザインやUXに関する観点が欠け、プロダクトの魅力が低下する可能性がある。

どんな人にも強み・弱みがあると思います。

スナックミーでも誰かの弱みは誰かの強みで補うように考えており、UI/UXに関してもデザイナーと一緒になって考えることで元のアイデアをブラッシュアップしたり、こういうアニメーションだったら意外と簡単に実装できるよとエンジニアが提案したり、こういうことをしたいけどこのあたりに問題があって今の状態では難しいよ等、全体のクオリティが下がらないように心がけることでデメリットを解消しています。

また、月に1日KAIZENタイムを設けることで、技術的負債の解消に取り組んだり、通常業務では取り掛れないことを行っています。

まとめ

エンジニアとして10%でもPM視点を持って、「なんでこれをやる必要があるんだっけ？」「あ、もしかしてあそこに影響が出てくるかも」と考えられるようになると、プロダクト開発を成功させる可能性が少しでも上げられて、チームに良い影響を与えられるようになると思います。

少しでも参考になれば幸いです。PM視点もってやっていきましょう！

スナックミーはエンジニア採用に注力しています。もし少しでも興味を持っていただけたら、ぜひカジュアルにお話させてください。 ※YOUTRUSTでカジュアル面談を公開しています。お気軽に話を聞きにきてください。

youtrust.jp

2023-03-09

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

こんにちは。スナックミーで採用を担当している伊藤です。

スナックミーでは今期から「サービス・フルサイクルエンジニアリング」というコンセプトを打ち出しました。これは、簡単にいえば「エンジニアがよりサービス全体に関与していく体制」なのですが、この背景にはプロダクト開発におけるサイロ化の課題解決と、「おやつ」というリアルな商品を扱うスナックミーならではの考え方があります。

今回の記事では、この「サービス・フルサイクルエンジニアリング」について解説、リアルな商品を扱うスナックミーならではの取り組みについて紹介します。

Netflixが提唱したフルサイクルエンジニアリングとは？

「サービス・フルサイクルエンジニアリング」の基になっているのは、Netflixが提唱した「フルサイクルエンジニアリング(Full Cycle Developers)」という考え方です。

netflixtechblog.com

フルサイクルエンジニアリングについて簡単に解説すると、従来のように部門ごとにスペシャリストを配置して局所最適を図るのではなく、プロダクト開発のライフサイクル全体の作業をエンジニアメンバーそれぞれが一貫して行い全体最適を図るというものです。

スペシャリスト配置型体制の問題

設計、開発、テスト、運用等を独立させた体制では、デバッグやシステムの問題解決のために部門をまたいだコミュニケーションが必要となり膨大な時間と労力がかかっていました。また、プロダクトの運用を考慮しきれずに、リリース後に多くの問題が発生するともしばしばあり、それを解決するのにまた膨大な時間がかかるなど、いわゆるサイロ化問題に苦しんでいました。

＜問題の一例＞・課題に関するフィードバックが適切に担当者に届けられない・他の部門、社外メンバーからの質問に回答できるメンバーが限られていて、回答にたどり着くまでに時間がかかる・運用チームがシステム変更についての理解がないため、運用における問題検出と解決に時間がかかる・コードが完成してからデプロイされるまでに数週間もの時間がかかる

フルサイクルエンジニアリングによる解決

こういったサイロ化の解決のためにNetflixが採用したのがフルサイクルエンジニアリングという体制です。プロダクト開発のライフサイクル全体(=フルサイクル)にまたがって開発を担当することで、部門間のコミュニケーションコストや運用における考慮漏れという課題を解決しました。

フルサイクルエンジニアリングによって、開発チーム内でフィードバックループが完結し、どのメンバーも技術的な質問に回答でき、運用の課題に関してはメンバーが直接システムを改善し、デプロイまでの時間も劇的に短縮されます。

一方で、プロダクトのフルサイクルを理解し責任を負うことには大きな負荷がかかります。各メンバーには幅広い技術知見が必要とされ、プロダクト全体を把握するには常にアンテナを張っておく必要があります。これらの課題に対して、Netflixは開発者の生産性を高めるツールを生み出すことや、各部門の責任をローテーションで管理するいった体制によって解決しています。

「おやつ」という商品には、フルサイクルでは足りない

スナックミーでもNetflixのように、サイロ化を防ぐためにエンジニアメンバーが特定の部門に閉じずにサービス全体に責任を負う「サービス・フルサイクルエンジニアリング」という体制をとっています。Netflixの「フルサイクルエンジニアリング」と異なるのは、"サービス"という言葉が加えられていることです。

なぜ"サービス"という言葉が加えられているかというと、スナックミーのサービスはWebシステムだけでは完結しないからです。

スナックミーが展開しているのは、パーソナライズされたおやつのサブスクリプションサービス「snaq.me（スナックミー）」や実店舗等でのオフラインサービスです。

いずれも「おやつ」というリアルな商品をユーザーに届けることがサービス提供のゴールです。また、「おやつ」の製造という工場と連携した生産管理等のリアルなオペレーションもサービスサイクルの中に含まれています。

Webシステムに限定されたサイクルの最適化では、サービスの一部分にしか影響を与えることはできないため、リアルなサイクルの最適化を含めて「サービス・フルサイクルエンジニアリング」というコンセプトを打ち出しています。

サービス・フルサイクルエンジニアリングの具体的な取り組み

スナックミーのサービスサイクルを簡単に紹介すると下記の図のようになります。

原材料の管理から、製造、ピッキング、出荷、そしてユーザーフィードバックを活用した商品開発のための分析まで、リアルなサイクルはWeb開発以上に多く存在しています。いずれもサービスにとっては重要な工程で、どれを欠いてもサービス成長は達成できません。

サービス・フルサイクルエンジニアリングには、部門を横断して全体最適を達成する、ということに加えて、「リアルなオペレーションの課題をエンジニアリングで解決する」という目的もあります。

＜事例：商品ピッキングの音声システムによる改善＞

スナックミーは自社で倉庫を保有しており、商品のピッキング(ピックアップして梱包する作業)も倉庫内で内製しています。ピッキングは地道な作業です。Amazonのような巨大倉庫では機械による自動化が進んでいますが、スナックミーの規模では設備投資と事業規模のバランスを考慮して、まだ手動部分が多く残っています。完全自動化とまではいかずとも、このピッキングを効率化するためにエンジニアリングで改善できることはないか、と考えた結果生まれたのが音声ピッキングシステムです。

従来、商品名、個数、配置場所をメモした用紙を出力し、それを見ながら目視でピッキングするというアナログな作業を行っていました。しかし、その運用ではわずかながらミスが発生し、効率もいいとはいえない状態でした。

音声ピッキングシステムは、「基となるバーコードを読み込むことで、選ぶ商品、場所を指示する音声を流す」というものです。音声ピッキングシステムの導入は、ピッキングの生産性に劇的な変化をもたらしました。出荷効率はおよそ10倍に向上し、商品発送の日数を短縮し、ユーザーへの提供価値を高めました。

※詳細はこちらの記事で紹介しています。

labs.snaq.me

このように、「サービス・フルサイクルエンジニアリング」ではWeb画面に閉じず、リアルなオペレーションをエンジニアリングで改善していくことで、ユーザーの体験、提供価値を高めていくことを目指しています。

課題を見つけ出すための文化づくり

上記のようなリアルなオペレーション上の課題を見つけ出すためには、エンジニアがプロダクトマネージャーの視点を持つこと、他部門とのコミュニケーションを活発にする仕組みが重要です。スナックミーでも、開発チームがRICEフレームワークを使って優先順位付けをしたり、ユーザーからのフィードバックを毎週確認する共有会を開催したりしています。

しかし仕組みだけでは、すべての課題を見つけることはできません。スナックミーでは、より多くの課題をエンジニアが見つけられるように、エンジニアと他の部門がそれぞれ歩み寄り、状況を共有する文化を作っています。

エンジニア自らが工場や倉庫に出向いて立ち話をしたり、エンジニアによってオペレーションが改善した事例を社内に広く共有することでエンジニアへ相談しやすい土壌を作ったり、スナックミーの開発チームではそういった愚直な施策を通して、他の部門とのメンバーの距離が近づけて、より多くの課題をテクノロジーで解決しようとしています。

エンジニアが自ら倉庫に出向いてオペレーションメンバーと会話をしています

おわりに

ここまでサービス・フルサイクルエンジニアリングやスナックミーの事例について紹介しましたが、スナックミー社内でも考え方・手法にはまだまだ改善の余地が残っています。 Netflixの記事の中でも書かれていましたが、こういった考え方・手法はそのまま転用しても成功せず、自社の状況に合わせてカスタマイズしていくことが必要です。

スナックミーのサービス・フルサイクルエンジニアリングはまだ未熟ではありますが、それでも自分の領域に閉じずにサービス全体を自身で作り上げていくという開発手法は、面白みもやりがいも大きいものだと考えています。

サービス全体に携わりたい
一つの領域に閉じずに関わる領域を広げていきたい
他の部門とコラボレーションしながら開発していきたい
何を開発するかを自ら決めていきたい

こういった志向性をお持ちのエンジニアの方には特に楽しんでいける環境があると感じています。スナックミーはエンジニア採用に注力しています。もし少しでも興味を持っていただけたら、ぜひカジュアルにお話させてください。

※YOUTRUSTでカジュアル面談を公開しています。お気軽に話を聞きにきてください。

youtrust.jp

2023-01-31

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

プロダクトの関与の向上 (提案から実行へ)
まとめ

プロダクトの関与の向上 (提案から実行へ)

以前からプロダクトに関与してなかったことではないが今回はよりプロダクトの関与を向上しようと共有しました

昨年は初めて自社店舗をオープンし、コンビニさんにも商品を卸す機会が増えた年でした。サービス当初から展開しているおやつの定期便は オンライン でsnaq.meとユーザーさんを繋いでいます。それに加え オフライン での接点が増え、少しずつではありますがsnaq.meのサービスを目にする機会が増えてきました。

昨年まではエンジニアはおやつの定期便に関することの開発をメインに行ってきました。今年もこのおやつの定期便に関する開発は引き続き行っていきますが、その先にある自社店舗やコンビニさんにあるオフラインのことを意識したプロダクト開発が必要だと感じています。

一言で言うと「視野を広げた開発」がより重要になってくるということです。snaq.meはおやつという「食する」ものを提供してますが、テクノロジーでおやつ以外の体験をよくしようと常日頃考えています。

・原料の在庫管理から、製造・出荷などのオペレーション (WMS)
・メールやLINEの顧客配信システム (CRM)
・マイページ (決済など含む)
など

弊社ではあらゆるものを自社で内製しています。この取り組みは必要に応じて開発していますが、オペレーション(製造・出荷) 商品開発 パティシエ マーケティング デザイナー (UI/UXからパッケージまで) CS CRM バックオフィス セールス など様々な役職が存在し、それぞれが合わさってsnaq.meというサービスができています。(弊社ではそのことを チームスナックミー と呼んでいます)

そこでエンジニアは チーム間の架け橋 となる存在に、ということを定期的に伝えてます。システム開発をよくわからないメンバーは、何がどうなると効率が良くなりクリエティブなことに時間を割けるのかいまいちイメージがつかない場合があると思っています。そのため、隔週でシステム開発したこと・アプローチ方法を共有する会を設けてます。この目的の一つとして、参加メンバーが少しでも自分ごとでき、アイデアが生まれやすくなれればと思い開催してます。共有会とは別のアプローチとしてプロダクトへの関与の向上 を今回掲げ、snaq.meというプロダクト以外にも、チーム毎の関与も含まれてます。それぞれが相乗的にパフォーマンスを上げられるようにエンジニアがよりプロダクトの関与を向上したいと思います。