2772
1
0

スクラムでゲーム開発をしていく中で試行錯誤した結果、本当にやりたかったことを実現できそうな気がした話

Published at November 29, 2019 12:26 a.m.
Edited at November 29, 2019 2:22 p.m.

Happy Elementsカカリアスタジオ Advent Calendar 2019の1日目の記事です。
スクラムでゲーム開発をしていく中で試行錯誤した結果、本当にやりたかったことを実現できそうな気がした話を書きたいと思います。

スクラムとは

スクラムはアジャイルソフトウェア開発手法のひとつです。
ウォーターフォール型開発では開発初期に綿密な計画を練る一方で、その計画がしばしば失敗に終わるということが多くの開発現場で起こっていました。
それに対する方法論としてアジャイルがあり、スクラムは開発の価値を最大化するためにアジャイルに対してフレームワークを提供しています。

スクラムでの役割

スクラムには大きくわけて3つの役割があります。

プロダクトオーナー

プロダクトオーナーはステークホルダー(利害関係者)と調整し、何が価値のあるタスクなのか判断します。

スクラムマスター

スクラムマスターはスクラムの進行を行い、開発チームの障害となる問題を取り除きます。

開発チーム

計画をもとに自律的に開発を行う少人数のチームです。

スクラムでの開発の流れ

スクラムは1-4週間のサイクルで開発を進めていきます。
一定のサイクルで開発を行うことでその期間でどのくらいタスクが進むかわかり、計画が立てやすくなります。

1日目

スプリント(それぞれのサイクルのこと)の計画を立てます。
プロダクトオーナーが優先順位を決め、開発チームでその見積もりを行います。
見積もりをもとにそのスプリントで行う内容を決め、開発チームがより細かくタスクに分けていきます。

毎日

デイリースクラム(朝会)を行います。
前の日に行ったこと、その日に行うこと、障害になっていることを共有します。
15分程度で終わることが推奨されています。

最終日

プロダクトオーナーとステークホルダーにスプリントで開発したものをレビューしてもらいます。
レビューの後に振り返りを行い、スクラムの改善を行っていきます。

スクラムでゲーム開発してみて困ったこと

スクラムはうまく取り入れれば、価値を最大限にする開発を行うことが(おそらく)できます。
しかし、実際に行ってみるとうまくいかない部分がたくさん出てきます。
特にスクラムでゲーム開発を行って困ったり、悩んだりしたことを書いていきます。

他職能との連携

エンジニアだけでスクラムを行っている場合、他職能との連携に課題が出ることがあります。
スクラムマスターはスプリント中に割り込みタスクが入らないよう調整するのですが、ゲーム開発では他職能との協力や割り込みなど日常茶飯事で、それを減らそうとすることでミスコミュニケーションが発生してしまうかもしれません。

なので、職能をまたいだ横断チームを作るのが良いと思うのですが、人数が多くなってしまったり、複数のチームに所属する人が多かったりして効率が下がっていきます。
ゲーム開発は多くの専門性の高い職能が連携していかなければならないため、スクラムの標準的なチームを構成することが極めて困難になっていそうです。

スプリント計画やスプリントレビューの負担

ゲーム開発で行うべきことは多岐に渡っており、プロダクトオーナーが圧倒的にいそがしくなってしまいます。
また、プロダクトオーナーやスクラムマスターが実際に開発を行うことも多く、スプリント計画やスプリントレビューの負担が大きくなっていきます。
割り込みや仕様変更も多いので、計画に時間をかけるよりその場その場で価値を判断していく方が効率的に動けそうです。
基盤部分の開発も多いのでレビューで特に見せるものがないということも頻発しています。

デイリースクラムで十分に相談できない

デイリースクラムを15分に収めると、一人2-3分程度で報告しなければならなくなります。
ゲーム開発は専門性の高い開発が多いので、共有・相談しておきたいことが毎日のように出てきます。(3Dとか音声とか、UIとかDockerとかとにかくいろいろ)
短いほうが良いことはわかるのですが、認識を合わせるにはあまりにも短すぎます。

こだわりが出しにくくなる

価値を優先してチーム全体でそれに取り組んでいくと、専門性が高くこだわりが強いメンバーが力を発揮しにくくなる場合があります。
「熱狂的に愛されるコンテンツ」を作っていくためには、こだわりが非常に重要なポイントになるので、そこが満たされないのは各メンバーにとっても会社にとってもデメリットになりそうです。
とは言え、価値の最大化は非常に重要なポイントでもあるのでバランスの取れた進め方を行う必要があります。

本当にスクラムでやりたかったこと

Happy Elementsカカリアスタジオでは、メンバーの当事者意識や熱意が「熱狂的に愛されるコンテンツ」をつくるために重要なものだと考えています。
スクラムをそのまま運用するだけでは、メンバーの熱意やこだわりを活かしたゲーム開発ができないと感じました。
「熱狂的に愛されるコンテンツ」をつくるための開発体制をスクラムの要素を取り込みながら調整していきました。

チーム内でナンバー1の分野をつくる

開発メンバーそれぞれが熱意を持った分野を担当し、それぞれの分野を責任を持って進めていく体制を取りました。
これにより、各メンバーのこだわりをゲームに反映することができるようになったと感じています。
「熱狂的に愛されるコンテンツ」をつくるための体制としては、3DやUI、アーキテクチャ設計やDockerへの挑戦など、思い入れのある分野に特化していくことが重要です。
思い入れのある分野にコミットすることでこだわりが生まれ、その結果ユーザーに愛してもらえるようになるのではないかと考えています。

職能ごとの朝会

各メンバーの専門性が上がっていくにつれ、情報共有が重要になってきます。
職能内の情報共有を円滑に行うため、エンジニアは毎日30分の朝会を行っています。
この中でそれぞれの専門分野や担当しているタスクについて相談し、認識をすり合わせていっています。
朝会の中で、知見の共有やコードの書き方のすり合わせ、前の日に出てきた疑問点相談などうまくできているのかなと思っています。

職能横断の定例

職能内での情報共有では解決できない問題に対応するため、週のはじめに職能横断の定例を行うことにしました。
先週やったこと・今週やること・他セクションとの相談などを事前に記入していただき、定例中に相談したり、その後ミーティングを開いたりしています。
定期的に相談できる場を設けることで、連携不足による開発速度の低下を防ぐことができていると思います。

随時行われる機能ごとの定例

週1回程度で、大機能ごとの定例が行われています。
機能開発の中で出てきた問題点などを相談していきます。

振り返り

エンジニアは週の最後に振り返りを行っています。
KPTを行っていますが、Tryについてはエンジニアチームの問題として解決していきます。
毎週少しずつですが改善を続けていて、業務の効率化など進めて行けていると思っています。

まとめ

スクラムでゲーム開発をしようと試行錯誤し、「熱狂的に愛されるコンテンツ」をつくるための開発体制に向けて調整していきました。
結果的にではありますが、各メンバーが自律的に、こだわりを持って開発を行っていく体制ができてきていると思います。
属人性が高まっていてリスクが上がっていたり、こだわりすぎてスケジュールが厳しくなるなど懸念はありますが、これらも少しずつ解消できるよう取り組んでいければと思っています。

いらすとやさんのイラストを使わせていただきました。