GDC2012 Scrum Essentials for GameTeams メモ

投稿日:

3/5 (Mon) は 10:00〜18:00 まで Scrum Essentials Tutorial というセッションに参加しました。 Agile Game Development with Scrum の著者、 Clinton Keith さんの話です。

構成はだいたいこんな感じ。

  • 10:00 〜 スクラムの概要説明 & ワークショップ
  • 12:00 〜 昼休み
  • 13:30 〜 幸せなチームを作るための「科学的な」アドバイス by Scott Crabtree
  • 14:30 〜 Sprint について & ワークショップ

発表資料は .pdf ファイルがコチラで公開されています。
(アニメーションしないので、そのままこれだけを見ると逆に分かりにくいかもしれない)

■感想
スクラムは軽量ゆえにIT系の開発に関わらず色んな分野に応用の効くフレームワークだと理解していますが、それをゲーム開発に特化して細かい説明を受けられたのはとても有益だったと思います。
Agile Manifesto の紹介では、ゲーム開発のコンテキストに則していくつか単語を置き換えて説明していましたし、 Potentialy Shippable Increment については Playable Game と、完全に言い換えていました。
こんな感じでスクラムの用語をゲーム開発用に適宜変換して説明してましたが、置換が非常に絶妙で、ゲームを開発した経験のある人であれば、このセッションに参加することでスクラムを理解しやすくなったかと思います。

個人的にこのセッションに参加しての最大の収穫は、弊社の執行役員(CTO)も同席させたことですかねw
「認定スクラムマスターコース、俺も受講してみようかなぁ」と昼飯食べながら言っていました。
# 「経営者ですから、CSPOの方がいいんじゃないですか？」 と言ってみましたが

いずれにしても、そのレベルでスクラムに理解をしてくれる人が社内に増えるのは喜ばしいこと。

■メモ
ワークショップも含めて全部英語だったので、完璧な記録ではないですし、エントリ書くところでかなり適当に意訳しています。そこんところはご了承ください。


  • ゲーム開発で重要なこと
    • 「楽しい」をいかに早く見つけるか (資料 p.7)
    古典的な開発手法で作っていくと
    • コンセプトを決める(紙で)
    • プロトタイプ開発
    • E3に出展するデモを作成
    • プロダクションレベルの開発を進めてクオリティを上げる
    • アルファ版、ベータ版を作成
    というカーブを描いて "fun" を増やしていく。そうではなく、早い段階で "fun" を最大限に大きくしてしまうのが一番良い。
    かつて ATARI は(ゲームセンター用アーケードゲームの)試作品の筐体を、特に何の告知も宣伝もせずにしれっとゲーセンに置いていた。週末の稼働状況を確認して $600 以上売り上がっていれば「面白いに違いない」と判断して本気で製品化を進め、逆に売上が $300 以下ならそのゲームはなかったことにし、 $300 〜 $600 くらいなら要検討、という感じで「面白いかどうか」をプロジェクトの最初に判断していた。
  • Ageile Manifesto をゲームで言うと
    • Working game over Design documents.
      • 「プレイできなければ意味ないよ」という強いメッセージを感じた
  • Do the right things, right way. (資料 p.21
    • .pdf だとアニメーションがなくなってしまってるので、? の正解が分からないですね。以下の表の通りです。
     Right Thing   Unsustainable wins   Enduring Success 
     Wrong Thing   Slow failure   Fast failure 
       Wrong Way   Right Way 
  • (質疑応答で)スプリントにかかる時間は? (必要経費的な時間は?)
    • 全体の10%くらいまでなら、スプリント計画とデモ・、振り返りの時間にかかってしまっても仕方ない
    • 2週間のイテレーションなら10日あるので、丸一日くらいかかっちゃっても最初はしかたない
    • もちろん、どこまでツッコんで計画するか、振り返りするか (level of detail)次第だ
  • スプリントの説明
    • 各スプリントの終わりには「デモができて、遊べるゲーム」ができているべき。
  • Doneの定義
    • 開発段階ごとに異なるdoneの定義が必要。(資料 p.29)
    • スプリントのDoneの定義 → コンセプトが固まっていること、遊ぶことができる(playable)こと
    • リリースのDoneの定義 → ゲームとして適切なパフォーマンス、雑誌にデモを提供できること
    • 出荷のDoneの定義 → QAのチェックがすべて完了していること
  • タスクボード
    • 資料 p.34 の区分け、パッと見「細かすぎるかな」と思ったけど、これはこれで案外便利かもしれない。
    To verify というのは「テスト担当者によるチェック」なので、スクラムチームにテスターを含めるべき、というメッセージと受け取った
  • 振り返り
    • 弊社ではいつもKPTでやっているけど、多分同じことだよね。
    • Start Doing
    • Stop Doing
    • Continue Doing

順番は前後しますが、Happy Brain Science のチーム作りの話

  • メンバーへのフィードバックは、ポジティブなことをネガティブなことよりかなり多めに伝える方がパフォーマンスが上がる
    • だいたい 5:1 とかの比率で。
  • happy brain の状態が一番望ましい
    • 脳が解釈する "us" の範囲が広がる。つまり、テンパった脳だと「またテスター連中がごちゃごちゃと・・」「プログラマたちが言うこと聞いてくれない」「デザイナーが・・」となってしまうが、そもそも同じチーム(会社、ゲームスタジオ)で作品作ってる仲間じゃん、って自然に思えるようになる。この違いは大きい。
  • 例えばメンバーと1対1で散歩しながら話す
    • 効果は抜群。実際にグループワークで隣の人と話しながら部屋を一周して体感した。座って顔を合わせた状態で話すよりも、なんだろう。いろいろ引き出し安いと感じた。
    # もちろん英語で話すんで、こっちは会話するだけで逆にいっぱいいっぱいだったけど。

以上。

明日は Unity Developer Day というのに参加します。まさか自分が3Dゲームエンジンを使うことになるなんて、夢にも思ってなかったYO!