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

Cookpad TechConf2016 参加レポート

Cookpad TechConfに参加してきました〜! 忘れないうちにレポート書きます!!

techconf.cookpad.com

1. 基調講演: ユーザーのために、技術をどう活かすか

発表者:舘野 祐一さん
ユーザファーストの考えが全てのスピーカーさん達に浸透していて素晴らしかったです。

まずは会社紹介

  • 社員約250人(エンジニア:80人、デザイナー15人)
  • 月間5500万人のユーザー
  • レシピだけでなく海外進出や他サービスもやってる

ユーザファーストのための技術

  • エンジニアに全てが求められる現在
    • フルスタックエンジニア
    • 他にも高レベルな技術
    • その中で今必要な技術は何なのか?
  • モバイルアプリに適した開発を考えて起用していく、変化を受け入れその時にあった技術開発を行うべき
    • マイクロサービスの適用
    • 必要な技術が自ずと選定できる

高速にサイクルをまわすことが大切

  • 仮説->実行->検証を素早く回す
    • 仮説:Chanko:高速にプロトタイピングを実現
    • 実行:テスト高速:RRRSpecで分散並列環境でテスト高速化1H→7分(2万以上のテスト)
    • 検証:Hakari一行コードを挿入するだけでメトリクスが図れる計測ツール
    • 素早く何度も検証することで価値が何かを学習する
    • 当たり前のことを当たり前にでき続けることが大切

ユーザファーストのための組織

  • 組織体制
    • 集約型:エンジニアだけの部署
    • 分散型:様々な部署にエンジニアがいる
  • クックパッドは横縦の両方が組み合った組織体制である
  • 正解はなく、その時にあった体制を取り入れるのが大事

情報共有

  • 対面と非対面
    • 対面での共有: プロダクト編成会、技術リーダー会、デザイナー会など
    • 非対面での共有 : Github,GithubEnterprise,Groupad(Blig+Wiki)社内ツール

Groupad(Blig+Wiki)とは

  • いろいろな技術やエンジニア以外のことを記事に書き、共有している。チームごとにやっていることがわかるし、社内のコミュニケーションも強化できる。
  • いろいろな部署があるからこお情報共有は大事
  • どんな人にどんなメッセージを伝えるのか、どういう風に伝えるか考えることは大事
  • クックパッド開発者ブログも行っている

一人一人の成長

  • 設計・実装・フィードバックのサイクル
    • GHEをと通したコードレビュー
    • 設計・サービスについての議論
    • できる人からのフィードバッグ
      • 詳しい人が一人いると、すごい速度で伝搬していく
      • なぜ?がすっきりと理解
  • レシピ以外のサービスも展開
    • 様々な視点を得る
    • 他の組織、開発を経験する
    • 知らない視点のインプット
  • 自発的な組織改善
    • Cookpad Loungeというイベントを実施
      • どういう風に組織全体を良くなるかを自発的に考える
      • エンジニアも主体的に組織改善に関わるを評価する
        • 行動評価
        • 社内外に影響を与えているか

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

発表者:内藤 雄介さん
中目黒は中目黒ではなかったのですね…。

www.slideshare.net

Holiday お出かけ情報共有雨サービス

  • Holidayでの検索
    • 全文検索ではうまくいかなかった
    • 中目黒は地理的に中目黒ではなかった・・・。
    • ユーザが考えることシステム的な正解は異なる
  • 全文検索*地理検索
    • 「どこで」を探すには全文検索では不十分
    • Elasticsearch1.7で地理実現
      • Geo Distance Filter:駅周辺のスポットで探す
      • Geo Polygon Filter:範囲内に入っているかどうか
      • Geo Bounding Box Filter:正確性は低いか高速
  • 地名を判別するために
    • 形態素分析 mecab-ipadic-NEologdの導入
    • Neologd:週に2回ウェブから情報とりアップデートしているらしい、現在は自動ではない。

3. Railsアプリの高速化

発表者:国分 崇志さん
発表も表題通り高速化されていました。速い(><)笑

speakerdeck.com

クックパッドの快適な機能開発

  • 機能開発
    • 高速なプロトタイピング:Chanko
    • 本番からレプリされる開発用DB
  • テスト実行
    • 分散RSpec実行 RRRSpec
  • デプロイ
  • クックパッドは機能開発の仕組みは整っていてテストもデプロイも高速で開発しやすいが、開発環境が遅い。
    • 何か変更してリロードするのに謎に16.2S待たされる
    • アセットコンパイルに23分56秒かかる
      • CIが遅くなる
      • ステージング環境へのデプロイが遅くなる

Railsの高速化

  1. MySQL: INSERT,DELETE,UPDATEが走ったらJOINも考慮してキャッシュクリアなど
  2. Solr: SunspotによるSolrへのクエリの結果をキャッシュなど
  3. GC: リクエスト処理中にGCがあまり走らないようになど
  4. Asset: アセットのリクエストをブラウザでキャッシュ、sprokets-railsデバッグ機能を切る

