クックパッドの開発体制、モバイルアプリを取り巻く環境と課題解決―Think IT Mobile Developer Seminar 2015レポート

クックパッドのモバイルアプリにおける開発体制・ソースコード管理・CI

レシピサイトとして有名なクックパッドは、世界有数の巨大なRailsアプリと言われている。そのサービス開発、特にモバイルアプリの開発体制と、ソースコード管理やCIについての実践を、クックパッド株式会社 技術部モバイル基盤グループ エンジニア 藤 吾郎氏が紹介した。

クックパッド株式会社 技術部モバイル基盤グループ エンジニア 藤 吾郎氏

なぜモバイルファーストなのか

クックパッドは社名であると同時にサービス名でもある。サービスは自社開発なので仕様を決めるのは社内の開発チームで、バグのトリアージも開発チームが行う。また、B2C製品なので使い方をユーザーに強制できない。例えば、開発者側では最新の端末、OSで使って欲しいが、それを強制することはできないという背景がある。

最近のユーザー比率は、PCが3に対してスマホが7と、スマホユーザーが多くなっている。さらに、スマホアプリとスマホWebを比べると、1:3でWebの方が多い。ただし、レシピを投稿できるログインユーザーに限ると、スマホアプリのみが60％で、ユーザーとのエンゲージメントはスマホアプリが強いことが分かる。また、アプリとWebを合わせたスマホでは85％となり、ユーザーはスマホでのサービスを求めている「モバイルファーストの時代」ということになる。サービスの性質にもよるが、B2Cのサービスなら同様の傾向だろう。

ただし、スマホには難しい面がある。大きくは以下の2点だ。

• 画面が小さいため、サービス設計が難しい
• アプリは提供サービスのコントロールが難しい

特に問題となるのは2つめだ。アプリとWebを比較すると、Webはインストールしなくても使えるため、基本的にすべてのユーザーが最新バージョンを使う。また、バグフィックスがあれば、それをすべてのユーザーに反映できる。しかしアプリの場合は、Webのように簡単にロールバックできないうえ、リリースに時間がかかる。また、バグフィックスをどんどんすればいいというわけではなく、あまりに頻繁なバージョンアップはユーザーにとって不便で、レーティングにも影響する。この配布形態の違いが、アプリとWebの最大の違いであり、これをふまえた開発体制が必要になる。

開発体制とソースコード管理

クックパッドのサービスは、まずPC用のWebから始まった。2010年頃からiOS/Android向けにWebアプリをリリースしてきたが、2012年頃にiOS向け、2014年にAndroid向けのネイティブアプリに書き換えた。Android版では滞在時間が1.5倍くらいに伸びているため、この判断は正しかったといえる。

アプリのリリース頻度は2週間に1回程度で、iOS/Androidそれぞれでリリースサイクルごとに約10人のエンジニアがコミットしている。エンジニアは各プラットフォームのエキスパートとジェネラリストは同数程度いる。ちなみにWebのチームは、iOSとAndroidを合わせた程度の人数である。チーム編成は、サービス開発部署と技術部、インフラ部で構成される。これはアプリもWebも同様だ。サービス開発部は特定機能について責任を持ち、技術部・インフラ部は、サービス全般の生産性や安定性などを担当する。

エンジニアはアプリかWebのどちらかだけを専門にする人もいれば、両方やるという人もいる。アプリ開発が始まった当初は、モバイルアプリエンジニアだけを集めた部署があり、各サービス開発チームがそこに仕事を発注するという形だった。しかし、それだと社内の外注部隊のようになり、モバイルエンジニアにとっては上から降ってくる仕事をこなすだけでやりがいに欠ける。そこで、2015年の初め頃から、各サービス開発部署にモバイルエンジニアが配属される形になった。

ソースコード管理には、GitとGitHub Enterpriseを導入している。ただし、ツールを入れればいいというわけではなく、重要なのはワークフローの設定だ。アプリとWebでは、以下のような理由から最適なワークフローが異なる。

• Webはリリースが一日に数回なので、生産性向上のためにはワークフローをシンプルにすることが重要
• アプリはリリースが2〜3週間に一度でロールバックもできないため、計画的に機能開発できるフローが必要

そこでクックパッドのサービスでは、WebはGithub Flowを採用し、アプリはgit flow（a successgull git branching model）を単純化した独自フロー「Mobile App Flow」を採用している。

●GitHub Flow

GitHubが提唱したワークフローで、継続的デリバリーに最適化した非常に単純なルール。masterを常にデプロイ可能に保つことが最も重要となる。修正は常にPR経由で、PRの動作確認をしてmasterにマージしたら、即座にデプロイしてよいものとする。

●Mobile App Flow

基本的にはGitHub Flowと同様に修正はすべてPR経由だが、チーム開発を前提としている。開発ブランチはmasterで、修正はすべてPR経由で行う。リリースが近づいたらリリースブランチを作り、そこではバグフィックスのみを入れる。リリースブランチを作ったら、masterは次のリリースに向かう。

Mobile App Flow

コードフリーズしてリリースブランチを作る点が、GitHub Flowとの大きな違い。リリースブランチには絶対に必要なバグフィックスのみを入れる。リリースブランチはタグを打ったらマスターに戻す。その間に、マスターブランチの方は次のバージョンに向けて機能を開発していく。

