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

1. アジャイル開発を使った
ゲームの作り方
てへぺろ(・ω<)
1

2. 自己紹介
• 田中 宏幸
• (株)イリンクス 社長 / プログラマー
– 現在PS3＆Vitaのゲームやエンジン等作ってます。
• 一応プロマネの資格持ってます
– 認定スクラムマスター (CSM)
– PMI認定Project Management Professional
• Twitter : swiftnest

3. さっそく質問

4. マネジメント
好きですか？

5. マネジメントのイメージ
怠けたら怒られる
面倒くさい
僕プログラマーだから
よく判らない
そんなことより野球しようぜ！

6. マクレガーXY理論
• X理論
人間は本来なまけたがる生き物で、責任をとり
たがらず、放っておくと仕事をしなくなる
• Y理論
人間は本来進んで働きたがる生き物で、自己実現
のために自ら行動し、進んで問題解決をする

7. マクレガーXY理論
• Y理論
人間は本来進んで働きたがる生き物で、自己実現
のために自ら行動し、進んで問題解決をする
「自ら行動」する為には
プロジェクトの状況把握が必要
プロジェクトマネジメントの役割
「プロジェクトの見える化」
人のマネジメント

9. 特にゲーム開発は
プロジェクト期間が長く
失敗率も高い

10. 国内のプロジェクト成功率
・2003年 26.7％
・2008年 31.1％

12. プロジェクトマネジメントは
「銀の弾丸」ではないが
それでも
プロジェクトの成功率を
上げる事は出来る

13. 誰かが行動しない事には現状は変わらない

14. そんな手法を
ゆるふわな感じで
紹介していきます∼

15. アジェンダ
• ウォーターフォール
• アジャイル
• スクラム（計画・チーム・スプリント）
• XP（TDD・ペアプロ・CI）
• アジャイルUX
• インセプションデッキ
• まとめ

16. プロジェクトマネジメントって
どんなのがあるの？

17. 大きく分けて2種類
ウォーターフォール
アジャイル

18. ウォーターフォール

19. ウォーターフォール
• 各工程で仕様や機能を確定させていき、前工程が終了す
るまで次工程を開始しない手法
• 大規模開発や要件定義にブレが少ないプロジェクトで使
用される事が多い

20. ウォーターフォール：ゲームでの適応は？
• ゲームでも何かの移植等、要件定義のブレが少な
い案件では相性が良い
• 外注の際も各段階で「要件定義書」「基本設計
書（仕様書）」といった書類を生成していくため
ブレのない発注が可能
• 新規タイトルなど、開発の初期段階で全ての要件
定義が出せないような場合は不向き

21. アジャイル

22. アジャイル開発
• アジャイル＝敏捷な
• 主に短い期間（１週∼４週）で計画、開発、評価、改善
を繰り返す開発手法
• 少しづつ軌道修正をしながら開発をしていくため
新規開発で主に使用される事が多い
計画 計画 計画
開発 開発 開発
評価 評価 評価
改善 改善 改善

23. ウォーターフォールとアジャイルの対比
ゴール ゴール
スタート スタート
ウォーターフォール アジャイル

24. ウォーターフォールとアジャイルの対比
ゴール ゴール
真の 真の
ゴール ゴール
スタート スタート
ウォーターフォール アジャイル

25. アジャイル開発の種類
利用されているアジャイル手法
Evo
その他
Crystal 20%
DSDM
XP
スクラム
XP 6%
50%
(eXtreme
Programming) スクラム/XPの組み合わせ
24%
スクラム
リーンソフト
米VersionOne
ウェア開発 State of Agile Development Survey 2009

26. スクラム

27. スクラムとは
• 一橋大学の野中郁次郎と竹内弘高が
１９８６年に日本の元気な製造業（富士ゼロッ
クス、キヤノン、ホンダ、NEC、セイコーエプソ
ン、ブラザー工業）に共通している手法をまとめ
論文として発表
• この論文を元にジェフ・サザーランドと
ケン・シュエイバーがソフトウェア制作技法とし
て作成したのがスクラム

28. 私が初めて
スクラムという名前を
聞いたのは

29. CEDEC2009
Scrum 最新技術事例
「Star Wars
The Old Republic」
での大容量ゲーム開発

30. スクラム採用例（たぶん）
• アンチャーテッド2(スクラム)
• Bio Shock (スクラム)
• Mass Effect (スクラム)
• Half Life2 (スクラム)
• Left 4 Dead2 (スクラム)
• Unreal Engine (スクラム)
• Gears of War (スクラムっぽい)
• アサシン クリード(スクラム)

31. スクラム３つの要素
• 計画
• チーム
• スプリント

32. その１・計画

33. プロジェクト４つの要素
スコープは比較的
動かしやすい

42. その２・チーム

