SlideShare a Scribd company logo
1 of 35
Download to read offline
PS開発プロジェクトへの アジャイルプラクティスの適用 
元気株式会社 PS事業部 
大谷 孝治 PMP 
PMI日本支部 AgilePM研究会(準備プロジェクト) 
2014年9月
はじめに 
PS開発=遊技機(ぱちんこ、パチスロ)の開発のことです。大手電機メーカーのゲーム機ではありません。 ただ、ゲーム開発との共通点も多いかと思います。今回はその中でも特に時間とコストのかかる液晶画面に 表示される映像演出の開発のプロジェクトマネジメントに特化した内容となっています。 
遊技機業界は、市場規模が縮小傾向の中、液晶画面の大型化や、ROM容量の増加により、演出数の増大 や、映像品質の向上が求められ、1つの遊技機の開発にかかるコストは増加傾向にあります。また、開発規 模の拡大に伴い、プロジェクトのマネジメントも複雑化し、管理工数が増え、さらにコストを押し上げる結果と なっています。 
このような状況の中で、なるべく管理の手間は減らし、それでいてプロジェクトの重要な情報(進捗や、納品 日等)はクライアントやチームメンバーに正しく伝わるマネジメント手法について調査、検討した結果、アジャイ ル開発手法の導入に至りました。 
この資料の中身は、2012年初めから2年半ほどの間、複数のプロジェクトにアジャイルプラクティスの一部を 適用した結果となります。ただ、具体的に記載出来ない部分が多々あり、また開発モデルも分かりやすくする ために単純化してあります。(実際の開発では、もっと各工程がぐちゃぐちゃに混ざっています。工程の順番す ら怪しいです) 
市場が再び活気を取り戻すためには、ソフト開発がより洗練され、高品質で楽しい遊技機が市場に数多く導 入されることが重要です。ソフト開発会社の1PMが業界に与えられる影響は微々たるものですが、多少なりと も、この資料がお役に立てれば幸いです。
アジェンダ 
• 
PS開発プロジェクトの概要~課題 
• 
アジャイルプラクティスの適用事例 
• 
今後の課題や取り組み
PS開発プロジェクトの概要~課題
PS開発プロジェクトの概略図 
・アニメーション 
・UI・3Dモデル 
・CGムービー 
・アニマティック…等 
企画 
演出 
絵コンテ 動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
試行錯誤を繰り返し 
価値ある映像を完成させる 
完成したサンプル動画を 
計画に沿って組み込む 
Value Driven 
Plan Driven 
※実際に、素材、サンプル動画作成にも量産化というPlan Drivenな工程があり、組込工程にも Value Drivenな工程が存在します。 
このようにPS開発は、Value DrivenとPlan Drivenが混在して開発が進んで行きます。 
組込工程 
企画・映像制作工程
この構造は・・・ 
企画 
デザイン 
設計 
試作 
評価 
生産 
技術 
※参考:トヨタ自動車東日本株式会社ホームページ(クルマができるまで)/http://www.toyota-ej.co.jp/process/ 
プレス 
ボディ 
塗装 
樹脂 
成形 
組立 
検査 
開発 
生産 
製造業の【開発】と【生産】の関係と似ています。
ただし・・・ 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 品管 
Value Driven 
Value Driven 
Plan Driven 
開発全体では、試作版をプレイして、 
より良い製品をつくり上げるための変更を繰り返す、反復型のプロジェクトとなります 
価値(映像品質、楽しさ、面白さなど)を高めるために、 
クライアントの変更要求に最大限応えることが重要 
・・・ですが、変更を繰り返すため、コストや時間が計画と乖離しやすく、 
マネジメントが難しいプロジェクトとなります。
マネジメントが難しい理由① 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
クライアント 
確認 
マスター 
オーサリング 
プログラム 
品管 
? 
組込工程 
答えのない業務のため、スケジュール通りに進まない。 
組込工程へ流れる物量が不定 
リテイクが何回発生するかわからない。 
納期 
納期と必要作業量から導かれる 
組込工程の適正工数 
作業出来る物 が少なく、手空 きが発生 
納期直前の大量納品で、 キャパシティーオーバー 
or 
最後まで作業量不足 
遅延とコストオーバー 
が発生 
お金は作業量にかかわらず、 
用意した人員分かかる 
成果物と工数との不一致も発生
マネジメントが難しい理由② 
A社 
(アニメ) 
B社 
(3DCG) 
素材 
D社 
(サンプル) 
サンプル 
E社 
(サンプル) 
マスター 
F社 
(マスター) 
プログラム 
C社 
(3DCG) 
物量の多さや、高度な専門性が要求される作業のため、一つの工程に 
複数の開発会社が関わる。(スケジュール管理が複数の会社で分担される場合も) 
複雑な開発体制
マネジメントが難しい理由③ 
α1 
β1 
マスター 
マイルストーン毎の仕様変更 
新アイデアのひらめき、動画を確認した結果、 
・・・などなど日常業務におけるいろいろなきっかけでの仕様変更 
毎日のように行われる仕様変更 
α2 
特にパチンコ演出は、基本的にすべての映像が繋がっているため、 
1つの演出の何気ない変更が、複数の演出の変更につながり、 
大規模な仕様変更へと発展する場合もあります。 
β2 
後工程側で作業中にも関 わらず、仕様が変わること もよくあります
プロジェクトへの影響 
スケジュール管理が、非常に煩雑で、状況を確認し判断することが困難 
このプロジェクトは、期日通りの終わるのか?遅れているのか? 
今回の仕様変更が、プロジェクトに与える影響は? 
この先どの程度の人員が必要となるのか? 
なにがいつ納品されるか分からないため、常に作業の入れ替えが必要 
管理のためだけに、数多くのリーダーが必要&多忙 
納品管理、作業指示、スケジュール管理、工程管理、客先対応・・・ 
調整のために繰り返されるミーティング等で現場への作業指示が遅れる 
スケジュール管理や工程管理だけを専門に行う人員が必要 
各工程間を調整する人員が必要 
全てのプロジェクトで、 
当初計画よりも納期が遅延し、コストが超過 
(元々計画自体が無茶なものもたまにありますが・・・)
従来のスケジュール管理 
有名なスケジュール管理ソフト「Excel」を利用。 
更新するだけでもかなりの時間がかかる上に、 
日常的に納品遅れ、リテイク、仕様変更等が発生 するため、専属のスタッフがいなければ、管理出来 ない状況に陥る。 
MS Projectも試験的に導入しましたが、頻繁な変更には不向き
改善したいこと① 
不規則に発生する作業の管理を簡潔に 
・作業の状況が一目で分かる! 
・残作業の内容や量を常に意識出来る!! 
・チームメンバーが、 
指示を待たなくても 
次の作業を進められる!!!
改善したいこと② 
スケジュール管理を簡潔に、 
そして、正確に・・・ 
・更新が簡単! 
・遅延状態が一目で分かる!! 
・仕様変更後の完了見込日が 
すぐ計算出来る!!!
改善により・・・ 
単なる工数削減、コスト削減ではなく、 
管理工数や、管理コストを重点的に削減 
リーダークラスが、 
ものづくりや品質管理に集中し、 
よりよいものを、 
クライアントが望むタイミングで納品出来る 
と言う効果を期待したい…
アジャイルプラクティスの適用事例
アジャイルプラクティスの導入 
試作版を何度もプレイして、変更を繰り返すPS開発プロジェクトとの親和性 
アジャイルプラクティス導入のきっかけ 
アジャイルソフトウェア開発の12の原則 
2.要求の変更はたとえ開発の後期であっても歓迎します。 
変化を味方に付けることによって、お客様の競争力を引き上げます。 
ただ、スクラム等の開発手法をそのまま導入することは、 
開発規模等いろいろな条件で難しいため、 
効果のありそうなプラクティスをいくつか選び※、 
「とりあえず、やってみよう」のノリでプロジェクトに導入 
※かんばん、バーンダウンチャート、朝会等
最初のプロジェクト 
プロジェクト概要 
工程 
プログラム 
導入プラクティス 
かんばん、朝会、イテレーション(2週間) 
目的 
作業管理の簡潔化 
1week 
1week 
1week 
2week 
2week 
2week 
作業予定 
作業中 
完了 
かんばんのイメージ 
タスク名 
作業者名 
特記事項 
付箋の書き方 
計画内 
タスク 
計画外 
タスク 
緊急 
タスク 
リテイクマーカー
結果は・・・ 
1week 
1week 
1week 
2week 
2week 
2week 
作業予定 
作業中 
完了 
計画外のタスクばかり 
どんどん増えて、 
計画したタスクが 
消化されない・・・ 
他にも、 
・納品タイミングがばらばら(イテレーション毎の作業量が不定) 
・前工程でのデータ作成不備による作業途中での中断 
・複数回の仕様変更によるリテイクマーカーの多重張り 
などなど、かんばんの本来の目的は果たせず 
大失敗!... 
ただし、最終工程において計画通りに作業が進まない状況がはっきりと見え、 
プロジェクト管理上の問題を、再認識出来る結果に。
次のプロジェクト 
プロジェクト概要 
工程 
素材、サンプル、マスター 
導入プラクティス 
かんばん、朝会、バーンダウンチャート 
目的 
作業管理および、スケジュール管理の簡潔化 
人員等 
社内7~10名、協力会社3社(素材2、サンプル・マスタ1) 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
開発依頼時点で、申請1年後、これらの工程を半年でという状況。 
(弊社比:50%~75%くらいの期間)
前回からの変更点 
・かんばん 
・作業予定タスクの 
随時追加 
・仕様変更タスクを 
別タスクとして管理 
・バーンダウンチャート 
・役割横断型チーム 
・イテレーション 
・複数色の付箋管理 
・リテイクマーカー 
改善・追加 
廃止
新しいかんばん 
素材 
素材 
素材 
素材 
サンプル 
サンプル 
サンプル 
サンプル 
マスター 
マスター 
マスター 
マスター 
作業予定 
作業中 
チェック待ち 
完了 
素材 
サンプル 
マスター 
展開するとWF型かんばん 
協力会社の作業も一括で管理 
付箋の動き
バーンダウンチャート 
当初の完了見込週 
仕様変更後の 
完了見込週 
最初の全作業の見積日数総和 
チーム平均作業工数(週間実績値) 
仕様変更作業の見積日数総和 
リテイク発生後の 
完了見込週 
完了見込週が簡単に算出できる 
リテイク分 
※こちらは社内工数のみの管理
プラクティス導入の成果① 
素材 
素材 
素材 
素材 
サンプル 
サンプル 
サンプル 
サンプル 
マスター 
マスター 
マスター 
マスター 
作業予定 
作業中 
チェック待ち 
完了 
大量のデータが協力会社から 
納品された結果、チェック人員の 
作業負荷が増大し、ボトルネックに 
サンプル作業メンバーの一人を 
マスターチェック作業の担当へ 
ボトルネックが解消され、 
後工程側への納品が 
スムーズに行われるように 
ポイントは、これらの施策を 
チームメンバー間で決めたこと 
かんばんと役割横断型チームによる成果
プラクティス導入の成果② 
導入前 
導入後 
労働時間イメージ 
スケジュール更新の工数が大幅に削減されただけでなく、 
遅れ等が早い段階で計算出来るため、 
計画的な残業や休日出勤などで、チームの速度をコントロールした結果、 
プロジェクト期間全体で、労働時間が平準化された 
最終成果物を、予定通りに納品!! コストも計画通り 
終盤に極端に労働時間が増え、 
遅延も発生するため、 
その状態が長く続く。 
その後、同規模のプロジェクトに関しては、同じような成果を発揮 
バーンダウンチャートによる成果
成功要因 
最大の成功要因は、 
チームメンバーが、 
自立的に動いたこと 
PM経験のないメンバーに、プラクティス導入の意味や、使い方等をレクチャーしたあとは、 その情報をもとに、チームで考え、工夫し、行動したことが、成功に繋がった。 
プロジェクトチームの自己組織化が成功の鍵 
チームを信頼し、適切な情報を正しく分かりやすく開示することが自己組織化を促す
開発現場の紹介 
かんばんはキャビネットを利用 
簡易撮影用のグリーンバック、 
ホワイトボードは 
メンバーが後から追加 
日々のコミュニケーションの 
中核としての役割も 
ビニールテープ 
導入にあたっての参考書籍(一部)⇒
考察的なもの 
何も考えずに導入しても、うまくいきません。何を変えたいかに対して、適切なプラクティスを導 入し、すでにうまくいっているのであれば、無理に導入する必要はありません。また、やり方自 体、組織やチームに合わせる必要があります。 
実際にやってみた結果、想像以上にチームが自らで判断して動くようになりました。ただ、全て のチームがそうなるかは分かりません。今回の結果、その後の同チームのプロジェクトの結果 を見る限り、最大の成功要因はプラクティスそのものではなく、チームの自己組織化だと考えま す。ただ、プラクティスにより適切な情報をチーム及び、組織の管理者、クライアントが得られる という点で、プラクティスそのものは有効に働きました。 
今回、主に小規模~中規模プロジェクトでの適用で成果がでました。試験的に大規模(60~ 100名)のプロジェクトに適用しましたが、適用前に予想した通り、同じような成果は出ませんで した。大規模プロジェクトへの適用については、今後の課題や取り組みとして、以降のページで 紹介します。 
クライアントによっては、これまで通りExcelを利用した各項目毎の詳細なスケジュールを求め られるため、結果的に専属のスタッフをアサインする必要がありました。無理に相手のやり方を 否定する必要はなく、このようなやり方もありますという形で理解を得ていければと思います。
今後の課題や取り組み
大規模プロジェクトの問題 
コミュニケーションパスの問題 
メンバーn人のチームのコミュニケーションパスは、n(n-1)/2 
チームメンバーが増えるほど、コミュニケーションロスが発生 
アジャイル開発でも1つのチームは10名くらいまで。 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
工程間のデータやりとりの問題 
主にここ 
小、中規模プロジェクトでは、1~2名程度で埋められる工程間の問題も、 
大規模プロジェクトでは埋められない。また、関わるメンバーが多いため、 
少しのデータ不備や遅れが大きなコスト超過や遅延につながる
今後の課題や取り組み① 
大規模プロジェクトへのアジャイルプラクティスの導入 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
役割横断型チームへの分割 
理想はこの範囲を役割横断型チームで複数化 
現実はこの範囲? 
どのような形の役割横断型チームへ分割し、 
プロジェクト全体をどのような構成にするかは、検討の余地あり 
ここは1つのチーム
今後の課題や取り組み② 
大規模プロジェクトにおける管理手法の確立 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
CCPMとの併用 
最終納品前のバッファマネジメントは基本として、 
スケジュールの変動が大きい、 
この工程間でのバッファマネジメント 
バーンダウンチャートも、CCも、 
チームのパフォーマンスを測定するという共通点がある
今後の課題や取り組み③ 
アジャイル開発に対応した組織づくり 
企画 
演出 
絵コンテ 
動画コンテ 
素材 
サンプル 動画 
マスター 
オーサリング 
プログラム 
品管 
専門職とマルチスキル職 
専門職が強みを発揮する工程(価値重視) 
マルチスキル職が強みを発揮する工程(計画重視) 
役割横断型チームの構成には、マルチスキル職の存在が重要。 
反面、遊技機の価値を高めるためには、高度な専門性を持つ人材の存在が強みに。 
これらの人材をバランス良く採用、育成、評価するシステムが必要となるため、 
プロジェクトのマネジメント手法だけでなく、組織の関与や活動がより重要
AgilePM研究会の紹介 
https://www.pmi-japan.org/news/info/2012_12_06_agile_pm_sig_initiation.php 
研究会への参加申し込みはこちらから 
2014年12月までは、PMI支部会員以外も参加出来ます 
https://www.pmi-japan.org/newsletter/2014/03/NL_vol58_2014_3.php 
活動の詳細については、こちらのページのニューズレターを参照ください 
アジャイル開発における、プロジェクトマネジメントについて、事例や検証等を通して、 
世の中に広く伝えていこうという趣旨の研究会となります。 
参加者も、すでに現場で実践されてる方、これからの方、スクラムコーチとして開発現場 
への導入をサポートしている方と、バラエティーに富んだ会となっています。 
ただ、残念ながらゲーム業界はもちろん、PS業界の方は誰もいません。ほぼIT業界です。 
一緒に活動する方いませんか?
参考書籍等 
・ゲーム開発プロジェクトマネジメント講座 (セミナー資料) 
株式会社スクウェア・エニックス CTO 橋本 善久 
・アジャイルサムライー達人開発者への道 
・アジャイルソフトウェア開発スクラム 
・XPエクストリーム・プログラミング実行計画 
・アジャイルな見積りと計画づくり 
・アジャイルなゲーム開発 
・リーン開発の現場 
・スクラム・ブートキャンプ ザ・ブック 
・アジャイル開発の本質とスケールアップ 
・TOC/CCPM標準ハンドブック 
・トヨタ生産方式 
・Redmineによるタスクマネジメント実践技法 
・わかりやすいアジャイル開発の教科書 
その他、AgileJapan、研究会等でのセミナー、読書会、イベントキャラバン等

