dshimizu/blog

アルファ版

Cookpad TechConf 2018に行ってきた

other Tech イベント

Cookpad TechConf 2018 に行ってきた。

2016年からやっているそうで、僕は今年初めて参加した。 場所は恵比寿ガーデンプレイス ザ・ガーデンホールというところで、参加人数は600人くらいいた模様。

まずいきなり驚いたのは司会進行がAmazon pollyだったこと。 しゃべり方は「もやもやさまぁ～ず」のナレーションのような感じで、特におかしなところはなく司会進行を行っていた。それどころか公演中に会場内で携帯電話の着信音が鳴り響いた後で、携帯はマナーモードにしてみたいなことを言ったあとで「ご機嫌なBGMは私がご用意します」といったユーモアあふれるコメントをするなど、かなりいい感じだった。

セッション

基調講演: 毎日の料理を楽しみにする挑戦をし続けた20年 / 橋本 健太 様 / 13:10 - 13:30

Cookpadの創業時のお話、その後テックカンパニーとしてのCookpadについて、グローバル展開について、新プロジェクトについて、最後にこれまでの取り組みの話がありました。

CookPadは料理レシピのサービスの会社ではなく「毎日の料理を楽しみにする会社」。そうしたCookpadにとってのテクノロジーとは以下を実現する方法論であるとのこと。

  • 料理が楽しくなる
  • ユーザの生活の役に立つ
  • 今の技術を活かせる

明確な企業理念に則った上での技術への向き合い方や採用方針は、企業文化を作る上で良さそうだと思った。

サービスを立ち上げるときの手法として最近はSprintという開発手法を使っているとのこと。

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

クックパッドの "体系的" サービス開発 / 新井 康平 様 / 13:30 - 13:50

Cookpadでのサービス開発の難しさに対する取り組み、開発のためのサイクルの回し方についてのお話だった。

サービス開発の最初の段階で、実施しようとしている施策に対する仮説の検証では、BML(Build, Mesucre Learn)ループを用いているとのこと。 これをうまく回すために、アンチパターンの例の説明があった上で、「BMLループを前から順番にやろうとしてはいけない」というのは説得力があった。

また、これらのサイクルをうまく回すために使っているという社内ツールの話では、様々なデータが見れるダッシュボードや、分析レポートの運用方法についての話が良かった。 各種分析レポートを Report.md という形で Markdown で作って Github にPRし、レビューが通ったものをリポジトリにマージする、というのはきちんとした情報が蓄積されてよさそう。

クックパッドクリエイティブワークフロー / 辻 朝也 様 / 13:50 - 14:10

デザイナーの方からのCookpadのサービス開発体制、事例、デザイナーの取り組みのお話だった。

チーム構成としては、投稿や検索といったサービス上の機能単位ごとでチームになっているらしい。 一つのチームの中にオーナー、デザイナー、各種エンジニアがいて、互いをフォローしあえるような形になっているとのこと。例えばディレクターは他部署とのコミュニケーションをうまくとったりユーザ目線に立った形で開発プロジェクトを進めたり、逆にエンジニアだと技術的な判断が得意だったり、それぞれの得意な部分を組み合わせて補えるような形にしている。こういうチーム体制だとコンテキストのズレとかが少なくてスピードある対応ができそう。

開発サイクルは基本的に2週間～1か月。 Github Issueをいろいろ活用しているらしい。

  • アイデアをGitHub issueに集めて、定期的に全員で検討
  • デザインレビューをGithub Issue上で、目的、背景、デザインの意図を明確にした上で横串で行う。
  • 前の発表でも出てきたReport.md。施策に関する情報(仮説、試算、実数、考察、次のアクション)は Github のリポジトリ上で管理して、PR、レビューしたり誰でも参照できるようにしているらしい。

デザイナーのロールでもサービスを横断的にみるための組織作りについてすごく考えられてて実践されている印象だった。

What/How to design test automation for mobile / 松尾 和昭 様 / 14:20 - 14:40

モバイルのテスト自動化についてのお話だった。

