Shoeisha Technology Media

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などのツールを利用して、クオリティを担保しているとのことである。


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

著者プロフィール

バックナンバー

連載:【デブサミ2014】セッションレポート

もっと読む

All contents copyright © 2006-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5