チーフネイティブエンジニア 藤原 聖氏
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アプリ） |
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（旧バージョン）はサイバーエージェントの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端末の実機が手元にあるのとほとんど変わらないデバッグ環境を実現している。
Android端末のデバッグを実行可能。STFもコア部分は一部オープンソース化されている
このように、さまざまなツールを活用することでAmebaネイティブアプリ開発チームが目指したのは、「誰が作っても同じように作る」「全部のアプリを同じように作る」ことのできる仕組みと体制だという。
「ネイティブエンジニアのチーム全体が、1人のスペシャリストであるかのように機能する。1人のスペシャリストがスピーディに、常に高いクオリティを保ってすべてのアプリを開発していくのと同じように、チームが開発を行う。そのような体制にできたのではないかと感じている」（藤原氏）
それが、「多くのネイティブアプリを複数人で流動的に開発する場合に、どのようにして“スピード”と“クオリティ”を担保するか」という課題に対する、藤原氏らが出した一つの答えということだろう。