テストを実施するにあたっての各開発者間でのコンテキストの差。どういう視点、意図でテストをするか。 開発スピードを上げたいのか、人手による不確定な作業を減らしたいのか、理想の開発手法を構築したいのか、自動化という文化を作りたいのか。

独自の項目としてSPLITという5つのキーワードにして、テストに関する問題を分割して考えるというやり方を紹介されていた。

  • Scope…テストの対象範囲
  • Phase…テストを分割する上でどのフェーズのものをテストするのか？通常の開発サイクルではなく、リリースを起点として開発環境・本番環境のどちらをテストするのか。
  • Level…どこまでテスト自動化を行うか。何をどこまでやってどう計測していくのか。
  • sIze…どういう単位でテストを自動化するか。単体、結合、OS、ネットワーク…etc
  • Type…どのようなタイプの目的を持ったテストをするか。

(参考)

Rubyの会社でRustを書くということ / 小林 秀和 様 / 14:40 - 15:00

Cookpad といえば Ruby や Rails のイメージが強かったけど、特にそれに固執しているわけではないとのこと。 マイクロサービス化が進んでいるそうで、それに伴って様々なサービスから使えてパフォーマンスも出せるような柔軟なPush通知配信基盤を作るためにRustを選択したとのこと。 マルチスレッドプログラミングを書くときデータ競合のある可能性のあるコードを、コンパイラが検知してエラーかWarningかを出してくれたりするらしい。 ただ、「Rustはより高速なプログラムを書くための機能がしっかりしているのであって、高速なプログラムを書くのはプログラマの仕事」というのはその通りだなと。

cookpad storeTV 〜クックパッド初のハードウェア開発〜 / 今井 晨介 様 / 15:00 - 15:20

スーパーに設置して料理動画を配信するサイネージであるcookpad storeTVのお話だった。

物理的な開発を伴うため時間はかかったそうだがソフトウェア開発と同じような改善サイクルを回したそう。 HW部分等の自社にとって不得意な部分は外部に任せるという戦略を取られたとのことで中国の工場で作ったそうだが、ロゴが微妙に違ったりという問題があり任せきりはダメだと分かったとのこと。「任せきりはだめ」というのは何にでもいえそう。 MDMでデバイスの一元管理し、アプリのアップデートを管理者側でコントロールできるようにし、高速な改善サイクルを実現できたらしい。

収益化の仕組みとしては料理動画のあとに広告を流しているとのこと。また、広告の機能として、タブレットのインカメラでどれだけの人が広告を見ているかを計測しているらしい。個人情報を残さず端末でカウントアップを行っているということだった。顔認識の機能はタブレットの計算資源を多量に使うので、集合写真を用いて顔認証がきちんと動作するか検証しているらしい。

Lifestyle Product Award授賞式 / 15:50 - 16:00

昨年開催された Lifestyle Product Award by Cookpad というものの表彰式が行われた。

優秀賞としてGOKURIという飲み込みの能力を計測するためのデバイスが選出された。

Challenges for Global Service from a Perspective of SRE / 渡辺 喬之 様 / 16:00 - 16:20

Cookpadのグローバルサービスについて、グローバルサービスの今、SREの課題や取り組みに関する内容でした。

海外の開発拠点はイギリスオフィスだそうだが、スタッフやコミュニティマネージャーは世界中にいるらしい。コードは日本のものとは異なるとのこと。

世界的にサービスを展開していることで生じる課題として、ユーザ体験に違いがあるとのこと。ここでのユーザ体験とはどういうものか説明はなかったと思うけど、サービスのレスポンスのことを差していたと思う。 問題や改善についての詳細については以下のブログ記事の内容の通りだったので、僕がグダグダ書くより以下の記事と動画、資料を参照したほうがよさそう。

そのほかとしては、各国で行われるイベントのタイミングでリクエストの増加が発生するが、各国のイベントが重なることでさらにリクエスト数が増加して負荷が高まるので、対策としてスケーラビリティの高いシステムにするためにAuroraを導入したり、ECS＋hakoによるデプロイ環境の整備、メトリックスを閲覧できるダッシュボードの整備をしたり、

