プロジェクトマネジメント勉強会（PMBOK概要）

@take3000Takehara.Masashi

調達兼マーケティング#DevLOVE、#FxUG、#SilverlightUG、#redajp

http://www.everystockphoto.com/photo.php?imageId=22643

①この勉強会には新しい知識はありません

②集中してください

③わからない単語はその場で質問してください

④私はウソをつきます

はじめに

プロジェクトマネジメントって何？

っていう漠然としたテーマではじめるとドツボにはまるので、今日はPMBOKに沿ってお話しします。

ＰＭＢＯＫって何?

ProjectManagementBookOfKnowledge

ウィキペディアによると

http://blogs.toonboom.com/professional/wp-content/uploads/2008/05/wikipedia-logo.png

PMBOK─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─PMBOK（ぴんぼっく、Project Management Body of Knowledge、プロジェクトマネジメント知識体系）とは、プロジェクトマネジメント協会が提供する、プロジェクトマネジメントの知識体系である。目次 [非表示]

概要─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─PMBOKは、国際的に標準とされているプロジェクトマネジメントの知識体系（ガイド、手法、メソドロジー、ベストプラクティス）であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する[1]。PMBOKはプロジェクトマネジメント協会（PM協会、Project Management Institute、PMI）が、PMBOKガイド（A Guide to the Project Management Body of Knowledge、PMBOK Guide）として提供しており、最新版は第4版である。またPMI本部が認定するプロジェクトマネジメントの国際資格に、PMP（プロジェクトマネジメントプロフェッショナル）がある。日本にはPMI日本支部がある。

多くのフォロアー?が生まれた。

・SWEBOK(ソフトウェアエンジニアリング基礎知識体系)

・SQuBOK(ソフトウェア品質知識体系)

・BABOK(ビジネスアナリシス知識体系)

・SABOK(システムアナリシスとの知識体系)

・REBOK(要求工学知識体系)

・DMBOK(データマネジメント知識体系)

http://www.everystockphoto.com/photo.php?imageId=22643

この知識体系に専門知識はついていません。(※ 別売り)

※用法用量は守ってお使い下さい。(まずSWEBOKとの併用がお奨めです)

http://arara.ti-da.net/e1643627.html

PMBOKによるプロジェクトの定義(特性)

1.有期性2.独自性3.段階的詳細化

1.有期性2.独自性3.段階的詳細化

http://www.shinrankai.or.jp/jinsei/jin01.htm

始まりがあって、終わりがある。

1.有期性2.独自性3.段階的詳細化

http://jp.makezine.com/blog/2008/01/post_173.html

同じ物はない。

1.有期性2.独自性3.段階的詳細化

細かいこと(本当のこと)は、後から少しずつわかる。。。

プロジェクトとは、ある一定の期間において、唯一の成果物(モノ/サービス)を生み出すための活動である。

プロジェクトマネジメントって何？

あえて

一言で表すと

フォースに調和をもたらすこと

http://www.mystarwarsposter.com/star-wars-poster/

説明しよう

ウィキペディアによると

http://blogs.toonboom.com/professional/wp-content/uploads/2008/05/wikipedia-logo.png

プロジェクトマネジメント（プロジェクト管理）とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。

プロジェクトマネジメント（プロジェクト管理）とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。

ちょっと足らない

プロジェクトマネジメント（プロジェクト管理）とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。また、利害が相反する関係者の意見を集約し、制約を利用しつつ、プロジェクトにおける共通目的を達成するために行うあらゆる活動。

だから

フォースに調和をもたらすこと

http://www.mystarwarsposter.com/star-wars-poster/

じゃ、何をするの？

プロセス順に説明

でも「プロセス」っていうと

こういうのとか

こういうのとか

http://www.thegeofactor.com/wordpress/wp-content/uploads/2008/01/rugby%20scrum.jpg

こういうイメージがあると思うんです。

http://www.marine-marine.com/costco_list_plastic_wrap.html

PMBOKのプロセスはもうちょっと汎用性のある(抽象的)なものです。

http://jibun.atmarkit.co.jp/lskill01/special/pmbok3rd/pmbok01.html

確かに抽象的だけど、どんなプロジェクトであってもこの5つは共通して必要。

プロセスの偏重は罠

身近な例

ガンプラ

1.頭2.胴体3.手4.足5.ｼｰﾙﾄﾞ6.ﾗｲﾌﾙ

1.頭2.胴体3.手4.足?5.ｼｰﾙﾄﾞ?6.ﾗｲﾌﾙ?

プロジェクトは「独自性」の特性を備えていることに注意し、プロセスを盲信しないこと。アジャイルだから上手くいく、ウォーターフォールだから失敗するわけではないこと。

（～略）これにより、本書で述べる知識、スキル、プロセスを常にすべてのプロジェクトへ画一的に適用すべきであるといっているわけではない。プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの程度の厳密さで実施すべきかを決定する責任がある。（略～）－PMBOKより(3版か4版のどっちか)

何をやるのか？

やらないのか？

曇りなき眼で見定めてプロジェクトを計画すること。

http://ameblo.jp/caqsule/image-10485874410-10457918270.html

