CookpadTechConf 2019 メモ
CookpadTechConf 2019
取り敢えず当時の記録
スライドが公開されたら資料のリンクも張っておきます
tag: #CookpadTechConf
クックパッドが目指す、これからのデザインとプロダクトのあり方
宇野 氏
そもそもCookPadってどんな会社?
「毎日の料理を楽しくする会社」
4k万人 71国
「デザインはデザイナーだけでやるものではない」
- 夢物語がもしれない課題を解決するものはあくまで技術であってほしい
生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて
長野 氏 Cookpad10年
昨年新規に立ち上げたCookpad Mart
- アプリで注文できる生鮮ECサービス
- 街の専門店や現地の生産者からのこだわりの品をラインナップ
- 受け取りは近くのお店でピックアップ
- コレによって最低注文価格なし 送料も無し
- 食材購入 +レシピによる UX
ペイン - 単身世帯 共働き世代 - 帰宅時間にはお店がしまっている 商品がないのを改善したい - 現在のネットスーパーも使いづらい
仮説検証
最初は車内でgoogle スプレッドシートで注文を受けて社員が買ってきて渡す形態でテストしていた。 お金をもらうことが重要。この形態でもクレカ決済できるようにしていた、
- 1対1の代行モデルはスケールの課題が大きい
梱包や仕分け作業が大変
自分が普段買いづらいものが買えることに価値があった
- 普段買えるものは手数料もあって高く感じられた
- 合わせてSLackでレシピを提供したら好評だった
↓
仮設を修正できた!
Next フェーズ 商品提供してくる人たちに価値を提供できるか?
- ここでデザインスプリントを実践した
- チームで短時間で検証する
検証したいこと「販売者などがお店の売上向上に期待できるか? 無理せず提供できるか?」
- ストーリボードを用意した
- スタッフがドライバー役になって体験してもらった
- インタビュー時は別室でスタッフが観察 意見を色分けしてボードを作っていた
- デザインスプリントは難しい課題ほど有効である
- 今回は2日で検証した
「今できる最速の方法で検証し仮設の角度をあげていく」
リリース後も同じ手法で改善している
サービス拡大するには
「価値を届けられるユーザー数を増やす」 - 配送頻度を増やす - 週2配送していたが毎日配送に - 店舗の発注 - 配送 - 色々とオペレーション改善が必要だった - ここで初めて自動化 LineWorksとFAXで依頼を自動配信 - 商品ラベルの発行と送付 - 週2時は車内で作ってバイク便配送をしていた - 現在は店舗にラベルプリンターを設置 依頼があれば自動で印刷するようにした - ドライバの集荷指示 - ここも自動化して配信
→ 結果的に週6配送を実現
受け取り場所の制約を減らす
- 現在は友人のところのみ対応
- 現在スマートロック対応を行って無人の場所でも設置できるようにしている
プラットフォームを増やす
「技術を使いより多くユーザーに価値を届ける」
最初は3人でスタート
現在は21人に増えてる
料理の学習体験をデザインする
新規サービス開発部 須藤 耕平 氏
新規サービスとしてリリースしたアプリについて
「たべどり」 を昨年リリース
「ユーザーの料理の腕を上達させる」
2018初旬リリース 5月 ベーター 8月 リリース 2019年 リニューアル中
何がむづかしいのか
- 上達の定義が難しい
- 初心者向けに作ってみたがみんな意外とできている
- 初心者向けにインタビューをしたが「もっとはじめのときに知りたかった」と言われて断念
- みんなどうなりたいんだろう?を聞いた
- 「レシピを見ないでもあるものでぱぱっと作りたい」
- ぱぱっとってなんだろう…?
- ぱぱっと ≒ 対応力 というのが見えてきた
- ぱぱっとってなんだろう…?
- 「レシピを見ないでもあるものでぱぱっと作りたい」
- みんなどうなりたいんだろう?を聞いた
あるものでぱぱっとは総合力だ
- 買い物スキル
- 献立計画
- 食材や調理スキル
- 場数
だけどアプリですべて対応することは難しいので「買い物スキル」「献立計画」は一旦捨てて課題をよりフォーカスして難しそうな課題に集中した
- レシピ単位で覚えるのは非効率
- 記憶には非効率
- 食材がいつもあるとは限らない
どうする? → 「食材 * 調理法 * 調味料」
- 具現化力ってなんだろう?
- 大枠の調理工程は共通している
- 日が通りやすくする
- 火を通す
- 味をつける
- 整える
- 各工程中間生成物がある
- 下茹でした大根
- にんにくの香りを移したオイル
- これをパターン化して覚えてもらおう!
- 小さいので覚えやすい
- 一つ一つは複雑ではない
- これをパターン化して覚えてもらおう!
→ 中間生成物ごとにカードを作ってプロトタイプ 「意外と簡単にできる!! パターンも無限大 これいける!」
→ アプリ「たべどり」 - ゲーム要素も追加
- 自分がどのように学んだのか何ができるのかをフィードバックするように
まだまだ理想には遠い
絶賛リニューアル中だから待っててくれよな!
興味がある人はJoinUs!
新規サービス開発を加速させる技術とデザイン
藤井 謙士朗 氏
komerco 「料理が楽しくなるマルシェアプリ」
- 18年6月リリース
- 料理が楽しくなる器や道具が買えるサービス
- 現在iosノミ
クリエイターが作ったものを買う クリエイターが作ったものを売ることができる
開発で取り組んだこと
- スピードが求められていた
- きれいなUIはあと
- 取り敢えずリリース
- 簡単な動線の設計をして実装
- 細かいエラー処理とデザインはあとで
- デザインをエンジニアと共有するのが大変…
- 履歴残すのも大変
- デザインする時間がどんどんへる…
- けどエンジニアが4人いるからデザインを求められてて辛い
- Sketch + abstract + zeplin + marvelでデザイン
- つらい…
- → Figma
- アトミックデザインを採用
- sketchでやるのは重くてしんどい
- Figmaだとすごいやりやすい
- → 開発スピードが上がった
- ただ構築に時間がかかる
Figmaの利点
- 同時編集が楽
- デザイン履歴をバージョニングできる
- プロトタイプも簡単に作れる
更にスピードを上げるには
- UIガイドラインを作った
- Figma上に全体のガイド欄を設定
- アイコンをアプリのために作成
- フォントにしてリソースを一つに
- Web Appと Native共通に
- バージョン管理はGithub
- 使えるアイコンはGithubPagesで見れるように
- フォントにしてリソースを一つに
リッチな体験を追求する
Challenges for Global Service from a Perspective of SRE 2nd season
海外版のメインの拠点は実はイギリス
SREのユーザーは誰だろう?
- Cookpadのユーザー
- 1行のログの向こうには1人のユーザーが居る
- 社内の開発者
- 可用性を制御する
2018年 の挑戦 自律的なチームへの移行
開発体制の変更
- 社内で意思決定できるようにしていく
- 海外開発体制を大きく変更してきた
- 横断的なちーむからチャプターごとのチームに
- エンジニアひとり増えるとコミュニケーション量は爆発的に増える
- コンウェイの法則
- 機能の構造は組織に依存する 「新機能の良し悪しはユーザーにぶつけるまではわからない」
- 海外開発体制を大きく変更してきた
- 社内で意思決定できるようにしていく
いいことばかりではなかった
- 海外のものでも日本のSREが一時受けしていた
- SREは無限にしんどい…
- 可用性の定義を書くチームと握れていない
- 逆コンウェイの法則などめったに見れないことが見れているのは楽しい
- 海外のものでも日本のSREが一時受けしていた
ステートレスなものはすべてコンテナ化
レシピを解析する！Machine Readable Recipe（MRR: 機械可読なレシピ）の開発
研究開発部 伊尾木 将之氏
「Beyond recipes」
- レシピデータを持っているのにレシピを見る以上の体験が提供できていない。
- IoT家電にレシピが連携できるようにしたい
課題
- レシピは自由記述
- 言葉揺れ
- 表現揺れが激しい
- マシンが読める形式MachineLeadebleeRecipe
- 書くアイテム工程をID管理
- 手順をツリーで保持
- Recipeをみて調味料をマージする「oisy teste」を開発
- 開発情報を公開中
MRRは難しい
- 材料名の正規化
- Action情報
- メタ情報
「MRRは非常に夢がある技術」
だけどアクションなどはまだまだ取れていない
面白いし可能性しか感じないやっていくしか無い
クックパッド動画事業開発のチャレンジ
cookpad tv.inc
2018年は事業領域を広げる一年
2019年は収益化を目標にしていく
cookpad StoreTV
- スーパーで料理動画を流して買い物客のレシピ決定の助けに
- 売上のPI工場が目的
- 1サイクル90秒 一時間40回
- 広告動画 再生数制御
- 各端末に配信計画と配信比率を配信
cookpad tv
- 一緒に作れるクックパッド
- 一緒に作ったりコメントしたり
大量メッセージ
- AWS AppSyncで配信
- ハートが47分の番組で150万
- 平均532pqs
- AWS AppSyncの限界
- →メッセージをバッファリングして配信
- 流量によってバッファ料とFlashタイミングをコントロ0る
- 順序保証はしない
- Goで実装
- GRPCで相互通信
- → DesignDocを整備
- 負荷試験計画作成
〜霞が関〜 クックパッドiOSアプリの破壊と創造、そして未来
- 最初のコミット2012/8 歴史がある
「ビルド時間に一日トータル1時間使ってい場合がある! 非生産的」
課題 - 25%あるobject-c - 一時間のビルド
↓
霞が関プロジェクト - コード整理 - Object-Cのは回 - ビルド時間改善
理想
- マルチモジュール化
- Module化して必要なところのみビルドするようにしたい
- 画面感を疎結合に
- Object-cとSwiftを混ぜた場合ブリッジを生成するために時間がかかってしまう
歴史
旧来のシステムはMVC+ごっちゃにで辛い
↓
クリーンアーキテクチャーへ
- xcode genによってmodule導入が容易に
スケーラブルなセキュリティ監視基盤の作り方
セキュリティは基本的に三つの柱がある
- 防御
- 完全な防御は存在しない
- 使わせないなどの対応になりがち
- 利用者の負担は減らしていきたい
- 検出
スケーラブルな監視とは
- サービスが＼増えると関しするものが増える
- 今回はアラートに注目したい
- ご検知 過剰検知で疲弊しては行けない
- 検知のルールで余分なアラートで除外していけばいいが…
- 調整後のルールーが動くのかわからない
- 判断に関するロジックがかけない
security as code」と言う概念
- 検知に関する処理をコード化
- 変更ルールをテストできるように
- バージョン管理化
アプリ認証
かきんまわりのろじっくはしんどい できることならビジネスロジックの認証に集中したい
そこでCuisineというらいぶらりを開発 - API通信時に自動で再認証する - ステートマシンで実装 - アプリ内課金を簡単にする - かくぷらっとふぉーむの課金の仕方を標準化して実装 - ここ数年サーバー側はマイクロサービスに移行中 - ユーザー管理 アプリ内かきんていきこうどくAPIを実装 - 標準化されたもののみ実装
カオスエンジニアリング生活
カオスエンジニアリング - 不安定な状態でも耐えれるシステム - 予防接種のように意図的に取り込んでも問題ないことを検証していく - カオスモンキーではない - ランダムに落とすことがカオスエンジニアリングではない - なぜ僕たちがカオスエンジニアリングをするのか - モノシリックからマイクロサービスへ移行したが通信状況などがわからない… - サービスメッシュへ アプリケーションレイヤーと通信を切り離して考える
