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.

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

7,900 views

Published on

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

Published in: Business

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

  1. 1. リーンソフトウェア開発から見るゲーム開発7つのムダ
  2. 2. 自己紹介 •  田中 宏幸(Hiroyuki Tanaka) •  (株)イリンクス CEO / Programmer
•  一応プロマネの資格持ってます –  認定スクラムマスター (CSM) –  PMI認定Project Management Professional •  Twitter : swiftnest
  3. 3. リーンソフトウェア開発「トヨタ生産方式(TPS)」を元にして作られたソフトウェア開発手法 リーン=ムダが無い、効率的
  4. 4. トヨタ生産方式(TPS) リーン生産方式 リーンソフトウェア開発 リーンスタートアップ リーンの系譜
  5. 5. リーン7つの原則 •  原則1:ムダをなくす •  原則2:品質を作り込む •  原則3:知識を作り出す •  原則4:決定を遅らせる •  原則5:速く提供する •  原則6:人を尊重する •  原則7:全体を最適化する
  6. 6. リーン7つの原則 •  原則1:ムダをなくす •  原則2:品質を作り込む •  原則3:知識を作り出す •  原則4:決定を遅らせる •  原則5:速く提供する •  原則6:人を尊重する •  原則7:全体を最適化する
  7. 7. 7つのムダ •  余分な機能のムダ •  未完成の作業のムダ •  再学習のムダ •  引き継ぎのムダ •  タスク切り替えのムダ •  遅れのムダ •  欠陥のムダ
  8. 8. ムダその1  余分な機能のムダ
  9. 9. その1ー余分な機能のムダ 余分な機能  複雑さを生む ・複雑なソースコード (作成コスト、バグの発生率、変更や管理の難度)・複雑な仕様 (作成コスト、把握ミス、変更や管理の難度) ・複雑さはプロジェクトの歩みを遅らせる・柔軟性が無くなる
  10. 10. その1ー余分な機能のムダ •  機能の必要性について「疑問」がある場合は追加しない•  後で機能を追加できるように考えておくただし製品に必要な機能であれば複雑であっても「余分」では無い 複雑さを避ける方法
  11. 11. ムダその2  未完成の作業のムダ
  12. 12. その2ー未完成の作業のムダ • テストやデバッグされてないソース• 承認の得られてない仕様• チェックを受けてないリソース• SVNやgitにコミットされてないリソース未完成なもの
  13. 13. 特に未完成のまま  放置がキケン!!
  14. 14. その2ー未完成の作業のムダ •  ソースコードの内容を忘れた状態でデバッグ•  実装後に見つかる仕様ミス•  量産後に大量のリテイク•  コミットしたら衝突した更なるムダを生み出す 放置した結果
  15. 15. ムダその3  再学習のムダ
  16. 16. その3ー再学習のムダ •  ドキュメントに残さない•  担当者に伝えない、伝わらない•  追求しない 決定・経験したことを•  キャラ1体1万ポリゴンで! →2万ポリゴンで作成 •  締め切りが変わりました →知らない人が居る•  何でこのプロジェクト上手く行かなかったんだろう →原因を探さない
  17. 17. ムダその4  引継ぎのムダ
  18. 18. その4ー引継ぎのムダ 1回の引継ぎで暗黙知が半分引き継がれると仮定すると…
  19. 19. 100% 50% 25% 引継ぎ2回で暗黙知は25%まで減る その4ー引継ぎのムダ
  20. 20. その4ー引継ぎのムダ 引継ぎ自体に時間が掛かる •  引継ぎはメンバーが増減した場合に多く起きる•  メンバーが増員した場合も、引継ぎが起きるためパフォーマンスは一時的に減少する•  引継ぎによる暗黙知の消失はミスに繋がる
  21. 21. ムダその5  タスク切り替えのムダ
  22. 22. 第1週 第2週 第3週 赤の作業が終わるのは3週目→未完成のムダ その5ータスク切り替えのムダ タスクを切り替える度に前回の作業を思い出す必要→再学習のムダ
  23. 23. ムダその6  遅れ(待ち)のムダ
  24. 24. 遅れのムダ  待ちのムダ その6-遅れ(待ち)のムダ •  誰かの作業完了待ち→いつ作業が終わるか判らない•  質問の返答待ち→いつ返答が来るか判らない•  承認プロセス→いつ承認が降りるか判らない
  25. 25. 待ち時間を少なくする  オススメ方法  全員が同じ部屋で働く
  26. 26. 全員が同じ部屋で働くメリット その6-遅れ(待ち)のムダ •  コミュニケーションがとりやすい•  すぐに質問できる•  口頭で質問できる•  状況の確認がしやすい•  誰かの作業の進捗•  誰かの出社状況
  27. 27. ムダその7  欠陥のムダ
  28. 28. 欠陥=ムダ  欠陥は早期に見つける  ほど修正コストが低い  ・欠陥を入れない  ・欠陥の早期発見
  29. 29. その7-欠陥のムダ •  テストやASSERTをコードに入れる•  Jenkins等で自動的にチェックする•  複雑さを避ける 欠陥を入れない•  常に最新のビルドが遊べるようにする•  マイルストーン毎にデバッグ期間を設ける•  エージングテストを日々行う(自動プレイ等)欠陥の早期発見
  30. 30. まとめ •  余分な機能のムダ •  未完成の作業のムダ •  再学習のムダ •  引き継ぎのムダ •  タスク切り替えのムダ •  遅れのムダ •  欠陥のムダ ムダを意識し、排除することで開発の効率化&安定化を!!
  31. 31. ポッペンディーク夫妻にゲーム開発の事例を見て貰い一刀両断された時の話
  32. 32. 考 プログラ  ミング グラフィック レベル  デザイン 結合 繰り返し1週間~1ヶ月 企画 ディレクター ディレクター 顧客
  33. 33. メ)「チェックはディレクターだけなの?顧客はしないの?」私)「顧客は居ません。ディレクターが顧客の代わりをします」メ)「…顧客は何万人といるんでしょ?本当にディレクター1人に顧客の代わりが務まるの?」私)「…」メ)「顧客に見てもらう事は出来ないの?」私)「例え見てもらえても、顧客は素人なので作りかけのゲームの合否を正確に判断出来ません」メ)「…もしそれが本当なら、ディレクター1人の才能にゲームの品質が左右されますね」
  34. 34. メ)「ピクサーは映画を作る際、何度も顧客に見て貰い、修正を繰り返すわ」私)「それをするには、資金も時間も沢山必要です」メ)「本当に?資金と時間が無ければ出来ないの?」私)「…」メ)「もしそれが本当なら、資金も時間も無いあなた方がこういった規模の大きいゲームを作るべきではないわ」私)「…」メ)「ソーシャルゲームはどう?資金も時間も少なくて済むわよ」私)「…(泣)」
  35. 35. その後、たまたまβ版を出してユーザーに遊んでもらい製品版に活かすという流れに 圧倒的に良くなった β版を出すのはお金も期間も掛かるのでどんなタイトルでも出来るわけではない。もっと安価で行う方法は無いだろうか…?
  36. 36. ご清聴ありがとうございました

×