43. スクラム：チーム
• プロダクトオーナー
製品に対して責任を持ち、機能に優先順位を付ける
ゲーム開発ではディレクターが兼任することが多い
• スクラムマスター
スクラムプロセスが上手く行くように外部からチームを
守る
• チーム（５∼９）
プロダクトの開発を行う。
製品の成功に向けて最大限の努力をコミットする

44. チームの規模が大きい場合
新機能チーム 新機能チーム
・PG ・PG
・企画 ・企画
・デザイナー ・デザイナー
量産チーム 量産チーム
・デザイナー ・企画
エンジンチーム
・PG

45. その3・スプリント
その３：スプリント

46. スプリント
毎日
朝会
全機能 今回の分 レビュー会
リスト チョイス
２∼４週 ふりかえり

47. スプリントのポイント
• 少しづつ作って全員で確認
• 問題があれば、その後のふりかえり会で改善
• 「全機能リスト」は定期的に更新

48. まだまだ
沢山あります!!

49. eXtream
Programming

50. eXtream Programming
• 2000年初頭に流行した
アジャイル開発の火付け役
• プログラマー向けのプラクティスが多いのが特徴
• 最初は12のプラクティスだけだったが改定され
今は１９に

51. eXtreme Programming 19のプラクティス
反復 １∼２週間の反復開発
共同のプ
共通の用語 用語集を作成し、用語の不一致を避ける
ラクティ
オープンな作業空間 会話しやすく、作業に打ち込める環境作り
ス 回顧 頻繁な振り返りで改善していく
テスト主導型の開発 プログラマは継続的にユニットテストを書く
開発者の
ペア･プログラミング 一台のマシンで2人のPGがコードを書く
プラク
リファクタリング 動作を変えることなくソースを改善する
ティス
集団的な所有権 誰でもどのコードでも修正できる
継続的インテグレーション 一日に何回もビルドし問題を改善する
YAGNI 今必要なことだけ行う
責任の受け入れ 開発者にコミットメントしてもらう
管理者の 援護 開発者が集中出来るように支援する
プラク 年に4回のレビュー 権限を持つプロジェクトの関係者で話合う
ティス ミラー 今どういう状態かをチームに知らせる
持続可能なペース 知的作業には週40時間の労働時間が最適
顧客のプ ストーリー伝達 ストーリーカードで要件を洗い出す
リリース計画 リリース計画をチーム合意で進める
ラクティ
受け入れテスト イテレーションごとに顧客の立場からテスト
ス 頻繁なリリース ユーザからフィードバックを得る

52. テスト主導型の開発（TDD)
テスト用のフレームワークと
ソースファイルを用意して
stack->push( 99 ) 最初に空のクラスと
stack->push( -1 ) テストコードを書き
CPPUNIT_ASSERT_EQUAL( -1, stack->pop());
CPPUNIT_ASSERT_EQUAL( 99, stack->pop());
テストが失敗したのを確認し
てからクラスを実装して
テストが通るのを確認し
リファクタリングする

53. テスト主導型の開発（TDD)
• リファクタリングにより
安全にクリーンなコードが書ける
• コードの拡張によるバグなどを減らせる
• 作業時間は１∼２割程度増えるが、その分デバッグ時間
が減るので、結果的に開発時間が減る
• ただし、UIといった見栄えや手動操作が必要な場所には
使いづらく、結果ゲーム開発ではそれほど普及していな
い（アメリカでも１５％程度）

54. ペア･プログラミング
• 1つの画面を2人で見る。片方がキーボードを叩き、もう片方は
それを見ていて気づいたことをコメントする
• 一節によると15% コーディング速度が低下するが、作りこむバ
グ数も 15%少なくなる。

55. 継続的インテグレーション（CI)
• ビルドやチェックを頻繁に自動で行うシステム
• ビルドエラーが起きた場合は、全員にメールで通知

56. Jenkinsに登録されている内容
• PS3版 ビルドチェック（３０分に１回）
• Windows版 起動チェック（３０分に１回）
• PS3版 起動チェック（３０分に１回）
• Windows版デザイナー環境作成（任意）
• PS3版デザイナー環境作成（任意）
• Vita版デザイナー環境作成（任意）
• ソースUTF8文字コードチェック（３０分に１回）

57. http://asanoken.jugem.jp/?eid=2143
アジャイルUX

58. アジャイルUX
• UX：ユーザーエクスペリエンス（体験）
• ユーザーの視点を常に意識する開発手法で、今ま
であったUXを軽量化（アジャイル）したもの
• 基本はユーザーに現在開発中の製品を遊んで貰
い、その内容を元に製品を改善していく
• ただし「ユーザーの声を聞いてはいけない」
？

