« 不具合情報に関する三菱自の意思決定過程 | トップページ | 第3章:プロジェクトマネジメントフレームワーク(その2) »

第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試験対策の目次に戻る
--

|

« 不具合情報に関する三菱自の意思決定過程 | トップページ | 第3章:プロジェクトマネジメントフレームワーク(その2) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 第3章:プロジェクトマネジメントフレームワーク(その1):

« 不具合情報に関する三菱自の意思決定過程 | トップページ | 第3章:プロジェクトマネジメントフレームワーク(その2) »