More Related Content

What's hot

チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるかチーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるかTakafumi Ikeda
 
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiBデブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiBakipii Oga
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにTakafumi Ikeda
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイルTakao Kimura
 
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2Miho Nagase
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門陽一 滝川
 
ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 Unicast Inc.
 
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して Rakuten Group, Inc.
 
はじめてのScrum
はじめてのScrumはじめてのScrum
はじめてのScrumKenji Morita
 
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いなぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いYoichi Tamamaki
 
スクラム開発について
スクラム開発についてスクラム開発について
スクラム開発についてAkio Terayama
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイルYoshihito Kuranuki
 
僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!Yasui Tsutomu
 
コンシューマゲーム開発におけるHansoftの活用事例
コンシューマゲーム開発におけるHansoftの活用事例コンシューマゲーム開発におけるHansoftの活用事例
コンシューマゲーム開発におけるHansoftの活用事例Hiroyuki Tanaka
 
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)Masashi Umezawa
 
プロジェクトマネジメント入門以前 Web
プロジェクトマネジメント入門以前 Webプロジェクトマネジメント入門以前 Web
プロジェクトマネジメント入門以前 Webminamo
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 

What's hot (20)

チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるかチーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
 
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiBデブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
 
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするためにCEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
 
アジャイルと私
アジャイルと私アジャイルと私
アジャイルと私
 
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 
 
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
 
