CodeZine(コードジン)

特集ページ一覧

【デブサミ2014】14-B-4 レポート
チームがまるで「1人のスーパーエンジニア」のように機能する Amebaの開発環境とは

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2014/04/17 14:00

 サイバーエージェントでは、「Ameba」を中心にブラウザ上で利用するWebサービスを幅広く展開する一方で、ネイティブアプリの開発にも注力。一部のゲームやコミュニティアプリについては、1チームが流動的に複数のアプリを担当する体制を採っている。こうした中で、いかにして開発のスピードとクオリティを保っているのか。そのためにサイバーエージェントが活用しているツールや開発環境などを、同社 アメーバ事業本部 チーフネイティブエンジニアの藤原 聖氏が紹介した。

株式会社サイバーエージェント アメーバ事業本部
チーフネイティブエンジニア 藤原 聖氏
株式会社サイバーエージェント アメーバ事業本部 チーフネイティブエンジニア 藤原 聖氏

GitHubやJenkins、独自ツールでチーム開発の効率をアップ

 Amebaのネイティブアプリの開発は、「プラットフォーム&ブログ(Amebaアプリ)」「ゲーム」「コミュニティ」という3つのチームに分かれて行われている。さらに、ゲームについては、『ミリオンチェイン』などのフルネイティブのゲームに特化した「Native Studio」と、『ガールフレンド(仮)』や『天下統一クロニクル』のようなブラウザゲームをネイティブアプリ化する「GP室」の2つに分かれている。

 各チームの人員は、プラットフォーム&ブログが、Android、iOSそれぞれ4名のエンジニアとQA(Quality Assurance)担当が2名の計10名。Native Studioは、クロスプラットフォーム対応のフレームワークであるUnityやCocos2d-xを使うエンジニアが5名と、デバイスごとの差異に対応するためのUnity plugin開発を行う2名。GP室は、AndroidあるいはiOSのエンジニアが8名以上。コミュニティは、AndroidあるいはiOSのエンジニアが15名以上である。

Amebaネイティブアプリ開発チームの体制
部署 体制 開発アプリ数
プラットフォーム&ブログ  
(Amebaアプリ)
Androidエンジニア:4名
iOSエンジニア:4名
QA(Quality Assurance)担当:2名
1
ゲーム   Native Studio Unity、Cocos2d-xのエンジニア:5名
Unity plugin開発者:2名
1
GP室 Androidエンジニア+iOSエンジニア:8名以上 5以上
コミュニティ Androidエンジニア+iOSエンジニア:15名以上   30以上

 全体的に少数ながらも、GP室とコミュニティのエンジニアが比較的多いのには理由がある。プラットフォーム&ブログとNative Studioが基本的に1チームで1アプリを開発するのに対し、GP室では5つ以上、コミュニティでは30以上と、1つのエンジニアチームで複数のアプリを担当するからだ。その中では、1人のエンジニアが複数のアプリを同時もしくは順番に開発することもあれば、2人以上のエンジニアが同じアプリを同時に開発することもある。担当アプリが変更になることも少なくないという。

 藤原氏は、このセッションでは、GP室やコミュニティのように1チームで複数アプリを開発するケースにフォーカスすると述べた上で、これまで重点課題として取り組んできた「多くのネイティブアプリを複数人で流動的に開発する場合に、どのようにして“スピード”と“クオリティ”を担保するか」について話を始めた。

 Amebaネイティブアプリ開発チームでは、この取り組みの第一歩として、2013年春までにすべてのプロジェクトにおいて、構成管理ツールをSubversion(SVN)からGitに変更。複数人での開発を支えるプラットフォームとして、GitHubも導入した。以来、git-flow(一部、GitHub-flowも併用)とPull Requestを使ったブランチ管理およびコードレビューを実施している。

 GitHubを採用した最大の理由は「Pull Requestを使いたかったから」。「経験上、特にネイティブエンジニアは大部分がローカルで開発できてしまうこともあって、1人で開発する場面が多い。そこで、Pull Requestを使うことで、コードレビューを開発フローに組み込んだ。クオリティアップのために、他のアプリを担当しているエンジニアがPull Requestを見てチェックし、マージする決まりになっている」(藤原氏)

 また、次に示す2つの目的から、CI(継続的インテグレーション)ツールのJenkinsも利用しているという。

 1つは、開発中のアプリ配布の自動化。これは、自社開発したツール「AppZone」との組み合わせで実現している。AppZoneの役割はファイルサーバに近い。Jenkinsでビルドしたアプリのファイル(apkやipa)をAppZoneにデプロイしておくことで、関係者はそれを容易に入手できる。デザイナーなどエンジニア以外の人たちでも、テストなどのために必要であれば、スマートフォンなどのデバイスからAppZoneにアクセスし、最新状態のアプリケーションファイル(apk/ipaファイル)をダウンロードできる。