59. ユーザーエクスペリエンスのポイント
• 「このゲーム敵が多くてイライラする」
‒ 敵が少なければイライラしない？
‒ よく見ると攻撃ボタンを押す回数が多い
‒ 敵が硬いのがイライラの原因では？
• ユーザーの声を聞いて鵜呑みにするのではなく
ユーザーの体験を通して原因を突き止める
ユーザーエクスペリエンス
（体験）

60. プラグマティックペルソナ
• このゲームの対象ユーザーの年齢や趣味、生活サイクルなどを
「想像で」書く
• 常に見える場所に貼っておき、ユーザーを意識しながら製品を作る
• 実際に近い人にインタビューし、方向性が間違ってないか確かめる

61. http://asanoken.jugem.jp/?eid=2143
ペーパープロトタイプ
• 製品を作る前に紙で試作画面を制作し、様々な人にインタ
ビューする
• あまり綺麗な画面を作ると機能より見栄えの方に意見が寄るの
でフリーハンドくらいな方が良い

62. ユーザーテスト
• 対象ユーザーに近い人を何とかして５名集める
‒ ５名＝８０：２０の法則
‒ 同僚、友人の友人の友人
‒ あまり人数が少ないと意見が偏る事がある
• ユーザーに思考発話を意識してもらいながら
ゲームをプレイしてもらう
• プレイの様子はビデオカメラで録画する
• 例えゲームが未完成でも、一部分を切り出して
積極的に行う

63. アジャイルUX（ユーザーエクスペリエンス）
• ユーザーの声を聞くべからず
• 一人のためにデザインする
• 手を動かしながら考える
• 早期に失敗する

64. インセプション
デッキ
Inception Deck

65. <あなたのプロジェクトの名前>
<あなたのスポンサーの名前>

66. なぜあなたはここにいるのか?
• ∼を題材としたアクションゲームを
PSVitaのローンチに合わせて発売するため
• 大事な理由 #2
• 大事な理由 #3
このプロジェクトを行う最大の理由をここに

67. エレベーターピッチ
• [必要性や機会を記述]を望んでいる
• [対象顧客]にとって
• [プロジェクト名]は
• [製品カテゴリ]に属しており
• [キーベネフィット, 購入への説得力ある理由]が
ある.
• [他の主要な競合製品]と違って
• 我々のプロジェクトは[主要な違いの記述]があ

68. プロダクトボックス(外箱)
<製品名>
楽しい絵
<スローガン>
<利点 #1>
<利点 #2>
<利点 #3>

69. やらないことリスト
やる（スコープ内） やらない（スコープ外）
未解決

70. あなたのプロジェクトコミュニティ
<コミュニティ#3>
<チーム#2> コアチーム
<グループ#1>
その他大勢！
...
は常にあなたが考える以上に大きい!

71. テクニカルソリューション
技術:
- <言語> 危険!
- <ライブラリ>
- <ツール>
- <その他技術要素> 範囲外

72. 夜も眠れないようなこと
• ディレクターに時間を割いてもらえない
• チームの作業場所が分散している
• 初挑戦のネットワーク対戦

73. Aチーム
# 役割 能力/期待すること
1 アナリスト ジャストインタイム分析が容易にできる.
テストが好きである.
2 開発者 素早い繰り返し開発が苦痛ではない.
C#, MVC.NET, jQuery, SQL
ユニットテスト, リファクタリング, TDD, 継続的インテグ
0.5 プロジェクトマ レーション
顔をあわせてのコミュニケーションへの責任
ネージャ 状況報告, スコープ, 予算, 上への報告

74. どのくらい大きいのか？
出荷!
構築 UAT トレーニング
~3ヶ月 1週間 1 週間
これは想定です.
約束ではありません.

75. トレードオフ スライダー
典型的な４つの分類
フィーチャーが完了すること(スコープ)
ON OFF予算内に収まること(予算)
ON OFF時間通りに納入すること (時間)
ON OFF高い品質、少ないバグ(品質)
ON OFF
その他の大事なこと
ON OFF 簡単に使えること
ON OFF考えさせない!
ON OFF詳細な証跡(なんでもログを取る)
ON OFF<好きなのをいれる>

76. 最初のリリース
出荷!
構築 UAT トレーニング
~3ヶ月 1 週間 1 週間
3
人,
3.5ヶ月,
250Kドル

77. まとめ
• ウォーターフォール開発
‒ 大規模開発に向く、計画主導型の手法
• アジャイル開発
‒ 小∼中規模開発に向く、開発主導型の手法
• スクラム
• XP
• アジャイルUX
• インセプションデッキ

78. まとめ
• 今回は概要を紹介しただけです！
• 興味のある人は、まず「アジャイルサムライ」を
読むのをオススメします！
• 他にも色々な勉強会があります
‒ すくすくスクラム
‒ スクラム道
‒ Game Development with Scrum読書会
‒ ゲーム開発環境勉強会
• そして…

79. 是非GamePM
に遊びに来て
下さい！