はじめてのScrum
はじめてのScrumはじめてのScrum
はじめてのScrum
 
Dev love kansai
Dev love kansaiDev love kansai
Dev love kansai
 
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いなぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
 
スクラム開発について
スクラム開発についてスクラム開発について
スクラム開発について
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
 
僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!
 
コンシューマゲーム開発におけるHansoftの活用事例
コンシューマゲーム開発におけるHansoftの活用事例コンシューマゲーム開発におけるHansoftの活用事例
コンシューマゲーム開発におけるHansoftの活用事例
 
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
 
Scrum
ScrumScrum
Scrum
 
プロジェクトマネジメント入門以前 Web
プロジェクトマネジメント入門以前 Webプロジェクトマネジメント入門以前 Web
プロジェクトマネジメント入門以前 Web
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 

Viewers also liked

クリティカルチェーン・プロジェクト・マネジメント
クリティカルチェーン・プロジェクト・マネジメントクリティカルチェーン・プロジェクト・マネジメント
クリティカルチェーン・プロジェクト・マネジメントTaku Aoyama
 
新カゴプロジェクトの プロダクトオーナーとして やってきたこと
新カゴプロジェクトの プロダクトオーナーとして やってきたこと新カゴプロジェクトの プロダクトオーナーとして やってきたこと
新カゴプロジェクトの プロダクトオーナーとして やってきたことAkane Yamarin
 
