PMBOKで学ぶプロジェクトマネジメントの基礎

6,598 views
6,243 views

Published on

GamePM#11で使用した資料です
https://sites.google.com/site/gpmahome/studysession11

Published in: Technology
0 Comments
20 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,598
On SlideShare
0
From Embeds
0
Number of Embeds
583
Actions
Shares
0
Downloads
105
Comments
0
Likes
20
Embeds 0
No embeds

No notes for slide

PMBOKで学ぶプロジェクトマネジメントの基礎

  1. 1. PMBOKで学ぶマネジメントの基礎<br />
  2. 2. 自己紹介<br />田中 宏幸<br />(株)イリンクス CEO/ Programmer<br />現在Vita、PS3、フィーチャーフォンでゲームやエンジン等作ってます。<br />一応プロマネの資格持ってます<br />認定スクラムマスター (CSM)<br />PMI認定Project Management Professional<br />Twitter : swiftnest<br />
  3. 3. 何故マネジメントを学ぶ必要があるのか?<br />
  4. 4. プロジェクトは中止だ!!<br />
  5. 5. http://leadinganswers.typepad.com/leading_answers/2007/05/large_project_r.html<br />
  6. 6. ゲーム開発はプロジェクト期間が長い傾向にある<br />
  7. 7. 面白いゲームを楽しく作りたい何故それがこんなに難しいんだろう?<br />
  8. 8. 国内Project成功率(Success)<br />・2003年 26.7%・2008年 31.1%<br />
  9. 9. http://itpro.nikkeibp.co.jp/article/NC/20081126/319990/<br />
  10. 10. プロジェクトマネジメントは「銀の弾丸」ではないが正しく使えばプロジェクトの成功率を上げる事は出来る!!<br />
  11. 11. PMBOKで学ぶマネジメントの基礎<br />
  12. 12. 1.PMBOKって何?<br />顧客が説明した要件<br />
  13. 13. PMBOKって何?<br />「Project Management Body of Knowledge」<br />日本語訳:プロジェクトマネジメント知識体系<br />「PMI」というプロジェクトマネジメントのデッカイ組織が作成<br />米国標準協会(ANSI)で米国標準規格として承認<br />会員は全世界154カ国<br />参考:PMP(Project Management Professional)」の資格保持者<br />事実上プロジェクトマネジメントの国際標準<br />
  14. 14. PMBOKって何<br />過去の成功プロジェクトや失敗プロジェクトの共通点をまとめたもの<br />ITだけでなく、製造全般、果ては文化祭まで何にでも適応できるようになっている<br />具体性に欠ける<br />
  15. 15. PMBOKからの派生<br />SWEBOK – ソフトウェアエンジニアリング(SoftWare Engineering Body Of Knowledge)<br />BABOK – ビジネス解析(Business Analysis Body of Knowledge)<br />SABOK – システムアナリスト(Systems Analyst Body Of Knowledge)<br />REBOK – 要求工学(Requirements Engineering Body Of Knowledge)<br />他にも「SQuBOK」「DMBOK」等々<br />
  16. 16. プロジェクトって何?<br />■プロジェクトって何?<br />定められた期間内に今までにはない目標を達成する<br />「有期性」と「独自性」があるもの<br />■プロジェクトの成功って何?<br />プロジェクトに課せられた様々な「制約事項」を満たしプロジェクトの目的が達成されたどうかで判断<br />制約事項:良くあるのは「スコープ(作業範囲)、タイム、コスト」<br />「完成が大幅に遅れたけど、皆で頑張り、学ぶことも多かった。 つまりこのプロジェクトは成功と言える!」<br />PMBOK的には失敗プロジェクト<br />
  17. 17. プロジェクトを成功させるには?<br />要求事項を特定し、目標を確立し1.時間2.予算3.品質4.スコープの競合する要求のバランスをとりステークホルダーがそれぞれ抱える関心・期待に応えるために仕様・計画を適用させる<br />
  18. 18. 以外に少ない?<br />
  19. 19. 2.要求事項を特定し目標を確立する<br />顧客が説明した要件<br />プロジェクト<br />リーダーの理解<br />
  20. 20. よくある話<br />このゲームの売りって何だっけ?<br />このゲームってターゲット層はどこ?<br />クライアントからネット対戦が必須って言われてたような…?<br />目標売上って何万本だっけ?<br />こんな状況で良いゲームが作れるハズがない!<br />
  21. 21. プロジェクト憲章<br />
  22. 22. プロジェクト憲章<br />プロジェクト立ち上げ時に作成する概要書<br />目的<br />シリーズの続編として、固定ファン層を…更に進化した…<br />スコープ(作業内容)<br />「PS3用RPGで、DLコンテンツでコスチュームチェンジ…」<br />ざっくりとしたスケジュールやコスト、制約事項<br />成功基準<br />国内販売50万本、ファミ通でゴールド<br />主要ステークホルダー(関係者)<br />クライアント、自社の管理部門<br />
  23. 23. クライアントや主要スタッフと認識を一致させる<br />
  24. 24. アジャイルサムライにもプロジェクト憲章と似たツールが紹介されてます<br />
  25. 25. インセプションデッキInception Deck<br />
  26. 26. 詳細はアジャイルサムライで紹介されてます。<br />またインセプションデッキは@RyuzeeさんのサイトでDLできます。「インセプションデッキ」で検索!<br />
  27. 27. 3.荒ぶる四天王<br />顧客が説明した要件<br />プロジェクト<br />リーダーの理解<br />営業・コンサルタントの表現、約束<br />
  28. 28. 荒ぶる四天王<br />バランスを取る<br />※図はアジャイルサムライのP86を使用<br />
  29. 29. スコープ<br />どんどん増える機能<br />遅れるスケジュール<br />増えるコスト<br />低下する品質<br />スコープは全ての上流<br />WBS<br />
  30. 30. WBS(Work Breakdown Structure)<br />http://www2.denshi.numazu-ct.ac.jp/mirsdoc2/mirs98sf/curr/num0007a/sysplan.html<br />
  31. 31. 段階的詳細化<br />
  32. 32. 段階的詳細<br />開発前にはどんなスコープがあるのか判らない<br />全ては判らなくても、大枠なら判る<br />いったん大枠で記載しておき、プロジェクトがすすむにつれて徐々に詳細にしていく<br />予定は一度で完成させるのではなく徐々に改善<br />
  33. 33. スケジュール<br />基本はガントチャートやマイルストーン<br />段階的詳細化<br />スクラムなどは付箋で管理<br />プロジェクトの進行状況を確認するだけでなく作業待ちやクリティカルパスの確認にも有効<br />見積る際は三点見積りを使うと良い<br />(4×「通常値」+「悲観値」+「楽観値」)÷6<br />多分5日で終わるけど、早ければ3日、最悪9日掛かるかな-> (4 x 5 + 3 + 9) ÷ 6 = 5.3日<br />
  34. 34. ガントチャート<br />http://minna-de-gantt.com/<br />
  35. 35. おまけ・スクラムでは付箋を推奨<br />http://knowscrum.com/<br />
  36. 36. コスト<br />ゲームの場合、殆どが人件費<br />遅れを取り戻そうと人を増やすとその分コストも増える<br />それ以外には、ソフトや開発機など<br />コスト管理には「人月表」が使われる事も多い<br />
  37. 37. ブルックスの法則(Brooks' law)<br />遅れを取り戻そうと人を入れると、一定以上は逆に遅くなる<br />http://blogs.itmedia.co.jp/morisaki/2007/10/brook_f97f.html<br />
  38. 38. 品質<br />検査より予防<br />TDD(CppUnit、GoogleTest)<br />CI(Jenkins)<br />静的解析(QAC++、Coverity)<br />レビュー(review)<br />頻度、対象<br />デバッグ(debug)<br />期間と規模<br />
  39. 39. QC7つ道具<br />特性要因図<br />管理図<br />ヒストグラム<br />フローチャート<br />ランチャート<br />パレート図<br />散布図<br />
  40. 40. 四天王が暴れない様に常に監視<br />
  41. 41. 変更管理委員会<br />
  42. 42. 統合変更管理<br />計画が変更になる際に必ず行う<br />変更内容を「変更管理委員会」が影響範囲などを調査し、変更するかどうかを判断する<br />変更管理委員会は主要メンバーと主要ステークホルダーがなることが多い<br />承認された場合、様々な計画(スコープ、スケジュール、コスト)が変更される場合がある<br />
  43. 43. プロジェクトを成功させるには?<br />要求事項を特定し、目標を確立し時間予算品質スコープの競合する要求のバランスをとりステークホルダーがそれぞれ抱える関心・期待に応えるために仕様・計画を適用させる<br />
  44. 44. 4.ステークホルダーがそれぞれ抱える関心・期待に応える<br />顧客が説明した要件<br />プロジェクト<br />リーダーの理解<br />営業・コンサルタントの表現、約束<br />プロジェクトの<br />ドキュメント<br />
  45. 45. ステークホルダー<br />プロジェクトに関係している人達<br />チームメンバー<br />クライアントのプロデューサー<br />社長<br />購入者<br />ゲームショップの定員<br />雑誌編集者<br />関心・期待に答える?<br />
  46. 46. コミュニケーション<br />
  47. 47. プロジェクトマネジャの仕事の80%はコミュニケーション<br />
  48. 48. コミュニケーション<br />いつ、誰に、何を、どうやって伝えるかを決める<br />毎週火曜日にプロデューサーに進捗をメールで送る<br />毎朝10:00にメンバー全員が集まって「昨日何をやったか」「今日何をやるか」「問題」を報告し合う<br />常時プログラマー全員が相談し合える用にSkypeルームを立ち上げておく<br />メールを全員に送ったらコミュニケーションという訳ではない!!<br />
  49. 49. コミュニケーションパス<br />N x (N – 1) / 2<br />人が増えるほど伝わらなくなっていく<br />
  50. 50. コミュニケーションナメんな<br />
  51. 51. 問題<br />プロジェクトマネージャの仕事をいくつか紹介しましたが<br />今紹介した以外の仕事を1つ挙げて下さい<br />
  52. 52. プロジェクマネージャーの仕事<br /> 要求事項定義<br /> スコープ定義<br /> WBS作成<br /> スコープ検証<br /> スコープ・コントロール<br /> ステークホルダー特定<br /> コミュニケーション計画<br /> 情報配布<br /> ステークホルダーの期待のマネジメント<br /> 実績報告<br /> アクティビティ定義<br /> アクティビティ順序設定<br /> アクティビティ資源見積り<br /> アクティビティ所要期間見積り<br /> スケジュール作成<br /> スケジュール・コントロール<br /> コスト見積り<br /> 予算設定<br /> コスト・コントロール<br /> 品質計画<br /> 品質保証<br /> 品質管理<br /> 人的資源計画<br /> プロジェクト・チーム編成<br /> プロジェクト・チーム育成<br /> プロジェクト・チームのマネジメント<br /> リスク・マネジメント計画<br /> リスク特定<br /> 定性的リスク分析<br /> 定量的リスク分析<br /> リスク対応計画<br /> リスクの監視コントロール<br /> 調達計画<br /> 調達実行<br /> 調達管理<br /> 調達終結<br /> システム開発プロジェクトにおける考慮点<br /> プロジェクト憲章作成<br /> プロジェクトマネジメント計画書作成<br /> プロジェクトの実行の指揮・マネジメント<br /> プロジェクト作業の監視コントロール<br /> 統合変更管理<br /> 要求事項定義<br /> スコープ定義<br /> WBS作成<br /> スコープ検証<br /> スコープ・コントロール<br /> ステークホルダー特定<br /> コミュニケーション計画<br /> 情報配布<br /> ステークホルダーの期待のマネジメント<br /> 実績報告<br /> アクティビティ定義<br /> アクティビティ順序設定<br /> アクティビティ資源見積り<br /> アクティビティ所要期間見積り<br /> スケジュール作成<br /> スケジュール・コントロール<br /> コスト見積り<br /> 予算設定<br /> コスト・コントロール<br /> 品質計画<br /> 品質保証<br /> 品質管理<br /> 人的資源計画<br /> プロジェクト・チーム編成<br /> プロジェクト・チーム育成<br /> プロジェクト・チームのマネジメント<br /> リスク・マネジメント計画<br /> リスク特定<br /> 定性的リスク分析<br /> 定量的リスク分析<br /> リスク対応計画<br /> リスクの監視コントロール<br /> 調達計画<br /> 調達実行<br /> 調達管理<br /> 調達終結<br /> プロジェクト憲章作成<br /> プロジェクトマネジメント計画書作成<br /> プロジェクトの実行の指揮・マネジメント<br /> プロジェクト作業の監視コントロール<br /> 統合変更管理<br />42項目!!<br />
  53. 53.
  54. 54. 計画、実行、監視コントロールで行うこと<br />
  55. 55. 人的資源<br />メンバーの役割と権限の決定<br />メンバーをいつ、どこから調達するのか<br />メンバーの育成計画<br />リーダーの育成<br />勉強会・カンファレンスの出席<br />自習時間<br />モチベーションの向上<br />マズローの欲求5段階説、ハーツバークの衛生理論 etc...<br />
  56. 56. リスクと調達<br />リスク<br />起こりうるリスクを予め想定し、対策を検討しておく<br />例)ハードの発売日が伸びた、メンバーが揃わなかった<br />主な対策:「回避」「転嫁」「軽減」「受容」<br />調達<br />調達する時期と内容<br />調達内容例)外注、ミドルウェア、機材等<br />内外制分析<br />内部で製作するのか、それとも外から入手するのか<br />評価基準とプロポーザル<br />
  57. 57. 終結<br />各種資料のまとめ<br />ふりかえり・ポストモーテム<br />
  58. 58. 5.まとめ<br />プロジェクト<br />リーダーの理解<br />営業・コンサルタントの表現、約束<br />プロジェクトの<br />ドキュメント<br />顧客が本当に必要だったもの<br />
  59. 59. プロジェクトの流れ<br />立ち上げ<br />計画(Plan)<br />監視コントロール<br />(Check)<br />実行(Do)<br />終結<br />
  60. 60. まとめ<br />プロジェクト憲章<br />WBS<br />スケジュール<br />コスト<br />品質<br />統合変更管理<br />コミュニケーション<br />
  61. 61. まとめ<br />マネジメントはプロジェクトの成功率に関わる<br />プロジェクトには荒ぶる四天王がいるのでそれを抑えるためには「計画」と「監視」が重要<br />変更は必ず起きるがそこからの最計画が重要<br />マネジメントの基本はコミュニケーション8割!<br />マネジメントごっことの違いは「改善」が働くか<br />

×