卒業制作でのチームゲーム開発におけるアジャイル手法の段階的適用に関する事例
Download as PPTX, PDF1 like1,852 views
卒業制作でのチームゲーム開発におけるアジャイル手法の段階的適用に関する事例
- 5. 背景 • 2016年度の卒業制作 • メンバー：６名 • GD: 3名 • PG: 2名 • Art: 1名 内、日本ゲーム大賞 アマチュア部門 大賞受賞チームメンバー４名 • 指導教官 • 教員１年目 • 認定スクラムプロフェッショナル、認定スクラムマスター
- 6. 指導方針 • 「普通の」ゲーム制作を行う • なるべく実際の環境で使われているものと同じ体制 • アジャイルな手法を導入する • 学生に指導されていない方法を実践してもらう • 面識はなかったため、徐々にプラクティスを追加
- 7. スケジュール 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 中間発表会 卒展 提出＆ 審査会 就活注力期間
- 8. 6月 7月 8月 9月 10月 11月 12月 1月 2月
- 9. スケジュール 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 中間発表会 卒展 提出＆ 審査会 就活注力期間 画 面 に 表 示 基 本 動 作 協 力 型 か ら 対 戦 型 に 変 更 分 岐 に よ る ゲ ー ム 性 向 上 見 や す さ 向 上 演 出 強 化 テ ス ト プ レ イ に よ る 改 善 ブ ラ ッ シ ュ ア ッ プ 最 終 調 整 ゲームシステムの検証
- 10. 開発体制 • 環境 • メイン画面・観戦モニタ：Unity • メンバーが親しんだ環境 • フロントエンド：enchant.js • とっつきやすさから • サーバー：node.js • ローカルWi-Fi環境を構築(展示時にトラブルが生じにくい環境の選択) • 開発ツール • GitHub Education • メイン画面:https://github.com/imagirelab/Graduation_Game • フロントエンド: https://github.com/imagirelab/Tiny_PhoneServer • サーバー https://github.com/imagirelab/websocket_prot • Google Drive • Slack • Unity Cloud Build の結果を通知 • HuBot：有効には使われず… • LINE: 学生間のコミュニケーション • wrecker: Unity の WebGL ビルドを行おうとしたが、体制を整えられず • Trello • 通知を見て進捗を確認し、指導を行った
- 12. プラクティス • タイムボックスの設定 • 講義の周期にあわせ、１週間スプリントに設定 • スプリントレビュー • 完了していないカードの項目はレビューしないことを徹底 • ふりかえり • 主としてKPT（うまく考えができないときに”タイムライン”などを実施） • 最初は教官がファシリテート。のちに学生だけで実施 • なぜかスプリントレビュー前に開催 • 1 on 1 • リズムを作り切れず • 朝会 • 就活で集まりが悪いため強制しなかったら、そのまま未実施に • バーンダウンチャート • 朝会がないために管理できず • 提出前の再実施は機能 • スプリントバックログ • プロダクトバックログの粒度を細かくすることで未採用 バーンダウンチャート
- 13. アジリティを高めるための指導 • すぐに確認できるものを優先的に作るよう指導 • 意識付け：「自分たちを週刊漫画家と思ってくださ い．評価が悪いとすぐに打ち切りになります．」 • 一月で遊べる状態に • ゲームが単調になることが判明し、2か月間でゲームシス テムを大幅に変更 • アセットの作りこみを後に回すことで手戻りを削減 6月 7月 9月
- 14. 役割の割当て • 最初の段階では導入せず • 面識が浅いため様子見 • テコ入れとして導入 • 問題点 • 仕様の策定に関して、多くの意見が出るが、まとまらない • やり方がおざなりになる（セレモニーの時間がルーズに） • テコ入れ • スクラムに関する講義 • 役割りを明確にしてもらう • プロダクトオーナー • プログラマ（最も活動的なメンバー）に決定 • プログラマの比率が少ないのであまりよくはないが、 チームの決定として採用
- 15. 終盤の対応 • 中だるみ • スプリントレビューを終えてから 次のタイムボックスの項目を検討 • 次のタイムボックスを気にし、 長期的な視点を見ない • 提出までの３か月を再設計 • 50％のプロジェクトバッファを見積もり、 2か月で終わる内容として再構築 • 卒業制作展示の作業も含めて検討してもらう • バーンダウンチャートを導入 • 追加項目もトレース • 結果的にバッファはほとんど消費せず • 逆に、やることがなくなると勘違い • 3月まで続く（期限が来た際に打ち切る） として項目を追加してもらう 11月 12月 1月 中間発表会 提出＆ 審査会 バックログ再構築 バーンダウン導入 プロジェクト バッファと想定
- 16. スケジュール 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 中間発表会 卒展 提出＆ 審査会 就活注力期間 画 面 に 表 示 基 本 動 作 協 力 型 か ら 対 戦 型 に 変 更 分 岐 に よ る ゲ ー ム 性 向 上 見 や す さ 向 上 演 出 強 化 テ ス ト プ レ イ に よ る 改 善 ブ ラ ッ シ ュ ア ッ プ 最 終 調 整 ゲームシステムの検証 Scrum解説 役割の割当て バックログ再構築 バーンダウン導入 バックログ再追加
- 17. アンケート いままでのゲーム制作の進め方と違った点はどこですか？ 作業を見える化 全員の作業を全員が把握できる仕組みが良かったです Slackなどのツールを使った 連絡のやり取り 今まで週一で集まってしか話をしていなかったが、家にいるときでもよく連絡を取るようになった SourceTreeを使った プロジェクトの管理 今まで、USBで渡していたが劇的に管理が楽になった 一週間の計画を毎週具体的に 考えて取り組んだ 作業の細分化ができてわかりやすかった。 振り返りを導入した 一週間のタイムボックスを決めて、必ず全員で個人や全員の問題点を挙げるので改善が早くできる 作業の確認を全員で行った 進捗が全員把握できて、作業の管理がだいぶ楽になった 毎週目標を作った 〇〇ができるまでやる。ではなく、毎週作業をどこまでやったか報告するので、価値の高いものが出来上が る。 気を付けるではなく問題を起 こさないシステム(ルール)を作 る ○○に失敗した。じゃあ気を付けよう。だけでは解決しないので、決まり事を作り改善した。 プロジェクト管理 各々の状況が詳細までわかるようになってたので良かったです Slackやterlloを使った連絡 連絡を取り合う他にも作業状況がすぐにわかっていました。私達は少々足りていないところもありましたが 以前と比べて密な連絡が取れたと思えます。 時間の見積もり 時間の見積もりを立てて優先順位や作業のめどを立てれるところが作業のしやすさにつながりました。 Trello 作業内容をカードにして、それをどんどん撃破していくのが楽しかった。 KPT会議 毎週、各々が思っていることを共有できてよかった。 時間見積もり 実際は見積もりよりも時間を要することが多かった。 「こうした方が良いのではないか」等の意見をください 1on1の数を増やすと良いのではないでしょうか？ タスク管理について、隔日でいいので講義をしたらよくなりそうと思いました。 チームメンバーへのアンケート
- 18. アンケート結果 • 導入した手法へのネガティブな意見は見られな かった • チームの開発が改善されたと考えることができる • 改善点に関して、追加の要望を提案される • 改善のためにプロセスに投資する余地があると考え らえる
- 19. まとめ • 卒業制作にアジャイルな手法を導入 • 朝会などいくつかのプラクティスはうまく導入できず • プロセスは改善 • まだよくする余地あり • 今後の課題 • うまくいかなかった手法の改善 • 多能工化の実現 • 学科内で、「GD」、「PG」、「Art」に分野が分けられている • そもそもゲーム開発で折り合うのか検証は必要 • チーム固有の問題と卒業制作(学生)での問題を分離 • 事例を積み重ねる • 個人の制作・研究の手法構築