今日はクックパッドさん主催の Cookpad TechConf に参加してきました。
250人の枠に1000人以上が応募するという人気ぶりでした。当選してよかった！
会場は恵比寿ガーデンルーム。早く着きすぎたこともあり、会場はまだ準備中でした。
5時間というボリュームたっぷりの内容でしたが、どの発表も非常に内容が濃く、あっという間に時間が過ぎてしまいました。
以下は個人用のメモになります。（読みにくい点はご容赦ください）
目次
- 目次
- ユーザーのために、技術をどう活かすか
- おでかけスポット検索のむずかしさ - Holiday を支える検索技術
- Railsアプリ開発環境の高速化
- R&D at Foodtech company
- 技術力を事業の強みするために必要なこと
- 開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法
- 「今日なに作ろう？」を支えるデザイン
- 確かめながら作るユーザー体験
- モバイルアプリのインタラクションプロトタイピング
- モバイルアプリ開発の"標準"を探る
- DWHに必要なこと
- クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について
ユーザーのために、技術をどう活かすか
舘野 祐一さんによる基調講演。クックパッドのエンジニア文化がよく分かる素晴らしい内容でした。
- 社員は250人
- エンジニア70人？（メモできず）
- デザイナー15人
- 月間5500万人のユーザ！
- ユーザファースト顧客第一主義
- ユーザファーストのための技術
- ユーザファーストのための組織
- 組織の形
- 集約型（エンジニアが集中）
- 分散型（様々な部署にエンジニアがいる）
- 現在のクックパッドは両方を取り入れている
- これが正解、というわけではなく、その時に合った形を取り入れていく
- 対面・非対面
- 一人一人の成長
- 開発を通して
- GHEを通したコードレビュー
- 「デキる人」からのフィードバック
- なぜ？がすっきり理解
- 自発的な組織改善
- Cookpad Lounge というイベント
- エンジニア発のイベント
- 今の会社に足りないのはなんだろう？といったことをキッチンで飲みながら話す
- エンジニアが主体的に組織改善に関わることを評価する
- 行動評価
- 社内外に影響を与えているか
- 「当たり前」のことを「当たり前」にでき続けることが大切
- 組織の形
おでかけスポット検索のむずかしさ - Holiday を支える検索技術
内藤 雄介さんによる発表。中目黒が中目黒にない問題はとても印象に残りました。
- Holiday
- いつもの休日のお出かけを楽しくすることで人生を豊かにするサービス
- 検索を文字列での全文検索でやってたけどうまくいかなかった
Railsアプリ開発環境の高速化
国分 崇志さんによる発表。発表自体も高速化されていていました！ :running:
- クックパッドの快適な開発環境
- 機能開発
- 高速なプロトタイピング Chanko
- 本番からレプリされる開発用DB
- テスト実行
- 分散RSpec実行 RRRSpec
- デプロイ
- 高速なデプロイツール Mamiya
- 機能開発
- なぜ高速化が必要か？
- ユーザに価値を早く提供するため
- 高速化を競うコンテストをしているわけではない
- 何をしたか
R&D at Foodtech company
有賀 康顕さんによる発表。クックパッドの研究開発内容について。
- なぜ研究開発か
- 食の分野の技術をリードし続けたい！
- 食に関する多くのデータが集まる
- クックパッドの研究開発
- 学術研究を支援する
- 「たべみる」の学術提供開始
- サービス活用事例
- 固有表現抽出を用いた商品名検索
- レシピの副菜提供
- レシピのカテゴリ分類による絞り込み検索
技術力を事業の強みするために必要なこと
大野 晋一さんによる発表。iPhoneでスライドを操作していたのが印象的でした。
- 事業と計画
- とにかくシンプルにする
- 営業力で何とかする組織にしない
- 技術力で価値を作る
- 責任範囲とリーダーシップ
- 議論や調整じゃなくて決定とテスト
- 誰が、を決める
- 責任レベル
- リーダー：成果を定義する
- アーキテクト：仕事を定義する
- エグゼクター：仕事を遂行する
- 行動とフィードバック
- 分担することでお互いを評価・牽制できる
開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法
五十嵐 啓人さんによる発表。何かひらめくことをクックパッドさんでは「温泉が湧く」と言うらしいです。これは積極的に使っていきたいと思いました！
- ディレクターだけどコード書かないとこの会社は生きてけない
- 検索のミッション
- 料理領域で世界で最高の料理検索エンジンをつくる
- クックパッドには技術がたくさんある
- 技術から製品をつくると失敗しがち
- 検索チームのプロダクト開発手法
- まず技術のことは一旦忘れる
- ユーザーの悩み、欲求にフォーカスする
- 「ないと死ぬ！」「ないと困る！」にフォーカスして悲しみの原因となる欲求を掘り下げていく
- 欲求から生まれた解決策に技術が使えそうであればその技術を使う
- 技術→製品→価値 ではなく 技術←製品←価値
- ひとりではなく、複数人で議論し、幅を広げるとともに経験を共有する
「今日なに作ろう？」を支えるデザイン
木村 真理さんによる発表。クックパッドではデザインについても GitHub の Issue でレビューする、というのがとても驚きでした。
- ユーザーファースト推進室の役割
- ユーザファーストなサービスとは
- ユーザが期待した通りの動きをする
- ユーザがついつい夢中になってしまう
- ストーリーで考える
- 機能にフォーカスすると目的を失いがち
- ユーザを常に主語にして考える
- クックパッドの開発
確かめながら作るユーザー体験
出口 貴也さんによる発表。新卒入社されてから3年目と聞いて驚きました。年次関係なく、大きなプロダクトを任される文化がクックパッドにはあるんだなぁ、と感じました。
- サービス開発はめっちゃむずかしい
- 決める段階での難しさ
- 誰も答えを知らない
- つくり上げる段階での難しさ
- 決めたことからブレること
- Cookpadの考え方
- 確かめるために定義する
- ユーザにどのような体験を提供するか
- 最初の仮説は思い込みの塊
- レビューを通して仮説の精度を上げる
モバイルアプリのインタラクションプロトタイピング
多田 圭佑さんによる発表。Flinto for Mac、すごく良さそうでした。
- 価値のあるプロダクトをつくるために
- 速さ
- すばやく発見する
- ユーザの変化に適応する
- 品質
- 価値を正しく届ける
- 価値を高める
- 速さ
- 画面設計→ビジュアル→アニメーション→実装
- 実装してみたらコレジャナイ感
- できあがりのイメージがしづらいため、それぞれの工程で問題に気づきにくい
- これを解決するためにプロトタイピングを使う
- どうやるのか
モバイルアプリ開発の"標準"を探る
藤 吾郎さんによる発表。gfxさんです！新しい技術に対する考え方がとても心に刺さりました。
- 開発における標準とは？
- 効果とコストのバランスがよく納得感のある開発
- 調べてもわからない秘伝のタレが多く、理不尽に感じる開発、は標準的ではない
- 枯れた技術のこととは限らない
- 環境の変化に付いていくことも大事
- 新しい技術を導入する
- 基本的に積極的に導入する
- それがどういう問題を解決するのかをきちんと明らかにすること
- 使う人は導入者だけ、と言うのは避ける
- Swift
- 言語仕様がまだ安定してないので、基本的には使わない方針
- ただし、新規ではSwiftを使ったアプリもある
- Appleによって未来が約束されている
- Kotolin
- モバイルアプリの特徴
- ユーザーが使うバージョンを制御できない
- アップデートしてくれるとは限らない
- 強制アップデートはしない方針
- 実行環境を制御することもできない
- 端末のスペック、OS、通信環境はまちまち
- ユーザーが使うバージョンを制御できない
- CI: Jenkins
- Pull-Request Builder (+dokumi) が行うこと
- 静的解析結果をPRの該当箇所にメッセージポストしてくれる
- Unit Test
- テストエンジニア二人体制
- 二人共コード書ける
- FTS (Failure Teaches Success)
- 思考のフレームワーク
- なぜこの問題が起きたのか
DWHに必要なこと
青木 峰郎さんによる発表。スライドの文字が少ないのにわかりやすい、という理想的なプレゼンでした。自分もあんな風に落ち着いてプレゼンできるようになりたい。
- 大量のデータを最高に活用したい
- ターゲティング広告
- ユーザ行動の分析
- ユーザコンタクトの一元管理
- DWH (Data Warehouse)が鍵となる！
- DWHとは
- 90年代に提唱されたデータ分析アーキテクチャ
- 大量のデータを集めて部署横断で分析
- DWHでない普通のｄｂは汚い！
- DWHをどうつくるか
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について
成田 一生（mirakui）さんによる基調講演。個人的には「コード品質はビジネスに影響するのか？」の話がとても刺さりました。寿命の長いコードを書いていきたいものです。
- 大前提
- 事業は変化する
- 組織は変化する
- プロダクトやコードには寿命がある
- 開発リソースは有限である
- クックパッドの歴史
- 最初は kitchen@coin というサービスだった
- 1998年にCookPadへ
- コードがでかいと何が起こるか
- 起動に時間かかる
- テストに時間かかる
- 静的解析系ツールが動かない
- ライブラリが動かない
- デプロイ大変
- レールに乗れない
- リニューアル大作戦
- いちから作りなおそうとしたが大失敗
- 仕様の整理とリニューアルを一緒にやろうとしたのが原因
- 2007年のRails移行はなぜうまくいったのか？
- サービスの機能が少なかった
- すでにぼろぼろだったから
- そもそもそんなに成功してなかった疑惑
- 若かった
- なぜ書き直したかったのか
- サービスの継続的な改善がしたかった
- リニューアル失敗が Chanko を生み出した
- コード品質はビジネスに影響するのか？
- yes
- 可読性
- メンテナンス性
- コードの寿命にも影響する
- 品質が高いと長持ちする
- どこまでやるべきか？
- やりすぎない
- 綺麗なコードを書くこと自体が目的ではない
- 事業のフェーズに合った品質
- コードレビューがそのへんを担保する
- コードレビュー
- コーディング規約を作っておくべき
- 最初は反対も合った
- 不毛な議論になるのを防げた
- 治安が良くなった
- yes
- インフラの老朽化
- 二度の全台作り直しを経て
- 役割の分からない謎のサーバが淘汰された
- 全サーバが Infra as Code 化された
- どさくさで OS や各種パッケージがアップデート出来た
- 式年遷宮すごいよ
- 20年ごとに重要な部分を作りなおす
- 1300年存在している
- 7世紀の弥生建築の技術が現役で伝承されている
- 二度の全台作り直しを経て
- 長生きする事業のために技術ができること
- 品質や新しさを保つこと自体を仕組み化する
- 手遅れになる前に少しずつやる
- 細かく成功体験を作り、アップデートの価値を組織に実感させる
運営関係者の皆さま、お疲れ様でした！😄
