クックパッド生鮮 EC お届けの裏側 2022 年版

クックパッドマート流通基盤アプリケーション開発グループでバックエンドエンジニアをしている奥薗 ( @mokuzon ) です。クックパッドマートは生鮮食品の EC サービスで、商品を届ける流通を内製しています。そんなクックパッドマート流通にエンジニアがどう貢献しているかを今日から 4 日連続でご紹介していきます。

今回はクックパッドマートの裏側の流通がどんな要素で構成されているかを一気にご紹介します。このエントリを読んでおくと今後クックパッドマートの関連エントリを読むときにより具体的にイメージしやすくもなると思います。

項目が多いので全体を俯瞰しやすいよう目次を貼っておきます。

クックパッドマートについて

クックパッドマートは 2018 年 9 月 20 日にリリースされた生鮮食品の EC プラットフォームです。リリースから 3 年以上経ち、新規事業ならではのスピードを維持しつつサービス拡大のため試行錯誤を日々続けています。

https://cookpad-mart.com/

クックパッドマートは iOS と Android の専用アプリと、最近ではクックパッドのレシピアプリでも利用可能になっています。このアプリで商品を購入して、近所の受け取り場所 ( ステーションと呼んでいます ) で受け取れます。有料で自宅配送するオプションもあります。

取り扱っている商品はクックパッドが生産・在庫を持っているわけではありません。市場の卸売業者の方々、農家の方々、小売店の方々など様々な販売者がクックパッドマートを通して商品を販売しています。これが生鮮 EC ではなく生鮮 EC プラットフォームを名乗っている理由です。

クックパッドマートではこれらの販売者が出荷した商品を前述のステーションまで運ぶ流通を内製しています。この流通についてより詳しくご紹介します。

クックパッドマートの流通

資材

コンテナ

商品単位ではなくコンテナ単位で流通させています。これは効率よく物流を回すためのセオリーで、コンテナ物語 という有名な本があるので興味がある方は読んでみてください。

Docker に代表されるコンテナ技術と同様、規格化には物流にも絶大な恩恵があります。

シッパー

冷蔵機能のない車で肉や魚をはじめとしたチルド商品を運ぶために使っています。断熱材で出来ていて、この中に業務用蓄冷剤を入れて使用しています。 1 つのシッパーには上記のコンテナが 4 つまで入ります。

ラベル

商品やコンテナに貼り付けるラベルシールはマート流通で非常に重要なユーザーインターフェースです。現実の物体とソフトウェア上のデータを紐付けたり、直接ラベルに作業指示を印字したり、活用方法は様々です。

QR コードを印字しているものもあります。なお、このラベルを印刷するプリンターをマートのネットワークに繋ぐハードウェアの制御部分は内製です。

プリンターについて過去にご紹介したエントリーはこちらです。 https://techlife.cookpad.com/entry/2019/04/10/180000

ドライバー

クックパッドには自前のドライバーはいません。数社の運送会社と契約し、クックパッドマートの配送業務を担っていただいています。車両は軽カーゴ ( いわゆる軽バン ) と 2t トラックを使い分けています。

拠点

商品を流通させるにあたって、一時的に商品を保管したり配送効率を向上させるための拠点が必要です。ユーザーから近い順に

  • ステーション
  • ハブ
  • ローカルスポット

の 3 種類あります。

ステーション

先程も紹介したユーザーが商品を受け取りに行く拠点です。

  • 駅
  • コンビニ
  • ドラッグストア
  • コインランドリー
  • マンション
  • 銀行

など、様々なところに設置させて頂いています。現在 1 都 3 県で 700 箇所超あり、どんどん増えています。 実際の受け取り場所は https://cookpad-mart.com/about/maps/stations で確認することが出来ます。

冷蔵庫についている A, B + 冷蔵庫内部の両サイドに貼られている数字のシールで番地を表現しています。

ハブ

マートが持つ最大の物流拠点で、複数箇所あります。一般的な物流用語だとデポと呼んだりします。販売者が出荷した商品を集約し、ここを基点に各ステーションに配送を行っています。 ハブ内でユニークな通し番号が振られた番地札がついています。

冷蔵庫とスチールラックの棚があります。冷蔵の必要のない商品は冷蔵庫を使わないほうが空間効率もコスト効率も圧倒的に高いため、スチールラックの活用は重要です。