アセットプリコンパイル(高速化のために何をしたか)

4. R$D at Fooddtech company

発表者:有賀 康顕さん
最近ブームな機械学習のワードが出てきました。

www.slideshare.net

研究開発

  • 食文化領域 食の問題(偏食、個食、伝統食の継承)
    • 季節性、地域性を検索履歴を通じて定量的に明らかにする
  • ヘルスケア領域
    • ごはんカメラ:糖尿病患者の食事記録

学術研究を支援する

  • 国立情報学研究所にデータを提供
    • 55大学81研究室で使われている
    • データ提供することで、データハッカソンの開催が出来る
    • たべみるの学術提供開始(検索履歴を可視化したサービス)

非専門家でも機械学習を使った開発ができる

  • レシピの自動分類による自動検索

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

発表者:大野 晋一さん
チーム体制のあり方について勉強になりました。

www.slideshare.net

事業と計画

  • とにかくシンプルにする
  • 事業の成果を何で説明できるか?(売り上げ?PV?)
  • 人流の数字で表せる、分解できる(100億円=クリック単価100円*、、、)
  • 分散することで今何をすれば良いのかがわかる(フォーカスする分野がわかる)

責任範囲とリーダシップ

  • 議論や調整じゃなくて決定とテスト
  • 誰がコミットするか、どこでを決める

行動

  • 集中する領域に加えて行動を定義
  • 評価をしやすくする(定義があることでできる)

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

発表者:五十嵐 啓人さん
「ユーザーの欲求は希望ではなく、悲しみの原因となることを集める」がごもっともでした。

技術開発+ユーザーが実感できる新しい価値創出

  • 技術から思いついたサービスはOUT
  • ユーザーの欲求から解決策を考える(どの技術が使えるか)
  • 価値->製品->技術の順番で行う

ユーザーの欲求を集める(特に悲しみや失望などのマイナスな点を集める、ないと死ぬ、困る!)

  • あったらいいなを防ぐ(希望)
  • 有望な案をブレイクダウン
  • 解決策は機能ではなく状態で考える
  • 製品化へ(どんどんプロトタイプを作って進める、とにかく仮説を形にしていく)

ユーザー欲求について意見を出し合うMTGを設ける

  • 複数人で議論し、幅を広げる、経験を共有する
  • 様々な意見から決まらなくなってしまわないために、決定者を設定する

7.『今日何作ろう』を支えるデザイン

発表者:木村真理さん
ツールを駆使した最適な方法、参考にしたいです。

www.slideshare.net

ユーザーファースト推進部

  • クックパッド全体のサービスを横断的・俯瞰的に見る
  • ファンを増やす、新規開発改善などをやっている
  • ユーザーファーストなサービスとは
    • ユーザが期待した通りの動きをする
    • ユーザがついつい夢中になる
    • 人にオススメしたくなる
  • 機能ではなく、ストーリーで考える
    • 機能にフォーカスすると目的を失いがち
    • ユーザのどんな問題を解決できるのか
    • ユーザーを主語にする

プロトタイピング

  • 目的:仮説検証、アイデア共有、小さく素早く試せる
  • 種類:ペーパープロト、デザインプロト、アニメーションプロと、動画モック
  • 利点:実装後の手戻りが少ない

デザインフレームワーク

  • Sara デザインフレームワーク
  • iOS UI
  • アイコンフォント 画像リソースを書く必要ない
  • オリジナル数字フォント
  • 変数でカラーマネージング

デザインレビュー

  • Github Issue
    • 他のデザイナー・開発者がレビュー
    • デザイン変更の経緯が誰でも参照できる、議論による新たな気づきもできる

デザインリリースマネージャー

  • リリース前にメンバー全員で実機(複数)で確認を行う

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

発表者:井口貴也さん
サービス開発の難しさに立ち向かう3つのことを教えてくれました!

speakerdeck.com

サービス開発は難しい

  • 決める段階での難しさ:誰も答えを知らないこと
  • 作り上げる段階での難しさ:決めたことが途中でブレること

* この2つをどう対処するのか * 確かめながらサービスを作る * 事前に目指すユーザー体験を定義する

cookpadの実践

  • どのような体験を提供するかを定義する
  • 作る前に確かめる
    • 仮説の質を高める
    • 方法:デザインレビュー、ユーザーインタビュー、紙とペン、プロトタイピング
  • 作った後に確かめる
    • 点の体験でなく、線で検証することも重要
    • 体験を定性的に確かめる (ドッグフーディング、ご意見ボックス、アンケート、ユーザテスト)
    • ストーリーの達成度を定量化する(ファネル分析) -> 定量、定性の検証手法を駆使する!

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