プロジェクトとプロジェクトマネジメントの基本
プロジェクトとプロジェクトマネジメントの基本プロジェクトとプロジェクトマネジメントの基本
プロジェクトとプロジェクトマネジメントの基本Toshiaki Baba
 
小さく始める大規模スクラム
小さく始める大規模スクラム小さく始める大規模スクラム
小さく始める大規模スクラムKeisuke Tsukagoshi
 
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるかプロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるかMizuki Tanno
 
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...POStudy
 
アジャイルな開発は『かんばん』でいこう!
アジャイルな開発は『かんばん』でいこう!アジャイルな開発は『かんばん』でいこう!
アジャイルな開発は『かんばん』でいこう!hiroyuki Yamamoto
 
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得Takaaki Umada
 

Viewers also liked (8)

クリティカルチェーン・プロジェクト・マネジメント
クリティカルチェーン・プロジェクト・マネジメントクリティカルチェーン・プロジェクト・マネジメント
クリティカルチェーン・プロジェクト・マネジメント
 
新カゴプロジェクトの プロダクトオーナーとして やってきたこと
新カゴプロジェクトの プロダクトオーナーとして やってきたこと新カゴプロジェクトの プロダクトオーナーとして やってきたこと
新カゴプロジェクトの プロダクトオーナーとして やってきたこと
 
