Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GCSアジャイル開発を使ったゲームの作り方

2,925 views

Published on

Game Comunity SummitのGamePM枠で講演した際の資料です
https://sites.google.com/site/gamecomsummit/

Published in: Business
  • Be the first to comment

GCSアジャイル開発を使ったゲームの作り方

  1. 1. アジャイル開発を使った ゲームの作り方 てへぺろ(・ω<) 1
  2. 2. 自己紹介• 田中 宏幸• (株)イリンクス 社長 / プログラマー – 現在PS3&Vitaのゲームやエンジン等作ってます。• 一応プロマネの資格持ってます – 認定スクラムマスター (CSM) – PMI認定Project Management Professional• Twitter : swiftnest
  3. 3. さっそく質問
  4. 4. マネジメント好きですか?
  5. 5. マネジメントのイメージ 怠けたら怒られる 面倒くさい 僕プログラマーだから よく判らない そんなことより野球しようぜ!
  6. 6. マクレガーXY理論• X理論 人間は本来なまけたがる生き物で、責任をとり たがらず、放っておくと仕事をしなくなる• Y理論 人間は本来進んで働きたがる生き物で、自己実現 のために自ら行動し、進んで問題解決をする
  7. 7. マクレガーXY理論• Y理論 人間は本来進んで働きたがる生き物で、自己実現 のために自ら行動し、進んで問題解決をする 「自ら行動」する為には プロジェクトの状況把握が必要 プロジェクトマネジメントの役割 「プロジェクトの見える化」 人のマネジメント
  8. 8. 特にゲーム開発はプロジェクト期間が長く失敗率も高い
  9. 9. 国内のプロジェクト成功率 ・2003年 26.7% ・2008年 31.1%
  10. 10. プロジェクトマネジメントは 「銀の弾丸」ではないが それでも プロジェクトの成功率を 上げる事は出来る
  11. 11. 誰かが行動しない事には現状は変わらない
  12. 12. そんな手法をゆるふわな感じで紹介していきます∼
  13. 13. アジェンダ• ウォーターフォール• アジャイル• スクラム(計画・チーム・スプリント)• XP(TDD・ペアプロ・CI)• アジャイルUX• インセプションデッキ• まとめ
  14. 14. プロジェクトマネジメントってどんなのがあるの?
  15. 15. 大きく分けて2種類 ウォーターフォール アジャイル
  16. 16. ウォーターフォール
  17. 17. ウォーターフォール• 各工程で仕様や機能を確定させていき、前工程が終了す るまで次工程を開始しない手法• 大規模開発や要件定義にブレが少ないプロジェクトで使 用される事が多い
  18. 18. ウォーターフォール:ゲームでの適応は?• ゲームでも何かの移植等、要件定義のブレが少な い案件では相性が良い• 外注の際も各段階で「要件定義書」「基本設計 書(仕様書)」といった書類を生成していくため ブレのない発注が可能• 新規タイトルなど、開発の初期段階で全ての要件 定義が出せないような場合は不向き
  19. 19. アジャイル
  20. 20. アジャイル開発• アジャイル=敏捷な• 主に短い期間(1週∼4週)で計画、開発、評価、改善 を繰り返す開発手法• 少しづつ軌道修正をしながら開発をしていくため 新規開発で主に使用される事が多い計画 計画 計画 開発 開発 開発 評価 評価 評価 改善 改善 改善
  21. 21. ウォーターフォールとアジャイルの対比 ゴール ゴール スタート スタート ウォーターフォール アジャイル
  22. 22. ウォーターフォールとアジャイルの対比 ゴール ゴール真の 真のゴール ゴール スタート スタート ウォーターフォール アジャイル
  23. 23. アジャイル開発の種類 利用されているアジャイル手法 Evo その他 Crystal 20% DSDM XP スクラム XP 6% 50% (eXtreme Programming) スクラム/XPの組み合わせ 24% スクラム リーンソフト 米VersionOne ウェア開発 State of Agile Development Survey 2009
  24. 24. スクラム
  25. 25. スクラムとは• 一橋大学の野中郁次郎と竹内弘高が 1986年に日本の元気な製造業(富士ゼロッ クス、キヤノン、ホンダ、NEC、セイコーエプソ ン、ブラザー工業)に共通している手法をまとめ 論文として発表• この論文を元にジェフ・サザーランドと ケン・シュエイバーがソフトウェア制作技法とし て作成したのがスクラム
  26. 26. 私が初めてスクラムという名前を 聞いたのは
  27. 27. CEDEC2009Scrum 最新技術事例 「Star WarsThe Old Republic」での大容量ゲーム開発
  28. 28. スクラム採用例(たぶん)• アンチャーテッド2(スクラム)• Bio Shock (スクラム)• Mass Effect (スクラム)• Half Life2 (スクラム)• Left 4 Dead2 (スクラム)• Unreal Engine (スクラム)• Gears of War (スクラムっぽい)• アサシン クリード(スクラム)
  29. 29. スクラム3つの要素• 計画• チーム• スプリント
  30. 30. その1・計画
  31. 31. プロジェクト4つの要素 スコープは比較的 動かしやすい
  32. 32. その2・チーム
  33. 33. スクラム:チーム• プロダクトオーナー 製品に対して責任を持ち、機能に優先順位を付ける ゲーム開発ではディレクターが兼任することが多い• スクラムマスター スクラムプロセスが上手く行くように外部からチームを 守る• チーム(5∼9) プロダクトの開発を行う。 製品の成功に向けて最大限の努力をコミットする
  34. 34. チームの規模が大きい場合 新機能チーム 新機能チーム ・PG ・PG ・企画 ・企画 ・デザイナー ・デザイナー 量産チーム 量産チーム ・デザイナー ・企画 エンジンチーム ・PG
  35. 35. その3・スプリントその3:スプリント
  36. 36. スプリント 毎日 朝会 全機能 今回の分 レビュー会 リスト チョイス 2∼4週 ふりかえり
  37. 37. スプリントのポイント• 少しづつ作って全員で確認• 問題があれば、その後のふりかえり会で改善• 「全機能リスト」は定期的に更新
  38. 38. まだまだ沢山あります!!
  39. 39. eXtreamProgramming
  40. 40. eXtream Programming• 2000年初頭に流行した アジャイル開発の火付け役• プログラマー向けのプラクティスが多いのが特徴• 最初は12のプラクティスだけだったが改定され 今は19に
  41. 41. eXtreme Programming 19のプラクティス 反復 1∼2週間の反復開発共同のプ 共通の用語 用語集を作成し、用語の不一致を避けるラクティ オープンな作業空間 会話しやすく、作業に打ち込める環境作り ス 回顧 頻繁な振り返りで改善していく テスト主導型の開発 プログラマは継続的にユニットテストを書く開発者の ペア・プログラミング 一台のマシンで2人のPGがコードを書くプラク リファクタリング 動作を変えることなくソースを改善する ティス 集団的な所有権 誰でもどのコードでも修正できる 継続的インテグレーション 一日に何回もビルドし問題を改善する YAGNI 今必要なことだけ行う 責任の受け入れ 開発者にコミットメントしてもらう管理者の 援護 開発者が集中出来るように支援するプラク 年に4回のレビュー 権限を持つプロジェクトの関係者で話合う ティス ミラー 今どういう状態かをチームに知らせる 持続可能なペース 知的作業には週40時間の労働時間が最適顧客のプ ストーリー伝達 ストーリーカードで要件を洗い出す リリース計画 リリース計画をチーム合意で進めるラクティ 受け入れテスト イテレーションごとに顧客の立場からテスト ス 頻繁なリリース ユーザからフィードバックを得る
  42. 42. テスト主導型の開発(TDD) テスト用のフレームワークと ソースファイルを用意してstack->push( 99 ) 最初に空のクラスとstack->push( -1 ) テストコードを書きCPPUNIT_ASSERT_EQUAL( -1, stack->pop());CPPUNIT_ASSERT_EQUAL( 99, stack->pop()); テストが失敗したのを確認し てからクラスを実装して テストが通るのを確認し リファクタリングする
  43. 43. テスト主導型の開発(TDD)• リファクタリングにより 安全にクリーンなコードが書ける• コードの拡張によるバグなどを減らせる• 作業時間は1∼2割程度増えるが、その分デバッグ時間 が減るので、結果的に開発時間が減る• ただし、UIといった見栄えや手動操作が必要な場所には 使いづらく、結果ゲーム開発ではそれほど普及していな い(アメリカでも15%程度)
  44. 44. ペア・プログラミング• 1つの画面を2人で見る。片方がキーボードを叩き、もう片方は それを見ていて気づいたことをコメントする• 一節によると15% コーディング速度が低下するが、作りこむバ グ数も 15%少なくなる。
  45. 45. 継続的インテグレーション(CI)• ビルドやチェックを頻繁に自動で行うシステム• ビルドエラーが起きた場合は、全員にメールで通知
  46. 46. Jenkinsに登録されている内容• PS3版 ビルドチェック(30分に1回)• Windows版 起動チェック(30分に1回)• PS3版 起動チェック(30分に1回)• Windows版デザイナー環境作成(任意)• PS3版デザイナー環境作成(任意)• Vita版デザイナー環境作成(任意)• ソースUTF8文字コードチェック(30分に1回)
  47. 47. http://asanoken.jugem.jp/?eid=2143アジャイルUX
  48. 48. アジャイルUX• UX:ユーザーエクスペリエンス(体験)• ユーザーの視点を常に意識する開発手法で、今ま であったUXを軽量化(アジャイル)したもの• 基本はユーザーに現在開発中の製品を遊んで貰 い、その内容を元に製品を改善していく• ただし「ユーザーの声を聞いてはいけない」 ?
  49. 49. ユーザーエクスペリエンスのポイント• 「このゲーム敵が多くてイライラする」 ‒ 敵が少なければイライラしない? ‒ よく見ると攻撃ボタンを押す回数が多い ‒ 敵が硬いのがイライラの原因では?• ユーザーの声を聞いて鵜呑みにするのではなく ユーザーの体験を通して原因を突き止める ユーザーエクスペリエンス (体験)
  50. 50. プラグマティックペルソナ• このゲームの対象ユーザーの年齢や趣味、生活サイクルなどを 「想像で」書く• 常に見える場所に貼っておき、ユーザーを意識しながら製品を作る• 実際に近い人にインタビューし、方向性が間違ってないか確かめる
  51. 51. http://asanoken.jugem.jp/?eid=2143 ペーパープロトタイプ• 製品を作る前に紙で試作画面を制作し、様々な人にインタ ビューする• あまり綺麗な画面を作ると機能より見栄えの方に意見が寄るの でフリーハンドくらいな方が良い
  52. 52. ユーザーテスト• 対象ユーザーに近い人を何とかして5名集める ‒ 5名=80:20の法則 ‒ 同僚、友人の友人の友人 ‒ あまり人数が少ないと意見が偏る事がある• ユーザーに思考発話を意識してもらいながら ゲームをプレイしてもらう• プレイの様子はビデオカメラで録画する• 例えゲームが未完成でも、一部分を切り出して 積極的に行う
  53. 53. アジャイルUX(ユーザーエクスペリエンス)• ユーザーの声を聞くべからず• 一人のためにデザインする• 手を動かしながら考える• 早期に失敗する
  54. 54. インセプション デッキInception Deck
  55. 55. <あなたのプロジェクトの名前><あなたのスポンサーの名前>
  56. 56. なぜあなたはここにいるのか?• ∼を題材としたアクションゲームを PSVitaのローンチに合わせて発売するため• 大事な理由 #2• 大事な理由 #3 このプロジェクトを行う最大の理由をここに
  57. 57. エレベーターピッチ• [必要性や機会を記述]を望んでいる• [対象顧客]にとって• [プロジェクト名]は• [製品カテゴリ]に属しており• [キーベネフィット, 購入への説得力ある理由]が ある.• [他の主要な競合製品]と違って• 我々のプロジェクトは[主要な違いの記述]があ
  58. 58. プロダクトボックス(外箱) <製品名> 楽しい絵 <スローガン> <利点 #1> <利点 #2> <利点 #3>
  59. 59. やらないことリスト やる(スコープ内) やらない(スコープ外) 未解決
  60. 60. あなたのプロジェクトコミュニティ <コミュニティ#3> <チーム#2> コアチーム <グループ#1> その他大勢! ...  は常にあなたが考える以上に大きい!
  61. 61. テクニカルソリューション 技術:- <言語> 危険!- <ライブラリ>- <ツール>- <その他技術要素> 範囲外
  62. 62. 夜も眠れないようなこと• ディレクターに時間を割いてもらえない• チームの作業場所が分散している• 初挑戦のネットワーク対戦
  63. 63. Aチーム # 役割 能力/期待すること 1 アナリスト ジャストインタイム分析が容易にできる. テストが好きである. 2 開発者 素早い繰り返し開発が苦痛ではない. C#, MVC.NET, jQuery, SQL ユニットテスト, リファクタリング, TDD, 継続的インテグ 0.5 プロジェクトマ レーション 顔をあわせてのコミュニケーションへの責任 ネージャ 状況報告, スコープ, 予算, 上への報告
  64. 64. どのくらい大きいのか? 出荷! 構築 UAT トレーニング ~3ヶ月 1週間 1 週間 これは想定です.  約束ではありません.
  65. 65. トレードオフ スライダー 典型的な4つの分類 フィーチャーが完了すること(スコープ)ON OFF予算内に収まること(予算)ON OFF時間通りに納入すること (時間)ON OFF高い品質、少ないバグ(品質)ON OFF その他の大事なことON OFF 簡単に使えることON OFF考えさせない!ON OFF詳細な証跡(なんでもログを取る)ON OFF<好きなのをいれる>
  66. 66. 最初のリリース 出荷! 構築 UAT トレーニング ~3ヶ月 1 週間 1 週間 3  人,  3.5ヶ月,  250Kドル
  67. 67. まとめ• ウォーターフォール開発 ‒ 大規模開発に向く、計画主導型の手法• アジャイル開発 ‒ 小∼中規模開発に向く、開発主導型の手法• スクラム• XP• アジャイルUX• インセプションデッキ
  68. 68. まとめ• 今回は概要を紹介しただけです!• 興味のある人は、まず「アジャイルサムライ」を 読むのをオススメします!• 他にも色々な勉強会があります ‒ すくすくスクラム ‒ スクラム道 ‒ Game Development with Scrum読書会 ‒ ゲーム開発環境勉強会• そして…
  69. 69. 是非GamePMに遊びに来て 下さい!

×