クックパッド サマーインターンシップ2017 「17day 技術インターンシップ」を開催しました

いつもお世話になっております。エンジニア統括マネージャーの高井です。

クックパッドでは毎年恒例となりつつある、クックパッドのサマーインターンシップのうち「17day 技術インターンシップ」を開催しました。インターンに来てくれた学生のみなさんは本当に優秀で、毎日真剣に取り組んでくれました。本当に感謝しています！

インターンは、前半の「サービス開発講義・課題」パートと後半の「サービス開発実践」から構成されています。前半パートでの講義について資料を公開いたしますので、みなさまぜひご覧ください。

f:id:takai_naoto:20170831080358j:plain

【1日目】サービス開発

初日は、クックパッドで実践されているサービス開発の手法について学ぶワークショップです。グループでのユーザーインタビューを通じてサービスの設計をしました。

【2日目】Rails・TDD・Git

昨年に引き続き、講義初日はGit、TDD、Railsを1日で一巡りするという、忙しい構成でした。

【3日目】モバイルアプリケーション

3日目は、 iOS と Android のふたつに分かれて、 Google 社の Firebase をつかった Cookpatodon というマイクロブログ風のアプリケーションを題材に学習をしました。アプリケーションの基本部分を実装したあとは各自で自由に機能を実装してもらい、最後に成果発表会という形で発表してもらいました。皆ユニークな機能を実装して大変盛り上がりました。

【4日目】インフラストラクチャー

Web アプリケーションのインフラについてAWSをつかいながら、Railsアプリケーション動作させるところから、パフォーマンスチューニング、スケールアウト、キャッシュなどのトピックについて触れています。

（資料は公開準備中です）

【5日目】SQL

Redshiftで構築されたデータウェアハウスをつかって、分析用のSQLを書いていました。クックパッドの実際のデータをつかったので、参加者たちは億単位のレコードがあるテーブルと格闘していました。

（内部データを利用した講習のため資料の公開はありません。どのようなものだったかを知りたい方はこちらまで。こちらの書籍でも概要を知ることができます）

【6日目】機械学習

機械学習は講義と実習のセットになっており、講義では「機械学習とは何か」という概観とディープラーニング（特にCNN）を学んだうえで、実習ではクックパッドのデータを使ったレシピ分類に取り組みました。最後は各々が興味をトピックを取り組んでもらってその成果を提出しました。

【7日目】Ruby

最終日のRubyの講義では、RubyでRubyのコンパイラを実装したり、その最適化を行ないました。

番外編

前半の講義が終わった懇親会では、先輩社員による就職活動の体験談LTなどが行なわれ、参加者のみなさんが楽しんでいました。

f:id:takai_naoto:20170831080459j:plain

その後の二次会も盛り上ったようです。

施策の質と職務能力を高めたい！ディレクター会の取り組み

こんにちは。サービス開発部 ディレクターの五味です。 Android版クックパッドアプリのリリースマネージャーと、アプリ利用者に関わるいくつかのプロジェクトを担当しています。今回は私たちの部で実施している、ディレクターの定例会について紹介します。

f:id:natsuki53:20170829223631p:plain

サービス開発部

クックパッドの開発体制は、2年前に私が ディレクター知見共有会についてのエントリー *1 を書いた頃から少し変遷を経て、2017年からはサービス開発部が、レシピ検索・投稿などの基幹機能と、サービス全体のユーザー体験を一手に管轄するようになっています。

部のメンバーは現在40人ほどおり、部の注力指標からブレイクダウンしたKPIをベースに9つのプロジェクトチームに分かれています。チームの編成や人数は様々で、状況に合わせて入れ替わりもOK、KPI達成に向かっていれば、各チーム主体的に動くことが推奨される柔軟な組織を試みています。

プロジェクトチームで働く中で