ローカルスポット

原則販売者は上記のハブに商品を出荷しに来ますが、ハブが遠い販売者のすべてがハブに直接出荷しに来ることは現実的には難しいです。そこで、各地に設けた一時置き場に販売者が一時的に商品を置いておき、マートのドライバーが回収しハブに運ぶ運用を一部しています。この一時置き場をローカルスポットと呼んでいます。

ルート

3 箇所の拠点を紹介しました。これらを 3 種類のルートで結んでいます。ユーザーから近い順に

  • ステーション便
  • ハブ便
  • 出荷サポート便

があります。

このルートの組み方、通称ルーティングには大きな技術的チャレンジがあります。ここでは簡単に種類だけご説明します。 詳細は クックパッドマートの配送ルートを自動生成している仕組み にて。

ステーション便

ハブそれぞれから 700 箇所強のステーションへ繋がるルートです。ハブで商品を集荷し、5-7 箇所のステーションへ運びます。車両は軽カーゴです。

ハブ便

ハブ同士を繋ぎ、マートの商圏のどこでも商品を届けられるようにしています。実際にはもう少し効率的な組み方をしていますが、環状線のようなイメージです。一般的な物流用語では横持ちと呼んだりします。この便は物量が多いので 2t トラックを使っています。

出荷サポート便

ローカルスポットからハブに商品を運ぶ便です。軽カーゴを使っています。

タイムライン

前述した 3 つの便は時間帯が決まっています。並べると以下のようになります。

販売者は 00:00-21:00 の間に出荷し、順次運ばれていきます。

現状のタイムラインだと販売者はユーザーから注文があった後に商品を出荷するため、それがこのタイムラインに乗ってステーションに届きユーザーが受取可能になるのにほぼ 2 日近くかかってしまうというのがサービス上大きな課題となっています。

より効率的な運び時間を短縮したり、時間枠をユーザーの生活時間にあわせて最適化するなど、今も様々な改善策を考えているところです。

なお、見て分かる通り配送はほぼ 24 時間動き続けています。システムにトラブルがあると即配送遅延に繋がるため、バックエンドエンジニアはシフトを組んで即応出来るようにしています。これについては以前エントリーを書いていますので興味のある方はどうぞ。 https://techlife.cookpad.com/entry/introduce-mart-on-call

アプリケーション

ひたすら物理世界の説明をしてきて、ついにアプリケーションの話です。開発者ブログとはいったい...いえ、これが面白いんですよ。

ドライバー向けアプリケーション

ドライバーにはルートの種類ごとに別のアプリケーションを提供しています。こういったパートナー向けアプリはモバイルアプリで提供されていることが多いと思いますが、マートではこれらはいま全て web フロントエンド技術で実装したアプリケーションを提供しています。 詳細は クックパッドマートのドライバー向けWebアプリケーション にて。

クックパッドスタッフ向け admin

これは特筆することはありません、典型的な管理画面です。

ラベル

ラベルの内容の定義方法についてご紹介した過去のエントリーです。 https://techlife.cookpad.com/entry/2021/08/18/100000

これ以外にも、Bluetooth プリンター向けに Flutter で書かれた専用のモバイルアプリもあります。

温度監視

食品を扱う以上、温度監視はとても重要です。一部構成が異なるものもありますが、各温度センサーから温度をリアルタイムでネットワーク越しに収集し、Grafana で表示したり Prometheus でアラートを飛ばすシステムを構築しています。

おわりに

クックパッドマートの流通の構成要素とそれに付随するアプリケーションについてご紹介しました。我々クックパッドマートの流通エンジニアが戦っている物理世界がどういうものであるか、イメージして頂けたら幸いです。

もう少しラフに流通エンジニアについて紹介している note がありますのでこちらもあわせてどうぞ。 https://note.com/cookpad_mart/n/nc38d718a5d90

今回は物理世界の説明が中心になってしまいましたが、明日からはより技術的に突っ込んだお話をしていきますのでお楽しみに。

クックパッドマートは流通エンジニアを大募集しています。少しでも興味を持っていただけましたら、Twitter で @mokuzon に声をかけていただいてもよいですし、カジュアル面談も実施していますのでぜひご応募ください。

cookpad.careers info.cookpad.com

2022年クックパッドマート連載の他のエントリ

