物理世界でモノを運ぶための仕組み / How to Distribute Items in Cookpad Mart

Slide 1

Slide 1 text

Slide 2

Slide 2 text

● 長俊祐 / OSA Shunsuke   ● 2020年6月から現職   ● いわゆるサーバーサイドエンジニア   ○ 普段書いてるのは Ruby, SQL, TypeScript あたり   ● クックパッドマートの流通をつくっています   ○ ドライバー向けアプリケーションの開発   ○ ルート計算の開発  ○ 流通構造の設計・検討   ○ etc  ● 情報の世界だけで完結せず、現実世界と向き合う必要があるプロダクトが好き   ● アカウントなど  ○ Twitter: @s_osa_  ○ GitHub: s-osa  © 2022 Cookpad Inc. 2 自己紹介  このスライド 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

● 便の種類や目的に応じて、複数のラベルを使い分けている   ○ 補助的なラベルなども合わせると10種類くらい   ● 実装の詳しい話など   ○ 過去にブログを書いたのでそちらもどうぞ   ○ 「クックパッドマートにおける宣言的ラベル生成」 https://techlife.cookpad.com/entry/2021/08/18/100000  © 2022 Cookpad Inc. 7 いろいろなラベル 

Slide 8

Slide 8 text

Slide 9

Slide 9 text

● QRコードが表現しているのは単なる URL   ○ 今回の場合 https://ckma.to/p/11b4?pb=CAISDgiF2bIBEgcIGhIDMTUz ● この URL にアクセスすると、商品ページにリダイレクトされる ○ 前半の https://ckma.to/p/11b4 部分 ○ 通常のQRコードリーダーはこの挙動 ● 流通用のデータはクエリ部分に入っているので、流通アプリはクエリ部分を読み取る ○ 後半の pb=CAISDgiF2bIBEgcIGhIDMTUz 部分 © 2022 Cookpad Inc. 9 2種類の挙動を示すQRコード 

Slide 10

Slide 10 text

● ラベルの面積は希少な資源 ● 前半の https://ckma.to/p/11b4 部分 ● URL 短縮サービスを立てている ○ https://cookpad-mart.com/products/48352 → https://ckma.to/p/11b4 ● 短いホスト名 ○ cookpad-mart.com → ckma.to ● 単語の短縮 ○ products → p ● 商品 ID の Base36 化 ○ 48352 → 11b4 ● 裏側は S3 (x-amz-website-redirect-location) + CloudFront © 2022 Cookpad Inc. 10 QRコードを小さくする / Host & Path 

Slide 11

Slide 11 text

● 後半の pb=CAISDgiF2bIBEgcIGhIDMTUz 部分 ● 素朴にやるとかなり長くなってしまう ○ e.g. ?kind=order_item_label&order_item_id=12345678&shipping_depot_id=123&shipping_depot_address=1234… ● Protocol Buffers でシリアライズしている ○ gRPC とかで使われてるやつ ○ 高効率なバイナリ形式 ■ Protocol Buffers バイナリを生成後、文字列にするために URL-safe Base64 エンコードしている ○ フィールド名がデータに含まれないのが大きい ■ 圧倒的なデータサイズ減少 ■ コードの可読性も損なわない ○ 型もついてきてハッピー ● 冒頭の文字列に概ね右の JSON のようなデータが入っている © 2022 Cookpad Inc. 11 QRコードを小さくする / Query 

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

● 便の種類に対応する複数のアプリケーションを使い分けている   ○ 便の種類によって、やること・作業者が全然違う   ○ アプリケーションを小さくシンプルに保ちたい   ■ ユーザーにとっても、開発者にとっても   ○ ひとつのアプリケーションにすると、認可まわりとかが特に大変   ● 技術スタックは作られた時代によっていくつかのパターンがある   ○ サーバーサイドは一貫して Rails   ● 最近は以下の構成に寄せている   ○ Next.js (React)  ○ TypeScript  ○ GraphQL (Apollo Client)   ○ MUI  ○ OpenID Connect (Azure AD)     © 2022 Cookpad Inc. 14 いろいろなアプリケーション 

Slide 15

Slide 15 text

Slide 16

Slide 16 text

● 少し前までは Web アプリではなく Android/iOS のネイティブアプリを中心に開発・運用していた   ● 改善を高速に回すことが難しいと感じることが多くなった   ○ チーム内にモバイルエンジニアがいない   ○ モバイルエンジニアの仕事が常にあるわけではないという事情がある   ■ フロントエンドに大きい改修を入れたい時期がある一方で、バックエンドのロジック改善を粛々とやっている時期もある   ● アプリケーションの性質やチームの体制などを踏まえて Web に寄せることにした   © 2022 Cookpad Inc. 16 ネイティブアプリから Web への移行 

Slide 17

Slide 17 text

● 使いやすさはどうか   ○ さすがにネイティブアプリには劣るが、作業効率などを考慮しても許容範囲内   ● QRコードの読み取りや作業報告写真のアップロードはできるか   ○ 最近の Web は普通にカメラを使えるので大丈夫   ○ QRコード読み取り時に音も鳴らせるし、Android ならバイブレーションも使えるので Haptic Feedback も可能（iOS……）   ● Push 通知はできるか   ○ できない、iOS (Safari) が対応していない   ○ ドライバーを Slack に招待する運用にして、メンションを飛ばすことで半ば強引に解決   ● GPS は使えるか  ○ フォアグラウンドでなら使える、バックグラウンドは……   ○ そもそもいる？  ● Flutter？  ○ 流通チーム内に書ける人がいないため、速が出せない   ○ コードベースは1つになるが、複数アプリストアへのリリースなどは引き続き残る   ○ 各 OS 向けのブリッジ実装が必要なケースもあり、結局そこがボトルネックになる可能性もある   © 2022 Cookpad Inc. 17 検討したこと 

Slide 18

Slide 18 text

● リリース頻度が増えた   ○ 開発しやすくなったことにより、小さい改善を高速にリリースできるようになった   ○ Web のデプロイは楽だなぁ   ● アプリケーションの新規作成が楽になった   ○ 技術スタックが揃っているのは楽   ○ 単純に Android/iOS の2つ作らなくて良いというのも気楽   ● 基本的な開発は流通チームだけで完結するようになった   ○ 優先順位やリリース時期などを流通チーム内で決めて進められるようになった   ○ 背景やドメイン知識を踏まえた開発ができるようになった   ● 単純な「ネイティブアプリ vs. Web アプリ」という話ではないので注意   ○ アプリケーションの性質や今のメンバー構成を踏まえた上での結果   ○ ネイティブアプリのほうが優れている点も多数あるものの、今の自分たちがより価値を置くものを選んだ結果   © 2022 Cookpad Inc. 18 移行した結果 

Slide 19

Slide 19 text

Slide 20

Slide 20 text

● 物理世界は大変なことも多い   ○ ラベルの印字面積は限られているし、一度印刷したラベルは書き換えられない   ○ オペレーションには慣性があって、急には変えられないこともある   ○ どんなに正確に計画を立てても、人間は間違える   ● でも、そういった制約や特性を考慮しながらより良い仕組みを模索して、物理世界に影響を与えるのはめっちゃ楽しい！   ○ コードだけではできないことができる   ● 興味ある方、ぜひ声をかけてください！   ○ この場でもインターネットでもどこでも   ○ https://twitter.com/s_osa_ （右のQRコード）   © 2022 Cookpad Inc. 20 まとめ 