このような体制の利点は、自分のチームのミッションに対して裁量を持って施策を考え取り組めることです。やりがいがある反面、以下のような悩みを感じるようになりました。

  • 部の目標に対するチーム横断での進捗度や、自分のチームの遅れが見えづらい
    • チームで決めた施策を進めるだけで、施策数や速度は本当に十分なの？
  • チームが自律的に動く反面、チーム間の情報連携や相互補完が難しい
    • 他のチームは目標をどう考えてどんな施策をしているのか、知りたいけど聞きづらい…
  • ディレクターとしての自分の成長がわからない
    • この職種に必要なスキルは何なのか、自分のパフォーマンスは足りているんだろうか？

ディレクター会の発足

これらの悩みを持ち掛けた方々から助言を得て、部のディレクターがチームを越えて集うディレクター会を始めることにしました。部内のディレクター職の他、ディレクター不在のチームからは同等の役割を担っている他職種の方にも声をかけます。

初回の開催で、会の目的とアジェンダを以下のように決めました。

  • 会の目的
    • サービス開発部でディレクターの役割を持つ人の情報・知見をチーム横断で共有する
  • 成功のイメージ（会の参加者に対して）
    • 担当施策について目標に対する成果を把握し、責任を持って報告できるようになる
    • 部内の施策の内容・効果を横断的に把握し、自分の提案に活かせる
    • 定期的に悩み相談や意見交換をする機会を得て、施策の精度が部署全体で上がる
    • ディレクターとしてのスキルアップに積極的に取り組めるようになる
  • アジェンダ（60分）
    • ① 実施した施策の共有 30分
    • ② 施策やチーム運営の相談 20分
    • ③ その他アナウンス、連絡事項 10分

意識したことは「先週これをやりました、今週これをやります」という業務進捗報告に時間を割かないことです。他のチームの施策の進捗を聞いても必要な情報や問題を見出すのは難しいことと、ディレクターなのでチームの進捗管理は各自できている前提にしたかったためです。

会議の時間は1時間、開催頻度は週1回と仮決めしてスタートしましたが、これは毎週ちょっとだけ時間が足りないくらいアジェンダがある状態が続けられているので、そのまま継続しています。

「実施施策の共有」について

ディレクター会のメインコンテンツにしている施策の共有について少し紹介します。

この会では、部で実施する施策をできるだけすべて議題にあげたいので、施策共有用に手間のかかる資料は作らないことにし、GitHub Issue に報告事項の箇条書きだけ準備する方式にしました。

ただし、箇条書きの項目はテンプレートで決まっており、報告には、仮説・試算・実数・考察・次のアクションの5項目が必要です。PDCAを回せるような設計がきちんとできていない施策はこの5つに埋められない項目が出てくるため、施策を考える人の自浄装置のような働きをしています。

例えばこのディレクター会をテンプレートに沿って報告しようとすると、下記のようになります。

# 施策名：サービス開発部のディレクター週例
- 仮説
  - ディレクターが定期的に施策情報を共有し意見交換できる場ができると、部全体の施策の精度とスピードが上がる
- 試算
  - 部の施策数が週5本（各チーム2週に1本）になる
  - 部の目標達成の進捗度が10%上がる
- 実数
  - 施策報告数：2〜3本/週
  - 部の目標達成進捗度：変化なし
- 考察
  - 定性意見より、会があることで施策/プロジェクトの成功への責任者意識は強まった
  - 他チームの成功・失敗事例やお互いの助言を担当案件に活かせる機会はできた
  - ただ、実際の施策のスピードやKPIの進捗に変化が起こるほどの成果には至っていない
- 次のアクション
  - アジェンダの見直し：参加メンバーに課題提起し、次の会で改善策を話す時間を取る

また直接この会に起因することではありませんが、最近サービス開発部では、施策結果のレポートをPull Requestで作ってチームでレビューする手法が採られ始めています。何かをリリースして完了ではなく、検証内容を振り返り次にどう進めるのかの判断にチームで取り組めることと、メンバーがレビューに入ることで、施策に対するチームの理解が揃う利点があります。

ディレクター会ではこれらの箇条書きやPull Requestを見ながら、施策共有に使える30分を週ごとの施策数で割って時間配分を決め、どんどん報告していってもらいます。報告を聞いている側の人は、気になる点や使える知見があれば自由に発言してもらい、特筆すべき意見は後で議事録に残して使ってもらいます。