世界中からデプロイが正常にできるようRundeck等を用いたデプロイ環境の整備を行ったりしたそう。

後はToilの撲滅。

  • 手動で対応している
  • 自動化の余地がある
  • 繰り返し発生する
  • 発生してからじゃないと対応できない
  • サービスの改善につながらない
  • サービスやユーザーの数に応じて増加

セッション内ではアカウント管理周りについて言及されていた。たくさんのツールを利用されていてSSOに対応してないものとかがあると、世界中のメンバーのアカウント管理は確かに大変そう。 解決策として Nginx + omniauth を用いて、アカウント作成等の権限を委譲していたったらしい。

Synthetic Monitoring を活用したグローバルサービスのネットワークレイテンシの測定と改善 - クックパッド開発者ブログ

動き出したクックパッドのCtoCビジネス / 村本 章憲 様 / 16:20 - 16:40

Cookpadの新規事業のプロダクト「Komerco」というものについてのお話だった。 クリエーターと料理をする人々を結びつけるサービスらしい。

スピーディーな開発を行うことを目的としていろいろ検討した結果、Firebaseが良いのではないか、という判断のもと採用したそうで、それによりサーバサイドエンジニアなしのサーバレスという形で開発を行っているらしい。 Firebase Japan User Group を立ち上げてコミュニティを盛り上げるのにも貢献しているそう。

OSSを利用するだけではなく、 Komerco で使っている技術をOSSとして公開しているらしい。

Solve "unsolved" image recognition problems in service applications / 菊田 遥平 様 / 16:50 - 17:10

MLを用いた画像分析に関するお話だった。 ML領域は全く手を付けたことがなく、セッション内容も高速だったのでその場ではなかなか理解できないところが多かった。 資料や参考URLの内容をあとでしっかり読み直す。

以下はメモまとめ。

チームは19名(学生アルバイト込み)、1年半前は4－5名だったそうなので、かなり大きくなっている印象。 料理の専門知識を持ってデータにラベルを付けるアノテータ、データを使って機械学習をする人、新しいデバイスを使って新しい料理体験を提供する人、食文化を研究する人、基盤整備する人などなどいろんなメンバーがいるらしい。

取り組みとしてはサービスに直結するものだけではなく、ML系の論文を発表したり発表したりと多岐にわたって取り組みを行っているとのこと。

画像が与えられたとき、料理か料理ではないかを見極めるという一見簡単なことだと思えそうなことがやってみるとかなり難しく、「サービスで解くべき問題は、自分たちがイメージしているものと違う」とのこと。

まず、画像分類の問題は、条件が整っている状況下では解くことは可能。適切なラベルが付与されてたり、適切なカテゴリ分けがされていたり。テストデータと学習データの割合、分布がきちんとなっているとき。 →見た目で分類できるものは解くのは可能。だが、例えばケーキの画像がクリスマス用 or 誕生日パーティ用というのを判断させるのは難しい。 例えば、ラーメンを分類する問題で学習データに多数のラーメン画像を学習させて、そこにケーキの画像が来ると、モデルは一番似ていると判断したものに分類させる。

「料理きろく」の事例

機械学習の観点から重要な点は、まずは出してみる。運用してみることで得られる知見がある。 単純な2値分類ではなく、間違いやすいものを特別にハンドリングしてその後に2値分類するとか。

論文も出されているらしい。

基調講演: Beyond the Boundaries / 成田 一生 様 / 17:10 - 17:30

扱っている技術やエンジニアの行動規範や組織作り、エンジニアが成長するための仕組みなどについてのお話だった。 自社のミッションに沿った組織づくりについてすごく試行錯誤して実践されている印象。見習いたい。

以下はメモ。

技術責任者としては「テクノロジーで料理の課題を解決していきたい」という思いを持って、いろいろ取り組まれているんだと感じた。

プロダクトを作ってユーザの課題を解決するために「技術を正しく理解して普通に使う」