「AppZone」で最新状態のアプリをスマホなどのテスト機にダウンロード可能に。
AppZone(旧バージョン)はサイバーエージェントのGitHubアカウントでオープンソース化されている
「AppZone」で最新状態のアプリをスマホなどのテスト機にダウンロード可能に。AppZone(旧バージョン)はサイバーエージェントのGitHubアカウントでオープンソース化されている

 Jenkinsを使うもう1つの目的は、レビューの自動化である。「Pull Requestをコードレビューするには、どうしても人の目が必要。ただ、時間的ロスも多いので、ある程度自動化するためにJenkinsを使って静的コード解析を行っている。コードレビューの結果はJenkins上に可視化(グラフ表示)されるので、すべてのアプリのコード品質が一目瞭然」(藤原氏)

 今のところ、コード解析ツールを導入しているのはAndroid向けアプリ開発のみで、LintやCheckStyle、FindBugs、PMD、cpdなどのツールを使用している。これらの設定値やAndroid向けに行ったカスタマイズなどは、GitHubにコミットしておく。これをメンバ全員が使うことによって、コードレビューの品質一定化を図っている。

 その他、アプリのクラッシュ原因分析・ログ収集用にCrashLyticsなどのツールを利用して、クオリティを担保しているとのことである。

1台のPCから複数端末に同じ指示を与えて実機テスト

 続けて藤原氏は、「iOSアプリ開発者の方には申し訳ないが…」と断りを入れつつ、Android向けの統合開発環境に話題を移した。

 Android開発者にとっての最近の大きな関心事の一つに、IDE(統合開発環境)が挙げられるだろう。これまでどおりEclipse(Eclipse ADT:Android Development Tool)を使うのか。それとも、Android Studioに乗り換えるべきか。藤原氏は「Android Studioのほうが、本番環境と開発環境との切り替えがスムーズで、gradle(jarファイルの生成などに使用するビルドツール)をより有効に使える」としながらも、Amebaのネイティブアプリ開発ではEclipseを使っているという。

 その理由の1つは、Android Studioのバージョンが0.4.2(2014年2月現在)の「Early Access Preview」であること。今後のメジャーリリースの際には、仕様把握などのために開発をいったん止めなければならないことも想定される。

 そして、もっと大きな理由として藤原氏が挙げたのは、EclipseにはSave Actions(保管アクション)の機能があることだ。Save Actionsを有効にしておけば、ファイルを書き換えて保存する際に、ソースコードのフォーマット(整形)やクリーンナップを自動実行させることができる。

 「複数人のエンジニアが、複数のアプリの開発を入れ替わり立ち替わり担当していく現場では、エンジニアごとの書き方や癖により、ソースコードが全体的にバラバラでわかりづらくなってしまうし、コンフリクトの原因にもなりかねない。だからといって、人の手で書き方を統一するのは大きな負担になる。そこで、コードフォーマッタで自動整形し、強制的に統一することにした。エンジニアは機能追加など本来の業務に専念できる」(藤原氏)

 また、antを使えば本番環境と開発環境の切り替えが「これならgradleを使わなくてもいいだろうというレベル」(藤原氏)で簡単にできたことも、Eclipseを選ぶ理由となった。

 開発環境の整備はこれだけではない、Androidアプリ開発では手間のかかるデバッグを効率化し、スピーディに行うために独自ツールを開発して活用しているという。

 「Androidのデバッグで一番の障壁は、端末の種類が多いこと。そこで、ブラウザからリアルタイムで複数のAndroid端末を同時にテストできるツール「Smartphone Test Farm(STF)」を開発した」(藤原氏)。

 STFでは、PCに複数のAndroid端末実機を接続し、ブラウザ上で接続した端末すべてに同じ指示を与えて実機テストを行うことができる。たとえブラウザ上のリモート操作でも多数の端末を1台ずつ操作するのは大変だが、STFは接続した端末を一斉に操作・テストできるのがポイントだ。たとえば、Web表示テストなら、1つのURLを指定すれば各端末で同じページが同時に表示され、表示結果の違いなどが即座に確認できる。もちろんブラウザ表示だけでなく、apkファイルをインストールしてアプリをテストしたり、logcatでログを取得して見たりすることも可能で、Android端末の実機が手元にあるのとほとんど変わらないデバッグ環境を実現している。

「Smartphone Test Farm(STF)」により、ブラウザからリアルタイムで複数の
Android端末のデバッグを実行可能。STFもコア部分は一部オープンソース化されている
「Smartphone Test Farm(STF)」により、ブラウザからリアルタイムで複数のAndroid端末のデバッグを実行可能。STFもコア部分は一部オープンソース化されている

 このように、さまざまなツールを活用することでAmebaネイティブアプリ開発チームが目指したのは、「誰が作っても同じように作る」「全部のアプリを同じように作る」ことのできる仕組みと体制だという。

 「ネイティブエンジニアのチーム全体が、1人のスペシャリストであるかのように機能する。1人のスペシャリストがスピーディに、常に高いクオリティを保ってすべてのアプリを開発していくのと同じように、チームが開発を行う。そのような体制にできたのではないかと感じている」(藤原氏)

 それが、「多くのネイティブアプリを複数人で流動的に開発する場合に、どのようにして“スピード”と“クオリティ”を担保するか」という課題に対する、藤原氏らが出した一つの答えということだろう。

お問い合わせ

株式会社サイバーエージェント

〒150-0043 東京都渋谷区道玄坂一丁目12番1号

TEL: 03-5459-0202(代表)

URL: http://www.cyberagent.co.jp/

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5