ビデオ配信があると知った時は家から論理参加してもいいかな、恵比寿遠いし…と日和ったが、対面でのコミュニケーションもいくつか交わせたので物理参加して良かった。
TechConf というものの techy な内容それ自体よりもプロダクトやユーザーの価値という視点からそれぞれの取組や技術について語っており、それが始めから終わりまで一気通貫して感じられたのが良かった。プロダクト開発に関する知見もいっぱいあった。
まず rejaspotaro さんの海外展開の話が良かった。 グローバルな開発という面では弊社も頑張っているし仕事で体験している l10n / i18n 周りとかを見て「わかるわかる…」と思っていたけど、"Right-to-left writing" とかユーザー定義・セグメンテーションの話あたりから「これは…数歩先を行っている…！？」という感じがした。頑張りたい。
その他、行動ログ分析、プロトタイピング、A/Bテストの話も興味深かった。これらはあまり深く実践できているところではないので折に触れて立ち戻って復習することになりそう。
あとこのブログで何回か書いた Jasper、その開発者の丸山さんに「いつも使っています、ありがとうございます」と伝えられたのも良かった。
以下、ただのメモ :memo:
※ 内容については間違っている可能性あり。
基調講演
- 言語数＝食文化数ではない
- 同じスペイン語圏でも食文化がまったく違う例
- 同じ食材でも名前が違ったり
- 言語をサポートしたからといってその国で使われるわけではない
- 今は15言語58カ国をサポート
Go Global
Product
- 生活習慣・味覚・宗教の違い、その他もろもろ現地の特異性を理解せずして海外展開なし
- 気候->民族文化->生活習慣の順に構築される
- Kano model (must-be / attractive quality) が国によって違う
- ユーザー定義が難しい。属性よりもコンテキストが大事になってくる（なぜ料理をする、どんな状況にいる）
- どうやって？（直接聞いた
Development
Global Team
- バラバラの拠点でビデオ会議やったりしている
- 公用語は英語
- OKR で目的を揃える
- 海外では無名だったが、海外カンファレンスに出たり大学に行って会社紹介したりすることで知名度を上げた結果採用につながったりした
- 使っているツールは英語圏対応しているものに変える
sorah
- global の cookpad は異なる codebase で0から作った
- global の方の Rails は今のところ普通に運用した AWS ap-northeast-1 us-east-1 / Amazon Aurora / ElastiCache (Redis/Memcache) / Ruby2.3 / Rails4.2
日本で失敗した反省を活かしている
Route53 Latency Based Routing で日本かアメリカのどちらかに振り分ける
Rails app are capable to autoscaling
Peak traffic
モバイルアプリの A/B テスト
- Chanko
- mobile cannot deploy so often unlike web
ユーザーが update してくれない
すでにいくつかABソリューションはある OSS もサービス（Optimizely / Firebase Remote Config / Apptimize）も
user-features モバイルの過酷な環境に耐える薄いライブラリ
- ユーザーごとに適用されている機能の組み合わせをJSONで取得
- オフライン時には最後に取得したキャッシャは1時間
- ずっと通信できていない場合は機能を無効化する
- なぜ内製した？既存のユーザーセグメントやログ基盤を利用したいし、ユースケースは限定的
チームでプロダクト開発をするための取り組み
- 料理きろくのプロダクトマネジメントをやっている
- スマホで撮影した写真のうち料理写真だけを記録する
- 写真の判定には機械学習を用いている
もともとエンジニアだったが、作りたい物を一人で実現するには限界があるのでチームで開発し、チームのパフォーマンス・成果最大化へフォーカスするようになった
圧倒的な技術力・ビジョン・実績で信頼を得るのは難しい
- 凡庸でもうまいやり方がある
- まずは信頼して任せる
よりよい検索体験の為の情報設計とプロトタイピング
- 検索事業部にデザイナーとして参加
最初はエンジニアの領域では？他にできることあるか？と思った
検索における主要な動機を設定する - 検索対象を自覚していない / している など探すシナリオを分解していく
- シナリオにアイデアが湧いたら対応が薄い箇所を特定する
- 機能を作っただけでは片手落ち。機能とシナリオをセットで考えて継ぎ目のないデザインをする。どの動機で入ってきても目的を達成できるような流れを作る。特定のシナリオやシーンで行き止まりにならないか考える。
- 肉or魚？->サバorぶり->揚げor照り焼き
- 不測の事態に対応するために実際の生活の中で試す
- 夕方ノープランで急いで買い物いって店頭で使えるか
- 冷凍してあると思った具材が無いと気付いたときにどうなるか
- 粗くても実際に使える、確度の高い部分から形にしていく
快適なサービス開発を支える技術
Setup
- 開発環境のセットアップ方法を curl setup.sh で全ての環境が整うようにしている
- 構成管理スクリプトをダウンロードする。MitamaeでChef風のRuby DSL
- Mitamae は mruby なので依存が少なくて壊れにくい
Development
- 共用の開発用データベースは本番のコピーになっている
- secure_ というカラム名はコピーしない
- ユーザー体験を考えて、テストデータを横行するときでも本番と同じつもりでやる
- マイクロサービス化
- Garage / Pact / Expeditor などマイクロサービスをサポートするツールを作っている
Testing
- Jenkins を使って自動テスト。テストを失敗させたユーザーにSlackでメンション
- 光速にテストするため、RRRspec / スポットインスタンスを活用
Deployment
- Slack から Deploy するようになっている
- デプロイサーバを一つ用意して排他制御するようにしている
- Slack 経由でデプロイする時、可能な時間は限定している。緊急の場合はシークレットキーを渡せば実行できるようにはなっている
- 一定期間デプロイロックもできる。その期間にデプロイしようとするとchatbotに怒られる
監視
- Sentry
- ジョブの失敗もSlackに通知
- サービスの障害はZabbixで、落ちたときには電話鳴る
まとめ
- サービス開発者の生産性第一
- ただしユーザーが先
Real World Machine Learning
- 料理きろくの画像認識を畳み込みニューラルネットワークで行っている
計算機環境の改善、計算機環境構築の効率化
- 2016/7 EC2 のGPUインスタンスを画像認識に利用していた。ubuntu:trusty から手動でセットアップ
- インフラの人が居ないと環境を整えられなかった
- nouveau / nvidea-driver / CUDA/CUDNN / Chaier/Tensorflow/Caffte / 環境変数 etc.. 整えるのに一苦労
- 全部のせしたAMIをPackerにより作成。手順のコード化＋実行の自動化。5分でオンデマンドGPU環境ができる
ML Lundh / ML Class
- Lunch: 週1で持ち回りで講義
- Class: 月1で外部から講師を招いて講義
行動ログでプロダクトを改善するには
- 検索成功率（満足度の定量化）
- 良いシナリオと悪いシナリオを定義する
- 良いシナリオ：セッションの最後が詳細ページで終わっている、ブックマークした、など
- 悪いシナリオ：セッションの最後が検索ページで終わっている
- どうやってセッション作る？ほぼSQLだけでできる。"sessionize" ユーザーごとにソート
lead 関数で次の行を見ることで、検索内容の推移がわかる（"ランチ"->"夫 ランチ"->"肉 ランチ" etc.）
データでは埋まらない部分
- ブックマーク内のフォルダ分けが正しくない
検索に使った値はプレースホルダーから来ていることもある。予測変換もあれば入力範囲の狭さから言葉が限定されたりする
フィードバックがかかりすぎないようにする
- ログの期間は有限にする
- 実測値/期待値で割り引く
- DWHは一箇所にすべき
