読者です 読者をやめる 読者になる 読者になる

Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

アカツキを支える大規模ゲーム開発プロセス

この記事は Akatsuki Advent Calendar 2016 の6日目です。

はじめに

こんにちは、アカツキでチーム開発マネージメントをしているゆのん(id:yunon_phys)です。 アカツキではアジャイル開発手法の一つであるスクラムを取り入れて、ソーシャルゲームの開発を小さなチームで取り組んできました。近年では、高品質かつ多くの機能を持ったゲームを短いスパンでリリースし続けることが市場として求められてきており、開発が年々大規模化してきています。このため、ユーザー価値を最大化しつつより開発がスケールするように、小規模チームから大規模チーム用に開発プロセスを拡張する必要性が出てきました。そこでこの記事では、アカツキの大規模チーム開発プロセスの取り組みを紹介します。

f:id:yunon_phys:20161205214347j:plain

大規模開発における課題

開発規模が大きくなると、小さな規模で発生しなかった問題がいくつか出てきます。様々な問題のうち、根本原因はコミュニケーションによるものだと仮定し、以下で課題整理をしていきます。

課題1. コミュニケーションコスト増大

まず何よりもコミュニケーションコストが単純に増大するという問題があります。n人がコミュニケーションを十分にとるためには、n(n-1)のコミュニケーションチャネル、つまりn2のオーダーのコミュニケーションチャネルが必要になり、コミュニケーションコストが爆増します。しかしさすがにこの課題を放置してコミュニケーションを個々に任せてやっていると開発が全く進まなくなったり、情報共有の密度が薄まったりするので、情報共有の仕組みを工夫しなければなりません。

課題2. 大人数参加型会議の効率の悪さ

課題1を解決するため、良くある手としては、一斉に情報共有する場として大人数参加型の会議を設置することです。しかし、大人数参加型会議で全員の意見を聞くわけにはいかなかくなるので、どうしても発言するメンバーに偏りが出てしまいます。そうなると会議への当事者意識も薄いメンバーが増えていき、結果として、情報共有に濃淡がうまれてしまいます。(ここでの問題は、会議への当事者意識を持てないメンバーではなく、そういう形式を取らざるをえない状態になっていることです。)

課題3. 開発時間の確保 -> 残業

全員参加型の会議を設置してもまだ情報共有が足りないので、じゃあそれを補うように・・・と、さらに会議を設置するようになります。そうすると、貴重な開発時間がどんどん奪われて開発スピードが低下するので、それを補うように残業が増え、どんどん開発の余裕が無くなっていきます。

課題4. コミュニケーションハブがSPOFに

じゃあ会議が増えないでもなんとかなるように・・・と、一部のメンバーにコミュニケーションハブ役になってもらって情報を集約させて、その人を介してコミュニケーションを取るようにしよう、という手を取る場合があります。しかしこれの問題は、ハブ役は常に情報収集・拡散をするため、ハブ役が忙しくなりすぎたり、ハブ役が不在のときに混乱が生まれたりする、ということにあります。ハブ役を設置する場合は、ハブ役が忙しくなりすぎないように、一極集中になりすぎない工夫をしなければならず、ぐぬぬ・・・となります。

f:id:yunon_phys:20161205213702j:plain

アカツキで実施した解決方法

大規模開発において4つの課題をあげましたが、本質的には課題1を何とかすれば全ての問題は解決します。しかし、やりたいことのために人数を減らすわけにもいかないので、アカツキでは、スクラムをベースに組織面の改善と会議体の工夫で解決をはかりました。

職能横断型チームを複数結成

ゲーム開発はクライアントエンジニア、サーバーエンジニア、プランナー、デザイナー、QA、デバッガーなど、多くの職種と密に連携する必要があります。しかし、これらのメンバーを全て1つのチームにするとどうしても人数が多くなりすぎる(課題1)という問題が出てしまうので、エンジニアチーム、プランナーチームのように各職種のコンポーネントチームを作るのが良くある対策かと思います。しかし、このチーム作りの問題は、大きな問題があります。それは、ある機能を開発しようとした際に、仕様共有会のメンバー選定、開発担当選定などの職種間の調整役が必要になり、上記の課題4と同じ状態になってしまうのです。さらに、その調整役がいないと職種間の相談がし辛い状態になってしまい、調整役がどんどん忙しくなり(以下略)

