こんにちは。スナックミーでエンジニアをしているタク（@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 がベースとなった機能の開発効率を上げていくことは、いい意味でも試行錯誤できる状況だと感じているので、積極的に挑戦していく価値がありますね。
スナックミーが提供しているメインサービスといえば「おやつの定期便」。その定期便がユーザーに届くまでにさまざまなドメインが乱立しています。
例えば、ユーザーとの接点である「マイページ」、定期便に入るおやつを作るための「製造管理」、おやつの在庫が必要十分であるかを担保するための「在庫管理」、定期便に入るおやつを選定する「パーソナライズ」、選定されたおやつを正確に箱に詰めていく「ピッキング」、ユーザーに届けるための「配送」などがあります。多岐にわたる作業を経て、ユーザーに定期便が届くわけです。
ローンチ当初は創業者3人だけで運用していたので、3人に最適化されたシステムを作っていました。そして時が経ち、人が増え…組織としての分業化が進む中で、その3人仕様のシステムが原因となり、たびたび不要なコミュニケーションが発生してしまうように。
組織体制に合うシステムアーキテクチャにしていくためにも、それぞれのドメインをいつでも切り出して開発できるよう、モジューラモノリスを意識して開発していこうと思っています。
おわりに
スナックミーは Lambda などの AWS サービスを開発に活用したり、「おやつの定期便」のパーソナライズに機械学習を使ったりするので、徐々に Python で開発する場面が増えてきました。モダンな開発環境になりつつありますが、プロダクトとして解決したい課題と技術的に実現したいことのバランスを調整して、技術を採択しているという背景があります。
その一方で、まだまだ技術的に課題に感じている部分があるのも事実。スナックミーでは、これから私たちと一緒に挑戦してくださる方を探しています！
この記事を読んで興味を持ってくださった方や、おやつが大好きで「おやつと世界を面白くしていきたい」とお考えの方がいらっしゃれば、ぜひ応募していただけると嬉しいです。
engineers.snaq.me
募集ポジション
ソフトウェアエンジニア Backend (lead) / 株式会社スナックミー
ソフトウェアエンジニア FrontEnd (lead) / 株式会社スナックミー
ソフトウェアエンジニア Data Engineer / 株式会社スナックミー
