CEDEC 2010「アジャイル開発手法スクラムの基礎とゲーム開発導入事例」
今回はゲームリパブリックさんのアジャイル開発手法のセッションまとめます。
このセッションは、アジャイルとはなんぞや？スクラムはどういうもの？という基本的なところからの説明で非常に分かりやすい内容でした。今までアジャイルの基礎をすっ飛ばしてきた自分には最適です。
なので自分でも詳細を振り返りつつ、レポートしてみます。
スクラムの基礎
参考にした資料
- Agile Game Development with Scrum
- ゲーム開発向けにアレンジが入っており、本家のスクラムとは若干違う手法になっている
アジャイル開発手法とは何か？
- ウォーターフォール型開発とは下図のように、仕様書を決めてから開発を行う手法
- 仕様書通りのものは完成するが、途中でレビューを設けていないので、完成してから「あれ？思ってたものと違う」となることが多かった。
- アジャイル開発とは「繰り返し開発」と呼ばれ、定期的にレビューをして、開発を繰り返す手法
- 特徴としては、レビューを複数回設け、ここで「思ってたものと違う」となった場合は、仕様を変更して開発を繰り返す
アジャイル開発の種類
スクラム系が74％を占める
スクラムの技法
スクラムの流れ
コレらを繰り返し繰り返し、ゲームの完成まで続ける
1.チーム分けと役割
- チームの人数は5〜8人が理想的
- チームの中の一体感・情報伝達のしやすさ
- 人数が多い場合は、チームをいくつか作る
- そのチームの代表同士で、またチームを組む
チーム分け
- これまでのチーム分けは職種ごとに行われる場合が多かったが、スクラムでは特徴(機能)ごとに職種混同のチームを作成する
- チーム単体で成果があげられる
特徴ごとのチーム分け
- 例えば「バトル」チームがあった場合、
- 企画：1人
- デザイナ：3人
- プログラマ：2人
- エフェクト：0.25人
- 0.25というのは、チームの掛け持ちを行う場合もあるため
職制を越えて意見を出し合い、チーム内で仕様を作っていく。
役割：プロダクトオーナー
- チームに所属し、以下の責任を負う
- 黒字にする責任
- ビジョンを提示する責任
- ゲームに入れる要素の決定権
- ゲームの出荷時期の決定権
- あくまで決定権なので"独裁者"ではない
- プロデューサーや、ディレクターがなることが多い
役割：スクラムマスター
- 2〜4のチームに所属し、以下の役割を担当
- 進捗のチェックを行ない、障害を取り除く
- 改善立案をする
- レビュー・振り返りの準備
- コミュニケーションを促進させる
- 何かを決定はしない
- プロジェクトの流れを促進する役割
- 出来れば開発者・プロダクトオーナーと兼任しない方が良い
2.リリース計画
- 目標はプロダクトバックログを作る
内容 重要度 工数(時間) PG 2D MODEL BG VFX 企画 車を20台作る。なぜなら他のゲームが19台だから 800 300 40 70 160 0 20 10 ヘッドライトが点灯して欲しい。何故なら車の接近に気がつかない 1000 20 10 00 0 0 10 0 壊れるように... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ※この表はイメージです。
3.スプリント計画(作業計画)
4.スプリント
- スプリントバックログで決めた内容を消化していく
- 毎日朝会を行ない、進捗確認・バーンダウンチャートの更新を行う
- 期間は2週間〜1ヶ月
- ゲームは2週間(次書こうと思っているQ-Gamesさんの事例では1週間と言われていました)
- 付箋とバーンダウンチャートを使用して進捗を把握する
- 紙が良い。常に関節視野に入る事でメンバーにスケジュールに対して意識を持ってもらう
- スプリント中の追加作業は避けるべき
- チームの責任と自律性を保つ
- 自分たちで作った計画に責任を持たせるため
- 途中で仕様を追加して「コレ入れたからスケジュール伸びても良いよね」となるのを避ける
ゲームでは仕様が変わりやすいので、期間が2週間というのはここから来ている
5.デイリースクラム(朝会)
- 平日の決まった時間(15分前後)に行う
- 各自が以下の報告を行う
- 昨日、なにをしたか
- 今日、なにをするのか
- 問題はあるか
- メンバーがお互いの進捗を確認するのが目的
- 雑談は入れない
6.スプリントレビュー
- 成果物の確認会
- スタッフ全員とプロデューサーとディレクターが参加
- 現状の確認
- 問題点
- より良くするアイデア
7.ふり返り
- 各チームでそれぞれ今回のスプリント内容を振り返り、改善案を出す
- 反省会ではなく、改善する会議
- KPT法が使われる事が多い
- Keep : 今回良かった所。これからも続ける
- Problem : 今回の問題点
- Try : 今後改善するところ
チームメンバーで相談しながら、次やることを決めていく
スクラム導入事例
- 2009年末頃からの新規PJ
- メンバーは20〜30名
- 過去、同じチームで製品を開発したことがある。
- ただし、スクラムは初めて
まずはディレクター(プロダクトオーナー)に賛同してもらう
2.スプリントバックログ
- バーンダウンチャート機能は無かったが、ガントチャート機能で代用
- 紙はさすがに面倒なのと、チームが以前Tracを使っていたので、乗り換えやすかった
- 紙ではないので、常に眼に触れるわけではないので、そこは不便だった
- 現在も悩んでいるところ
おまけ
- 最近、海外のアジャイラーの間で人気のソフト「Pivotal Tracker」
3.スプリント
- 期間が2〜4週間と言う事だったので、ひとまず4週間に設定。
- パブリッシャーへの提出が月1だった
- 今までのチームが1ヶ月単位で動いていた
- ただ、やはり長かった・・・。
- 開発期間1年のプロジェクトだと、8回くらいしかレビューできない
- 8回しか変更できない・・・。
- プロジェクト中、時々仕様変更が入ってしまった
- アジャイルとしてはご法度
次は2週間で検討
4.レビューとふり返りでの工夫
- 最初はとりあえずチームメンバー全員を集めた
- 会議室に全員押し込んだ
- 時間は2時間
- プロダクトオーナーが遊んだ後、メンバーが自由に遊んでみた
結果はあまり良いものではなかった
- 日本人特有、意見を出す人が少ない
- ひとまず、声の大きい人から意見が徴収できた
- メンバー全員で、ゲームの進捗の把握ができた
- 2回目からは、1回30分交代制
- 最低6人(プロダクトオーナーは、全てに参加)
- 発言しないメンバーへの対策
- 付箋に良かった点・改善点を書き、壁に貼っていく方式に
- リラックスできるように、お菓子を常備
結果：
- 付箋だと、たくさんの良い意見と、たくさんの悪い意見を徴収できた
- 30分だと拘束時間も短い
- ただ、人数が少なくなるので"議論"ができなくなった
- レビュー会以外で、議論の場を設けて改善
- 改善点をプロダクトバックログに反映
5.振り返り
- 会社には全く無かった習慣だったので、当時は効果が不鮮明だったため導入を見送った
- ただし、次回からは導入したい
何故なら
- 制作タイムライン改善の機会がなかった
- レビュー会で問題点を洗い出せるが、それからどうしようという行動を議論できなかった
- 行動を議論する場所が"振り返り"のはず
まとめ
スクラムの効果
- メンバーの意見が多くひろえるようになった
- レビュー会の付箋・議論の効果が大きかった
- ビジョンが共有できるようになった
- リソースの破棄が減った
- 朝会の効果
- チームが生き生きしている
- 目で見て感じるくらい
- 周りのチームからも「あのチーム楽しそうだよね」と、よく言われるようになった
- ビジョンが共有できて、迷い無く仕事が出来ている
さらに学びたい方へ
参考資料
特におすすめな資料3点
- Agile Game Development with Scrum(参考資料でも紹介したものです)
- Scrum Guide - JA.pdf
- THE_SCRUM_PRIMER_ja.pdf
- リンク先のDownload Nowボタンで
勉強会
- Game PM勉強会
- 次回開催は2010年10月26日
- すくすくスクラム
- IT系の勉強会。
- 参加費無料
- 2ヶ月に1回程度
※こちらも1点、書き逃しています…。このあたりのどれかだったような…。
