Cookpad TechConf2016 参加レポート
Cookpad TechConfに参加してきました〜！ 忘れないうちにレポート書きます！！
1. 基調講演: ユーザーのために、技術をどう活かすか
発表者：舘野 祐一さん
ユーザファーストの考えが全てのスピーカーさん達に浸透していて素晴らしかったです。
まずは会社紹介
- 社員約２５０人（エンジニア：８０人、デザイナー15人）
- 月間５５００万人のユーザー
- レシピだけでなく海外進出や他サービスもやってる
ユーザファーストのための技術
- エンジニアに全てが求められる現在
- フルスタックエンジニア
- 他にも高レベルな技術
- その中で今必要な技術は何なのか？
- モバイルアプリに適した開発を考えて起用していく、変化を受け入れその時にあった技術開発を行うべき
- マイクロサービスの適用
- 必要な技術が自ずと選定できる
高速にサイクルをまわすことが大切
- 仮説->実行->検証を素早く回す
- 仮説：Chanko:高速にプロトタイピングを実現
- 実行：テスト高速：RRRSpecで分散並列環境でテスト高速化１H→７分（2万以上のテスト）
- 検証：Hakari一行コードを挿入するだけでメトリクスが図れる計測ツール。
- 素早く何度も検証することで価値が何かを学習する
- 当たり前のことを当たり前にでき続けることが大切
ユーザファーストのための組織
- 組織体制
- 集約型：エンジニアだけの部署
- 分散型：様々な部署にエンジニアがいる
- クックパッドは横縦の両方が組み合った組織体制である
- 正解はなく、その時にあった体制を取り入れるのが大事
情報共有
Groupad(Blig+Wiki)とは
- いろいろな技術やエンジニア以外のことを記事に書き、共有している。チームごとにやっていることがわかるし、社内のコミュニケーションも強化できる。
- いろいろな部署があるからこお情報共有は大事
- どんな人にどんなメッセージを伝えるのか、どういう風に伝えるか考えることは大事
- クックパッド開発者ブログも行っている
一人一人の成長
- 設計・実装・フィードバックのサイクル
- GHEをと通したコードレビュー
- 設計・サービスについての議論
- できる人からのフィードバッグ
- 詳しい人が一人いると、すごい速度で伝搬していく
- なぜ？がすっきりと理解
- レシピ以外のサービスも展開
- 様々な視点を得る
- 他の組織、開発を経験する
- 知らない視点のインプット
- 自発的な組織改善
- Cookpad Loungeというイベントを実施
- どういう風に組織全体を良くなるかを自発的に考える
- エンジニアも主体的に組織改善に関わるを評価する
- 行動評価
- 社内外に影響を与えているか
- Cookpad Loungeというイベントを実施
2. おでかけスポット検索のむずかしさ - Holiday を支える検索技術
発表者：内藤 雄介さん
中目黒は中目黒ではなかったのですね…。
www.slideshare.net
Holiday お出かけ情報共有雨サービス
- Holidayでの検索
- 全文検索ではうまくいかなかった
- 中目黒は地理的に中目黒ではなかった・・・。
- ユーザが考えることシステム的な正解は異なる
- 全文検索＊地理検索
- 「どこで」を探すには全文検索では不十分
- Elasticsearch1.7で地理実現
- Geo Distance Filter:駅周辺のスポットで探す
- Geo Polygon Filter:範囲内に入っているかどうか
- Geo Bounding Box Filter:正確性は低いか高速
- 地名を判別するために
3. Railsアプリの高速化
発表者：国分 崇志さん
発表も表題通り高速化されていました。速い(><)笑
クックパッドの快適な機能開発
- 機能開発
- 高速なプロトタイピング：Chanko
- 本番からレプリされる開発用DB
- テスト実行
- 分散RSpec実行 RRRSpec
- デプロイ
- 高速なデプロイツール Mamiya
- クックパッドは機能開発の仕組みは整っていてテストもデプロイも高速で開発しやすいが、開発環境が遅い。
- 何か変更してリロードするのに謎に16.2S待たされる
- アセットコンパイルに23分56秒かかる
- CIが遅くなる
- ステージング環境へのデプロイが遅くなる
Railsの高速化
- MySQL: INSERT,DELETE,UPDATEが走ったらJOINも考慮してキャッシュクリアなど
- Solr: SunspotによるSolrへのクエリの結果をキャッシュなど
- GC: リクエスト処理中にGCがあまり走らないようになど
- Asset: アセットのリクエストをブラウザでキャッシュ、sprokets-railsのデバッグ機能を切る
アセットプリコンパイル（高速化のために何をしたか）
4. R$D at Fooddtech company
発表者：有賀 康顕さん
最近ブームな機械学習のワードが出てきました。
www.slideshare.net
研究開発
- 食文化領域 食の問題（偏食、個食、伝統食の継承）
- 季節性、地域性を検索履歴を通じて定量的に明らかにする
- ヘルスケア領域
- ごはんカメラ：糖尿病患者の食事記録
学術研究を支援する
非専門家でも機械学習を使った開発ができる
- レシピの自動分類による自動検索
5. 技術力を事業の強みするために必要なこと
発表者：大野 晋一さん
チーム体制のあり方について勉強になりました。
www.slideshare.net
事業と計画
- とにかくシンプルにする
- 事業の成果を何で説明できるか？（売り上げ？PV？）
- 人流の数字で表せる、分解できる（100億円＝クリック単価100円＊、、、)
- 分散することで今何をすれば良いのかがわかる（フォーカスする分野がわかる）
責任範囲とリーダシップ
- 議論や調整じゃなくて決定とテスト
- 誰がコミットするか、どこでを決める
行動
- 集中する領域に加えて行動を定義
- 評価をしやすくする（定義があることでできる）
6. 開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法
発表者：五十嵐 啓人さん
「ユーザーの欲求は希望ではなく、悲しみの原因となることを集める」がごもっともでした。
技術開発＋ユーザーが実感できる新しい価値創出
- 技術から思いついたサービスはOUT
- ユーザーの欲求から解決策を考える（どの技術が使えるか）
- 価値->製品->技術の順番で行う
ユーザーの欲求を集める（特に悲しみや失望などのマイナスな点を集める、ないと死ぬ、困る！）
- あったらいいなを防ぐ（希望）
- 有望な案をブレイクダウン
- 解決策は機能ではなく状態で考える
- 製品化へ（どんどんプロトタイプを作って進める、とにかく仮説を形にしていく）
ユーザー欲求について意見を出し合うMTGを設ける
- 複数人で議論し、幅を広げる、経験を共有する
- 様々な意見から決まらなくなってしまわないために、決定者を設定する
7.『今日何作ろう』を支えるデザイン
発表者：木村真理さん
ツールを駆使した最適な方法、参考にしたいです。
www.slideshare.net
ユーザーファースト推進部
- クックパッド全体のサービスを横断的・俯瞰的に見る
- ファンを増やす、新規開発改善などをやっている
- ユーザーファーストなサービスとは
- ユーザが期待した通りの動きをする
- ユーザがついつい夢中になる
- 人にオススメしたくなる
- 機能ではなく、ストーリーで考える
- 機能にフォーカスすると目的を失いがち
- ユーザのどんな問題を解決できるのか
- ユーザーを主語にする
プロトタイピング
- 目的：仮説検証、アイデア共有、小さく素早く試せる
- 種類：ペーパープロト、デザインプロト、アニメーションプロと、動画モック
- 利点：実装後の手戻りが少ない
デザインフレームワーク
デザインレビュー
- Github Issue
- 他のデザイナー・開発者がレビュー
- デザイン変更の経緯が誰でも参照できる、議論による新たな気づきもできる
デザインリリースマネージャー
- リリース前にメンバー全員で実機（複数）で確認を行う
8. 確かめながら作るユーザー体験
発表者：井口貴也さん
サービス開発の難しさに立ち向かう３つのことを教えてくれました！
サービス開発は難しい
- 決める段階での難しさ：誰も答えを知らないこと
- 作り上げる段階での難しさ：決めたことが途中でブレること
* この２つをどう対処するのか * 確かめながらサービスを作る * 事前に目指すユーザー体験を定義する
cookpadの実践
- どのような体験を提供するかを定義する
- 作る前に確かめる
- 仮説の質を高める
- 方法：デザインレビュー、ユーザーインタビュー、紙とペン、プロトタイピング
- 作った後に確かめる
- 点の体験でなく、線で検証することも重要
- 体験を定性的に確かめる （ドッグフーディング、ご意見ボックス、アンケート、ユーザテスト）
- ストーリーの達成度を定量化する(ファネル分析) -> 定量、定性の検証手法を駆使する！
9. モバイルアプリのインタラクションプロトタイピング
発表者：多田圭佑さん
Prott！！時々使ってます。
www.slideshare.net
価値のあるプロダクトを作るために速さと品質が必要
- 価値のあるプロダクトを作るために
- 速さ（価値を発見、ユーザーの変化に適応）
- 品質（価値を正しく届ける、価値を高める）
仮説、実行、検証を細かく何回も回す
- しかし、モバイルアプリの場合実行がしにくい
- 画面設計、ビジュアル、アニメーションを動作モックにして仮説検証を繰り返す。
- 出来上がりのイメージがしやすいため早い段階で確認出来る事が多い
動作モック
- ページベース（ページが切り替わる）
- Finto/InVision/Prottなど
- 少ない手間で実機で動かせる
- 画面の抜け希がないか確認出来る
- 複数パターンを作って確認
- レイヤーベース(各レイヤーごとに切り分けられる)
- Flinto for Mac
- 普通の画面性から凝ったインタラクションまで精度の高いものができる
- 実際のアプリに近い形で確認出来る
- Xcode Tweaks(ライブラリ)
- 値をアプリ上で変更できる
10. モバイルアプリ開発の”標準”を探る
発表者：藤 吾郎さん
新技術導入について、使う人は導入者だけ。なんか見たことあるような。
現在
開発における標準
- 標準的な開発＝効果とコストのバランスが良く納得感のある開発
新技術の導入
- 基本的に積極的に採用する方針
- それがどういう問題を解決するのかをきちんと明らかにすること
- 使う人は導入者だけと言うのは避ける
Swift
Kotolin
- Androidアプリ開発で注目されている
- しかし、これによって「何を解決するのか」が明らかでない
モバイルアプリの特徴
- 特徴
- CI:Jenkins(multi slaves)
- Pull-Reauest Builer(Jenkinsのプラグイン)
- 静的解析結果をPRの該当箇所にメッセージポストしてくれる
- Unit Test
- テストエンジニア二人体制(コード書ける)
- テストコードはプラットフォームごとの標準テストフレームワークを使っている
- Failure Teaches Success：障害レポートのフォーマット
- 問題をあれば根本的に解決
- なぜこの問題が起きたのかを分析して技術的な解決策に落とし込む
- 開発における標準を作る過程でもある
11. DWH（Data WereHouse）に必要な事(1人で始めるCIO)
発表者：青木 峰郎さん
本当にわかりやすいプレゼンでした。DWHについて考え方が変わりました！
データ活用基盤(大量のデータを最高に活用したい)
- ターゲティング広告
- ユーザ行動の分析
- ユーザコンタクトの一元管理 -> DWH (Data Warehouse)が鍵となる！
DWHとは綺麗なデータベースである
- 90年代に提唱されたデータ分析アーキテクチャ
- 大量のデータを集めて部署横断で分析
- DWHでない＝普通のDBは汚い！
DWHをどう作るか
- がんばる
- 基本方針（3つ）
12. 継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について
発表者：成田 一生さん
仕様の整理とリファクタリングは同時にやらない方がいい！笑
- 大前提
- 事業は変化する
- 組織は変化する
- プロダクトやコードには寿命がある
- 開発リソースは有限である
- 歴史
クックパッドは世界一のRails使用
- 不名誉らしい?
- なぜRailsに書き直したかったか
- サービスの継続的な改善がしたかった
- リニューアル失敗が Chanko を生み出した
- コードがでかいと何が起こるのか
- 起動に時間かかる
- テストに時間かかる
- 静的解析系ツールが動かない
- ライブラリが動かない
- デプロイ大変
- レールに乗れない
コード品質はビジネスに影響するのか？
- 影響する
- 可読性、メンテナンス性、コードの寿命にも影響する、品質が高いと長持ちする
- どこまでやるべきか？
- やりすぎない、綺麗なコードを書くこと自体が目的ではない、事業のフェーズに合った品質、コードレビューがそのへんを担保する
- コードレビュー
- コード規約を作る（Githubに記入）
- 最初は反対意見もあったが、不毛な議論を防げた
インフラお老朽化
- 2011 DC -> AWS
2012 EC2 Classic -> VPC
長生きする事業のために技術ができること
- 品質や新しさを保つこと自体を仕組み化する
- 手遅れになる前に少しずつやる
- 細かく成功体験を作り、アップデートの価値を組織に実感させる
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
興味深い内容が盛りだくさんでした。
スピーカーの方たちのプレゼンが上手くて聴き入ってしまいました。
ありがとうございました。