ディレクター会の効果と課題

現在、この会を始めて2ヶ月ほどが経ったところです。前段の報告テンプレートの事例で少し前述していますが、現時点で良かったと感じている点は以下です。

  • 他チームの成功・失敗事例や、他のメンバーの助言など、自分の施策に活かせる第三者からの情報を得やすくなった
  • 週ごとに報告できる施策の数から、各チームの進捗スピードが推し測れるようになった
  • ディレクター：プロジェクトを成功に進める責任者という意識を合わせ、施策に取り組めるようになった

反面、まだ成果は定性的なものに止まっており、施策のスピードや部の目標達成の進捗に効果が表れるには至っていません。またディレクターのスキルアップのような長期の取り組みには手を出せていない状況です。

ちょうど先週これらを課題として改善策を相談し、次から以下の2つを変更してみる予定です。

  • 施策報告を、終了した施策だけでなく、これから実施する施策も対象にする
    • 結果だけだとチームが何を考えてその施策をしたのかわからない、終了施策にツッコミをもらっても「次頑張ります」としか言えないという意見から。施策の改善の余地に事前に気づいて検証の精度を上げられるように。
  • 進行中施策に直接紐づかない大きめのトピックも持ち込むようにする
    • 仮説定義や分析手法のノウハウなど、具体的な解がすぐ出せないから話題にしづらいが、各自悩みの深い相談を持ち掛けられるように。

このような取り組みを継続させるコツ

前回ディレクター知見共有会のエントリーを読んだ方から「うちはこういう会を始めても3回で自然消滅します…」という感想をいただいたので、大変僭越ですが、複数のメンバーを巻き込んで定常的な取り組みを行う際に意識していることを紹介させていただきます。

1. 参加者のコストを必要最小限にする

時間と手間を取りすぎないことを念頭に置いています。 今回であれば、会議が1時間を過ぎないよう時間配分することと、準備はGitHubのIssueにテンプレートに沿った箇条書きで済むようにしています。

2. 参加者がすぐ活かせる粒度の情報を入れる

「ディレクターに必要なスキルとは？」といった少し高い次元の議論だけでなく、明日から自分の業務に使える実用的な情報を得られる議題を含めることで、参加の利点を感じやすくします。 そのためディレクター会では実施施策の話題に時間を厚めに充てています。

3. “他人事” になっているメンバーを放置しない

取り組みが軌道に乗ってから1番気を配る点です。会議中ぼんやり聞いているだけの人が出てくるようになったら要注意です。敢えてその人に指名で意見を求めてみたりして反応を見ながら、会議の内容自体に原因がないか見直しを考えます。

最後に

ディレクターはエンジニアやデザイナーに比べて職務定義が難しいということをよく聞きます。また1つのプロジェクトに複数名でアサインされることは少なく、1人で複数のプロジェクトを掛け持ちすることは多いため、各自が抱える情報や知見を共有するには意識的な働きかけが必要だと感じます。

ただ、どんなプロジェクトでどのような働きをしているにせよ、ゴールに向かってチームを進めていく大事な役割を担っていることは確実だと考えます。

開発者がすごい！と言われるクックパッドですが、「ディレクターもすごいんです！」と言えるよう、今後も頑張っていきたいと思います。

そして、そんなチームに一緒に加わって頑張ってくださるメンバーを募集しておりますので、よろしくお願いいたします！ https://info.cookpad.com/careers

*1:注: 「ディレクター知見共有会」はそのあと対象を広げ、今は参加者の職種は問わず様々な部署の体制や取り組みについて聞ける場として継続されています。

Genymotion On Demandを使うようになってAndroidのCIがさらに1分短縮した話

Android 開発環境 ツール

こんにちは。技術部モバイル基盤グループの門田(@_litmon_)です。

モバイル基盤グループでは、エンジニアの方々が快適に開発できる環境を整えるため、日々アプリのビルド時間やCIの実行時間などを短くする方法を模索しています。

今回は、Genymotion On Demandを使ってみた結果、CI上でのAndroidアプリのinstrumentation testの実行時間が1分短くなった話をしようと思います。

