技術の共通・共有・標準・基盤化組織「A.R.T.」のビジョン

アプリボットでは横軸で技術を共有、共通化、標準化、基盤化、するための 「A.R.T.(Applibot Root Technologies)」 という組織があります。

本記事ではこの組織についてご紹介します。

なぜ横軸の開発チームが必要か

同じ機能を別のところで複数回コストをかけてつくる、という無駄をなくしたい
ノウハウの共有やクオリティの担保
高難易度の技術的課題をプロジェクトの枠を超えて解決したい
こういうところが機能している組織って魅力的

A.R.T.に所属するメンバはこれを実現するために、機能開発だけではなく、プロジェクトへの導入やOSS、SGE GitLab、SGE Qiita:Team、技術ブログ(てっくぼっと)への発信を積極的にやろう、という方針の組織です。

※現時点でOSSはやれていません…。

※SGE GitLabとSGE Qiita:Team：サイバーエージェントグループのゲーム事業を行っている各社は、

情報交換を行うためにGitLabとQitta:Teamで情報を共有しています。

当初やっていたこと

サーバーサイド

Java基盤のバージョンアップ
静的解析の共通化(SonarQube)
リリース前プロジェクトの支援(コードレビュー等)
gRPCの検証

-> 例：Java(Kotlin)におけるgRPCライブラリの選定と実装および速度比較検証

クライアントサイド(Unity)

新規プロジェクトで利用する機能の共通化、ライブラリ化(課金、SNS連携、動画広告、等のゲームに依存しない箇所)
リリース前プロジェクトの支援(広告対応、課金対応、海外対応、等のゲーム側の対応)
-> 例：課金実装 UnityIAP – 実装事例 –

共通

Qiita:Teamの検証
Wrikeの検証

当初の方針

先にやったことを書きましたが、最初の方針としてはいきなり「基盤システムつくります、みんな使ってね」ではなく今後の方針を模索するべくプロジェクトに寄り添う、というものでした。

アプリボットのサーバーサイドは既に開発のベースとなる基盤システムが存在していて、各ゲームタイトルではその基盤をもとに開発が行われています。これらのメンテナンスをしつつ、より良い開発環境にするために静的解析等を試してみました。

クライアントサイドは基盤と呼べるようなものはなく、Unityでの開発経験を積み重ねている状況だったので、まずは各プロジェクトでつくったものを可視化するために、有用なものをライブラリ化(共通化)しよう、という方針にしました。

こういった横軸組織で大事なのは、共通部分を開発するメンバと、プロダクト開発を行っているメンバとの認識のすり合わせだと思っています。

A.R.T.がプロジェクトに入って導入するところまで積極的にやる姿勢なのは、ただ使って欲しいからではなく、お互いが信頼しあっている状態をつくることと、共通部分を開発するメンバがプロダクト開発を行うメンバの気持ちを忘れないためでもあります。

基本的には使われるものをつくる人は使う人の気持がわかってないと良いものがつくれないと考えています。ユーザーファーストという言葉を広義に捉えてもらえれば理解しやすいのかなと思います。

今やるべきこと

設立が決まってから小さく進めてきましたが、最近大きく決めたミッションがあります。

それは

サーバーサイドKotlinへの挑戦。基盤化。
クライアント(Unity)基盤への着手

です。

この2点の詳細については後述しますが、A.R.T.を設立し、地道にやるべきことに向き合う組織ができたからこそ出せた答えだったと思います。

また正直なところ、小さな開発しかなく、プロジェクト支援的なタスクが多くなると、成果や組織の意義もわかりづらくなるなと思っていたタイミングだったので、この方向に舵を切れたことは良かったです。

サーバーサイドKotlinへの挑戦

Androidの公式言語になった頃からアプリボットのJava基盤との相性の良さもあり、挑戦したいという声があがっていました。

一度つくった基盤を捨てるのかという議論ももちろんあるのですが、今挑戦しないとずっと挑戦しない組織になってしまう、というデメリットの方が大きいと考えました。

詳細は「なぜサーバーサイドKotlinを導入するのか？」にもまとめてあるのでそちらも読んでみてください。

ちなみに、アプリボットのサーバーサイドは前述したとおり、基盤をつくってその上で開発を行うことが浸透しています。

そのため、基盤って使われるんだっけ？という不安は特になく、あとはやりきるだけです。

クライアント(Unity)基盤への着手

サーバーサイドに比べて、クライアントサイドの基盤づくりは慎重です。

私自身もどちらかといえば基盤の上でものをつくるよりも、知見やノウハウの共有に留め、各プロジェクトが責任を持って開発を行うスタイルが好きだったりします。

では何故着手するのかというと、以下のような理由が挙がります。

プロジェクトの数も増えてきたので横での連携を強める必要性を感じていた
開発が長期化する中で、効率化はいろいろな角度から重要性を増すようになった
各プロジェクトのエンジニアと話をしていく中で、ゲームに依存しないシステム面のノウハウ共有は多くの人が価値が高いと感じている
サーバーサイドが基盤化前提で進められていることもあり、この分野はセットで共通化しやすい
スマホゲームでサーバーとクライアントの結合まわりはかなり重要
私自身が今までのプロジェクトでサーバーとのやりとりする箇所のベース設計をやっているのでノウハウも貯まっている
サーバーで基盤が浸透したのも主導者(エンジニアのトップレベル)がぐいぐいと引っ張ることができたから
クライアントがやれてないのは誰も引っ張らないから、じゃあA.R.T.でやるか

ということで、流れから察することができる通り、まずは通信部分からやります。

基盤というよりスタンダードな機能郡をつくって使いまわせるようにする、という方がイメージが近いかもしれませんが。

サーバー x クライアント

ということで、当面はスマートフォンゲーム開発の心臓部と言っても過言ではない、サーバーとクライアントの連携部分に着手していきます。

例えば過去にやってよかったAPIドキュメントからのコードの自動生成はより良いものを検証し、標準化していきます。

こういった内容はサーバーとクライアントの距離感がより近いチーム・組織だからこそ進めやすいことだと思います。

元々アプリボットのサーバーサイドの連携は厚く、強みだと思っていたので、そこにクライアントサイドも加わることで相乗効果を出していきたいです。

最後に

こんな感じで個人的にも組織的にもここに書いたことに力を入れていきます。

最初の方で方針に書いたとおり、なるべくオープンに情報を公開していこうと思っているので、今後のてっくぼっと！の記事にもご期待下さい。