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

自己紹介

•  田中 宏幸(Hiroyuki Tanaka)

•  (株)イリンクス　CEO / Programmer

•  一応プロマネの資格持ってます

– 認定スクラムマスター (CSM)

– PMI認定Project Management Professional

•  Twitter : swiftnest

リーンソフトウェア開発

「トヨタ生産方式（TPS）」を 元にして作られた

ソフトウェア開発手法

リーン＝ムダが無い、効率的

トヨタ生産方式（TPS）

リーン生産方式

リーンソフト ウェア開発

リーン スタートアップ

リーンの系譜

リーン７つの原則

•  原則1：ムダをなくす

•  原則2：品質を作り込む

•  原則3：知識を作り出す

•  原則4：決定を遅らせる

•  原則5：速く提供する

•  原則6：人を尊重する

•  原則7：全体を 適化する

リーン７つの原則

•  原則1：ムダをなくす

•  原則2：品質を作り込む

•  原則3：知識を作り出す

•  原則4：決定を遅らせる

•  原則5：速く提供する

•  原則6：人を尊重する

•  原則7：全体を 適化する

７つのムダ

•  余分な機能のムダ

•  未完成の作業のムダ

•  再学習のムダ

•  引き継ぎのムダ

•  タスク切り替えのムダ

•  遅れのムダ

•  欠陥のムダ

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

その１ー余分な機能のムダ

余分な機能　　複雑さを生む

・複雑なソースコード 　（作成コスト、バグの発生率、変更や管理の難度）

・複雑な仕様 　（作成コスト、把握ミス、変更や管理の難度）

・複雑さはプロジェクトの歩みを遅らせる ・柔軟性が無くなる

その１ー余分な機能のムダ

•  機能の必要性について「疑問」がある場合は 追加しない

•  後で機能を追加できるように考えておく

ただし製品に必要な機能であれば 複雑であっても「余分」では無い

複雑さを避ける方法

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

その２ー未完成の作業のムダ

• テストやデバッグされてないソース • 承認の得られてない仕様 • チェックを受けてないリソース • SVNやgitにコミットされてないリソース

未完成なもの

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

その２ー未完成の作業のムダ

• ソースコードの内容を忘れた状態でデバッグ • 実装後に見つかる仕様ミス

• 量産後に大量のリテイク • コミットしたら衝突した

更なるムダを生み出す

放置した結果

ムダその３  再学習のムダ

その３ー再学習のムダ

•  ドキュメントに残さない

•  担当者に伝えない、伝わらない

•  追求しない

決定・経験したことを

•  キャラ１体１万ポリゴンで！ 　→２万ポリゴンで作成

•  締め切りが変わりました 　→知らない人が居る

•  何でこのプロジェクト上手く行かなかったんだろう 　→原因を探さない

ムダその４  引継ぎのムダ

その４ー引継ぎのムダ

１回の引継ぎで 暗黙知が

半分引き継がれると 仮定すると…

100％ 50％ 25％

引継ぎ2回で暗黙知は２５％まで減る

その４ー引継ぎのムダ

その４ー引継ぎのムダ

引継ぎ自体に時間が掛かる

•  引継ぎはメンバーが増減した場合に多く起きる

•  メンバーが増員した場合も、引継ぎが起きるため パフォーマンスは一時的に減少する

•  引継ぎによる暗黙知の消失はミスに繋がる

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

第１週 第2週 第3週

赤の作業が終わるのは３週目 →未完成のムダ

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

タスクを切り替える度に 前回の作業を思い出す必要

→再学習のムダ

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

遅れのムダ　　待ちのムダ

その６－遅れ（待ち）のムダ

• 誰かの作業完了待ち →いつ作業が終わるか判らない

• 質問の返答待ち →いつ返答が来るか判らない

• 承認プロセス →いつ承認が降りるか判らない

待ち時間を少なくする  オススメ方法  

全員が同じ部屋で働く

全員が同じ部屋で働くメリット

その６－遅れ（待ち）のムダ

• コミュニケーションがとりやすい • すぐに質問できる

• 口頭で質問できる • 状況の確認がしやすい

• 誰かの作業の進捗 • 誰かの出社状況

ムダその7  欠陥のムダ

欠陥＝ムダ  欠陥は早期に見つける  ほど修正コストが低い  

・欠陥を入れない  ・欠陥の早期発見

その７－欠陥のムダ

•  テストやASSERTをコードに入れる

•  Jenkins等で自動的にチェックする

•  複雑さを避ける

欠陥を入れない

•  常に 新のビルドが遊べるようにする

•  マイルストーン毎にデバッグ期間を設ける

•  エージングテストを日々行う（自動プレイ等）

欠陥の早期発見

まとめ

•  余分な機能のムダ

•  未完成の作業のムダ

•  再学習のムダ

•  引き継ぎのムダ

•  タスク切り替えのムダ

•  遅れのムダ

•  欠陥のムダ

ムダを意識し、排除することで 開発の効率化＆安定化を!!

ポッペンディーク夫妻に ゲーム開発の

事例を見て貰い 一刀両断された時の話

考

プログラ  ミング

グラフィック

レベル  デザイン

結合

繰り返し 1週間～１ヶ月

企画 ディレクター ディレクター 顧客

メ）「チェックはディレクターだけなの？顧客はしないの？」

私）「顧客は居ません。ディレクターが顧客の代わりをします」

メ）「…顧客は何万人といるんでしょ？ 本当にディレクター１人に顧客の代わりが務まるの？」

私）「…」

メ）「顧客に見てもらう事は出来ないの？」

私）「例え見てもらえても、顧客は素人なので作りかけのゲームの合否を正確に判断出来ません」

メ）「…もしそれが本当なら、ディレクター１人の才能に ゲームの品質が左右されますね」

メ）「ピクサーは映画を作る際、何度も顧客に見て貰い、修正を繰り返すわ」

私）「それをするには、資金も時間も沢山必要です」

メ）「本当に？資金と時間が無ければ出来ないの？」

私）「…」

メ）「もしそれが本当なら、資金も時間も無いあなた方が こういった規模の大きいゲームを作るべきではないわ」

私）「…」

メ）「ソーシャルゲームはどう？資金も時間も少なくて済むわよ」

私）「…（泣）」

その後、たまたまβ版を出してユーザーに遊んでもらい 製品版に活かすという流れに

圧倒的に良くなった

β版を出すのはお金も期間も掛かるので どんなタイトルでも出来るわけではない。

もっと安価で行う方法は無いだろうか…？

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