そこで、アカツキではそういった調整役を立てるのではなく、チームで1つの機能の開発を完結出来るように職能横断型チーム(フィーチャーチーム)を複数結成しました。これにより、誰が何をやっている状態かチーム内で完結出来るようになったので、余分なコミュニケーションハブ役を立てる必要が無くなりました。

ただフィーチャーチームのデメリットとしては、職種内の横のつながりのコミュニケーションが薄れ、スキル向上が図りにくくなってしまう危険性があることです。そこで、チーム単位ではなく職種単位で島を作り、席配置をすることで、スペシャリストのスキルを伝搬しやすくしました。また、定期的な職種内の情報共有会を促し、そこで出てきた課題をバックログリファインメントに持ち込み、非機能や開発・運用効率化施策も開発に組み込めるようにプロセスを工夫しました。

スプリントをチーム間で同期

開発サイクルがチーム毎に異なってしまうと、プロダクトオーナー(PO)がチーム毎にプロダクトバックログをチューニングしなければならないため非現実的だと考えました。また、全メンバーに共有すべきことが常にある一方で、全メンバーが集まるのはなかなか高コストなので、出来る限り全メンバーが集まる機会を少なくしたいという思いがありました。

そこで、スプリントをチーム間で同期することで、これらの問題を解消しました。具体的には、スクラムの各セレモニーを以下のようにしました。

スプリントプランニング

全メンバーを招集してスプリントプランニングを実施するようにしました。スプリントプランニングは2パートあります。

まず、情報共有に数分使います。更に、チームにアサインされていない機能がある場合は、ここでどのチームが実施するかその場で決めます。

次に、全体共有を終えたら、チーム毎に集まります。後は通常通りタスク割り振り、見積りをチーム内で実施すればOKです。

スプリントレビュー

他のチームが何をやったかをわかるように、チームメンバー全員が同じ時間、同じ場所で行うようにしました。大規模開発とはやや違うコンテキストですが、プロダクトに関わるメンバーに全員に集まってもらい、そのスプリントのチームの成果を見えるようにもしていました。

スプリントレトロスペクティブ

まずチーム毎に通常通り振り返りを実施します。次に、タイムボックスの最後の15分を使って全チームメンバーが集まり、振り返り内容を共有するようにしました。これにより、他のチームでどういう問題が起きているか、共通に解決出来る問題が無いかをチームメンバー全員がわかるようにしました。

バックログリファインメント

バックログリファインメントだけ、やや込み入った話になるのでメンバーを厳選しました。具体的には、PO、各職種の代表とチーム代表が集まり、非機能や開発・運用効率化施策を開発に組み込めるように話す場としました。また、プロダクト全体に関わる課題の共有や、不具合の修正担当チーム決めなども行うようにしました。

その他

他にも、POは忙しくなりすぎるのでプロダクトバックログの優先度だけジャッジする、チームメンバーは基本固定化する(チーム間を行き来しない)など、取り入れました。

f:id:yunon_phys:20161205214814j:plain

大規模開発プロセスを取り入れてどうだった?

じゃあ、実際に上記の開発プロセスを入れてどうだったのか?というのが気になるところだと思います。

最初は職能横断型チームに対してやはり戸惑いの声が多く、XXXの機能は他チームのAさんがいないと出来ない、YYYの不具合修正に他チームのBさんの力が必要・・・といった不安の声が多くありました。しかし、1ヶ月も続けると、ちょっと手が空いた人が自発的に他の人のサポートに入る、チームランチなどチーム活性化施策を自分たちで行う、カンバンをチームで独自に改良する、など目に見えてチームの結束力が高まり、チーム力が増していきました。

最終的には、上記の開発プロセスを導入した私が出る幕が無くなり、ゲーム開発プロセスのマネージャー不在の組織を実現出来ました。

最後に

実は先日認定LeSS実践者研修に参加した のですが、ほぼほぼLeSSと同じやり方でびっくりしました。もちろん、完全なLeSSではないですし、まだ改良の余地がありますが、後はチームメンバーが自分たちの力でなんとかやっていくことでしょう。

今後もユーザー価値最大化のために、アカツキでは最高のチーム作りをしていきます!