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

1. リーンソフトウェア開発から見る
ゲーム開発7つのムダ

2. 自己紹介
• 田中 宏幸(Hiroyuki Tanaka)
• (株)イリンクス CEO / Programmer
• 一応プロマネの資格持ってます
– 認定スクラムマスター (CSM)
– PMI認定Project Management Professional
• Twitter : swiftnest

3. リーンソフトウェア開発
「トヨタ生産方式（TPS）」を
元にして作られた
ソフトウェア開発手法
リーン＝ムダが無い、効率的

4. トヨタ生産方式（TPS）
リーン生産方式
リーンソフト
ウェア開発
リーン
スタートアップ
リーンの系譜

5. リーン７つの原則
• 原則1：ムダをなくす
• 原則2：品質を作り込む
• 原則3：知識を作り出す
• 原則4：決定を遅らせる
• 原則5：速く提供する
• 原則6：人を尊重する
• 原則7：全体を最適化する

6. リーン７つの原則
• 原則1：ムダをなくす
• 原則2：品質を作り込む
• 原則3：知識を作り出す
• 原則4：決定を遅らせる
• 原則5：速く提供する
• 原則6：人を尊重する
• 原則7：全体を最適化する

7. ７つのムダ
• 余分な機能のムダ
• 未完成の作業のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ

8. ムダその１
余分な機能のムダ

9. その１ー余分な機能のムダ
余分な機能 複雑さを生む
・複雑なソースコード
（作成コスト、バグの発生率、変更や管理の難度）
・複雑な仕様
（作成コスト、把握ミス、変更や管理の難度）
・複雑さはプロジェクトの歩みを遅らせる
・柔軟性が無くなる

10. その１ー余分な機能のムダ
• 機能の必要性について「疑問」がある場合は
追加しない
• 後で機能を追加できるように考えておく
ただし製品に必要な機能であれば
複雑であっても「余分」では無い
複雑さを避ける方法

11. ムダその２
未完成の作業のムダ

12. その２ー未完成の作業のムダ
• テストやデバッグされてないソース
• 承認の得られてない仕様
• チェックを受けてないリソース
• SVNやgitにコミットされてないリソース
未完成なもの

13. 特に未完成のまま
放置がキケン!!

14. その２ー未完成の作業のムダ
• ソースコードの内容を忘れた状態でデバッグ
• 実装後に見つかる仕様ミス
• 量産後に大量のリテイク
• コミットしたら衝突した
更なるムダを生み出す
放置した結果

15. ムダその３
再学習のムダ

16. その３ー再学習のムダ
• ドキュメントに残さない
• 担当者に伝えない、伝わらない
• 追求しない
決定・経験したことを
• キャラ１体１万ポリゴンで！
→２万ポリゴンで作成
• 締め切りが変わりました
→知らない人が居る
• 何でこのプロジェクト上手く行かなかったんだろう
→原因を探さない

17. ムダその４
引継ぎのムダ

18. その４ー引継ぎのムダ
１回の引継ぎで
暗黙知が
半分引き継がれると
仮定すると…

19. 100％
50％
25％
引継ぎ2回で暗黙知は２５％まで減る
その４ー引継ぎのムダ

20. その４ー引継ぎのムダ
引継ぎ自体に時間が掛かる
• 引継ぎはメンバーが増減した場合に多く起きる
• メンバーが増員した場合も、引継ぎが起きるため
パフォーマンスは一時的に減少する
• 引継ぎによる暗黙知の消失はミスに繋がる

21. ムダその５
タスク切り替えのムダ

22. 第１週
第2週
第3週
赤の作業が終わるのは３週目
→未完成のムダ
その５ータスク切り替えのムダ
タスクを切り替える度に
前回の作業を思い出す必要
→再学習のムダ

23. ムダその6
遅れ（待ち）のムダ

24. 遅れのムダ 待ちのムダ
その６－遅れ（待ち）のムダ
• 誰かの作業完了待ち
→いつ作業が終わるか判らない
• 質問の返答待ち
→いつ返答が来るか判らない
• 承認プロセス
→いつ承認が降りるか判らない

25. 待ち時間を少なくする
オススメ方法
全員が同じ部屋で働く

26. 全員が同じ部屋で働くメリット
その６－遅れ（待ち）のムダ
• コミュニケーションがとりやすい
• すぐに質問できる
• 口頭で質問できる
• 状況の確認がしやすい
• 誰かの作業の進捗
• 誰かの出社状況

27. ムダその7
欠陥のムダ

28. 欠陥＝ムダ
欠陥は早期に見つける
ほど修正コストが低い
・欠陥を入れない
・欠陥の早期発見

29. その７－欠陥のムダ
• テストやASSERTをコードに入れる
• Jenkins等で自動的にチェックする
• 複雑さを避ける
欠陥を入れない
• 常に最新のビルドが遊べるようにする
• マイルストーン毎にデバッグ期間を設ける
• エージングテストを日々行う（自動プレイ等）
欠陥の早期発見

30. まとめ
• 余分な機能のムダ
• 未完成の作業のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ
ムダを意識し、排除することで
開発の効率化＆安定化を!!

31. ポッペンディーク夫妻に
ゲーム開発の
事例を見て貰い
一刀両断された時の話

34. 考
プログラ
ミング
グラフィック
レベル
デザイン
結
合
繰り返し
1週間～１ヶ月
企画
ディレクター
ディレクター
顧客

35. メ）「チェックはディレクターだけなの？顧客はしないの？」
私）「顧客は居ません。ディレクターが顧客の代わりをします」
メ）「…顧客は何万人といるんでしょ？
本当にディレクター１人に顧客の代わりが務まるの？」
私）「…」
メ）「顧客に見てもらう事は出来ないの？」
私）「例え見てもらえても、顧客は素人なので作りかけのゲーム
の合否を正確に判断出来ません」
メ）「…もしそれが本当なら、ディレクター１人の才能に
ゲームの品質が左右されますね」

36. メ）「ピクサーは映画を作る際、何度も顧客に見て貰い、修正を
繰り返すわ」
私）「それをするには、資金も時間も沢山必要です」
メ）「本当に？資金と時間が無ければ出来ないの？」
私）「…」
メ）「もしそれが本当なら、資金も時間も無いあなた方が
こういった規模の大きいゲームを作るべきではないわ」
私）「…」
メ）「ソーシャルゲームはどう？資金も時間も少なくて済むわよ」
私）「…（泣）」

37. その後、たまたまβ版を出してユーザーに遊んでもらい
製品版に活かすという流れに
圧倒的に良くなった
β版を出すのはお金も期間も掛かるので
どんなタイトルでも出来るわけではない。
もっと安価で行う方法は無いだろうか…？

39. ご清聴ありがとうございました