fastText in Cookpad

研究開発部の原島です。去年からはレシピサービス開発部も兼務しています。そちらの話（検索の話）はおいおいするとして、今日は研究開発部の話（機械学習の話）をします。

fastText

単語の分散表現、重要ですよね。ニューラル全盛期の現代において、使わないという選択肢はほとんどないように思います。

最初に話題になったのは、2013 年に発表された word2vec でしょう。「king」のベクトルから「man」のベクトルを引き、「woman」のベクトルを足したら「queen」のベクトルになったという話は有名です。一方、最近は、2018 年に発表された BERT（及び、それに類するモデル）の話題で持ちきりですね。

fastText は、ご存知の方も多いと思いますが、分散表現を学習するためのライブラリです。学習のアルゴリズム自体を指すこともあるように思います。fastText の論文は以下です。2017 年に発表されたものなので、発展が速いこの業界においてはもう古い論文なのかもしれません。

  • Enriching Word Vectors with Subword Information. Piotr Bojanowski, Edouard Grave, Armand Joulin, Tomas Mikolov.

なぜ fastText なのか？

クックパッドでは fastText をよく使っています。では、なぜ fastText なのでしょう？上でも触れたように、word2vec や BERT などの選択肢もあります。もちろん、fastText も主要な選択肢の一つではありますが、どうして fastText なのでしょうか？

様々な理由がありますが、まとめると、「性能と運用のバランスがよい」といったところでしょうか。

性能の面では、サブワード（部分文字列）が考慮できる分、word2vec よりは fastText がよいでしょう。一方、文脈を考慮した表現が学習できる分、fastText よりは BERT がよさそうです。もちろん、これらは一般論です。実際にはタスクや学習データによって話が違ってくるでしょう。

一方、運用の面では BERT より fastText や word2vec がよいでしょう。BERT は事前学習が大変です。クックパッドでも何度かトライしていますが、お金も時間もかかります。学習データ、単語分割器、サブワード分割器、whole word masking、マスク確率、...。試行錯誤するだけでもかなりのお金と時間がかかります。

もちろん、ファインチューニングで済ますという手もあります。ありがたいことに、世の中には事前学習済みのモデルが沢山あります。これらを使えば、事前学習する必要はありません。しかし、結局、デプロイするにはモデルが大きかったり、API として使うには推論が遅かったりといった問題が残ります。

このように、性能と運用のバランスを考えると、fastText はいまでも非常に優れた選択肢だと思います。

fastText を使っている取り組み

クックパッドで fastText を使っている取り組みとしては、たとえば、以下があります。

  • 単語埋め込みを利用した商品に対するキーワードの予測（to appear）. 山口泰弘, 深澤祐援, 原島純. 言語処理学会第 28 回年次大会発表論文集.

こちらは、クックパッドマートの商品名から、食材を表すキーワードを予測する取り組みです。キーワードや商品名をベクトルに変換するのに fastText を使っています。予測結果はクックパッドマートの管理画面で使われています。

余談ですが、こちらの取り組みは今年の言語処理学会で委員特別賞をいただきました。ありがとうございます。

こちらは、レシピのタイトルから、そのレシピで使われるであろう食材を予測する取り組みです。タイトル中の単語をベクトルに変換するのに fastText を使っています。予測結果はレシピの投稿画面で使われています。

こちらは、レシピのタイトルから、そのレシピのカテゴリ（e.g., 肉料理、魚料理、野菜料理、...）を予測する取り組みです。こちらも、タイトル中の単語をベクトルに変換するのに fastText を使っています。予測結果は、近日中に、レシピのブックマーク画面で使われる予定です。

その他、まだ実験段階の取り組みでも fastText をよく使っています。

fastText の学習・利用フロー

以下は、クックパッドにおける fastText の学習・利用フローです。Redshift から学習データを取得し、fastText を学習した後、モデルを S3に保存するというのがおおまかな流れです。たいしたことはしていません。ちょっと変わったことがあるとすれば、学習データが Redshift にあることくらいでしょうか。

f:id:jharashima:20220418092004p:plain:w300

1. 学習データの取得

fastText の学習にはテキストが必要です。日本語の場合、さらに、単語分割が必要です。