発表者:多田圭佑さん
Prott!!時々使ってます。

www.slideshare.net

価値のあるプロダクトを作るために速さと品質が必要

  • 価値のあるプロダクトを作るために
  • 速さ(価値を発見、ユーザーの変化に適応)
  • 品質(価値を正しく届ける、価値を高める)

仮説、実行、検証を細かく何回も回す

  • しかし、モバイルアプリの場合実行がしにくい
  • 画面設計、ビジュアル、アニメーションを動作モックにして仮説検証を繰り返す。
    • 出来上がりのイメージがしやすいため早い段階で確認出来る事が多い

動作モック

  • ページベース(ページが切り替わる)
    • Finto/InVision/Prottなど
    • 少ない手間で実機で動かせる
    • 画面の抜け希がないか確認出来る
    • 複数パターンを作って確認
  • レイヤーベース(各レイヤーごとに切り分けられる)
    • Pixate,HTML+CSS+JS,Framer,Xcodeなど
      • 実際のコンテンツを複数パターン作れる
      • 自由度が高い(インタラクションの表現)
  • Flinto for Mac
    • 普通の画面性から凝ったインタラクションまで精度の高いものができる
    • 実際のアプリに近い形で確認出来る
  • Xcode Tweaks(ライブラリ)
    • 値をアプリ上で変更できる

10. モバイルアプリ開発の”標準”を探る

発表者:藤 吾郎さん
新技術導入について、使う人は導入者だけ。なんか見たことあるような。

speakerdeck.com

現在

  • スホマ、タブレットなどのモバイルからのアクセスが過半数を超えている
  • ゲストユーザのうちスマホは7割
  • アカウント持ちユーザーはアプリが6割
  • ゲストはアプリ1割

開発における標準

  • 標準的な開発=効果とコストのバランスが良く納得感のある開発

新技術の導入

  • 基本的に積極的に採用する方針
  • それがどういう問題を解決するのかをきちんと明らかにすること
  • 使う人は導入者だけと言うのは避ける

Swift

  • 言語仕様がまだ安定してないので、基本的には使わない方針(ただし、新規ではSwiftを使ったアプリもある)
  • Appleによって未来が約束されている

Kotolin

  • Androidアプリ開発で注目されている
  • しかし、これによって「何を解決するのか」が明らかでない

モバイルアプリの特徴

  • 特徴
    • ユーザーのバージョンを制御できない
    • Androidは新しいパーミッションを追加すると顕著にアップデート率が下がる
    • 実行環境を制御することができない
    • ウェブアプリよりも失敗が重くテストが難しい
    • コードレビュー、CI,QAなどの品質管理が重要
  • 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つ)
    • その1:データは一箇所に集める
      • Redshift(AWSが提供するRDBMS)
      • 早い、安い、SQL
    • その2:データを3層で整理する
      • データは加工しないと何も使えない
    • その3.:SQLで全ての処理を行う
      • 加工は全てSQL
      • ウェブとDWHでは同じSQLでも使い方が違う

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

発表者:成田 一生さん
仕様の整理とリファクタリングは同時にやらない方がいい!笑

speakerdeck.com

  • 大前提
    • 事業は変化する
    • 組織は変化する
    • プロダクトやコードには寿命がある
    • 開発リソースは有限である
  • 歴史
    • 1998.3 kitchen@coinを開始
    • 2007 coldFusion -> Railsに以降
    • 2009.11 クックパッドを開始(iOS)
    • 2010.1 クックパッドを開始(android

クックパッドは世界一のRails使用

  • 不名誉らしい?
  • なぜRailsに書き直したかったか
    • サービスの継続的な改善がしたかった
    • リニューアル失敗が Chanko を生み出した
  • コードがでかいと何が起こるのか
    • 起動に時間かかる
    • テストに時間かかる
    • 静的解析系ツールが動かない
    • ライブラリが動かない
    • デプロイ大変
    • レールに乗れない

コード品質はビジネスに影響するのか?

  • 影響する
    • 可読性、メンテナンス性、コードの寿命にも影響する、品質が高いと長持ちする
  • どこまでやるべきか?
    • やりすぎない、綺麗なコードを書くこと自体が目的ではない、事業のフェーズに合った品質、コードレビューがそのへんを担保する
  • コードレビュー
    • コード規約を作る(Githubに記入)
    • 最初は反対意見もあったが、不毛な議論を防げた

インフラお老朽化

  • 2011 DC -> AWS
  • 2012 EC2 Classic -> VPC

  • 長生きする事業のために技術ができること

    • 品質や新しさを保つこと自体を仕組み化する
    • 手遅れになる前に少しずつやる
    • 細かく成功体験を作り、アップデートの価値を組織に実感させる

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
興味深い内容が盛りだくさんでした。
スピーカーの方たちのプレゼンが上手くて聴き入ってしまいました。
ありがとうございました。