前回のあらすじ

今回の記事は、OpenSTFでAndroidのCIを2倍早くする の続編のような記事で、AndroidのCI環境を整えている話です。 まだ読んでいない方はぜひ上の記事から読むことをオススメします。

前回は、Jenkins上でAndroidのエミュレータを起動して使用する方法から、OpenSTFというリモートで実機端末を操作することが出来るオープンソースツールを使用する方法に切り替えた結果、エミュレータの起動時間などが削られ実行時間が約9分近く削ることが出来ました。

しかし、OpenSTFをしばらく運用していくといくつかの問題点が見つかりました。

OpenSTFをCIで使う際の問題点

OpenSTFはエミュレータの起動を待つこと無くテストを行うことが出来るため、とても優秀なツールだったのですが、実際に運用を進めていくと以下のような問題点が見つかりました。

  1. OpenSTFサーバー自体が不安定になることが時々あり、サーバーのプロセスが終了してしまうことが度々あった
  2. 実機の状態が不安定で、時々接続に失敗することがあったりしてメンテナンスコストが高い
  3. CI専用の端末を用意する必要があり、slaveごとに端末が必要になるのでスケールしづらい

1.のOpenSTFサーバーが不安定な点に関しては、正しくメンテナンスを行うことで回避することが出来たかもしれませんが、しばらくはプロセスが終了しており失敗している場合は手作業で立ち上げ直すという運用を取っていました。だいたい、2週間に一度は調子が悪くなり、そのたびに再起動を行っている、という状況でした。

また、2.に関しては、実機の状態が不安定で"なぜか"OpenSTFに認識されないときがあり、そのたびに検証端末が置かれた棚を開きにいっており、毎回原因を追求することまではせず運用でカバーしていました。そのため、端末を管理するコストが大きくなっていました。

現状の問題点

ということで、現状の問題点を整理すると、

  • 自社でOpenSTFサーバーを立てると相応のメンテナンスコストがかかる
  • 物理端末に依存することで、端末の管理コストがかかりスケールしづらい

という2点が挙げられます。

これらの問題点を解決するため、様々なサービスを検討した結果、Genymotion On Demandにたどり着きました。

Genymotionとは

Genymotionは、Genymobile Inc.が出している非公式のAndroidエミュレータです。 Android Studioに標準で搭載されている公式のエミュレータよりも多機能なエミュレータで、x86仮想化を使った公式エミュレータが利用できなかった頃はお世話になったAndroidエンジニアのみなさんも多いのではないでしょうか？

Genymotion On Demandとは

Genymotion On Demandは、そんなGenymotionをAmazon EC2(EC2)インスタンス上で起動し、扱うことが出来るものです。 EC2インスタンス上に起動したエミュレータとADB接続でき、ADBコマンドから端末を操作することが出来るすぐれものです。

Genymotion On Demandを導入することで、物理端末の制約から逃れ、快適なCI環境を手に入れることが出来ると考え、クックパッドでは5月頃から導入を始めています。

Genymotion On Demandの使い方

ここで、簡単にGenymotion On Demandの使い方を紹介します。

といっても、手順は公式のチュートリアルにとてもよくまとまっているので、そのとおり進めるだけで簡単に使うことが出来ます。

Genymotion on Demand – Tutorial –

おおまかな流れとしては、以下のような形になります。とても簡単ですね。

  • AWS ConsoleからGenymotion On Demandのインスタンスを購入する
  • sshでエミュレータに接続し、ADBを有効に設定する
    • この設定はインスタンスごとに一度行えばよく、再起動時には不要
  • sshでport:5555に対して接続することで、エミュレータをADBで認識できるようにする

Genymotion On Demandで使用できるAndroid OSバージョンは、現在5.1, 6.0, 7.0の3種類になります。クックパッドでは、導入時の最新である6.0を使用しています(5月時点では5.1, 6.0の2バージョンだった)。

また、Genymotion On Demandでは、EC2のインスタンスタイプも指定できますが、t2.smallではテスト実行時間が若干遅くなるものの、それぞれ大きな差はありませんでした。 クックパッドでは現在m4.largeを使用しています。

