第3章:プロジェクトマネジメントフレームワーク(その1)
ここでは、プロジェクトマネジメントフレームワークの以下のキーワードについてまとめます。
プロジェクトの定義
プログラムの定義
ステークホルダー
社会、経済、環境の持続性
3つの制約条件
プロジェクトライフサイクル
プロジェクトマネジメントライフサイクル
プロセス同士の関連性
プロセス分類表
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
プロジェクトの定義(p.4)
- 独自の製品やサービスを創造するために実施される期間が区切られた業務
- 始まりと終わりがある
- 目標、目的、ゴールetc…がある
- 人によって実施される
- 限られた資源によって制約される
- 計画→実行→コントロール→計画… と繰り返される
プログラムの定義(p.10)
- 関連性のあるプロジェクトのグループ
- 調和の取れた方法でマネジメントされるプロジェクト群
- 反復的/周期的業務も含まれる
ステークホルダー(p.16)
- プロジェクトマネージャ、スポンサー、チームだけではない
- プロジェクトにより、自分の利益にプラスまたはマイナスの影響を受ける個人/組織
- プロジェクトに積極的に関与している個人/組織
- プロジェクトマネージャ - プロジェクトをマネジメントする責任を有する個人
- 顧客 - プロジェクトの成果物を使用する個人/組織
- スポンサー - プロジェクトの資源を資金面から支える個人/組織
- チーム - プロジェクトのタスクを実行する人々
社会、経済、環境の持続性(p.27)
プロジェクトは、社会、経済、環境に対し責任、説明義務(アカウンタビリティ)がある。プロジェクトが終結し、年月が経った後も、説明義務は持続する。
…要はずっと先を見越しておきなさい、ってこと。原発は火力よりも安上がりだ~と強弁し、バカバカ作りまくっておきながら、「解体→保管費用を計算に入れてませんでしたので税金で補完して下さい」と泣きついているヤツ逝って良し!!
3つの制約条件(p.29)
「3つ」といっておきながら、キーワードは実はたくさんある。多分この3つが基本
・コスト
・時間
・スコープ
でこれに、付随するのが、
・品質
・顧客満足(カスタマーサティスファクション)
これらは相互に影響しあい、ときにはトレードオフの対象となる(現実では、顧客満足は対象から外される)。
チョト余談。リアルでは、よく「品質第一、品質が大事だ、ヒンシツゥゥ-」という品質厨房がいる。やつに聞いてごらん「品質とは何ですか?」ってね、きっと答えられないよ。PMBOK日本語版にその定義が書いてあるけれど、意味わかってねぇぞ、こいつも。翻訳ソフトそのまんまだし。
あのな、品質とは「予定したものとできたものの差」なんだよ。例えば、
- ソフトウェアなら、要求仕様書と出来上がったソフトウェアとのちがい
- 建築物なら、青写真と建造物自体のちがい
- サービスなら、提供サービスの説明と実際に行われたサービスのちがい
なの! 。
品質のよしあしを決めるのは「予定した/計画した/要求された」ものと「現実に行われた/できあがった/提供された」もののブレなんだよ! よく「品質はお客様に評価していただく」というけれど、それは大ウソ。お客様が「事前に合意した/定義した/要求した何か」が決めるんだよ! ここでいう「何か」は設計書であれ、仕様書であれ、好きなものを入れてちょうだい、ただし残るものでね(w
だから、品質管理だけ力を入れることは不可能なの! 品質管理をちゃんとやるためには、少なくとも最初に「なにを作るのか/したいのか」が明確化されてなければならないの! PMBOKでいうと「スコープ」だね。んで、どれぐらいお金がかかるのか(コスト)、納期はいつになるのか(時間)を事前に決めてなきゃね。
「なにを作るのか/したいのか」が明確化されていないのであれば、品質なんてないも同然。自分が何を欲しているのすら説明できない厨房がいるけれど、そいつは「ヒンシツ」という語句はクチに出すことすら禁止な。 …をっといかんいかん。三菱自のアレで、にわか品質厨房が評論家を気取っているから、ついアツくなっちまった。
よく「コスト、時間、品質」と三拍子であげられるけれど、これで違うことが分かったよね。「コスト、時間、スコープ」です。んで、コストは見積もりどおり、時間(期限/納期)も予定通り、スコープ(要求仕様/事前説明)どおりのモノが提供されて、初めて「高品質」と評価されるのです。
以上、「品質」についての余談でした。リアルでの「品質」とPMPの "quality" はかなり違うのでご注意を。
ちょいネタ。品質関連でこの選択肢がでてきたら正解と思ってもいいです。
- 要求事項への適合
- 使用適合性
プロジェクトライフサイクル(p.11-15)
プロジェクトマネジメントライフサイクルとは違うことに注意。プロジェクトライフサイクルとは、プロジェクトにおいてやる仕事のこと。例えば、
ソフトウェア開発の場合…
1) 要求仕様の分析
2) 基本・詳細設計
3) コーディング
4) テスト
5) インテグレーション
6) 移行、運用
建設プロジェクトの場合…
1) フィージビリティ・スタディ(採算性調査)
2) 計画
3) 設計
4) 施工
5) 引渡し
6) 操業開始
これらの1)~6)をフェーズと呼ぶ。各フェーズの中に、以下の「プロセス」がぐるぐる回っていると考える(常にそうなるとは限らない)。
プロジェクトマネジメントライフサイクル(p.32-37)
以下のプロセス群により構成される。
・立ち上げプロセス群
・計画プロセス群
・実行プロセス群
・コントロールプロセス群
・終結プロセス群
情報は(p.31図3-1)の通りに流れる
・立ち上げ→計画→実行→コントロール→終結
・コントロール→実行
・コントロール→計画
それぞれのプロセス群は、必ずしも段階を追って順々に実行される必要はなく、オーバーラップする部分もある(p.31図3-2)
一つのフェーズの中に、プロジェクトマネジメントライフサイクルが含まれている(p.31図3-3)。
- 立ち上げプロセス群:プロジェクトを認可する
- 計画プロセス群:目標を定義して、詳細化する。その目標を達成するためにやるべきことを選択する
- 実行プロセス群:計画を実行するために人・資源の調整を行う
- コントロールプロセス群:計画からの差異を検出するため、進捗を定期的にチェックする。必要な場合は是正処置を行う
- 終結プロセス群:プロジェクトをを承認し、プロジェクトを終わりへ導く
プロセス同士の関係性
プロセス同士の関係性は、以下の図を暗記すること。矢印は情報の流れを示す。「○○の次に何をするのか?」の設問の大半は、ここから出題されるから。
p.32図3-4
p.33図3-5
p.35図3-6
p.35図3-7
p.37図3-8
プロセス分類表示
39のプロジェクトマネジメントプロセスを、知識エリアへ割り付けた一覧表(p.38図3-9)を暗記すること。
・プロジェクト計画の段階的な詳細化はローリング・ウェーブ計画法と呼ばれ、計画作成が反復的で継続的なプロセスであることを示している
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--

| 固定リンク
コメント