新SDKでは“ネイティブアプリのように扱える”
HTML5ベースのアプリ開発が可能に
グリーは「世界で10億人が利用するサービス」を目標に掲げ、グローバル展開を加速する方針を明確に打ち出している。その布石ともいえるのが、今年5月の「GREE Platform」のリリースだ。これまで日本と海外で別々に展開していたソーシャルプラットフォームを統合し、新たに世界共通のグローバルプラットフォームとして提供。これにより、グリーは世界最大規模のソーシャルアプリケーションプラットフォームを有することとなった。
プラットフォームのグローバル化とともに、開発者に提供されるSDK（GREE Platform SDK）も大幅に刷新。より効率的なモバイルアプリケーション開発を支援する新機能の搭載や、グローバル対応を図っている。
米国チームと共同でこの新SDKの開発を担当した高木氏は、まず、「GREE Platform」以前のレガシープラットフォームにおけるSDK開発について振り返る。
「レガシーSDKの開発では、gitによるコード管理やJIRAによるタスク管理は行っていたが、成果物管理は手動。リリース作業やQA（Quality Assurance）、確認用アプリケーションの作成などもエンジニアの手作業で、作業が属人化しがちだった。それでも、ほとんどが少人数での開発だったので、何とか運用できていたのだと思う」
今回のプラットフォーム統合・グローバル化に伴うSDKの刷新では、エンジニアの人数や作業量、作業期間なども大幅に増えることは明らかだった。そこで、グリーでは開発体制を大幅に変更したという。
「まず、開発スタイルは数か月周期の反復型開発からスクラム開発に変更し、1スプリントを2週間としてそれを約半年間回した。JIRAの運用ルールなども見直し、粒度に応じたタスク定義やチケットのオープンからクローズまでのフロー化など、より定型化された管理が行えるようにした」（高木氏）
さらに、コード管理ではGitHubを導入。Tech Lead（テクニカルリーダー）を設定し、Pull Requestの機能を用いたコードレビューによって、Tech Leadの承認がなければ最終的にコミットできないフローとすることで、コードの品質を保てるようにした。
そして、高木氏が「今回最も大きな変化であり、最も役に立った」と強調するのが、Jenkinsの導入だ。
「GitHubと連携してコミットがあると自動的にビルドチェックが走るとともに、自動でユニットテストを走らせたり、コードカバレッジを評価したりできるので、コードのほかにも成果物に対する評価が容易に行えるようになった。ビルドやユニットテストの自動化で高い品質を保持できるうえに、開発者の手間も大幅に削減されたのは大きなメリット」
もちろん開発体制だけでなく、SDK自体の機能も大きく変わっている。中でも今回特に強化されているのが、JavaScriptを介してネイティブコードを呼び出す「ネイティブブリッジ機能」だ。
「グリーでは『GAWADAKE』と呼ばれるHTML5ベースのWebViewアプリケーションを作るためのExtension SDKを提供しているが、日本ではこのWebViewアプリの需要が非常に大きい。我々としても、WebViewを活かしつつ、さらにネイティブの機能を呼び出して、よりネイティブアプリに近い感覚で扱えるアプリケーションを実現する仕組みを提供する必要があると考えていた」（高木氏）
GREE Platform SDKでは、ネイティブのさまざまな機能をJavaScriptから呼び出し、さらにその実行結果をWebViewに返せる仕組みを提供。これにより、WebView上からもネイティブコードを読んでいるかのように振る舞うことができる。
「もちろん、ネイティブの機能をそのまま利用することも可能。例えば、現在、日本ではHTML5ベース、米国ではネイティブベースのアプリケーションの需要が大きいが、各国のデベロッパーがそれぞれの希望に応じたアプリケーションを開発できるように、GREE Platform SDKではさまざまな選択肢を用意した」（高木氏）
（次ページ：グローバル開発の課題となったのは、時差や暦、エンジニアの方向性の違い）
Webアプリケーションでありながらネイティブアプリケーションの
さまざまな機能を呼び出して利用できるようになる。
グローバル開発の課題となったのは、
時差や暦、エンジニアの方向性の違い
今回のGREE PlatformおよびSDKの開発は米国チームとの共同作業であり、高木氏らはグローバルな開発体制ならではの課題にもたびたび直面した。特に影響が大きかったのは、“時差”や“暦”の違いだ。
「特にリアルタイムなコミュニケーションをとることが難しかった。例えば日本が月曜日でも米国ではまだ日曜日ということもあるし、各国独自の祝日などもある。時差の関係で、電話やテレビ会議を行う時間が一方の国ではどうしても早朝や深夜の時間帯になってしまうことも多かった」（高木氏）
なお、コミュニケーションは原則すべて英語で行っていたが、“言葉の壁”については、それほど問題にはならなかったという。
「米国チームは、こちらがあまり英語が得意ではないことを理解しているので、分かりやすく丁寧に話してくれた。また、米国側で独自に日本語の講習会を開くなど、かなり言葉の壁を乗り越えようと意識してくれていた。おかげで、我々は不慣れな英語ながら活発に意見交換できたと思う」
時差や暦の違いのほかに、もう一つ、日米チーム間のギャップとしてあったのは、“エンジニアの方向性の違い”だ。高木氏によると、米国のエンジニアの多くはネイティブベースのアーキテクチャを得意とし、最適化や高速化が得意な人も多かったという。これに対して、日本のエンジニアはWebベースのアーキテクチャおよび共通化や互換性の確保を得意とする傾向が強かったそうだ。日米でエンジニアの方向性がはっきり分かれているのはなかなか興味深いが、最適化・高速化と共通化・互換性はほとんどの場合、トレードオフの関係にある。そのため、「実装に関してどちらをとるか、議論が白熱することもあった」と高木氏は語る。
「そのような場合、日米のエンジニア同士でしっかり話し合って方向性を決めていくのはもちろんだが、基本的にはSDK開発における役割分担を適正化して、それぞれが力を発揮できるような体制にした」
具体的には、米国のエンジニアはAPIに近い部分や高いパフォーマンスが必要なベース箇所を担当し、SDKの基本性能の向上に注力。一方、日本のエンジニアはHTML5やJavaScript、WebKitを使ったWebサービス機能などを担当するとともに、今回サーバ側は主に日本で開発していたので、日本のサーバエンジニアと密接にかかわる部分をカバー。こうした体制によって、距離やコミュニケーションの問題を解消しながら、GREE Platform SDKの開発を成功させることができたのだ。
最後に、高木氏は「今回のSDK開発を通じて考えた」という、今後求められるエンジニア像として、次の3つの条件を挙げた。
- Webとネイティブ、両方の技術を持ったエンジニア
- インフラを意識できるエンジニア
- ビジネス面を意識できるエンジニア
1つ目については、多くの方がすでに実感していることでもあるだろう。
2つ目の「インフラを意識できる」とは、高木氏によれば「世界中でアプリケーションが使われることを意識し、どんな環境のユーザーにもサービスを提供できる」ということだ。例えば、スマートフォン向けアプリ開発なら、そのアプリが使われるであろう国の通信回線状況や端末の普及状況なども考慮したうえで、通信量や対応OSのバージョンなどを含めた最適な実装を考えなければならない。
また、3つ目の「ビジネス面を意識できる」については、高木氏は「ビジネス面でのメリットとリスクも考慮して、使うべき技術を考えられる」ことであると補足。
これら3つをすべてクリアするのは、かなりハードルが高いように思えるが、世界で戦えるエンジニア、そしてグリーが求める「世界で10億人が利用するサービス」を作るエンジニアを目指すなら、いずれは克服しなければならない条件ともいえるだろう。
実際の開発では、それぞれの特性に合わせて力を発揮できるように役割を分担。
