Download - プロジェクトマネジメント入門以前 Web
プロジェクトマネジメント入門以前
プロジェクトマネジメント入門以前
プロジェクトマネジメント入門以前
2009/04/18
minamo
2009/04/18
minamo
タイトルは・・・
こちらから取りました!
何年も前に読んだ本ですが、良書です!
突然ですが!突然ですが!
デスマーチになったことがある人は挙手!
デスマーチになったことがある人は挙手!
マスターアップ後の常套句
• 「いやぁ、なんとかなったね」
• 「次回からはもっと余裕を持って(ry」
• 「今回は特別だったから」
マスターアップ後の常套句
• 「いやぁ、なんとかなったね」なんとかなってない。
• 「次回からはもっと余裕を持って(ry」また繰り返す悲劇。
• 「今回は特別だったから」プロジェクトは毎回特別。
出来上がった商品も・・・
• デスマーチをこなしたからといって、いい商品ができるわけじゃない
• やるべきことで、やり残したことがいっぱい
• ゲームをプレイしてても、「ここはこうするつもりだったんだろうな」と感じる部分も
このままじゃダメだ!!このままじゃダメだ!!
なんとかせねば!
なんとかせねば!
理想を言えば・・・
• 売れる/ユーザーに楽しんでもらえる
• プロジェクトに振り回されるのではなく、コントロールしたい
• スタッフが疲弊せずに、イキイキと制作にあたることが出来る
今は・・・
• せっかくの「スタッフの技術」と「努力」が、ちゃんと作品に反映されてない!!
技術&努力
作品
本来なら・・・
• 本来なら、こうなるべき!!
技術&努力
作品
いやいや
• 理想はこうだ!!
技術&努力
作品
チームワー
ク
そもそも・・・
プロジェクトがコントロールを失った状態というのは、
損失以外のなにものでもない!
こういうのを解決しようとする活動
プロジェクトの成功を目指す活動を、
プロジェクトマネジメント
というようだ。(とても広義な意味で)
ちゃんと考えてるIT業界
ゲーム業界のお隣であるIT業界は、
そのあたりのことを
ちゃんと考えているらしい。
いや、ちょっと訂正
ちゃんと考えている企業は
ちゃんと考えているらしい。
そして何より、体系立った方法論がある!
→もうあるんだったら、 IT業界を参考にするのが早そうだ!
IT業界を参考にする理由
類似点–プロジェクトベース– 仕様+プログラム(+素材)で成り立つ
そしてさらに・・・–ゲーム業界より歴史が長い(ゲーム:25年? IT:40年?)
– 市場規模・就業人口が多い(ゲームソフト: 8500億円 ハード: 2兆円 ↑国内+海外出荷 2008CESAゲーム白書より IT業界: 12.3兆円)
– 体系立ったプロジェクトの進め方がある
今日の趣旨
何があるか知ろう!
今日の趣旨
何があるか知ろう!
本日のお品書き
• プロジェクトマネジメントとは?
• プロジェクトマネジメント手法
• PMBOKの全体像
• プロジェクトライフサイクルと開発手法
プロジェクトマネジメントとは?
プロジェクトマネジメントとは?
プロジェクトの定義
プロジェクトとは・・・• 有期的であること• 独自性があること
ゲーム関係でプロジェクトではない例としては・・・•ユーザーサポート•ネットゲームの運営
プロジェクトの成功とは
Q:プロジェクトの成功とは?
制作側にフォーカスすると・・・• 品質(クオリティ)• 予算(コスト)• 納期(スケジュール)これらを満たすこと。
その他、プロジェクトごとに売り上げ以外の目標が設定されていることもある。
A:売り上げ目標を上回ること
プロジェクトマネジメントとは
プロジェクトマネジメントといって思い浮かべるもの。
• スケジュール管理?• 外注管理?• 予算管理?
プロジェクトマネジメントとは「プロジェクトを成功に導く活動」
のこと。
プロジェクトマネジメントとは
現状との区別をハッキリさせると・・・
プロジェクトマネジメントとは「プロジェクトを成功に導く活動」
“ 各種知識やスキルを用いて”プロジェクトを成功に導く活動
どうやって成功に導くか?
どうやって成功に導くか?
プロジェクトマネジメント手法プロジェクトマネジメント手法
~QCDマネジメント~
昔から製造業全般で使われていたマネジメント手法。QCDはそれぞれ次の意味。•Q: Quality(品質)•C: Cost(コスト)•D: Delivery(納期)
現在は“満たすべき基準”として語られることが多い印象。
~PDCAサイクル~
製造業や建設業における管理サイクル・マネジメント。PDCAはそれぞれ次の通り。
•Plan(計画) •Do(実行)•Check(評価)•Act(改善)
Planから Actまで順番に行い、再び Planに戻る。こうして、継続的な改善をしていく。
Plan
DoCheck
Act
紹介 ~CMM(CMMI)~
CMM( capability maturity model)→ 能力成熟度モデル
企業や組織をある一定の基準で判定しレベル付けすることで、向上を目指す。主にソフトウェア開発を対象としている。
•レベル1 プロセスが確立されていない初期段階。•レベル2 プロジェクトを計画通りに組織的に実行できる。
ただし、特定のリーダーや技術者に依存している。•レベル3 首尾一貫したプロセスを標準として持っている。•レベル4 標準化されたプロセスを定量的に測定し、
洗練化していく状態。•レベル5 技術・要件環境の違いによって、
標準プロセスを最適化して用いられる段階。
国内でレベル3以上は10社前後。「CMMレベル=開発力」ではないが、知っておいて損はない。
~PMBOK~ 注目!
PMBOK( Project Management Body of Knowledge)→ プロジェクトマネジメント知識体系ガイド
• アメリカの非営利団体PMI が定めた物• 現在のデファクトスタンダード• 適応範囲は製造業全般• PMBOKの資格であるPMPは全世界で
約25万人、日本で2万人が取得している
PMBOKにフォーカ
ス
PMBOKにフォーカ
ス
<理由>使えるのが多いから
<理由>使えるのが多いから
<理由>メジャーだから
<理由>メジャーだから
PMBOKの全体像PMBOKの全体像
PMBOKを導入する利点
PMBOKは、「計画と追跡の優れたツール」である。
• プロジェクトのコントロールができる“コントロールを取り戻せ!”
• マネジメントしないときと比べて、理想の着地点に近づける
• 改善のための“気づき”を与えてくれる
“ 現状把握”できれば怖くない
個人的な意見として……
• プロジェクトの現状を正しく“実感として”把握できれば、マネジメントの6~7割は完了している
のではないかと思う。それくらい現状を把握することは重要。でも、これが難しい。⇒PMBOKは”現状把握”を助けてくれる!
PMBOKの全体像
PMBOKは
• 9つの知識エリア(ジャンル)
• 5つのプロセス群(開発ライフサイクル)
によって定められている。
9つの知識エリア
ジャンルごとに9つに分けたもの。• 統合・マネジメント• スコープ・マネジメント• スケジュール・マネジメント• コスト・マネジメント• 品質・マネジメント• 組織・マネジメント• コミュニケーション・マネジメント• リスク・マネジメント• 調達・マネジメント(外注マネジメント)
5つのプロセス群
プロジェクト・ライフサイクルごとに5つに分けたもの。• 立ち上げフェーズ• 計画フェーズ• 実行フェーズ• 管理フェーズ• 終結フェーズ
今回は・・・
GamePM#2でやった「よりぬきPMBOK」から、さらによりぬいてみた
今回は・・・
前回は知識エリアでまとめましたが、今回はプロセス群でまとめました。
• 9つの知識エリア(ジャンル)
• 5つのプロセス群(開発ライフサイクル)
立ち上げフェーズ
プロセス群 その1
立ち上げフェーズの主なプロセス
• プロジェクト憲章作成(総合マネジメント)
• プロジェクトスコープ記述書暫定版作成(総合マネジメント)
計画フェーズ
プロセス群 その2
計画フェーズの主なプロセス
• WBS作成(スコープ・マネジメント)• スケジュール作成(スケジュール・マネジメント
• コスト見積もり(コスト・マネジメント)• コストの予算化(コスト・マネジメント)
• 品質計画(品質・マネジメント)
• 人的資源計画(人的資源・マネジメント)
• コミュニケーション計画(コミュニケーション・マネジメント)
• リスク・マネジメント計画(リスク・マネジメント)
その他色々。計画フェーズが一番多い。
WBS作成
• プロジェクトの作業をすべて洗い出す⇒いわゆるタスクリストのようなもの
↓行う際に重要なこと• MECE(漏れなくダブりなく)で洗い出す
• 段階的に割り出す• WBS番号を振る
WBS作成 サンプル1
プロジェクト名
プロジェクト基盤 実装 素材作成 ・・・・・・
企画立案 仕様書作成
・・・・・・ ・・・・・・
タイトル画面 キャラ選択画面 ・・・・・・ ・・・・・・
WBS作成 サンプル2
WBS作成 ワーク パッケージ
• WBSの最下層のタスクを、ワーク パッケージという
• ワーク パッケージは細かくなりすぎないように(2~4週間程度)
• 1つのワーク パッケージに付き、1人の担当者を振り分けられるレベルまで細分化する
コスト見積もり
• 各アクティビティ、各リスクを見積もる• 見積もり方法
– 類推見積もり(コレが多いか?)– ボトムアップ見積もり(アクティビティごとに見積もる)
– 係数見積もり(コンテンツビジネスでは使わない?)
• コンティンジェンシー予備は最低でも1割くらいほしい(日本では承認されないことが多いので、見積書上は他の項目に割り振っておくのが主流)
コストの予算化
• プロジェクトをコントロールするための、コスト・ベースラインを設定する
• 時系列で、どのタイミングでどれだけコストがかかるかまとめる
• 通常、S字カーブを描く
コス
ト
時間
ベースライン
コミュニケーション計画
• 情報配布の計画を立てる
• 具体的には次のことを決める– 誰に?– いつ?– どのような情報を?– どのような形式で?– 誰が?
• 不足が無く、かつ細かすぎないのがベスト
実行フェーズ
プロセス群 その3
実行フェーズの主なプロセス
• 情報配布(品質・マネジメント)
• プロジェクトチーム編成(人的資源・マネジメント
• プロジェクトチーム育成(人的資源・マネジメント)
• 納入者選定(調達・マネジメント)
etc……
管理フェーズ
プロセス群 その4
管理フェーズの主なプロセス
• 統合変更管理(統合・マネジメント)
• スコープ・コントロール(スコープ・マネジメント)• スケジュール・コントロール(スケジュール・マネジメント
• コスト・コントロール(コスト・マネジメント)• 品質管理(品質・マネジメント)
• プロジェクト・チーム・マネジメント(人的資源・マネジメント)
• ステークホルダー・マネジメント(コミュニケーション・マネジメント)
• リスク監視・コントロール(リスク・マネジメント)
etc……
統合変更管理
• プロジェクト途中で発生した変更を管理する
↓行う際に重要なこと• 変更要望を上げるときのルールを作る• 要求された変更を分析し、承認を行う• 変更ログを付けて情報を共有する
統合変更管理 サンプル
Excelで十分可能!
コストコントロール
• コストの予算化で作成したコスト・ベースラインと実際の経過を比較して、正しい対処をする
• 対処としては・・・– 追加予算の調達– コンティンジェンシー
予備の投入– スコープの縮小
時間
ベースライン
実コスト
成果物
コス
ト
アーンドバリュー法
時間
ベースライン
実コスト
成果物コス
ト
スケジュール差異
コスト差異
現在完了予定
超過予算予想
これがアーンドバリュー法
終結フェーズ
プロセス群 その5
終結フェーズの主なプロセス
• プロジェクト終結(統合・マネジメント)
• 契約終結(調達・マネジメント)
雰囲気をつかんで頂けましたか?
雰囲気をつかんで頂けましたか?
まとめるとPMBOKは・・・
• 計画重視のマネジメント手法
計画 コントロール
まとめるとPMBOKは・・・
• プロジェクトでコントロールすべき要素を全て網羅してある
• 当たり前のことを、しっかりと記した教科書的な内容
プロジェクトマネジメントの基礎
しかししかし
違った視点もある違った視点もある
PMBOKの紹介を聞いて・・・
• Q.PMBOKの紹介を聞いて、違和感や疑問を感じませんでしたか?
A.計画通りに行くことは少ない
A.計画通りに行くことは少ない
プロジェクトライフサイクルと制作手法
プロジェクトライフサイクルと制作手法
プロジェクトライフサイクルとは
• プロジェクトの開始から終了までのフェーズの移り変わり
• PMBOKであれば、 立ち上げフェーズ 計画フェーズ 実行フェーズ 管理フェーズ 終結フェーズ
プロジェクトライフサイクルとは
• プロジェクトライフサイクルには、いくつか種類が存在する
PMにおける制作手法とは
• 明確な定義はないけど・・・
プロジェクトライフサイクル
+フェーズごとのプロセス
(スキル)
ウォーターフォール開発
~ウォーターフォール開発~
一番単純な構造の開発手法。
基本計画
外部設計
内部設計
コーディング
テスト(デバッグ)
リリース仕様は変わらないという前提で進められる。
~ウォーターフォール開発~
• 利点– 承認プロセスが明確– 分業しやすい– 文書の管理がしやすい
• 欠点– 手戻り(仕様変更)が発生した際のコストが高い
–プロジェクト終盤にならないと動作しない– 大量に文書化する必要がある
~ウォーターフォール開発~
• 先ほどのPMBOKと相性が非常によい
• 大規模開発に向いていると言われている
※ITとゲームでは、“大規模開発”の規模が違う
GTA4:100億円(ゲームの最大規模)
携帯電話:80億~100億(このくらいらしい) 三菱東京UFJ銀行 システム統合PJ: 技術者6000人・2500億円
プロトタイピングプロトタイピング
~プロトタイピング~
実働するプロトタイプを早期に制作し、それに拡張を加え完成を目指す。(プロトタイプを破棄を前提に作ることもある)
プロトタイプA プロトタイプB マスター
追加&改良
追加&改良
設計(仕様策定)
実装
テスト
実装
テスト
実装
テスト
回数はプロジェクトによる
~プロトタイピング~
•利点– 早い段階から動いている物がある– 各段階で仕様変更のチャンスがある
•欠点– 作業者が「後から考えればいい」と、最初の仕様策定の手を抜く可能性がある
– プロトタイプ作成に時間をかけすぎることがある
一般的なゲーム制作に一番近い開発手法。
そして!そして!
これを話したかった!
これを話したかった!
アジャイル開発アジャイル開発
~アジャイル開発~
アジャイルソフトウェア開発とは、一つの開発手法を示すのではなく、次の特徴を持つ開発手法全般のことを示す。
• プロセスやツールよりも、個人と対話を優先する • 包括的なドキュメントよりも、動作するソフトウェアを優先する
• 契約の交渉よりも、顧客との協調を優先する • 計画に従うよりも、変化への対応を優先する
-アジャイルソフトウェア宣言より-
簡潔に言うと・・・
• 仕様変更を“抱擁する”柔軟な開発「計画通りのもの」ではなく、「本当に必要なもの」を作り出す
• 開発者がイキイキと開発できることを目指す
アジャイル開発の主な特性
• 1週間~1ヶ月の短い期間で区切る(イテレーションなどと呼ぶ)
• フィードバックを重視する
• どうやって仕様の変更に耐えるかの工夫がある
• コミュニケーションにフォーカスした工夫がある
アジャイル開発の利点と欠点
• 利点– 仕様変更を前提としている– 制作者が作っていて楽しい– 常に最新の状態の動くソフトウェアがある
• 欠点– 承認プロセスがあいまい– 書類化しない部分が多い– 予算見積もりがしづらい⇒大規模開発に向かない
ほんの少しだけご
紹介
ほんの少しだけご
紹介
アジャイル開発:XPアジャイル開発:XP
アジャイル開発:XP
XP( eXtreme Programming )エクストリームプログラミング。WindowsXPとは全く関係ない。
• アジャイル開発の代表的な開発手法• 4つの価値と19のプラクティス• ペアプログラミングや短期リリース、テスト駆動開発などで有名
• 2005年前後に流行した
プラクティス例 ~スタンドアップミーティング~
• 毎日実施(プロジェクト規模により変化)
• 立ったままのミーティング
• 10分程度で終了
• 「前日のタスク」「本日のタスク」「問題点」の3点のみをひとりひとり報告する
• 解決すべき問題点は、ミーティング後に解決する
プラクティス例 ~ペアプログラミング~
• 2人で1台のPCを使ってプログラム
• 「ドライバー」がコードを書き、「ナビゲーター」は後ろから見ている
• 「ナビゲーター」は気になる点を助言をする
• 一定時間ごとに役割を交代する
プラクティス例 ~テスト駆動開発~
• ITでは“テスト”と呼ばれる、プログラムを検査するプログラムを組むことが多い(ほとんど?)
• 通常“テストプログラム”はコーディングの後に行うが、XPではコーディングの前に書く
• 例)四捨五入をする関数に対して、・「 9.49」を渡して「 9」が返ってくるか・「 9.5」を渡して「 10」が返ってくるかなどなど
ゲームに有効かはわからないケド
アジャイル開発:SCRUMアジャイル開発:SCRUM
アジャイル開発:SCRUM
スクラム/SCRUM XPが技術的要素を多く含んでいるのに対して、チームとしての振る舞いを中心としている。
「XPは開発されているソフトウェアの質を増強し、 スクラムはプロジェクトの日々の運営を増強する」
(アジャイルソフトウェア開発スクラムより)
• ゲーム開発で一番事例が多い開発手法• 30日のイテレーション(スプリント)で開発• PDCAを毎日/スプリントごとに行うようなもの?• 欠点:日本の書籍が少ない
詳しくは今度!詳しくは今度!
ここまで紹介してきましたがここまで紹介してきましたが
一番考えなきゃいけないことが残ってます
一番考えなきゃいけないことが残ってます
ゲーム開発に適応するにはゲーム開発に適応するには
ITとゲームの主な違い
• クオリティ(品質)の指標
• グラフィック/サウンドの扱い
• ビジネスモデル
クオリティ(品質)の指標
• ゲームにおける品質– おもしろさ– 遊びやすさ– 見た目の質– バグがないこと– 統一性
• ITにおける品質– 顧客の求めるものを提供すること– 保守・拡張のしやすさ– バグがないこと– 統一性
グラフィック・サウンド
ゲームではグラフィックとサウンドの質が品質を大きく左右する。
特にグラフィックは開発要員の半分を占めるため、この違いは大きい。
ビジネスモデル
• ゲームのビジネスモデル– パッケージ売り–ダウンロード販売⇒お客様は一般ユーザー
• ITのビジネスモデル– Webサービス– 組み込み系– 上流・下流工程に分かれた受託開発⇒お客様は企業のことが多い
で、どうするかで、どうするか
次回以降に一緒に考えていきましょう
次回以降に一緒に考えていきましょう
最後に最後に
導入に当たって
• こういうプラクティスは、一気に導入しようとすると失敗する
• ミニマムに導入して広げていくのがベター
• 今回のPMBOKも、全部やろうとしないで、気になったひとつを試してみるといいかも
テーラリング
• テーラリング(仕立て直し)とは、自分の状況に合わせてカスタマイズすること
• 手法は型(テンプレート)なので、必ずテーラリングを行う必要がある!
参考書籍
• プロジェクトマネジメント標準 PMBOK入門 / 広兼修• Webプロジェクトマネジメント標準 PMBOKでワンランク上のWebディレクションを目指す / 林千晶 , 高橋宏祐
• プロジェクトマネジメント リテラシ / アイテック情報技術教育研究部
• ベースラインで成功する プロジェクトマネジメント / 深沢隆司
• 実践 ! プロジェクト管理入門 増補改訂版 / 深沢隆司• 実務で役立つプロジェクトマネジメント / カーティス・R・クック 中西 全二
• 実務で役立つWBS入門 / Gregory T. Haugan 伊藤 衡• アジャイルソフトウェア開発スクラム / ケン シュエイバー ・マイク ビードル 他
ご静聴ありがとうございました!
ご静聴ありがとうございました!