講演者
田中 宏幸
序盤は講演内容の書き起こし、最後と※部分に個人的な見解を記載しています！
■2009年 アジャイル開発との出会い
・ゲームリパブリック時代
リーダーがredmineでガントチャートベースのスケジュールを作成
↓
ゲームは作ってみないと分からないので、頻繁に再計画をしtづける必要があるがガントチャートの修正は結構大変
↓
リーダーは常に忙しいのでスケジュール修正が遅れたり、更新がされなくなり誰もスケジュールがわからなくなる
↓
結果、期間と仕様のトレードオフができなくなる
頻繁にデスマーチが発生！
やりたくないランキング
1位 徹夜
2位 休日出社
3位 残業
それだけ頑張ってできたものを誰も称賛してくれないのが辛かった
■AAAゲーム開発を成功させる方法って何だろう・・・？
CEDEC2009 Scrum最新技術事例「Star Wars The Old Republic」での大容量ゲーム開発
・アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
これがデスマーチに打ち勝つ方法だと思った！
■2010年スクラムを始めました
まずは2人で始めて見た
講演だと簡単そうだったのにむっちゃ難しい
↓
勉強！
↓
認定スクラムマスター、PMPを取得
↓
ディレクターを説得
Redmineでスプリントバックログ
→付箋を使ったほうがいい
バーダウンチャートの代わりにロードマップ
バーンダウンチャートの代わりにロードマップ
ウォーターフォール！？
全然スクラムじゃない！
2010年6月 ゲーム開発者向けにスクラムを解説した本が発売
Agile Game Development with Scrum
→すごくわかりやすい！
CEDECで講演！
やまもといちろう氏にロックオンされる
↓
そんなこと言ってもいいゲーム作れてないじゃん
↓
タイタンがうまくいかなかったからアジャイルを始めたんだよ！
↓
ゲームリパブリック倒産
■2011～2012年 スクラム再スタート
起業、トップダウンでスクラムを開始
CEDEC2012 アジャイル開発はスクラムだけじゃない！
・プロダクトバックログ
・リリースバックログ
・スプリントプランニング
・タスクボード
・バーンダウンチャート
・スプリントレビュー
・ふりかえり
・プログマティックペルソナ
いろいろ改善されたが混沌な部分も多い
・2012年ごろのスクラム
洗い出しができている
バックログは減らせている
仕様の追加や変更が積み重なりプロジェクト後半にバックログが溢れ、全体スケジュールが間に合わない
リソース管理は看板を使用しているが、リソース数が多いため、付箋だと手に余る状態
■2013年～2014年 デジタル管理
会社が大きくなりプロジェクトも大きくなり付箋まみれに
付箋は計画を立て借り見えるかには便利だが、長期間の運用で問題になった
特にコンシューマゲームは開発年数が数年になるため、付箋の数が数千枚となったり、付箋が破損したりなくなったりした。
アナログだとベロシティやバーンダウンチャート数えたりするのが大変
社外のステークスホルダーに説明する際にも困った
・Hansoftによる改善
タスクの日数もベロシティもバーンダウンも一瞬で表示される
プロダクトバックログの総日数がN日だから多少バックログがふえてもマイルストーンに間に合う、など直近のスプリントだけでなく長期スケジュールも確認できる
様々な情報をPDF化してステークスホルダーに提出できる
やっぱり検索は便利
計画は付箋。運用、報告はHansoft。
スクラムにも慣れ、安定した状態に
■2015年～2016年 停滞とトラブル
会社を設立し本格的にスクラムを始めてから約5年
停滞した空気が流れると同時にトラブルも出始めた
・その１ 振り返りの廃止
振り返りはKPTを開催
結構強めの発言をするプログラマーがメンバーにおり～が悪い適菜空気を出すことがあった
そのためPOから振り返りの開催をしばらく辞めたいと相談された
その後再開の機会を度々打診はしたが、結局再開せずにプロジェクトが終了し、その後も振り返りは行えず
・その２ デイリースクラムを1週間単位に
特に問題なし
■2017年～2018年
タスクもスプリント内に消化できてるしスケジュールもトラッキングできてる
タスクは消化できているが「品質不足」「機能が足りない」「思っていたものと違う」などでタスクが度々追加される
一向に減らないプロダクトバックログ遅延していくスケジュール
■2019年 転機
・その1 スクラムマスターを採用
二人で2プロジェクトを見る体制
二人体制の良さ
-新スクラムマスターがSMとしてチームに入り、私は新しいSMやPOを支援
スプリントプランニング終了時期等で二人で話し合い、次の施策などを決める
-自分だけでは気づかないことにもう一人が気付く
-得意不得意を分担できる
-ゆとりが出来て、いろいろなことに気が回せる
二人体制最高！
・その2 アジャイルコーチをお願いする
松元健氏
最近マネジメントがうまくいっていないように思うのですが、何が下人かわかりますか？
↓
うまくいくとはどういう状態のこと？
↓
うまくいっているマネジメントとは何か、その場ではこたえられず
新体制になってから数カ月。スプリントプランニング中にこんな話を耳にする
デザイナー
レビュー会を開催してほしいんですけど
ディレクター
タスク単位でなく、完成した機能について話がしたいんだよね
SM
わかりました。どんな感じでやりましょうか？
あれ？これって・・
今チームに足りてない要素に開発メンバーは気づいている
・スプリントが1週間になった影響
スプリントを1週間にする
↓
毎週スプリントプランニングとスプリントレビューは大変なのでレビューがおざなりになる
↓
タスクやスケジュールについての会話中心になる
ゲームについての会話がなくてもタスクが消化できれば開発は進みスケジュールも守れる
それの何が悪いのか？
スクラムチームは改善する問題を正しく選んでいますか？
もうからないプロダクトを良い方法論、良いチームで作ってももうからないことには変わりない
・うまくたくさん作ることが最重要なわけではない
成果のほうが重要
↓
ゴミの高速生産は意味がない
↓
もっとスクラムチーム全体が成果にフォーカスする必要性
↓
気が付いたらスクラムのスケジュールに関するプラクティスしかせず成果について抜けている
スケジュールに間に合わせるためにスクラムを始めた？→No
山本一郎をぎゃふんといわせるため？→20％ 基本No
面白いゲームを作ることそのためのスクラム
そして、振り返りが無くなったのでこんな単純なことに気づくのにずいぶん時間が掛かった
チームメンバーは成果が抜けていることを経験で知っていた
■2020年 今、そしてこれから
というのがマネジメントがうまくいっている状態って何？という問いについての答えなのですが
↓
では、そのために田中さんはまず何をしますか？（スパルタ）
・成果を出すために再起動
まずはスプリントレビューをしっかりやる
スプリントを4週にし、価値単位でバックログを作成する（INVESTを意識）
4週で作った価値をしっかり画面で確認し、フィードバックを得る
次のスプリントやバックログに上記を活かす
デイリースクラムは一旦1週間単位で行う
面白いゲームを作るために対話を
振り返りの再導入も考えていきたい
飽きない、楽しいふりかえり←重要！！！
■まとめ 10年アジャイルをするとどうなるのか
・結果1 何のためにスクラムをしているのか忘れた
1日0.028％忘れた計算
・結果2 結果的にスクラムのすごさを知る
アジャイルソフトウェア開発宣言に戻る
スクラムの定義
複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである
スクラムでの改善イベント
問題設定に対する改善
スプリントレビュー
開発力やチーム力に対する改善
ふりかえり
メンバーの経験値を価値に活かせない
・結果3 チームメンバーにスクラムで大切なことを教えてもらう
■おまけ アジャイルコーチってどうなの？
問題点や改善方法といったことに対して気づくきっかけが得られる
ただし気づきを得るにはいくつか必要条件がある
目標が定まっていること
何に対しての気づきが欲しいのか提示が必要
聞く姿勢があること
腹落ちしない限り、気づきに繋がらない
考えるゆとりがあること
ゆっくり考える時間がないと気づけない
アジャイルコーチ活用術 吉羽龍太郎氏のスライドがあるのでそちらを参照
■最後に
やまもといちろうさんへ
アジャイル開発10年やってみたけどゲーム開発との相性そんなに悪くないよ
■Q&A
Q.仕様書の精度はどこまでの精度のものを？
A.無茶苦茶作ります。
包括的なドキュメントよりも動くソフトウェアを
とは言いますが包括的なドキュメントに価値があるのは当たり前。
相対的に動くソフトウエアのほうに価値を持たせるということだけです。
Q.全体スケジュールとしての終わりはどのように設定しているか？
A.アジャイルは終わりの定義がない。運営に近い。
バックログを眺めつつ、価値のある物から作っていく。
時間がきて残っていたらそれを切り捨てる
Q.発言力のあるネガティブな発言をする人にはどうやって対処したか？
A.対処できずに退職されました
■感想
個人的に交流があるのですでに聞いていた話もいくつかありました。
田中さんは物腰柔らかでお話も面白い素晴らしい方です。
正直ひどい目にあってきていると思うのですが、それなのにあのようにふるまえるのは本当にすごいと思います。
この講演を聞いて自分の会社だからできるんだろうって、考えると思うのですがイリンクスさんはデベロッパーです。
パブリッシャーではない。
デベロッパーで顧客に納得してもらってアジャイルを行うって本当に大変ですよ。
講演を聞いて思ったのは銀の弾丸なんてなくて、アジャイルを採用することで楽になんかならない
アジャイルをやるために勉強しないといけないし、それを維持するためには労力もいる
でも、成果物はよくなる。ということなんでしょうね。
逆に言うと成果物を上げるところをちゃんと担保できるのならアジャイルでなくてもいいのかもしれませんが。
基本私はゲーム制作でアジャイルは難しいと思っています。
確かに向いているとは思いますが、それはチームメンバーのほとんどがアジャイルについての知識がある場合。
全く興味を持ってくれない人たちが一定数いると機能しにくい。
労力だけかかって効果が出ない状態になります。
でもまあデザイナーさんとかにちゃんと理解してほしいというのは、正直酷かなと思っている。
あと上司や、クラインアントの要望に応えにくいものが多い。
上から押し付けられるやり方をはねのけれないと何がアジャイルだってなるし、まあはねのけられないですよね。
だからこそ効率が悪い開発が続くのですが。
なのでなんちゃってアジャイルになります。
スプリントを随時設定してそれを管理していく。
アジャイルは終わりの定義がない。運営に近い。
バックログを眺めつつ、価値のある物から作っていく。
時間がきて残っていたらそれを切り捨てる
私のやり方もこれに近いですね。アジャイルという体は取らず、個別のスプリントを私が設定してしまいます。
で、時間が来たところで終了。
大概は期間内でスケジュール通りでそのチームで作れる一番いいものを作ることが出来ます。
でもまあ結果だけ見てもわかりにくいのでなかなか評価されなかったりもするのですが…。
アジャイルのやり方も勉強になりますが、この講義のようにやった結果どうなったか？という話は本当にためになりますね。