記事一覧
（更新: 2022/11/28）

「Cookpad Tech Conf 2022」に参加してきました。

#Blog #Ruby #DevOps #Conference

はじめに

Cookpad Tech Conf 2022に参加してきましたのでそのレポートです。

オンライン開催は2年ぶりらしい！！

Cookpad TechConf 2022

少し長いので目次

Today’s Schedule

Contents

Program

メインの発表以外にもLive designゃLive codingもされていました。夜は野毛で懇親会みたいです（楽しみ）

基調講演「失敗を活かす組織」

CTO 成田さん x Designer 米田さん

開催に向けて

最初は2016年開催だった。2年間できていなかった。

CTOとして「カンファレンスは物理開催じゃないと意味がない。」と考えている

今の期間をどう考えているか

2017〜2027年を投資期間として位置付けていた。既存事業を海外事業として立ち上げしたい。海外での有料会員事業の成功を狙っている。

Mission

毎日の料理を楽しみにする

様々なアプリケーションをOpen・Closeしてきた。

  • みんなのお弁当

  • tabeta (SNS)

  • cookpad DO!

  • 美味しいテイスト

💡 サービスには持続可能性が大切

エンジニア組織

プロダクトと横断組織で分けている

Cookpad Manifest

  • 境界を越える

    • ソフトウェアエンジニア
    • デザインだけでなく境界を超えて仕事をする
    • 専門性だけでない

  • 技術を楽しむことに責任を持つ

    • 楽しんだ分、バージョンアップなど責任を持たなければいけない
    • 楽しまなければ責任を持てていない

  • 作ったもので語る

    • 挑戦を続ける
    • 言葉でなく口にしなければいけない

デザイナーの話

デザイナー陣は２週間に1回LTをしている

デザイナーがプロダクト責任を持とうとしている？

  • なぜLTをしているのか

💡 自分でなんとかするために自分と頼れる人のマッピングをする

つまり失敗を活かす組織とは

🔄 失敗から学ぶ！！成長する未完成であり続けること（=持続可能性に繋がる）

レシピサービスにおける持続的なプロダクト開発プロセスについて

技術領域担当: 大石さん PD: 島さん

組織と開発プロセスのリデザイン

レシピサービスとは？

  • cookpad
    • 1998年〜
    • ユーザ投稿型サービス

なぜリデザインが必要なのか？

2020年にアプリを大規模リニューアルをした

思うように開発が進まないと感じていた。

想像以上に時間がかかると感じていた。

時を同じくして

#どうしたらいいんだ Slackチャンネルw が発足していた。

何かがおかしい。。。

組織として問題解決しないと不味い

課題と指針を言語化をおこなった（意外とシンプル！）

リアルで時系列で振り返りをした。

わかった問題の3つ

  1. 無理を強いる開発進行

  2. 開発進行の属人か

  3. 期限ドリブン

  4. 情報の透明性のなさ

  5. 技術的なコストを事業として考慮できていない

  6. 運用コスト、技術的負債の認識がない

  7. 大規模プロジェクトによって残された負債

  8. 技術戦略面のミスコミュ

  9. 技術戦略の共有不足

  10. アーキテクチャと組織不一致（逆コンウェイ的な話）

アクションの制約

規模を考慮

開発を止めない

  • 負債解消プロジェクトではない

解決

  • スクラムの導入

  • プロセスの型を作る

  • プロセスの側面からサポート

結果として

定期的な機能・サービスの棚卸。２ヶ月に一回「サービス継続確認会」をしている

スクラムでプロセスが統一されて、コミュ・意思決定がスムーズになった

  1. 定期的な振り返り、バックログで情報の透明化でゴールの解像度が上がった

  2. プロダクトバックログでコストや技術課題を見える化・技術課題の投資判断もした

  3. 物理的に組織を近くすることでコミュコストを下げた・アーキテクチャの選定で広がった

結果。。。。

🔥 あの日の行き詰まりを完全に乗り越えた！！

巨大なレシピサービスのアーキテクチャを最高にしたい

Engineer: 宮崎さん

レシピサービスの巨大なレシピサービス

Web、Android、iOS

歴史の長いサービス

1,500,000（LoC: Line of Code）