プロジェクトとプロジェクトマネジメントの基本
プロジェクトとプロジェクトマネジメントの基本プロジェクトとプロジェクトマネジメントの基本
プロジェクトとプロジェクトマネジメントの基本
 
小さく始める大規模スクラム
小さく始める大規模スクラム小さく始める大規模スクラム
小さく始める大規模スクラム
 
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるかプロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
 
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...
プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネー...
 
アジャイルな開発は『かんばん』でいこう!
アジャイルな開発は『かんばん』でいこう!アジャイルな開発は『かんばん』でいこう!
アジャイルな開発は『かんばん』でいこう!
 
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
 

Similar to Ps開発プロジェクトへのアジャイルプラクティスの適用

NTTデータはどうやってCCPMを導入したのか?
NTTデータはどうやってCCPMを導入したのか?NTTデータはどうやってCCPMを導入したのか?
NTTデータはどうやってCCPMを導入したのか?shibao800
 
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣loftwork
 
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sortloftwork
 
AgilePM reading circle #9 - Cost Management
AgilePM reading circle #9 - Cost ManagementAgilePM reading circle #9 - Cost Management
AgilePM reading circle #9 - Cost ManagementTadatoshi Sekiguchi
 
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~Yuichi Hasegawa
 
PMBOKで学ぶマネジメント基本のキ
PMBOKで学ぶマネジメント基本のキPMBOKで学ぶマネジメント基本のキ
PMBOKで学ぶマネジメント基本のキHiroyuki Tanaka
 
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~apkiban
 
請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値sunnyone41
 
失敗しないパッケージ導入7
失敗しないパッケージ導入7失敗しないパッケージ導入7
失敗しないパッケージ導入7小島 規彰
 
失敗しないパッケージ導入1
失敗しないパッケージ導入1失敗しないパッケージ導入1
失敗しないパッケージ導入1小島 規彰
 
No020-01-suc3rum-20101129
No020-01-suc3rum-20101129No020-01-suc3rum-20101129
No020-01-suc3rum-20101129Sukusuku Scrum
 
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Appsグリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & AppsGoogle Cloud Platform - Japan
 
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由gree_tech
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望についてKen Azuma
 
conte - ABEMA's Design System
conte - ABEMA's Design Systemconte - ABEMA's Design System
conte - ABEMA's Design SystemYusuke Goto
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望についてKen Azuma
 

Similar to Ps開発プロジェクトへのアジャイルプラクティスの適用 (20)

NTTデータはどうやってCCPMを導入したのか?
NTTデータはどうやってCCPMを導入したのか?NTTデータはどうやってCCPMを導入したのか?
NTTデータはどうやってCCPMを導入したのか?
 
プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣プロジェクトを成功に導くための秘訣
プロジェクトを成功に導くための秘訣
 
20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort20090924 YAMAHA Webforum Sort
20090924 YAMAHA Webforum Sort
 
AgilePM reading circle #9 - Cost Management
AgilePM reading circle #9 - Cost ManagementAgilePM reading circle #9 - Cost Management
AgilePM reading circle #9 - Cost Management
 
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
 
PMBOKで学ぶマネジメント基本のキ
PMBOKで学ぶマネジメント基本のキPMBOKで学ぶマネジメント基本のキ
PMBOKで学ぶマネジメント基本のキ
 
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
Application Re-Architecture Technology ~ StrutsからSpring MVCへ ~
 
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
 
Wagby10min2011
Wagby10min2011Wagby10min2011
Wagby10min2011
 
請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値請負型システム開発とプログラマの価値
請負型システム開発とプログラマの価値
 
失敗しないパッケージ導入7
失敗しないパッケージ導入7失敗しないパッケージ導入7
失敗しないパッケージ導入7
 
AgilePM読書会 #5
AgilePM読書会 #5AgilePM読書会 #5
AgilePM読書会 #5
 
失敗しないパッケージ導入1
失敗しないパッケージ導入1失敗しないパッケージ導入1
失敗しないパッケージ導入1
 
No020-01-suc3rum-20101129
No020-01-suc3rum-20101129No020-01-suc3rum-20101129
No020-01-suc3rum-20101129
 
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Appsグリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
 
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由
 
楽天エンジニアライフ
楽天エンジニアライフ楽天エンジニアライフ
楽天エンジニアライフ
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
 
conte - ABEMA's Design System
conte - ABEMA's Design Systemconte - ABEMA's Design System
conte - ABEMA's Design System
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
 

