[Slide] プロジェクトマネジメント勉強会(PMBOK概要)20100824

5,533 views

Published on

Published in: Design
1 Comment
22 Likes
Statistics
Notes
No Downloads
Views
Total views
5,533
On SlideShare
0
From Embeds
0
Number of Embeds
1,080
Actions
Shares
0
Downloads
77
Comments
1
Likes
22
Embeds 0
No embeds

No notes for slide

[Slide] プロジェクトマネジメント勉強会(PMBOK概要)20100824

  1. 1. プロジェクトマネジメント勉強会 (PMBOK概要) @take3000 Takehara.Masashi 調達兼マーケティング #DevLOVE、#FxUG、#SilverlightUG、#redajp
  2. 2. http://www.everystockphoto.com/photo.php?imageId=22643
  3. 3. ①この勉強会には新しい知識はありません②集中してください③わからない単語はその場で質問してください④私はウソをつきます
  4. 4. はじめに
  5. 5. プロジェクトマネジメントって何?
  6. 6. っていう漠然としたテーマではじめるとドツボにはまるので、今日はPMBOKに沿ってお話しします。
  7. 7. PMBOKって何?
  8. 8. ProjectManagementBookOfKnowledge
  9. 9. ウィキペディアによるとhttp://blogs.toonboom.com/professional/wp-content/uploads/2008/05/wikipedia-logo.png
  10. 10. PMBOK──────────────────────PMBOK(ぴんぼっく、Project Management Body of Knowledge、プロジェクトマネジメント知識体系)とは、プロジェクトマネジメント協会が提供する、プロジェクトマネジメントの知識体系である。目次 [非表示]概要──────────────────────PMBOKは、国際的に標準とされているプロジェクトマネジメントの知識体系(ガイド、手法、メソドロジー、ベストプラクティス)であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する[1]。PMBOKはプロジェクトマネジメント協会(PM協会、Project ManagementInstitute、PMI)が、PMBOKガイド(A Guide to the Project ManagementBody of Knowledge、PMBOK Guide)として提供しており、最新版は第4版である。またPMI本部が認定するプロジェクトマネジメントの国際資格に、PMP(プロジェクトマネジメントプロフェッショナル)がある。日本にはPMI日本支部がある。
  11. 11. 多くのフォロアー?が生まれた。
  12. 12. ・SWEBOK (ソフトウェアエンジニアリング基礎知識体系)・SQuBOK (ソフトウェア品質知識体系)・BABOK (ビジネスアナリシス知識体系)・SABOK (システムアナリシスとの知識体系)・REBOK (要求工学知識体系)・DMBOK (データマネジメント知識体系)
  13. 13. http://www.everystockphoto.com/photo.php?imageId=22643
  14. 14. この知識体系に専門知識はついていません。(※ 別売り)
  15. 15. ※用法用量は守ってお使い下さい。(まずSWEBOKとの併用がお奨めです) http://arara.ti-da.net/e1643627.html
  16. 16. PMBOKによるプロジェクトの定義(特性)
  17. 17. 1.有期性2.独自性3.段階的詳細化
  18. 18. 1.有期性2.独自性3.段階的詳細化
  19. 19. 始まりがあって、終わりがある。 http://www.shinrankai.or.jp/jinsei/jin01.htm
  20. 20. 1.有期性2.独自性3.段階的詳細化
  21. 21. 同じ物はない。 http://jp.makezine.com/blog/2008/01/post_173.html
  22. 22. 1.有期性2.独自性3.段階的詳細化
  23. 23. 細かいこと(本当のこと)は、後から少しずつわかる。。。
  24. 24. プロジェクトとは、ある一定の期間において、唯一の成果物(モノ/サービス)を生み出すための活動である。
  25. 25. プロジェクトマネジメントって何?
  26. 26. あえて
  27. 27. 一言で表すと
  28. 28. フォース に調和を もたらす ことhttp://www.mystarwarsposter.com/star-wars-poster/
  29. 29. 説明しよう
  30. 30. ウィキペディアによるとhttp://blogs.toonboom.com/professional/wp-content/uploads/2008/05/wikipedia-logo.png
  31. 31. プロジェクトマネジメント(プロジェクト管理)とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。
  32. 32. プロジェクトマネジメント(プロジェクト管理)とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。
  33. 33. ちょっと足らない
  34. 34. プロジェクトマネジメント(プロジェクト管理)とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。また、利害が相反する関係者の意見を集約し、制約を利用しつつ、プロジェクトにおける共通目的を達成するために行うあらゆる活動。
  35. 35. だから
  36. 36. フォース に調和を もたらす ことhttp://www.mystarwarsposter.com/star-wars-poster/
  37. 37. じゃ、何をするの?
  38. 38. プロセス順に説明
  39. 39. でも「プロセス」っていうと
  40. 40. こういうのとか
  41. 41. こういうのとかhttp://www.thegeofactor.com/wordpress/wp-content/uploads/2008/01/rugby%20scrum.jpg
  42. 42. こういうイメージがあると思うんです。 http://www.marine-marine.com/costco_list_plastic_wrap.html
  43. 43. PMBOKのプロセスはもうちょっと汎用性のある(抽象的)なものです。
  44. 44. http://jibun.atmarkit.co.jp/lskill01/special/pmbok3rd/pmbok01.html
  45. 45. 確かに抽象的だけど、どんなプロジェクトであってもこの5つは共通して必要。
  46. 46. プロセスの偏重は罠
  47. 47. 身近な例
  48. 48. ガンプラ
  49. 49. 1.頭2.胴体3.手4.足5.シールド6.ライフル
  50. 50. 1.頭2.胴体3.手4.足?5.シールド?6.ライフル?
  51. 51. プロジェクトは「独自性」の特性を備えていることに注意し、プロセスを盲信しないこと。アジャイルだから上手くいく、ウォーターフォールだから失敗するわけではないこと。
  52. 52. (~略)これにより、本書で述べる知識、スキル、プロセスを常にすべてのプロジェクトへ画一的に適用すべきであるといっているわけではない。プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの程度の厳密さで実施すべきかを決定する責任がある。(略~)-PMBOKより(3版か4版のどっちか)
  53. 53. 何をやるのか?やらないのか?
  54. 54. 曇りなき眼で見定めてプロジェクトを計画すること。 http://ameblo.jp/caqsule/image-10485874410-10457918270.html
  55. 55. 「計画?」
  56. 56. http://jibun.atmarkit.co.jp/lskill01/special/pmbok3rd/pmbok01.html
  57. 57. 何をどう計画する?
  58. 58. PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ用意されている。
  59. 59. 1. 統合2. スコープ3. タイム4. コスト5. 品質6. 人的資源7. コミュニケーション8. リスク9. 調達
  60. 60. プロジェクトスコープマネジメント• スコープ計画• スコープ定義• WBS作成スコープ• 検証スコープ・コントロール
  61. 61. プロジェクトタイムマネジメント•アクティビティ定義•アクティビティ順序設定•アクティビティ資源見積り•アクティビティ所要期間見積り•スケジュール作成•スケジュール・コントロール
  62. 62. プロジェクト人的資源(リソース)マネジメント• 人的資源計画• プロジェクト・チーム編成• プロジェクト・チーム育成• プロジェクト・チームのマネジメント
  63. 63. プロジェクトコストマネジメント• コスト見積もり• コストの予算化• コスト・コントロール
  64. 64. プロジェクト品質マネジメント•品質計画•品質保証•品質管理
  65. 65. プロジェクトコミュニケーションマネジメント• コミュニケーション計画• 情報配布• 実績報告• ステークホルダー・マネジメント
  66. 66. プロジェクトリスクマネジメント• リスク・マネジメント計画• リスク識別• 定性的リスク分析• 定量的リスク分析• リスク対応計画• リスクの監視コントロール
  67. 67. プロジェクト調達マネジメント• 購入・取得計画• 契約計画• 納入者回答依頼• 納入者選定• 契約管理• 契約終結
  68. 68. プロジェクト統合マネジメント• プロジェクト憲章作成• プロジェクト・スコープ記述書暫定版作成• プロジェクトマネジメント計画書作成• プロジェクト実行の指揮・マネジメント• プロジェクト作業の監視コントロール• 統合変更管理• プロジェクト終結
  69. 69. インプットとアウトプットに着目し、シンプルに考えること。全て下記のパターンでできてる。1. ○○のインプット2. ○○のツールと技法3. ○○のアウトプット
  70. 70. いきなり全部細かにかくのはしんどいから、簡単なところから。
  71. 71. 顧客名・プロジェクト名・担当者名・プロジェクト(システム)の目的、背景 -スコープ/SOW(Statement of work) *機能(ユースケース上)スコープ *システム構成上のスコープ *作業スコープ *成果物スコープ -契約、支払いに関する特記事項 -予算 -時期 -技術における特記事項,制約 -開発時の体制/調達
  72. 72. このレベルでもしっかり書く(把握する)だけで、プロジェクトの見通しは随分違う。
  73. 73. http://www.everystockphoto.com/photo.php?imageId=22643
  74. 74. コミュニケーション
  75. 75. コミュニケーションパスを求める式 n(n-1)/2 n=メンバーの数※コミュニケーションパスは指数的に増加します。
  76. 76. このパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生する。
  77. 77. 「計画」
  78. 78. 丌確実性のコーン http://www.pmaj.or.jp/online/0901/message4.html
  79. 79. ブルックスの法則http://perfdynamics.blogspot.com/2010/06/calculating-cost-of-elastic-capacity.html
  80. 80. PERT図
  81. 81. ガントチャート
  82. 82. バーンダウンチャート
  83. 83. SWEBOKから一つだけ抜粋
  84. 84. 「瑕疵」
  85. 85. 1. エラー2. フォールト3. 故障4. 間違い
  86. 86. そろそろまとめ
  87. 87. プロジェクトは 人が為すことhttp://s3.amazonaws.com/estock/nasas1/7/51/79/everystockphoto-nasa-space-75179-o.jpg
  88. 88. 知識も大事だけど、相手の気持ちを推し量ることも大事
  89. 89. メンバーに対するプロジェクトマネジメント
  90. 90. 正しい管理の四つの本質1. 適切な人材を雇用する。2. その人材を適所にあてはめる。3. 人びとの士気を保つ。4. チームの結束を強め、維持する。(それ以外のことは全部管理ごっこ)「デッドライン―ソフト開発を成功に導く101の法則」トム デマルコ (著), 伊豆原 弓 (翻訳) 日経BP社
  91. 91. って、
  92. 92. こんなPMの人も 言ってましたよね。http://unrealitymag.com/wp-content/uploads/2009/02/johnny-depp-jack-sparrow.jpg
  93. 93. お客さまに対するプロジェクトマネジメント
  94. 94. “AgileConference2009”というイベントで聞いた話が元ネタ※想い出補正付き
  95. 95. 質問者「アジャイル型の開発プロセスを導入したいが、日本では請負契約でウォーターフォール型の開発が主流となっている。どうすれば良いか?」
  96. 96. 回答者
  97. 97. そういう問題は私たちも経験している。契約書はテンプレート化されており、現場と接点の薄い調達部門で処理される。よって変えられない。
  98. 98. しかし、私たちが柔軟な開発を望むように、顧客だって柔軟な対応を望んでいるのではないか?
  99. 99. そこで(アジャイルにある)、ショートサイクルリリースを行い、少しずつ顧客の信頼を得ていくことを心掛けている。
  100. 100. 信頼関係の構築
  101. 101. 「1対1もオフェンスの選択肢の 一つにすぎねぇ それが わからねぇうちは おめーには負ける気がしねえ」 仙道彰(陵南バスケ部) http://www.great-saying.com/w-slumdunk51.html
  102. 102. 「顧客要求の本質」を掴むことが大事!
  103. 103. http://www.amazon.co.jp/gp/product/images/4822282686/ref=dp_image_0?ie=UTF8&n=465392&s=books
  104. 104. 次回「要求開発」編
  105. 105. 乞うご期待

×