読者です 読者をやめる 読者になる 読者になる

koogawa log

iOS、Android、foursquareに関する話題

Cookpad TechConf に行ってきたよ #CookpadTechConf

勉強会

f:id:koogawa:20160123204850j:plain

今日はクックパッドさん主催の Cookpad TechConf に参加してきました。

techconf.cookpad.com

250人の枠に1000人以上が応募するという人気ぶりでした。当選してよかった!

会場は恵比寿ガーデンルーム。早く着きすぎたこともあり、会場はまだ準備中でした。

f:id:koogawa:20160123205001j:plain

5時間というボリュームたっぷりの内容でしたが、どの発表も非常に内容が濃く、あっという間に時間が過ぎてしまいました。

以下は個人用のメモになります。(読みにくい点はご容赦ください)


目次

ユーザーのために、技術をどう活かすか

舘野 祐一さんによる基調講演。クックパッドのエンジニア文化がよく分かる素晴らしい内容でした。

2.jpg

  • 社員は250人
    • エンジニア70人?(メモできず)
    • デザイナー15人
  • 月間5500万人のユーザ!
  • ユーザファースト顧客第一主義
  • ユーザファーストのための技術
    • エンジニアに求められている技術が増えている
      • iOSAndroid、フロントエンドエンジニア…
      • インフラ…
      • ユーザ体験…
    • そのなかでクックパッドに必要な技術とは何なのか?
    • 仮説→実行→検証 を素早くぐるぐる回す
    • 素早く何度も検証することで価値が何かを学習していく
    • 2万以上のテストに1時間かかっていたが、RRRSpecで7分に短縮!
    • 変化を受け入れること(難しいけど)
    • 自分が得意な技術セットを捨てて変化できる開発者が大事
  • ユーザファーストのための組織
    • 組織の形
      • 集約型(エンジニアが集中)
      • 分散型(様々な部署にエンジニアがいる)
      • 現在のクックパッドは両方を取り入れている
      • これが正解、というわけではなく、その時に合った形を取り入れていく
    • 対面・非対面
      • 対面での共有
        • リアルタイムで共有したほうが良い内容
        • リーダ会議など
      • 非対面での共有
    • 一人一人の成長
      • 開発を通して
      • GHEを通したコードレビュー
      • 「デキる人」からのフィードバック
        • なぜ?がすっきり理解
    • 自発的な組織改善
      • Cookpad Lounge というイベント
      • エンジニア発のイベント
      • 今の会社に足りないのはなんだろう?といったことをキッチンで飲みながら話す
    • エンジニアが主体的に組織改善に関わることを評価する
        1. 行動評価
        1. 社内外に影響を与えているか
    • 「当たり前」のことを「当たり前」にでき続けることが大切

おでかけスポット検索のむずかしさ - Holiday を支える検索技術

内藤 雄介さんによる発表。中目黒が中目黒にない問題はとても印象に残りました。

3.jpg

  • Holiday
    • いつもの休日のお出かけを楽しくすることで人生を豊かにするサービス
  • 検索を文字列での全文検索でやってたけどうまくいかなかった
    • 中目黒、中目黒にない問題
    • 実際の中目黒はユーザが期待する中目黒ではなかった!
    • 単純に全文検索せずに、"中目黒 カフェ"=>カフェ AND ( 中目黒 or 位置情報)
    • Elasticsearch の Geo Polygon Filter を使った
    • 地名を判別するために形態素解析も強化

Railsアプリ開発環境の高速化

国分 崇志さんによる発表。発表自体も高速化されていていました! :running:

4.jpg

  • クックパッドの快適な開発環境
    • 機能開発
      • 高速なプロトタイピング Chanko
      • 本番からレプリされる開発用DB
    • テスト実行
      • 分散RSpec実行 RRRSpec
    • デプロイ
  • なぜ高速化が必要か?
    • ユーザに価値を早く提供するため
    • 高速化を競うコンテストをしているわけではない
  • 何をしたか

R&D at Foodtech company

有賀 康顕さんによる発表。クックパッドの研究開発内容について。

5.jpg

  • なぜ研究開発か
    • 食の分野の技術をリードし続けたい!
    • 食に関する多くのデータが集まる
  • クックパッドの研究開発
    • 食文化研究
      • 偏食
      • 個食(1人で食べる)
      • 伝統食の継承
        • 季節性・地域性のある伝統食を検索履歴を通じて定量的に明らかにする
    • ヘルスケア領域
      • 製薬会社とともにアプリを糖尿病学会に展示
    • クックパッド食みらい研究所
  • 学術研究を支援する
    • 「たべみる」の学術提供開始
  • サービス活用事例
    • 固有表現抽出を用いた商品名検索
    • レシピの副菜提供
    • レシピのカテゴリ分類による絞り込み検索

