こちらに参加してきました
基調講演
遅れて参加したので聞いてません。
クックパッドの “体系的” サービス開発
BMLループ
- リーンスタートアップの考え方
buildの失敗
- 手戻り?
mesureの失敗
- ログの取り忘れ
learnの失敗
- 数字は動いた
- しかしイマイチ効果がわからない
- 数字は得られたが学びがない
- 属人的
Buildの前に行っておくこと
- BMLループを前から順に行わない
- 手戻り防止
- 逐次にやろうとすると結構大きな手戻りが起こる
- 最初にサイクル全体を設計する
- 効率的な学び
- 施策結果に対する予想
- 現実の理解
- サービスに対する理解
- 想定との良し悪し->なんで??
- どういう結果が出そうなのか?
- mesureやlearnのフェーズで考える内容を考えておく
- 施策結果に対する予想
Mesureの前にしておくこと
- 計測結果の選定
- KPI設定
- 指標やKPIはそれ単体で存在することは珍しい
- 通常は別の指標とバッティングする
- 事前にバッティングする箇所を予想しておく
- ログの確認、SQLの実行
Learn前にしておくこと
- 指標解釈の整理
- 結果の想定
- 👉成功のイメージを共有する
- その施策が成功した時に、ユーザーはどういう体験をしているのか?
社内ツール
- Build
- Mesure
- 社内ツールがある
- Hakari2
- papa dashboard
- 社内ツールがある
- Learn
- Report.md
- 施策の分析レポートをMarkdownで作成し、PRベースで管理していく
- Report.mdを先に作ってサイクルを決める
- Report.md
価値仮設シート、ついつい「届ける価値」の欄をこれから作ろうとしているサービス(機能)にしがちなのですが、そこをぐっとこらえて「届けるべき価値」を埋めないといけないのです。#CookpadTechConf pic.twitter.com/31WziUoyIj
— Cookpad Tech Life (@cookpad_tech) 2018年2月10日
まとめ
- 仮説の実行から学びを得るサイクルを先に設計する
- 前から逐次体に行わない
クックパッドクリエイティブワークフロー
Cookpadは1サービスを作るのに140人のエンジニアがいる
- ユーザーのシーンごとにGroup分けしている。
料理きろくのアプリ版チーム
- Missionオーナー
- デザイナー
- エンジニア ✕ 2
- エンジニアとデザイナーがお互いを補完する
目的と仮説を明確に
- 常になんのためにしているのか意識する
- リポジトリ見れる全員に対してオープンにする
デザインレビュー
- 目的・背景・コンテキストを明確化
- 職種関係なく、横串でデザインを評価する
- 品質向上
数値は全員が見れる場所に
テスト
- 考慮漏れ・見つめ直す
- TsuyoiUI・・・社内のチェックツール
- issue作ったら、issueテンプレートに自動的に反映する
- TsuyoiUI・・・社内のチェックツール
リリース・分析
- あの時誰かがしてたな???(゜゜)問題
- チーム内外の共有をすぐしたい
- Report.mdの誕生
- 見たい時にすぐ見れるレポートの管理
`https://t.co/2NfxkWIhBf` 弊社内ではだいたいこういうテンプレートがよく使われています。https://t.co/f5ziX1yeUe#CookpadTechConf
— Cookpad Tech Life (@cookpad_tech) 2018年2月10日
デザイナの役割
- デザインリリースマネージャ
- リリース単位で体験やUIの変更箇所を把握、デザイン周りを一貫してみる役割
What/How to design test automation for mobile
テスト自動化について
- 開発サイクルの効率化?
- 自動化がモチベーション?
テストで話が噛み合わないところのコミュニケーションの方法
SPLIT がキーワード
-よくわからないものを分割していく
Scope
Phase
- 開発中?orリリース後?
- in Production
- 世に出したあとのテスト
- A/Bテスト
- カオスエンジニアリング
- 世に出したあとのテスト
- in Production
Level
- なにをテストするのか?
- どこを自動化するのか?
sIze
テストの種別
- UnitTest
- IntegrationTest
- ...
テストサイズを分割する
- どういう形に落とし込んでいくのか?
Type
- テストを目的別に区分
- Agile Tesing Quadiants
範囲、時間的なもの、どこまでするのか、どこまで自動化するのか?にどんどん分割していく。
Cookpad Android for Globalでの事例
- 事前のコミュニケーションが大事
- Scope事例
- ユーザーが実際に使う状態に近しい環境
- ネットワークが関係する環境のテスト
- Phase
- in developent
- 開発中だった
- sizeを再定義 3つから4つ
- UnitTest
- IntegrationTest
- UI Components based
- User Senario based
- in developent
iOSはパフォーマンスをテスト自動化しようとしている
- 以前似たような状況にあって、パフォーマンスが劣化した例があった。
Rubyの会社でRustを書くということ
- 多くのサービスがRuby on Rails
- 但し全てのサービスがrubyで書かれているわけではない
- Middlewareなどはjava、Goで書かれてたりする
- CookpadはRubyの会社だけではあるが、Rubyだけの会社ではない。
Push通知を配信基盤をなんとかする
都度配信
- イベントごと
一斉配信
- 特定層に一斉配信
Rustで書き直す前のPush通知配信基盤とは?
- 殆どの部分をアプリケーションが担っていた。
- 基盤というにはあまりに機能が少なすぎた
もともとは世界最大のRailsアプリケーション
- Pushするアプリケーションは1つ以上にある
- しかし今はマイクロサービス化が進んでいる。
- 1つのときは基盤が貧弱でもなんとかなった
- 同じロジックが色んなアプリケーションにコピペされている。
- DBを共有することは避けたい
- DBに接続することも避けたい
新規版では全てのステップを配信基盤で担う
- UserId指定
- 配信先を受信設定に基づいてfilterする
- Push通知の配信見積もり
厳しい性能要件があるアプリケーションをrubyで書くのはしんどい
- Rustには色んなメリットがある。
- 型、安全性、並行性
- トレイト
- データ競合のあるロジックはコンパイラが起こってくれる
Rust is not magic
Facebookのデータローダの考え方を使う
- クエリをまとめる
OSSを開発
※ ここからはさきは説明形式なのとrustなので詳しくわからず
- ブロッキングな処理をFutureに変換しているとみなせる
- JSのプロミス的な概念
Rustのいいところ
マルチスレッドが安全
- マルチスレッドとイベントループを混ぜ込むみたいな複雑なアーキテクチャも採用できる。
とりあえずロックとかなくなる
- 安心して高速化
- 型安全、強力
cookpad storeTV 〜クックパッド初のハードウェア開発〜
StoreTVは三者にメリットがあるサービス
- スーパー
- ユーザー
- 食料品メーカー
ハードウェアでも改善サイクルを回していく - ユーザーにあててサイクルを回す
サイクル
- 第1サイクル
- 最小価値影響
- 売り場で料理動画を探す
- 料理動画を探す・見れる
- 300台配布
- キッティング
- 1台10分
- 週ごとに料理動画を作った
- 売り場で料理動画を探す
- 価値検証
- 電話調査
- 動画見てて楽しい!
- 自分の作りたい動画探せる!
- アプリの利用ログ
- 売上 -> Posデータの提供を受けた
- StoreTVの採用した売り場は他の売り場の1.3倍の効果アリ
- 電話調査
- その他の問題
- 動画の数
- 注力商品のみで良いと思っていた
- 売り場にあってない
- 注力商品のみで良いと思っていた
- 見た目の問題
- 目立たない
- キッティング
- 手作業が手間
- 端末管理
- アプリの更新が手作業
- 動画の数
- 最小価値影響
- 第2サイクル
- スケール
- なにをやって、なにをやらないか
- 得意なことは自分たちでやる、不得意なことは誰かに任せる
- 動画の数
- 毎月100本
- 見た目
- 不得意
- ケースを作成する
- 業者に依頼
- 中国製
- 中国に行ってきた
- ロゴがバグってるw
- 業者に依頼
- 不得なことは1人でやらない、でも任せっきりはだめw
- キッティング
- 不得意
- 業者に依頼
- どうしても人力に頼らざる得ない
- アプリケーションを整えた
- どうしても人力に頼らざる得ない
- 業者に依頼
- 不得意
- 端末管理
- 不得意
- 自動アップデート
- MDMによる一元管理(Mobile Device Managiment)
- 自動アップデート
- 不得意
- 問題点
- サイネージサイズ
- 大きすぎる
- 売り場に置けない
- 大きすぎる
- 開発新興
- バグが増え始める
- サイネージサイズ
- スケール
- 第3サイクル
Challenges for Global Service from a Perspective of SRE
クックパッドのグローバル・サービスってなに?
- 海外向けのレシピサービスを提供している
- 22言語68カ国で提供
- イギリスで提供している
2017年のグローバルサービスの成長
- 対応言語数
- 15->22言語
- 7言語の増加について
- 全言語対応 ≠ 世界対応
- 去年のスライド見てね
- 7言語の増加について
- 15->22言語
現状の課題や挑戦
特定の国のユーザー体験が悪い
- 国ごとに差が出始める。
- 原因がわからないと改善できない。
- 国ごとに差が出始める。
世界中のユーザー体験を測定する
- イベントのバリエーションが多い
- ex.
- 展開国が増えるとイベントバリエーションが増大する
- SREは「毎月バレンタイン」
- 課題改善
- Amazon Auroraを導入
- オートスケーリング
- Dockerアプリ開発環境の提供
- ECS + hakoでのデプロシステムの導入
- hako-consoleを使って状態を管理
- 日本で培った技術をグローバルに応用
- Amazon Auroraを導入
- デプロイのオペレーションコストが高い
- ネットワークが安定しない、日常的に停電が起きる国とかある。
- デプロイを他の人に依頼する問題
- 世界中どこからでもデプロイ出来るようにする
- 米国にデプロイサーバーを用意
- デプロイサーバーでのマニュアルオペレーションの課題もある
- デプロイを他の人に依頼する問題
- 改善策
- slackによるbotデプロイ
- ネットワークが安定しない、日常的に停電が起きる国とかある。
- toilが急増する
- toilとは?
- 骨の折れる業務
- アカウント管理業務とか
- SREの対応する依頼業務が増大
- toilの割合が増大
- SREが本来したい業務ができなくなった
- 世界中に社員がいるからこその課題。
- アカウント管理
- nginx + omniauth
- アカウント管理のセルフ管理化(移譲)
- SREのマルチリージョン対応
- 時差の壁を超えたりとか
- toilとは?
動き出したクックパッドのCtoCビジネス
- komercoの発表
- もので毎日の料理を楽しくするプラットフォーム
- 料理を盛る器や鍋がいいと、もっと料理が楽しくなる
- もので毎日の料理を楽しくするプラットフォーム
komercoにはサーバーサイドエンジニアがいない
- サーバレス
- Firebaseで開発している
(このあたりやたらFirebaseの宣伝というか、いいこと話してること多かった)
※ Firebase Japan User Group入っておこう。
OpenSourceにすること
- 少人数で品質を担保するため
- Opensourceすると品質が向上する
- 外部の人がチームのリソースになる
- 再利用できる
- 他チームで利用できる
技術一覧はこちら
先ほど一気に紹介されたレポジトリをこちらでも紹介いたします。https://t.co/t8blyovai7https://t.co/0Q8N0Ws48Yhttps://t.co/m8FitHRORNhttps://t.co/dRe9tdonKohttps://t.co/DdrmpeoowPhttps://t.co/pwIsUML1NPhttps://t.co/AWU8bwdzDzhttps://t.co/i4eUIFhKF4#CookpadTechConf
— Cookpad Tech Life (@cookpad_tech) 2018年2月10日
Pring
- firebase Model framework
Orderable
- Order processing framework
開発の高速化の先になにがあるのか?
- 大胆な戦略変更
- 複数回の仕様変更
- エンジニアが消耗しない
- コミュニケーションコストがかからない
- たくさん試すことができる
- 事実は我々の中にない、市場に聞くべき
- たくさん試すべき
Solve "unsolved" image recognition problems in service applications
画像分析のお話
昨今の画像分類問題
- 理想的な状況下では「解けた」と言われている
- 適切なラベルの付与
- 適切なカテゴリの設計
- closed set
- 現実世界はopen setである
- ラーメンの画像分析にケーキの画像がくることなんて容易にある。
- 私たちが本当にときたい問題はなんなのか?
- 解くべき問題の多くは「間違っている」
- 本当に時対問題をtry and errorで探していく
料理きろくの進化と現在
- 機械学習の観点から見る重要な点
- クイックスタート
- 要素技術が成長している
- モデルの改善と苦手なカテゴリの考慮
- 間違いやすいやつら
- 植物はサラダと分類される
- テストデータの拡充
- 局所性を取り込むためのpatch化
- 画像の一部だけに料理が移っていた時
- ふと、お店で出てきた画像とかどうするんだろう?
- 自分で作った料理ではなさそう???
- それは分類されてもいいのかな???
- 料理きろくのその先へ
- 勝利写真のレシピカテゴリに分類
- 単純な分類に見えて実は非常に難しい
- openset における予測
- 類似カテゴリをどう予測するか
- 類似画像に対する分類
- クイックスタート
類似モデルは生まれるのか?
- カテゴリを設定した時にどういう画像が生まれやすいのか?
モバイルへの移植
- どうサービスに載せるか
- 次に来そうな領域
Beyond the Boundaries
※ 基調講演
- 技術を正しく理解し、「ふつうに使う」
- 技術スタック
- 自分たちの道具は自分たちで持続可能にする
- コミュニティへの還元
- 「境界」を認識し、乗り越える強い組織へ
まとめ
2年ぶりにCookpad Tech Confに参加してきました。
領域としてはプロダクト作りからグローバルでのサービス展開、機械学習まで幅広い話が聞くことができました。
個人的には、SREの話やPush基盤作りの話が面白いなーと感じましたが、HTTPやCookpadのプラットフォーム作りの話をもう少し聞いてみたかったと思いました。