2018年の技術スタック

  • サーバサイド: Rails, Go, Rust
  • ネイティブアプリ(スマートフォン): swift, kotlin
    • →kotlinの利用はGoolgeが公式サポートする旨を聞いて即意思決定
  • ネイティブアプリ(プロトタイプ向け): React Native
    • →プロトタイプを重要視しているのでそれらを素早く開発できるようにするため
  • serverless: Firebase
  • サーバサイド基盤: Docker(Amazon ECS + Hako)
    • →サーバサイドアプリはECSでのDockerを使い、Hakoによるデプロイで稼働させているらしい

Rubyの上で動いているCookpadというサービスの開発を持続可能にするのは企業の責任として考え、フルタイムのコミッタ、笹田様、遠藤様を自社に迎えてコミュニティにも還元できるように心がけているそう。

エンジニア企業文化

行動規範として「Beyond the Boundaries」を掲げているとのこと。 これは、知らず知らずのうちに「自分にはそれはできない」「自分の責任ではない」と自ら引いてしまっている境界(Boundaries)を認識し、そして自分の仕事の境界を認識して上でそれを超えていこう、ということらしい。 自分が何をすべきか、役割を広くとらえて動くことで、組織全体としてうまく動くようにしていこうとしている。

新しい人が入ってくきて組織が大きくなると、役割が特化した働き方ができる、細分化していく。自分がやらなくても組織は回っていくようになる。 ただ、それに逆行してもっと流動的に役割を飛び越えて働くようにしたい、それが若者の育成に重要と考えている、とのこと。

今回のカンファレンスの発表者も新卒～2年目、3年目が多く、若くて優秀な人が多く入ってきて成長できる環境を育成できていると感じているそう。

これは昔から同じようなことを考えていて、例えば職種ごとに部門が分かれたりしていると、各部署間でのミッションのズレが起こり「これはうちの部署の責任ではないからよい」とかになってプロダクトとしてあるべき形を見失う。 ただ、明確な線引き、責任分解点があったほうがやりやすいというのはあるので、そういうのは組織の文化とかとのバランスなのかな、と思ったりしている。

テックリード制度

各部署にミニCTO(技術選定、コードレビュー、メンタリング、エンジニア評価)を配置。その部署の技術責任者、メンバーの成長に責任を持つ。 CTOはテックリード(ミニCTO)と面談、コミュニケーションをして、組織や技術をどうしていくのが良いか等を話し合う。 これをやって状況がかなり改善したらしい。

全社ハッカソン

役割が細分化していくと、自分が触ったことのない技術が増えていく。さらに自動化が進むと、触る必要もなくなってくる。 昔はいろいろ触れる機会があったが減ってきた。それを補うために、全社ハッカソンを実施。

専門外の難しいことをみんなでやる。Rubyのインタプリタ開発や機械学習領域。

料理を楽しむ人がもっとクリエイティブになれる場所へ

1つの取り組みとしてCookpad Studio。料理動画を投稿できるようにしたいが料理動画を撮るのは難しいがそれを解決するための場所らしい。レシピ投稿者ならだれでも利用できるとのこと。

Cookpadは「レシピ検索」中心のサービスでそれによって解決できる問題は「今日何を作ろう？」というもの。ただ、もっと広く考えているのは「毎日の料理を楽しみにしたい」ということ。 対して、料理する人は減ってきているらしい。

未解決の食の課題はたくさんある。 そういうことについて分析したそうで、それが以下の食と料理にまつわる社会課題マップとのこと。

現在、プロダクトとして立ち向かえている領域は少ししかないが、これに立ち向かっていきたいとのこと。

LT

あまりよく聞こえなかったのでとりあえず見つけた資料のリンクのみ張っておく。

まとめ

Cookpad TechConf 2018 に参加してきたのでその振り返りとしてのまとめを書いた。 Cookpadの技術的な取り組みに関して知ることができ、楽しい1日を過ごせたイベントだった。関係者の皆様、ありがとうございました。