CI上でのGenymotion On Demandの利用

現在、クックパッドではJenkinsのSlaveとしてEC2インスタンスを用いています。(参照: OpenSTFでAndroidのCIを2倍早くする)

そして、Slave 用のインスタンスの起動時に localhost:5555 を Genymotion On Demand のインスタンスへと転送する簡易プロキシを起動しています。 こうすることで、Slaveを立ち上げた時点ですでにGenymotionのエミュレータがADBに認識された状態になるため、Job側でなにも設定することなくエミュレータを使うことが出来ます。

そのため、既存のJobの設定を編集する際も、OpenSTFのプラグインの設定を無効にするだけで簡単に移行が完了します。

f:id:litmon:20170822115529p:plain

導入しただけでinstrumentation testの実行時間が1分短く！

導入してしばらく様子を見ていたのですが、明らかにJobの実行時間が短くなっているのを体感しました。 以下の画像は、縦軸が時間で横軸が実行したジョブの番号を示しています。そして、 #1899 以降がGenymotion On Demandを導入した後になっています(※ときどき失敗しているのは、不安定なテストがあるせいです。気にしないでください)。

f:id:litmon:20170822115903p:plain

このグラフから分かる通り、7分近くあったジョブの実行時間が6分弱に収まっていることが分かります。約1分弱の短縮に成功しました！🎉

詳しく状況を見てみると、以下のようになっていました。

  • 端末との接続を確立するまでで 20秒 短縮
  • ./gradlew :cookpad:connectedAndroidTestStagingDebug が 45秒 短縮
  • ./gradlew :cookpad:uninstallAll が 10秒 短縮

なんと、instrumentation testの実行時間が45秒も短くなっているではありませんか！ それだけではなく、端末との接続時間や、アプリのアンインストール時間が短縮されていることが分かります。

仮説ですが、OpenSTFは自社のローカルネットワーク上で起動しており、Genymotion On DemandはJenkins Slaveと同じEC2インスタンスのため、ネットワークの接続(apkの転送時間など)に影響があったのではないかと考えています。

安定感がスゴイ！

そんなGenymotion On Demandですが、やはり気になるのは安定性です。 現在、導入して3ヶ月ほど経ちました。弊社のJenkins Slaveは2台あり、内1台はフルタイムで活動しています。そして、Genymotion On DemandのインスタンスはSlaveの起動時に同時に起動し接続しているため、内1台は常に活動したままです。

にも関わらず、5月31日に起動して以来今までGenymotionのエミュレータの調子がおかしくなったことはありません。すごい安定性ですね！ これだけ安定して使えるのであれば、ということで、6月の半ば辺りから徐々に既存のJobで使われているOpenSTFをGenymotion On Demandに置き換えていって、今ではほとんどのJobがGenymotion On Demandを使うようになっています。

Genymotion On Demandの制限・注意点

ここまで、Genymotion On Demandの良いところをたくさん挙げてきましたが、いくつか制限もあります。

  • Google Play Serviceが利用できない
  • instrumentation testでタイムゾーンに依存するテストがある場合、失敗する可能性がある
    • 一度これでハマってテストが落ち続けていたので、注意する…
    • エミュレータのタイムゾーンを変更することは可能です

現在、クックパッドの日本のアプリでは上記2つともそこまで大きな問題ではないのですが、プロジェクトによっては導入する際の障害になりうるので、参考になればと思います。

まとめ

OpenSTFを使った実機でのinstrumentation testをGenymotion On Demandを使ったGenymotionエミュレータでのテストに置き換えた結果、CIの実行時間が1分近く短縮されました。また、安定性やスケーラビリティなど、実機で管理していた際の問題点も解消することが出来ました。

クックパッドでは、アプリの開発ももちろんのこと、こういったアプリのビルドやCI周りに対しても様々な取り組みを積極的に行っています。 アプリの基盤の仕組みを整えたり、新たに作り出していける、いきたいAndroidエンジニアのみなさんを募集しています。 もし興味があったらぜひぜひ遊びに来てください。お待ちしています！

クックパッド株式会社 採用情報