デカすぎて開発不可

うおおおお。時代はマイクロサービスだ！！

BFFを導入をする。FrontendのためのAPIを集約するやつ

開発保守がしやすくなった

かつて：巨大モノリス

2018年後：マイクロサービス化

現在：マイクロサービスがたくさん、BFFの活躍、開発保守は楽になった、、、？

でも開発が辛い

⇒ /api のレスポンスどうだったけとかコミュニケーションが増えた

マイクロサービス（たくさん）x BFF（難しい）

なんか開発が辛い

  • アプリケーションごとの責務が不明瞭

    • BFFにビジネスロジックが発生する（しんどい）
    • BFFにロジックをもたない方が複雑性は小さい
    • 特にルールがないまま運用されてるので複雑性が多い

  • API仕様がどういったAPIなのかわからない

  • 技術スタックの分散

    • Backend: Ruby, BFF: Java, Web BFF: TypeScript
    • コンテキストスイッチの学習が多い（やりたいことはシンプルなのに）

Takanawa Projectがスタート

レシピサービスへのGateway 開発

  • API Gateway

アプリケーション事の責務の整理（コンテキスト整理が必要！！！）

  • API4-gateway

  • API Gateway パターン

    • クライアントからはリクエストはここを通る
    • GraphQL スキーマを通す

  • GraphQLでスキーム

  • ロジックデータを持たせない

難しいことは全部バックエンドに寄せる

メインとなるバックエンドを決めた

メリット

  • ロジック。データの責任所在が明らか

  • 共通スキーマでみんなわかる

  • 難しいロジックをRubyで書ける

  • アプリ用BFFを捨てて言語を1つ減らせる

まとめ

  • マイクロサービスBFFは導入が難しい

  • 既存のアーキテクチャが抱えている辛さを無くしたい

  • TakanawaでAPI4-gateway で既存の辛みを無くしたい

生鮮食品をユーザーに届ける流通の仕組みと技術

Engineer: 長さん. @s_osa_

流通を作る理由

  • 新鮮な野菜

  • 変わった食材（マグロのテール、製麺所が作っている餃子の皮）がある

魅力的な食材に出会えているか？？ ⇒ No

ユーザに届けるためにクックパッドが作る！！

ステーション配送

課題

  • 宅配の受け取りのための在宅は大変

    • 非同期で解決できる！！

  • 毎日送料かかるのは負担が大きい

解決

  • 冷蔵庫のステーションに置いておく

  • まとめて配送することで1品から送料無料にできる

仕組みはなかでJWTTokenで開くシステム

大量の商品を正確に選ぶ

  • バラバラ

  • 大量

  • 多種多様な似たような商品

⇒ ラベルで解決、識別と作業指示、

ラベルは書き換えができない、ハードウェア的な難しさがある、安全かつ高速に生成できる用にしている

配送アプリケーション

  • 普遍的な情報提供

  • 元々はAndroid・iOSで作っていたが、チーム体制を抱える面も踏まえて、Web版にしている

  • 技術要素: TS, React, GraphQL, MUI, OAID,,,

配送オペレーション

  • 計画が必要

  • ルート生成

    • 各ステーションに配送するためのルートを組む
    • 様々な制約がある！！
      • 時間、物量、営業時間
    • 制約を満たして、技術的にどう満たしているか

  • 技術要素要素：

    • OSRM
      • 2点間の移動時間
    • OR Tools
      • 数理最適化ライブラリ
      • 配送計画問題の近侍回を求めている
    • 上記の2つの軸に自分たちの制約を入れて出力している

これから作っていくもの

スケーラブルな流通を作っていく

現実世界で倉庫をスケールするのは非常に難しい。

正確・確実に届く流通

  • 人間が作業してるのでミスが出る

  • スキャナ導入する

  • 追跡ログの導入

大きい食材を入れるための枠を作る

まとめ

ソフトウェアとハードウェア開発をしている

現実世界の難しさがある

関連する技術ブログ

クックパッドマート最難解ロジック!?「採番」 - クックパッド開発者ブログ

新規事業クックパッドマートを支える機械学習の技術

機械学習の分析アーキテクチャはシンプル

RecVAE