「計画？」

http://jibun.atmarkit.co.jp/lskill01/special/pmbok3rd/pmbok01.html

何をどう計画する？

PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ用意されている。

1. 統合2. スコープ3. タイム4. コスト5. 品質6. 人的資源7. コミュニケーション8. リスク9. 調達

プロジェクトスコープマネジメント• スコープ計画

• スコープ定義

• WBS作成スコープ

• 検証スコープ・コントロール

プロジェクトタイムマネジメント•アクティビティ定義•アクティビティ順序設定•アクティビティ資源見積り•アクティビティ所要期間見積り•スケジュール作成•スケジュール・コントロール

プロジェクト人的資源(ﾘｿｰｽ)マネジメント• 人的資源計画

• プロジェクト・チーム編成

• プロジェクト・チーム育成

• プロジェクト・チームのマネジメント

プロジェクトコストマネジメント• コスト見積もり

• コストの予算化

• コスト・コントロール

プロジェクト品質マネジメント•品質計画•品質保証•品質管理

プロジェクトコミュニケーションマネジメント• コミュニケーション計画

• 情報配布

• 実績報告

• ステークホルダー・マネジメント

プロジェクトリスクマネジメント• リスク・マネジメント計画

• リスク識別

• 定性的リスク分析

• 定量的リスク分析

• リスク対応計画

• リスクの監視コントロール

プロジェクト調達マネジメント• 購入・取得計画

• 契約計画

• 納入者回答依頼

• 納入者選定

• 契約管理

• 契約終結

プロジェクト統合マネジメント• プロジェクト憲章作成

• プロジェクト・スコープ記述書暫定版作成

• プロジェクトマネジメント計画書作成

• プロジェクト実行の指揮・マネジメント

• プロジェクト作業の監視コントロール

• 統合変更管理

• プロジェクト終結

インプットとアウトプットに着目し、シンプルに考えること。全て下記のパターンでできてる。

1. ○○のインプット2. ○○のツールと技法3. ○○のアウトプット

いきなり全部細かにかくのはしんどいから、簡単なところから。

顧客名・プロジェクト名・担当者名・プロジェクト（システム）の目的、背景－スコープ/SOW(Statement of work)

＊機能（ユースケース上）スコープ＊システム構成上のスコープ＊作業スコープ＊成果物スコープ

－契約、支払いに関する特記事項－予算－時期－技術における特記事項,制約－開発時の体制/調達

このレベルでもしっかり書く(把握する)だけで、プロジェクトの見通しは随分違う。

http://www.everystockphoto.com/photo.php?imageId=22643

コミュニケーション

※コミュニケーションパスは指数的に増加します。

コミュニケーションパスを求める式

n(n-1)/2

n=メンバーの数

このパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生する。

「計画」

丌確実性のコーンhttp://www.pmaj.or.jp/online/0901/message4.html

ブルックスの法則http://perfdynamics.blogspot.com/2010/06/calculating-cost-of-elastic-capacity.html

PERT図

ガントチャート

バーンダウンチャート

SWEBOKから一つだけ抜粋

「瑕疵」

1. エラー2. フォールト3. 故障4. 間違い

そろそろまとめ

プロジェクトは人が為すこと

http://s3.amazonaws.com/estock/nasas1/7/51/79/everystockphoto-nasa-space-75179-o.jpg

知識も大事だけど、相手の気持ちを推し量ることも大事

メンバーに対するプロジェクトマネジメント

正しい管理の四つの本質1. 適切な人材を雇用する。2. その人材を適所にあてはめる。3. 人びとの士気を保つ。4. ﾁｰﾑの結束を強め、維持する。(それ以外のことは全部管理ごっこ)

「デッドライン―ソフト開発を成功に導く101の法則」トム デマルコ (著), 伊豆原 弓 (翻訳) 日経BP社

って、

こんなPMの人も言ってましたよね。

http://unrealitymag.com/wp-content/uploads/2009/02/johnny-depp-jack-sparrow.jpg

お客さまに対するプロジェクトマネジメント

“AgileConference2009”というイベントで聞いた話が元ネタ※想い出補正付き

質問者「アジャイル型の開発プロセスを導入したいが、日本では請負契約でウォーターフォール型の開発が主流となっている。どうすれば良いか？」

回答者

そういう問題は私たちも経験している。契約書はテンプレート化されており、現場と接点の薄い調達部門で処理される。よって変えられない。

しかし、私たちが柔軟な開発を望むように、顧客だって柔軟な対応を望んでいるのではないか？

そこで(アジャイルにある)、ショートサイクルリリースを行い、少しずつ顧客の信頼を得ていくことを心掛けている。

信頼関係の構築

「１対１もオフェンスの選択肢の一つにすぎねぇそれが わからねぇうちはおめーには負ける気がしねえ」

仙道彰（陵南バスケ部）

http://www.great-saying.com/w-slumdunk51.html

「顧客要求の本質」を掴むことが大事!

http://www.amazon.co.jp/gp/product/images/4822282686/ref=dp_image_0?ie=UTF8&n=465392&s=books

次回「要求開発」編

乞うご期待