技術力を事業の強みするために必要なこと

大野 晋一さんによる発表。iPhoneでスライドを操作していたのが印象的でした。

6.jpg

  • 事業と計画
    • とにかくシンプルにする
    • 営業力で何とかする組織にしない
    • 技術力で価値を作る
  • 責任範囲とリーダーシップ
    • 議論や調整じゃなくて決定とテスト
    • 誰が、を決める
    • 責任レベル
      • リーダー:成果を定義する
      • アーキテクト:仕事を定義する
      • エグゼクター:仕事を遂行する
  • 行動とフィードバック
    • 分担することでお互いを評価・牽制できる

開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法

五十嵐 啓人さんによる発表。何かひらめくことをクックパッドさんでは「温泉が湧く」と言うらしいです。これは積極的に使っていきたいと思いました!

7.jpg

  • ディレクターだけどコード書かないとこの会社は生きてけない
  • 検索のミッション
  • クックパッドには技術がたくさんある
    • 技術から製品をつくると失敗しがち
  • 検索チームのプロダクト開発手法
    • まず技術のことは一旦忘れる
    • ユーザーの悩み、欲求にフォーカスする
    • 「ないと死ぬ!」「ないと困る!」にフォーカスして悲しみの原因となる欲求を掘り下げていく
    • 欲求から生まれた解決策に技術が使えそうであればその技術を使う
    • 技術→製品→価値 ではなく 技術←製品←価値
  • ひとりではなく、複数人で議論し、幅を広げるとともに経験を共有する

「今日なに作ろう?」を支えるデザイン

木村 真理さんによる発表。クックパッドではデザインについても GitHub の Issue でレビューする、というのがとても驚きでした。

8.jpg

  • ユーザーファースト推進室の役割
    • クックパッドのファンユーザを増やす
    • クックパッド全体のサービスを、横断的・俯瞰的に捉える
    • ユーザーファーストを加速させる
  • ユーザファーストなサービスとは
    • ユーザが期待した通りの動きをする
    • ユーザがついつい夢中になってしまう
  • ストーリーで考える
    • 機能にフォーカスすると目的を失いがち
    • ユーザを常に主語にして考える
  • クックパッドの開発
    • プロトタイピングの目的
    • プロトタイピングの利点
      • 実装後の手戻りがない
    • デザインフレームワーク
      • 見出し、リスト
      • 変数名でカラーマネージング
    • デザインレビュー
      • GitHubにIssueを立てて他のデザイナー・開発者がレビュー

確かめながら作るユーザー体験

出口 貴也さんによる発表。新卒入社されてから3年目と聞いて驚きました。年次関係なく、大きなプロダクトを任される文化がクックパッドにはあるんだなぁ、と感じました。

9.jpg

  • サービス開発はめっちゃむずかしい
  • 決める段階での難しさ
    • 誰も答えを知らない
  • つくり上げる段階での難しさ
    • 決めたことからブレること
  • Cookpadの考え方
    • 確かめながらサービスを作る
    • そのために目指すユーザ体験を定義する
    • 機能の要件定義をするのではなく、ユーザーにどのような体験を提供するのかを定義する
    • Cookpad内にはそのためのフレームワーク複数ある
  • 確かめるために定義する
    • ユーザにどのような体験を提供するか
    • 最初の仮説は思い込みの塊
    • レビューを通して仮説の精度を上げる

モバイルアプリのインタラクションプロトタイピング

多田 圭佑さんによる発表。Flinto for Mac、すごく良さそうでした。

10.jpg

  • 価値のあるプロダクトをつくるために
    • 速さ
      • すばやく発見する
      • ユーザの変化に適応する
    • 品質
      • 価値を正しく届ける
      • 価値を高める
  • 画面設計→ビジュアル→アニメーション→実装
    • 実装してみたらコレジャナイ感
    • できあがりのイメージがしづらいため、それぞれの工程で問題に気づきにくい
    • これを解決するためにプロトタイピングを使う
  • どうやるのか
    • Flinto / Invision / Protto
    • HTML + CSS + JS
      • インタラクションの表現の自由度が高い
      • インタラクションの精度を高めるのは大変
    • Flinto for Mac
      • とてもパワフル
      • 精度の高いプロトタイプを素早く作ることができる
      • 表現できないインタラクションもある
    • Xcode
      • なんでもできる
      • 手間がかかる
      • Tweaks
        • アニメーション変数、文字サイズなどの値をアプリ上で変更できる
        • 外で使っている時などにUIを調整できる

モバイルアプリ開発の"標準"を探る

藤 吾郎さんによる発表。gfxさんです!新しい技術に対する考え方がとても心に刺さりました。