クックパッドの場合、全レシピのテキスト（e.g., タイトル）が Redshift に保存されています。また、その分割結果も Redshift に保存されています。詳細は以下の記事をご覧ください。fastText の学習にはこれを使っています。

分割結果の取得には Queuery（きゅうり）というシステムを使っています。Queuery は、UNLOAD を使うことで、Redshift やクライアントに負荷をかけずに SELECT を実行できるシステムです。Queuery は去年末に OSS 化されました。詳細は以下の記事をご覧ください。研究開発部の山口による Python クライアントもあります。

2. fastText の学習

Python スクリプトに以下の 2 行を書くだけです。fastText、便利すぎますね...。

import fasttext
model = fasttext.train_unsupervised('data.txt', model='skipgram')  # cbow でも可

全レシピ（2022 年 4 月時点で約 367 万品）のテキストを使っても、学習は約 10 分で終わります。メモリも 2GB 程度で済んでいます。学習には EC2 のスポットインスタンスを使っています。

パラメータは特にいじっておらず、デフォルトのままです。たとえば、ベクトルの次元数は 100 です。パラメータのチューニングは今後の課題（後述）です。

3. モデルの保存

モデルは S3 に保存しています。ロールバックできるように、過去に学習したモデルも残してあります。幸い、実際にロールバックが必要になったことはありません。まだ特に困っていませんが、ライフサイクルくらいは設定してもいいかもしれません。

4. モデルのダウンロード

学習済みのモデルを使いたいアプリケーションに対して S3 の該当フォルダへの Read アクセスを許可します。これで各アプリケーションでモデルをダウンロードできます。

以上が fastText の学習・利用フローです。その他、補足事項として以下があります。

fastText はレシピのフィールド（e.g., タイトル、材料、...）毎に学習しています。これは、fastText を使うタスク毎に着目するフィールドが違うためです。タイトルに着目するタスク（e.g., レシピの分類）ではタイトルで学習したモデルが使えるように、材料に着目するタスク（e.g., 材料の分類）では材料で学習したモデルが使えるようにしています。

ジョブスケジューラーやデプロイツールには Kuroko2 や hako を使っています。実行は基本的に月次です。学習時間が短いので、日次で実行したところで、特に問題はありません。ただ、分散表現はそんなに変わらないだろうと思うので、月次としています。もしかしたら年次でもいいのかもしれません。

今後の課題

最後に、今後の課題を三つほど挙げておきます。

一つ目は、「fastText の学習」でも触れたように、パラメータのチューニングです。学習アルゴリズムや学習データ、学習率、ベクトルの次元数、サブワードのレンジなど、チューニングの余地はたくさんあります。この辺りは腰を据えて取り組んでいきたいです。

二つ目は分散表現の評価です。一つ目の話とも関連するのですが、どのような分散表現がよいかは自明ではありません。基本的には、後段のタスクにおける評価指標を最適化する分散表現がよい気がします。ただ、後段のタスクにもいろいろあるので、悩ましいところです。

三つ目は代替モデルの調査です。「なぜ fastText なのか？」でも触れたように、本番での運用まで考えると、BERT のようなモデルが fastText より明らかによいとは言えません。一方、この業界の発展は速く、様々な懸念を払拭するモデルが明日にも発表されるかもしれません。業界の動向には常にアンテナを張っていきたいです。

おわりに

そういえば、つい最近、就業形インターンシップに「機械学習コース」を開設しました。上で挙げた課題はもちろん、クックパッドにおける機械学習に興味がある方は是非ご応募ください。

中途採用のご応募もお待ちしております。

クックパッドに転職して感じたこと

こんにちは。 レシピサービス開発部でエンジニアを担当しているnaraです。
クックパッドには2022年1月に転職し、早くも3ヶ月が過ぎました。
まだまだ分からないことが多いですが、日々楽しく開発に携わっています。

今回は転職間もない自分が、クックパッドで"実際に働いてみて感じたこと"を紹介したいと思います。
本エントリーが、クックパッドに興味を持っている方の参考になれば幸いです！

働き方が柔軟

突然ですが、私は現在イギリスの大学でComputer Scienceを専攻しています。
日中は仕事を行い、仕事が終われば学業に専念するといったハードな生活を送っており
これらを両立させるには、時間を上手くコントロールする必要があります。

