Aiming におけるSCRUM

株式会社 Aiming東京開発グループ ゼネラルマネージャ

小林 俊仁 (@toshi_k)2013年1月18日

於 エンジニアサポート CROSS 2013

About: Aiming

• オンラインゲームに必要な機能が揃った組織

• 2011年5月12日設立

• 250人くらい

About: Aiming 東京開発G

2000 2010 2011

Aiming東京開発G

ONE-UP東京開発G

CommunityEngine

About: Games

Lord of Knights

Blade Chronicle剣と魔法のログレス

About: Games

武神大戦！ Project G

SCRUM 関連イベント協賛

• Agile Samurai Dojo Gatheringhttp://agile-samurai-ja.github.com/dojo-gathering/2012/

• Scrum Alliance Regional Gathering Tokyo 2013http://scrumgatheringtokyo.org/2013/

社員の執筆

SCRUM に対する基本姿勢

SCRUM *推奨*

• ゲームの面白さを仕様書で記述することは難しい• 作ったらクソゲー• ゲーム開発は本質的に、試行錯誤可能な開発プロセスを必要とする

• ボトムアップに SCRUM っぽくなっていった• 細かいやり方は個々のプロジェクトにお任せ

壁足りない

Aiming’sSCRUM Facts

• 朝会: ほぼ全プロジェクトで導入。10:15頃～• 夕会: 半分程度のプロジェクトで導入。18:45頃～

• Scrum Master の配置: 適宜• Impediment List: ホワイトボードや wiki で見える化

• スプリント期間: 1週間が多い• スプリント計画: いろいろ流儀あり• スプリントでのコミットメントと進捗の見える化: アナログ + デジタル両方

• 開発段階や、地理的な分散状況に従って変化ex: プリプロ: タスクボード → プロダクション前半: Pivotal Tracker → 後半: Redmine

• スプリントレビュー: 常に皆でプレイしているので明確にしていない場合も。

• 振り返り: スプリント毎かマイルストーン毎。 人事や勉強会運営も KPT をやる。

• TDD: サーバはちゃんとテストを書く。クライアントはモデルやロジックはテストを書くことにしている。

• CI: ほぼ全プロジェクトが Jenkins を利用• ペアプロ: そこら中でやっている• ソースコード管理: git or gerrit

• プロジェクトの目標や制約条件等の見える化• 一部でインセプションデッキをやっている。トレードオフスライダーだけホワイトボードに書いておくプロジェクトもある

• 見積もりをみんなのものにする• 一部で見積りポーカー。（やらない場合も、見積もりをチームの合意にするプロセスは入れる）

その他

プラクティスコミュニティ• 社内勉強会 (社内)• Web 開発オフ会 (社内)• クライアントオフ会 (社内)• Aiming Study (社外, official)• shinjuku.rb (社外, unofficial)• Agile Game Development with Scrum 読書会 (社外, unofficial)

我々が直面している難しさ

• チームの分散• ex: Client: 東京, Server: 札幌, Debug: 大阪• 要素技術の違い• ex: Client: C#, Server: C++ & Ruby• 文化の違い• web 業界＆ゲーム業界, 前職のチーム, etc..

• Done の定義が曖昧になりがち• ユーザが遊べる系のタスクは、どこまで作りこめば終わりなのか？

• アセット制作パイプラインの長さとスプリントという概念のミスマッチ

• 大規模JSプロジェクト ロードオブナイツの管理手法紹介http://www.slideshare.net/toshi_k/js-20121106

試行錯誤中