また、継続的インテグレーションツールとしてJenkinsを使用している。Gitへのプッシュをトリガーにして、テストなどを行う。Webの場合は、EC2上にJenkinsを展開している。Webアプリが巨大で、ローカルでのテストでは時間がかかりすぎるため、分散テストシステムを自社開発し、CIでテスト・開発環境へのデプロイ・本番環境へのデプロイ準備をする。

一方、アプリはiOSとAndroidの違いに苦労している。Webと同様にJenkinsを使っているが、iOSの場合はテストにMacが必要なため、EC2などのクラウドは利用できない。また、テスト自体は独自開発ではなく、プラットフォームごとの標準テスト機構を使用。CIでアプリケーションパッケージをテストアプリ配布サービスにアップロードもしている。

ユーザーはスマホ上で動くものを求めており、モバイルファーストは避けられない流れだ。モバイルでの開発では、Webの開発を踏襲するだけでは不十分であり、開発体制やワークフローなど、それぞれに適したやり方やツールを見つける必要がある。

モビリティを取り巻く環境の今と求められていること

アプリケーションは、ビジネスをドライブするためのひとつのツール。そのアプリケーションをいかに早く、品質よく開発するかにフォーカスしたのが、アプリケーション・デリバリ・マネージメント、ADMだ。日本ヒューレット・パッカード株式会社 HPソフトウェア事業統括 ITマネジメント統括本部 戦略推進室 ADMビジネス推進 石坂 浩之氏が、モバイルアプリケーションを取り巻く環境と課題解決について解説した。

日本ヒューレット・パッカード株式会社 HPソフトウェア事業統括 ITマネジメント統括本部 戦略推進室 ADMビジネス推進 石坂 浩之氏

モバイルアプリを取り巻く環境

石坂氏は最初に、World Quality Reportや総務省のレポートを参考に、モバイルの利用拡大について紹介した。例えば米国では、銀行取引額全体の伸びよりも、モバイルでの取引額の伸びの方が大きい。ポイントは以下の3つだ。

• モバイルのトランザクションが増加（グローバル）
• スマートフォン・タブレットの保有率が拡大（国内）
• 3GやLTEなどの高速通信環境が整っている（国内）

さらにモバイルアプリを取り巻く環境として、ビジネス、テクノロジー、ユーザーの視点で何が起きているかを解説した。

ビジネスにおいては、モバイルアプリの利用が拡大したことで、ビジネス要件の変更が頻繁になっている。また、ユーザーは使い勝手が悪いとすぐに削除して別のアプリに乗り換えるため、高度なユーザー体験の追求が必要になっている。さらに、ビジネスのドライバとして考えるには、市場投入時間の短縮が求められる。その他、アプリケーション提供の主体が、IT部門からビジネス部門に変化しているという背景もある。

テクノロジー面では、デバイスやOSなどの多様性が拡大していることが大きな問題だ。さらに、通信や連係サービスなどのインフラ環境も多様化し、複雑になっている。ユーザーの利用も多様化している。BYODの広がりでスマートフォンには趣味のアプリと仕事で使うアプリが混在する状況になり、使い方は人それぞれでユーザーの挙動が予測できない。さらに、ユーザーはさまざまなデバイスで同じように使いたいと考えている。

モバイルアプリがフォーカスするエリアを調査したWorld Quality Reportのレポートでは、当然のことながら一番はセキュリティだ。パフォーマンスや機能も上位を占めるが、ユーザーインタフェース／利便性や、互換性／回帰テストといった項目が、ここ3年で大きく伸びている。また、かつてはモバイルテストを行っているケースが少なかったが、それが一般的になっているという調査結果もある。しかし専門家は逆に減っていて、テスト環境の整備やテスト時間の確保にフォーカスされるようになっている。

モバイルアプリにおける課題と解決策

モバイルアプリを取り巻く環境と課題をまとめ、アプリケーション開発のライフサイクルに当てはめて整理すると、以下のようになる。

モバイルアプリの課題

計画と開発のフェーズで必要なのは、要件の把握と追跡性、変更への迅速な対応、小規模単位の開発である。ウォーターフォールのような、伝統的な開発標準の限界が来ているため、アジャイル方法論に移行せざるを得ない。

アジャイルによるモバイル開発課題への対応

テストフェーズでは、ユーザーの環境が多様化しているため、多様なテストが必要になるのが課題だ。テストが大量になるため、テスト環境の整備が必要になる。また、ユーザー体験の検証が必要になっている。ポイントは、以下のような点である。

• 多様なデバイスを用意して管理するのは大変なので、リモートアクセス可能なモバイルテストラボで集中的にテストデバイスを管理する
• デバイスが多様なためテストが大量になるので、自動化は必須
• 手動での多重アクセスは無理なので、パフォーマンステストはツールを使う
• パフォーマンステストはネットワーク環境を考慮して行う必要がある

さらに、どのテストをどの範囲で行うかといった、テスト管理の整備も必要だ。

テスト管理の整備

運用のフェーズでは、使ってみてどうだったかというユーザー体験を補足し、問題があれば対策を打つ。そのためには、ユーザーの利用環境を把握しなければならいし、何が起きたかというイベントを記録しておく必要がある。このため、本当のユーザー体験を計測する、予測的なモニタリングが必要になる。

各課題を解決するためのツールについては次のセッションで紹介するが、課題と解決策を整理すると以下の図のようになる。

HPモバイルソリューションのフォーカスエリア

後編に続く。