特に、試験期間中は学業に専念したくなるのですが、クックパッドではフルフレックスで働けるので、 業務時間を柔軟に調整できています。
実際、前期の試験期間中は"稼働を減らして、試験に専念する"といった選択を取ることができ、 試験を無理なく乗り越えられました。

このように、柔軟に働き方を調整できるため、自分のような社会人学生も
働きやすい環境だと実感しています。

あらゆる情報がオープン

クックパッドでは、あらゆる情報がオープンに発信されています。
前職では、コミュニケーションが部内に閉じられており、他部署の情報が入ってくることがありませんでした。
そのため、ほぼ全ての情報が公開され、部署関係なく自由に意見が交換されている
クックパッドの文化に最初は驚きました。
現在は、前職のように組織の壁を感じることがほとんどなく、部署間の連携もスムーズに行えていると感じます。

また、コミュニケーションだけでなく、データもオープンにされており
全ての社員がDWHにアクセスして、分析SQLを発行できます。
SQLの実行結果を共有する仕組みも存在しており、デザイナーが分析SQLを共有しているのを見たときは驚愕しました....

ユーザとの距離がとても近い

クックパッドで働いていると、社員同士だけでなくユーザーとの距離も近いと感じます。
特にそう感じる理由として、ユーザーインタビューがほぼ毎週のように実施されており
エンジニア・デザイナー問わずユーザーと触れ合う機会が多いためです。

前職でもユーザーへのインタビューは実施されていましたが、年に数回行われるレベルだったため
仮説を定性的に評価するのが難しいと感じた経験がありました。

この点、クックパッドではユーザーインタビューの仕組みが整っているため
仮説を定性的にも評価した上で、サービス開発を行えています。

ユーザーインタビューに関する取り組みは、以下の記事を読むと面白いと思います。
note.com

業務の域を超えて仕事ができる

個人的に入社して最も驚いたのは、業務の域に制限がないことです。
前職では、部署/職種単位で細かく役割が分かれており、基本的にトップダウンで与えられた役割に従って個々が動いていました。

しかし、クックパッドでは「何をやって欲しいか？」より「何をやりたいか？」が問われ
個人の挑戦したいことをベースに、個々が全体の目標に向かって動いています。

そのため、業務の域を超えて仕事に携わることができ、 実際に自分もエンジニアとしての機能設計・開発に留まらず、 企画やデータ分析まで自分の得意分野を活かしながら、幅広く業務に携われています。

また、エンジニアとして業務の幅も広く
モバイルエンジニアでありながらサーバーサイドの開発に携わったり
複数のサービスの開発に携わって活躍しているメンバーもいます。
(個人的に、一つの領域のみやっているエンジニアの方が少ないのでは?と思っています)

もちろん「複数の業務に携わる」 = 「仕事の範囲が増える」ので、
その分タフネスが要求されますが、主体的にチャレンジするのが好きな人にとって
やりがいのある職場だと感じています。

助け合いの文化である

前述のように、何でもチャレンジできる職場ではあるのですが
クックパッドのシステムは歴史があり、アーキテクチャも複雑です。
また、レシピサービスは複数のマイクロサービスのもと稼働しており
一つの機能を開発するにも、様々なアプリケーションに手を入れる必要性が出てきます。

実際にエンジニアとして開発に携わってみて、設計や実装の難しさを日々感じています。

しかし、クックパッドではSlackで雑に助けを求めると、誰かがすぐに助けてくれたり
チーム外の人がPull Requestのレビューに参加して、アドバイスをくれたりします。
また、ペアプロにも気軽に応じて貰えます。

個人的にはこの助け合いの文化のおかげで、経験のない言語で書かれたアプリケーションでも、 率先して開発にチャレンジする事ができています。

まとめ

本エントリーでは、クックパッドで"実際に働いて感じたこと"を書いてみました。
これまで自分が経験してきた職場と異なり、クックパッドのエンジニアは裁量が大きく
何でもチャレンジできる反面、主体性が求められていると日々感じます。

また、エンジニアとして課題にぶち当たることも多いですが、 職種やチームを超えて助けあう文化があるので、楽しく開発にチャレンジできています！

最後に

クックパッドではエンジニアを絶賛募集しています。
主体的にサービス開発を楽しみたい方には、活躍できる場がたくさんあります！

ぜひ、お気軽にご応募ください！
info.cookpad.com