11.jpg

  • 開発における標準とは?
    • 効果とコストのバランスがよく納得感のある開発
    • 調べてもわからない秘伝のタレが多く、理不尽に感じる開発、は標準的ではない
    • 枯れた技術のこととは限らない
    • 環境の変化に付いていくことも大事
  • 新しい技術を導入する
    • 基本的に積極的に導入する
    • それがどういう問題を解決するのかをきちんと明らかにすること
    • 使う人は導入者だけ、と言うのは避ける
  • Swift
    • 言語仕様がまだ安定してないので、基本的には使わない方針
    • ただし、新規ではSwiftを使ったアプリもある
    • Appleによって未来が約束されている
  • Kotolin
    • Androidアプリ開発で注目されている
    • しかし、これによって「何を解決するのか」が明らかでない
  • モバイルアプリの特徴
    • ユーザーが使うバージョンを制御できない
      • アップデートしてくれるとは限らない
      • 強制アップデートはしない方針
    • 実行環境を制御することもできない
      • 端末のスペック、OS、通信環境はまちまち
  • CI: Jenkins
  • Pull-Request Builder (+dokumi) が行うこと
    • 静的解析結果をPRの該当箇所にメッセージポストしてくれる
  • Unit Test
    • テストエンジニア二人体制
    • 二人共コード書ける
  • FTS (Failure Teaches Success)

DWHに必要なこと

青木 峰郎さんによる発表。スライドの文字が少ないのにわかりやすい、という理想的なプレゼンでした。自分もあんな風に落ち着いてプレゼンできるようになりたい。

12.jpg

  • 大量のデータを最高に活用したい
    • ターゲティング広告
    • ユーザ行動の分析
    • ユーザコンタクトの一元管理
  • DWH (Data Warehouse)が鍵となる!
  • DWHとは
    • 90年代に提唱されたデータ分析アーキテクチャ
    • 大量のデータを集めて部署横断で分析
    • DWHでない普通のdbは汚い!
  • DWHをどうつくるか
    • がんばる
    • 基本指針1
      • データは一箇所に集める
      • RedShift使った
        • 速い!
        • 安い!
        • 普通のSQL使える
      • データを集めただけで DWH か?
        • データは加工しないと DWH にならない
    • 基本指針2
      • データを3層に整理する
    • 基本指針3
      • SQLですべての処理を行う

クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について

成田 一生(mirakui)さんによる基調講演。個人的には「コード品質はビジネスに影響するのか?」の話がとても刺さりました。寿命の長いコードを書いていきたいものです。

13.jpg

  • 大前提
    • 事業は変化する
    • 組織は変化する
    • プロダクトやコードには寿命がある
    • 開発リソースは有限である
  • クックパッドの歴史
    • 最初は kitchen@coin というサービスだった
    • 1998年にCookPad
  • コードがでかいと何が起こるか
    • 起動に時間かかる
    • テストに時間かかる
    • 静的解析系ツールが動かない
    • ライブラリが動かない
    • デプロイ大変
    • レールに乗れない
  • リニューアル大作戦
    • いちから作りなおそうとしたが大失敗
    • 仕様の整理とリニューアルを一緒にやろうとしたのが原因
  • 2007年のRails移行はなぜうまくいったのか?
    • サービスの機能が少なかった
    • すでにぼろぼろだったから
    • そもそもそんなに成功してなかった疑惑
    • 若かった
  • なぜ書き直したかったのか
    • サービスの継続的な改善がしたかった
    • リニューアル失敗が Chanko を生み出した
  • コード品質はビジネスに影響するのか?
    • yes
      • 可読性
      • メンテナンス性
      • コードの寿命にも影響する
      • 品質が高いと長持ちする
    • どこまでやるべきか?
      • やりすぎない
      • 綺麗なコードを書くこと自体が目的ではない
      • 事業のフェーズに合った品質
      • コードレビューがそのへんを担保する
    • コードレビュー
      • コーディング規約を作っておくべき
      • 最初は反対も合った
      • 不毛な議論になるのを防げた
      • 治安が良くなった
  • インフラの老朽化
    • 二度の全台作り直しを経て
      • 役割の分からない謎のサーバが淘汰された
      • 全サーバが Infra as Code 化された
      • どさくさで OS や各種パッケージがアップデート出来た
    • 式年遷宮すごいよ
      • 20年ごとに重要な部分を作りなおす
      • 1300年存在している
      • 7世紀の弥生建築の技術が現役で伝承されている
  • 長生きする事業のために技術ができること
    • 品質や新しさを保つこと自体を仕組み化する
    • 手遅れになる前に少しずつやる
    • 細かく成功体験を作り、アップデートの価値を組織に実感させる

運営関係者の皆さま、お疲れ様でした!😄