Ps開発プロジェクトへのアジャイルプラクティスの適用

  • 1. PS開発プロジェクトへの アジャイルプラクティスの適用 元気株式会社 PS事業部 大谷 孝治 PMP PMI日本支部 AgilePM研究会(準備プロジェクト) 2014年9月
  • 2. はじめに PS開発=遊技機(ぱちんこ、パチスロ)の開発のことです。大手電機メーカーのゲーム機ではありません。 ただ、ゲーム開発との共通点も多いかと思います。今回はその中でも特に時間とコストのかかる液晶画面に 表示される映像演出の開発のプロジェクトマネジメントに特化した内容となっています。 遊技機業界は、市場規模が縮小傾向の中、液晶画面の大型化や、ROM容量の増加により、演出数の増大 や、映像品質の向上が求められ、1つの遊技機の開発にかかるコストは増加傾向にあります。また、開発規 模の拡大に伴い、プロジェクトのマネジメントも複雑化し、管理工数が増え、さらにコストを押し上げる結果と なっています。 このような状況の中で、なるべく管理の手間は減らし、それでいてプロジェクトの重要な情報(進捗や、納品 日等)はクライアントやチームメンバーに正しく伝わるマネジメント手法について調査、検討した結果、アジャイ ル開発手法の導入に至りました。 この資料の中身は、2012年初めから2年半ほどの間、複数のプロジェクトにアジャイルプラクティスの一部を 適用した結果となります。ただ、具体的に記載出来ない部分が多々あり、また開発モデルも分かりやすくする ために単純化してあります。(実際の開発では、もっと各工程がぐちゃぐちゃに混ざっています。工程の順番す ら怪しいです) 市場が再び活気を取り戻すためには、ソフト開発がより洗練され、高品質で楽しい遊技機が市場に数多く導 入されることが重要です。ソフト開発会社の1PMが業界に与えられる影響は微々たるものですが、多少なりと も、この資料がお役に立てれば幸いです。
  • 3. アジェンダ • PS開発プロジェクトの概要~課題 • アジャイルプラクティスの適用事例 • 今後の課題や取り組み
  • 5. PS開発プロジェクトの概略図 ・アニメーション ・UI・3Dモデル ・CGムービー ・アニマティック…等 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 試行錯誤を繰り返し 価値ある映像を完成させる 完成したサンプル動画を 計画に沿って組み込む Value Driven Plan Driven ※実際に、素材、サンプル動画作成にも量産化というPlan Drivenな工程があり、組込工程にも Value Drivenな工程が存在します。 このようにPS開発は、Value DrivenとPlan Drivenが混在して開発が進んで行きます。 組込工程 企画・映像制作工程
  • 6. この構造は・・・ 企画 デザイン 設計 試作 評価 生産 技術 ※参考:トヨタ自動車東日本株式会社ホームページ(クルマができるまで)/http://www.toyota-ej.co.jp/process/ プレス ボディ 塗装 樹脂 成形 組立 検査 開発 生産 製造業の【開発】と【生産】の関係と似ています。
  • 7. ただし・・・ 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 Value Driven Value Driven Plan Driven 開発全体では、試作版をプレイして、 より良い製品をつくり上げるための変更を繰り返す、反復型のプロジェクトとなります 価値(映像品質、楽しさ、面白さなど)を高めるために、 クライアントの変更要求に最大限応えることが重要 ・・・ですが、変更を繰り返すため、コストや時間が計画と乖離しやすく、 マネジメントが難しいプロジェクトとなります。
  • 8. マネジメントが難しい理由① 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 クライアント 確認 マスター オーサリング プログラム 品管 ? 組込工程 答えのない業務のため、スケジュール通りに進まない。 組込工程へ流れる物量が不定 リテイクが何回発生するかわからない。 納期 納期と必要作業量から導かれる 組込工程の適正工数 作業出来る物 が少なく、手空 きが発生 納期直前の大量納品で、 キャパシティーオーバー or 最後まで作業量不足 遅延とコストオーバー が発生 お金は作業量にかかわらず、 用意した人員分かかる 成果物と工数との不一致も発生
  • 9. マネジメントが難しい理由② A社 (アニメ) B社 (3DCG) 素材 D社 (サンプル) サンプル E社 (サンプル) マスター F社 (マスター) プログラム C社 (3DCG) 物量の多さや、高度な専門性が要求される作業のため、一つの工程に 複数の開発会社が関わる。(スケジュール管理が複数の会社で分担される場合も) 複雑な開発体制
  • 10. マネジメントが難しい理由③ α1 β1 マスター マイルストーン毎の仕様変更 新アイデアのひらめき、動画を確認した結果、 ・・・などなど日常業務におけるいろいろなきっかけでの仕様変更 毎日のように行われる仕様変更 α2 特にパチンコ演出は、基本的にすべての映像が繋がっているため、 1つの演出の何気ない変更が、複数の演出の変更につながり、 大規模な仕様変更へと発展する場合もあります。 β2 後工程側で作業中にも関 わらず、仕様が変わること もよくあります
  • 11. プロジェクトへの影響 スケジュール管理が、非常に煩雑で、状況を確認し判断することが困難 このプロジェクトは、期日通りの終わるのか?遅れているのか? 今回の仕様変更が、プロジェクトに与える影響は? この先どの程度の人員が必要となるのか? なにがいつ納品されるか分からないため、常に作業の入れ替えが必要 管理のためだけに、数多くのリーダーが必要&多忙 納品管理、作業指示、スケジュール管理、工程管理、客先対応・・・ 調整のために繰り返されるミーティング等で現場への作業指示が遅れる スケジュール管理や工程管理だけを専門に行う人員が必要 各工程間を調整する人員が必要 全てのプロジェクトで、 当初計画よりも納期が遅延し、コストが超過 (元々計画自体が無茶なものもたまにありますが・・・)
  • 12. 従来のスケジュール管理 有名なスケジュール管理ソフト「Excel」を利用。 更新するだけでもかなりの時間がかかる上に、 日常的に納品遅れ、リテイク、仕様変更等が発生 するため、専属のスタッフがいなければ、管理出来 ない状況に陥る。 MS Projectも試験的に導入しましたが、頻繁な変更には不向き
  • 13. 改善したいこと① 不規則に発生する作業の管理を簡潔に ・作業の状況が一目で分かる! ・残作業の内容や量を常に意識出来る!! ・チームメンバーが、 指示を待たなくても 次の作業を進められる!!!
  • 14. 改善したいこと② スケジュール管理を簡潔に、 そして、正確に・・・ ・更新が簡単! ・遅延状態が一目で分かる!! ・仕様変更後の完了見込日が すぐ計算出来る!!!
  • 15. 改善により・・・ 単なる工数削減、コスト削減ではなく、 管理工数や、管理コストを重点的に削減 リーダークラスが、 ものづくりや品質管理に集中し、 よりよいものを、 クライアントが望むタイミングで納品出来る と言う効果を期待したい…
  • 17. アジャイルプラクティスの導入 試作版を何度もプレイして、変更を繰り返すPS開発プロジェクトとの親和性 アジャイルプラクティス導入のきっかけ アジャイルソフトウェア開発の12の原則 2.要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方に付けることによって、お客様の競争力を引き上げます。 ただ、スクラム等の開発手法をそのまま導入することは、 開発規模等いろいろな条件で難しいため、 効果のありそうなプラクティスをいくつか選び※、 「とりあえず、やってみよう」のノリでプロジェクトに導入 ※かんばん、バーンダウンチャート、朝会等
  • 18. 最初のプロジェクト プロジェクト概要 工程 プログラム 導入プラクティス かんばん、朝会、イテレーション(2週間) 目的 作業管理の簡潔化 1week 1week 1week 2week 2week 2week 作業予定 作業中 完了 かんばんのイメージ タスク名 作業者名 特記事項 付箋の書き方 計画内 タスク 計画外 タスク 緊急 タスク リテイクマーカー
  • 19. 結果は・・・ 1week 1week 1week 2week 2week 2week 作業予定 作業中 完了 計画外のタスクばかり どんどん増えて、 計画したタスクが 消化されない・・・ 他にも、 ・納品タイミングがばらばら(イテレーション毎の作業量が不定) ・前工程でのデータ作成不備による作業途中での中断 ・複数回の仕様変更によるリテイクマーカーの多重張り などなど、かんばんの本来の目的は果たせず 大失敗!... ただし、最終工程において計画通りに作業が進まない状況がはっきりと見え、 プロジェクト管理上の問題を、再認識出来る結果に。
  • 20. 次のプロジェクト プロジェクト概要 工程 素材、サンプル、マスター 導入プラクティス かんばん、朝会、バーンダウンチャート 目的 作業管理および、スケジュール管理の簡潔化 人員等 社内7~10名、協力会社3社(素材2、サンプル・マスタ1) 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 開発依頼時点で、申請1年後、これらの工程を半年でという状況。 (弊社比:50%~75%くらいの期間)
  • 21. 前回からの変更点 ・かんばん ・作業予定タスクの 随時追加 ・仕様変更タスクを 別タスクとして管理 ・バーンダウンチャート ・役割横断型チーム ・イテレーション ・複数色の付箋管理 ・リテイクマーカー 改善・追加 廃止
  • 22. 新しいかんばん 素材 素材 素材 素材 サンプル サンプル サンプル サンプル マスター マスター マスター マスター 作業予定 作業中 チェック待ち 完了 素材 サンプル マスター 展開するとWF型かんばん 協力会社の作業も一括で管理 付箋の動き
  • 23. バーンダウンチャート 当初の完了見込週 仕様変更後の 完了見込週 最初の全作業の見積日数総和 チーム平均作業工数(週間実績値) 仕様変更作業の見積日数総和 リテイク発生後の 完了見込週 完了見込週が簡単に算出できる リテイク分 ※こちらは社内工数のみの管理
  • 24. プラクティス導入の成果① 素材 素材 素材 素材 サンプル サンプル サンプル サンプル マスター マスター マスター マスター 作業予定 作業中 チェック待ち 完了 大量のデータが協力会社から 納品された結果、チェック人員の 作業負荷が増大し、ボトルネックに サンプル作業メンバーの一人を マスターチェック作業の担当へ ボトルネックが解消され、 後工程側への納品が スムーズに行われるように ポイントは、これらの施策を チームメンバー間で決めたこと かんばんと役割横断型チームによる成果
  • 25. プラクティス導入の成果② 導入前 導入後 労働時間イメージ スケジュール更新の工数が大幅に削減されただけでなく、 遅れ等が早い段階で計算出来るため、 計画的な残業や休日出勤などで、チームの速度をコントロールした結果、 プロジェクト期間全体で、労働時間が平準化された 最終成果物を、予定通りに納品!! コストも計画通り 終盤に極端に労働時間が増え、 遅延も発生するため、 その状態が長く続く。 その後、同規模のプロジェクトに関しては、同じような成果を発揮 バーンダウンチャートによる成果
  • 26. 成功要因 最大の成功要因は、 チームメンバーが、 自立的に動いたこと PM経験のないメンバーに、プラクティス導入の意味や、使い方等をレクチャーしたあとは、 その情報をもとに、チームで考え、工夫し、行動したことが、成功に繋がった。 プロジェクトチームの自己組織化が成功の鍵 チームを信頼し、適切な情報を正しく分かりやすく開示することが自己組織化を促す
  • 27. 開発現場の紹介 かんばんはキャビネットを利用 簡易撮影用のグリーンバック、 ホワイトボードは メンバーが後から追加 日々のコミュニケーションの 中核としての役割も ビニールテープ 導入にあたっての参考書籍(一部)⇒
  • 28. 考察的なもの 何も考えずに導入しても、うまくいきません。何を変えたいかに対して、適切なプラクティスを導 入し、すでにうまくいっているのであれば、無理に導入する必要はありません。また、やり方自 体、組織やチームに合わせる必要があります。 実際にやってみた結果、想像以上にチームが自らで判断して動くようになりました。ただ、全て のチームがそうなるかは分かりません。今回の結果、その後の同チームのプロジェクトの結果 を見る限り、最大の成功要因はプラクティスそのものではなく、チームの自己組織化だと考えま す。ただ、プラクティスにより適切な情報をチーム及び、組織の管理者、クライアントが得られる という点で、プラクティスそのものは有効に働きました。 今回、主に小規模~中規模プロジェクトでの適用で成果がでました。試験的に大規模(60~ 100名)のプロジェクトに適用しましたが、適用前に予想した通り、同じような成果は出ませんで した。大規模プロジェクトへの適用については、今後の課題や取り組みとして、以降のページで 紹介します。 クライアントによっては、これまで通りExcelを利用した各項目毎の詳細なスケジュールを求め られるため、結果的に専属のスタッフをアサインする必要がありました。無理に相手のやり方を 否定する必要はなく、このようなやり方もありますという形で理解を得ていければと思います。
  • 30. 大規模プロジェクトの問題 コミュニケーションパスの問題 メンバーn人のチームのコミュニケーションパスは、n(n-1)/2 チームメンバーが増えるほど、コミュニケーションロスが発生 アジャイル開発でも1つのチームは10名くらいまで。 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 工程間のデータやりとりの問題 主にここ 小、中規模プロジェクトでは、1~2名程度で埋められる工程間の問題も、 大規模プロジェクトでは埋められない。また、関わるメンバーが多いため、 少しのデータ不備や遅れが大きなコスト超過や遅延につながる
  • 31. 今後の課題や取り組み① 大規模プロジェクトへのアジャイルプラクティスの導入 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 役割横断型チームへの分割 理想はこの範囲を役割横断型チームで複数化 現実はこの範囲? どのような形の役割横断型チームへ分割し、 プロジェクト全体をどのような構成にするかは、検討の余地あり ここは1つのチーム
  • 32. 今後の課題や取り組み② 大規模プロジェクトにおける管理手法の確立 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 CCPMとの併用 最終納品前のバッファマネジメントは基本として、 スケジュールの変動が大きい、 この工程間でのバッファマネジメント バーンダウンチャートも、CCも、 チームのパフォーマンスを測定するという共通点がある
  • 33. 今後の課題や取り組み③ アジャイル開発に対応した組織づくり 企画 演出 絵コンテ 動画コンテ 素材 サンプル 動画 マスター オーサリング プログラム 品管 専門職とマルチスキル職 専門職が強みを発揮する工程(価値重視) マルチスキル職が強みを発揮する工程(計画重視) 役割横断型チームの構成には、マルチスキル職の存在が重要。 反面、遊技機の価値を高めるためには、高度な専門性を持つ人材の存在が強みに。 これらの人材をバランス良く採用、育成、評価するシステムが必要となるため、 プロジェクトのマネジメント手法だけでなく、組織の関与や活動がより重要
  • 34. AgilePM研究会の紹介 https://www.pmi-japan.org/news/info/2012_12_06_agile_pm_sig_initiation.php 研究会への参加申し込みはこちらから 2014年12月までは、PMI支部会員以外も参加出来ます https://www.pmi-japan.org/newsletter/2014/03/NL_vol58_2014_3.php 活動の詳細については、こちらのページのニューズレターを参照ください アジャイル開発における、プロジェクトマネジメントについて、事例や検証等を通して、 世の中に広く伝えていこうという趣旨の研究会となります。 参加者も、すでに現場で実践されてる方、これからの方、スクラムコーチとして開発現場 への導入をサポートしている方と、バラエティーに富んだ会となっています。 ただ、残念ながらゲーム業界はもちろん、PS業界の方は誰もいません。ほぼIT業界です。 一緒に活動する方いませんか?
  • 35. 参考書籍等 ・ゲーム開発プロジェクトマネジメント講座 (セミナー資料) 株式会社スクウェア・エニックス CTO 橋本 善久 ・アジャイルサムライー達人開発者への道 ・アジャイルソフトウェア開発スクラム ・XPエクストリーム・プログラミング実行計画 ・アジャイルな見積りと計画づくり ・アジャイルなゲーム開発 ・リーン開発の現場 ・スクラム・ブートキャンプ ザ・ブック ・アジャイル開発の本質とスケールアップ ・TOC/CCPM標準ハンドブック ・トヨタ生産方式 ・Redmineによるタスクマネジメント実践技法 ・わかりやすいアジャイル開発の教科書 その他、AgileJapan、研究会等でのセミナー、読書会、イベントキャラバン等