AutoEncoder系の手法でTop-N推薦まとめ - Qiita

レビューチェッカーを導入した

半自動でCSさんの負荷を前よりも減らす

レビューチェッカーで食べ物かどうかチェックをしている、つくれぽの仕組みと一緒

クックパッドが挑戦する「レシピ」と「かいもの」をつなぐ新しいサービス作り ~ 役割にとらわれず新しい価値に向き合い続けるチーム ~

Engineer 谷口さん, Designer: 新妻さん

10名で開発をしている

1. レシピと買い物をつなぐ

クックパッドマートとレシピをつなぐ

「買い物」と「献立決め」は隠れた意思決定がある

2. 新しい機能を使ってもらうための取り組みと学び

買い物機能を知らせるために色々施策をした

  • 機能紹介：x

  • 無料お試し：△（無料だと後から請求されそうで怖い）

  • いちご試食：○

  • 商品の紹介：x

    • 広告のように見えた

  • 食材の一覧をマートで表示する：△

    • 工夫したものの食材と内容に差異がある難しさ
      • ニンニク ⇒ ニンニクチューブ
      • 鳥もも1枚 ⇒ カット済み鳥もも肉

3. 作ったもので語る

コンセプトやデザインモックはユーザ体験を都合のいいように解釈してしまう

プロトタイプをつくって学びを得るまで2時間！！

最後に

毎日のように料理を楽しむ

ユーザと一緒によりよいサービスを作る

デザイナーやエンジニアが役割を超えて、新しい価値に出会える

Go Global Search 2

Engineer: Orgilさん

Cookpad Globalはイギリスで運営している

100人以上の40カ国以上の人たちで関わっている

アーキテクチャを刷新した

Ruby x ElasticSearchでの検索システムを作っている人たちは少なかった。採用が困難だった。

Python x ElasticSearchでリアーキテクチャして計算もしやすくした

学習の仕組み

kafka event streaming

⬇️

Faust by python

⬇️

DB table Update

No more shared DB!

前はレシピとDBを共有していた

ABテストの仕組み化

Enrichment pipeline by ML API

Yamlファイル + FeatureToggleで簡単にABテスト

検索は何度もデータを取らないと良いものにはならないのでABテストができる仕組みは非常に大事

エンジニアだけでは30言語の改善は難しいので現地の人たちを頼りに改善を重ねていった

まとめ

人員も増え、自分達で検索生を向上させ、検索UIも改善して全て自分たちで改善することができるようになった

最後に

懇親会

野毛で一番大きい居酒屋でワイワイしました。様々な職種の人が集まっていて楽しい会でした。（はなたれは野毛で一番大きいらしい）

有志で二次会のシーシャバー

個人的な感想です！見たい人はどうぞ🫰

初めての参加でしたが、完全招待制で参加できてよかったです。限定的に大事にされてる感じがして参加していて集中して聞けました。無駄にノベルティ配り合戦もないのも良いところ。（結局みんな捨てて無駄になるしね）

みんな技術にイキイキしていて速攻にプロトタイプを実装していたりしていて、チャレンジし易い環境がすごく羨ましく思えました。その代わり責任も大きいので大変そうですが、失敗を受け入れて次に活かす組織を醸成していて、羨ましいなと思いました。

マイクロサービスでの苦労やイケてないと思えるチーム構成を奥せず変更していける組織は強いなと感じました。組織変更が一番大変なイメージだからそれできるんだ！という驚き。（自分の今の環境でやろうと思うと何年かなるんだろう、、、）

あと発見だったのはクックパッドマートってどうせ高いんでしょ？というイメージだったけれどそんなこともなくて、よくよく考えてみるとユーザからしたら非同期的な仕組みで配送も貯めれるし、注文者も家で待たなくて良いし、まさにメッセージング的な仕組みで可用性高いなと感じました🤔

もう少し前から気づいていればもっと使ったのにと思ったので家内で勧めていこうと思う。また使ってみたら感想をTwitterとかに投げてみようと思う（優秀なクックパッドの人が拾ってくれるかもしれない）

後日資料と動画がアップされるらしいので要チェック！！

https://techconf.cookpad.com/2022/

招待ありがとうございました！また来年も参加したいです🫰