第3章：プロジェクトマネジメントフレームワーク(その1)

ここでは、プロジェクトマネジメントフレームワークの以下のキーワードについてまとめます。

プロジェクトの定義
プログラムの定義
ステークホルダー
社会、経済、環境の持続性
3つの制約条件
プロジェクトライフサイクル
プロジェクトマネジメントライフサイクル
プロセス同士の関連性
プロセス分類表

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

プロジェクトの定義(p.4)

• 独自の製品やサービスを創造するために実施される期間が区切られた業務
  
• 始まりと終わりがある
  
• 目標、目的、ゴールetc…がある
  
• 人によって実施される
  
• 限られた資源によって制約される
  
• 計画→実行→コントロール→計画… と繰り返される
  

プログラムの定義(p.10)

• 関連性のあるプロジェクトのグループ
  
• 調和の取れた方法でマネジメントされるプロジェクト群
  
• 反復的/周期的業務も含まれる
  

ステークホルダー(p.16)

• プロジェクトマネージャ、スポンサー、チームだけではない
  
• プロジェクトにより、自分の利益にプラスまたはマイナスの影響を受ける個人/組織
  
• プロジェクトに積極的に関与している個人/組織
  
• プロジェクトマネージャ　－　プロジェクトをマネジメントする責任を有する個人
  
• 顧客　－　プロジェクトの成果物を使用する個人/組織
  
• スポンサー　－　プロジェクトの資源を資金面から支える個人/組織
  
• チーム　－　プロジェクトのタスクを実行する人々
  

社会、経済、環境の持続性(p.27)
プロジェクトは、社会、経済、環境に対し責任、説明義務(アカウンタビリティ)がある。プロジェクトが終結し、年月が経った後も、説明義務は持続する。
…要はずっと先を見越しておきなさい、ってこと。原発は火力よりも安上がりだ～と強弁し、バカバカ作りまくっておきながら、「解体→保管費用を計算に入れてませんでしたので税金で補完して下さい」と泣きついているヤツ逝って良し!!

3つの制約条件(p.29)
「3つ」といっておきながら、キーワードは実はたくさんある。多分この3つが基本
　・コスト
　・時間
　・スコープ
でこれに、付随するのが、
　・品質
　・顧客満足(カスタマーサティスファクション)
これらは相互に影響しあい、ときにはトレードオフの対象となる(現実では、顧客満足は対象から外される)。
　チョト余談。リアルでは、よく「品質第一、品質が大事だ、ヒンシツゥゥ-」という品質厨房がいる。やつに聞いてごらん「品質とは何ですか?」ってね、きっと答えられないよ。PMBOK日本語版にその定義が書いてあるけれど、意味わかってねぇぞ、こいつも。翻訳ソフトそのまんまだし。

品質とは、あるものの、明示された、または暗黙のニーズを満たす能力に関する特性の全体(p.96)

　あのな、品質とは「予定したものとできたものの差」なんだよ。例えば、

• ソフトウェアなら、要求仕様書と出来上がったソフトウェアとのちがい
• 建築物なら、青写真と建造物自体のちがい
• サービスなら、提供サービスの説明と実際に行われたサービスのちがい

なの! 。

　品質のよしあしを決めるのは「予定した/計画した/要求された」ものと「現実に行われた/できあがった/提供された」もののブレなんだよ! よく「品質はお客様に評価していただく」というけれど、それは大ウソ。お客様が「事前に合意した/定義した/要求した何か」が決めるんだよ! ここでいう「何か」は設計書であれ、仕様書であれ、好きなものを入れてちょうだい、ただし残るものでね(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試験対策の目次に戻る
--