こんにちは、ネイティブエンジニアをやっているszです。
今回はよくある技術ネタから趣向を変えて、アプリの開発体制についてご紹介したいと思います。
紹介するのは、現在リリース中のサービスである「グリモア～私立グリモワール魔法学園～ 」と、現在新規開発中のタイトルです。
アプリ開発は「会社の文化」・「なにをつくるのか」・「どういったメンバでつくるのか」等により様々な体制があると思うので、参考になれば幸いです。
では、さっそくグリモアの開発体制について書いていきます。
グリモアプロジェクトの開発体制
公式HP：http://grimoire.applibot.co.jp/preregister/grimoire_new/
公式Twitter：https://twitter.com/Grimoire_Staff
グリモアの特徴は以下のとおりです。
- ソーシャルゲーム開発の中でも、比較的規模の大きめの開発
- クライアント側のベースは別プロジェクトで開発されたもの
- Cocos2d-xでの開発
仕様を決めて実装するまでの縦の体制
- 機能毎に担当のプランナがつき、ディレクタは全体の管理を行う。ディレクタの役割はスケジュール管理に重点を置き、仕様などはプランナの決定権が強い。
- メリットしては機能毎に並走しての開発がやりやすい
- デメリットとしては各機能ごとに仕様やスケジュール管理のクオリティに差が出やすい
- エンジニアも基本的には機能毎に分かれる。たとえば、クエストはAさん、PVPはBさん、といった形をとる。
クライアントエンジニアの横の体制
- ベースコードのリファクタ時から明確な担当分けを実施。
- ベースコードから最低限のリファクタをしたおかげでViewとModelの切り分けが促進された。
- ViewとModelと分けて作業ができるので、開発が止まりづらい体制になった
(※ここでいうView = UIの表示や入力イベントを扱うクラス、Model = 通信やデータを扱うクラス、となります。）
このあたりのアーキテクチャに関しては別途記事をエントリ予定ですので、そこで改めて紹介できればと思います。
上記がリファクタの一例のイメージです。いろいろ整理はしたものの、ベースコードの闇が直せない箇所も多かったです。
とはいえ、0からつくっていたらもっと時間かかっていたと思いますが。(いろいろ事情はありましたが、こういう時は0からつくるのが絶対にオススメです)
現在開発中の新規プロジェクトの開発体制
次に、開発中の新規プロジェクトの開発体制の特徴は以下のとおりです。
- グリモアと比べると少し規模の小さいプロジェクト
- Unityでの開発
- ゲームの詳細は…すみません、まだ秘密ですが比較的ゲーム性の高いアプリです。
仕様を決めて実装するまでの縦の体制
- 機能毎にチーム(ユニット)つくり、仕様を考えていく。
- 最終的にはディレクタが仕様もスケジュールも全て決めて管理する。プランナはディレクタの手が回らない細々したところのサポート。
- メリットとしては情報や決断が一人に集約されるので、混乱やクオリティのばらつきがおきない。
- デメリットとしてはディレクターが業務過多でボトルネックになりやすい。
- グリモアと大きく異なるのは、比較的ゲーム性の高いアプリを開発しているので、一番開発コストがかかるメイン部分とその他機能で管理を分けている。
アプリボットでは企画職だけでなく技術職でも積極的に仕様に対してアイデアを提案する文化があります。
この文化を積極的に活かすために、今回の開発ではそれぞれの機能毎にユニットをつくり、仕様についての詳細を決めていく、という体制を試みています。
クライアントエンジニアの横の体制
- 「アプリ依存コード」と「汎用的に使えるコード」をディレクトリごと分けることで、汎用化を意識した開発を行っている。
新しく入ってきたメンバにも「ここのディレクトリ以下にあるクラスはアプリ依存コードは書かないでくださいね」と言うだけでみんな意識してくれるので、単純ではありますが効果的なやり方だと思っています。(実際に次のプロジェクトで活躍するかは乞うご期待…)
まとめ
今回はアプリボットにおけるアプリの開発体制の一例をご紹介しました。
よりよいアプリを作るためには、「会社の文化」・「なにをつくるのか」・「どういったメンバでつくるのか」等により最適なチームビルドをすることが大切なので、各プロジェクトごとに体制は試行錯誤しています。
