第4章：プロジェクト統合マネジメント(その1)

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

まとめ役(integrator)としてのプロジェクトマネージャ
制約条件
過去の情報
プロジェクト計画法
プロジェクトマネジメント情報システム
アーンドバリューマネジメント
プロジェクト計画書
プロジェクト計画の策定
プロジェクト計画書の承認
ベースライン
キックオフミーティング
作業認可システム
変更要求

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

まとめ役としてのプロジェクトマネージャ
　プロジェクトの実行プロセスでは、メンバはそれぞれの仕事に没頭しているはず。スポンサーやシニアマネージャがワヤワヤ言ってくることがある。プロジェクトマネージャはそうしたワヤワヤのせいで時間などをムダにしないように、プロジェクトを守る必要がある(もちろんキチンと報告するが)。

　プロジェクトマネージャは、プロジェクト全体を統括する役目がある。アッタリマエなんだけど、意外と抜けているのがコレ。

制約条件(p.110)
　プロジェクトチームが取れる行動を狭める要素を制約条件という。主なものに、

• コスト
  
• 時間
  
• 人的資源
  
• 組織構造(によりプロマネの権力が弱いとか)
  
• 労働組合
  
• メンバの好み(仕事のやり方)
  

過去の情報
　過去のプロジェクトの実績データのこと。きちんとまとめ&記録していない会社があるが、個人レベルでもいいからやっておくこと。次に使える情報をもっている/もっていないの差は大きい。過去の情報は、例えば…

• タスク(WBSのさらに内側の作業)
  
• WBS
  
• 作業報告書
  
• 見積もり
  
• プロジェクト計画書
  
• 教訓
  
• ベンチマーク
  
• リスク
  
• (必要とした)リソース
  
• 文書(指示書、メール、通達書など)
  

教訓(p.49)
　PMBOKでは軽～く触れられているだけだが、超重要ナリ。教訓とは、

• そのプロジェクトで採択した是正措置、結局合ってたのか、違っていたのかについて書いてあるモノ
  
• もう一度そのプロジェクトをやるのなら、変わっていたかもしれない選択肢について書いてあるモノ
  
• その実装方式が採択された理由など、プロジェクトの技術的観点
  
• どうやってWBSを作成したのか?リスクを洗い出したのか?
  
• コミュニケーションやリーダシップをどう発揮していたのか
  

　上記の観点で当てはまる議事録、メール、是正措置の結果などがそれにあたる。教訓は、「過去の記録」というタイトル名で記録される。

　PMBOKでは、教訓を記すのは、終結フェーズの完了手続きプロセス(p.125)だと書いてある。ウソだ。教訓はプロジェクトのどの段階でも得られるし、記されるべきである。

　ﾄﾞｷｭｿ営業が大甘甘甘見積もりを行った結果、実行プロセスで苦悩しているのなら、その段階で記録するべきだし、脳無トップがクチバシを突っ込んだおかげで大規模な手戻りが発生したのなら、そこがどの段階であれ、その時点で残しておくべき。記憶は風化するし、仮にも、そのﾊﾞｶﾓﾉ以外の尽力によりプロジェクトが成功したら、「その誤判断は無かったこと」になるのだから(あなたの会社でもよくある話でしょ?)。

プロジェクト計画法(p.44)
　「プロジェクト計画の策定時に指針として用いられる体系的な計画技法のこと」とPMBOKにあるが、具体的にはコレ↓

• 報告書や計画書の書式・様式・ひな型
• 選択案を検討する際、組織が取っている検討方式(モンテカルロ法とかデシジョンツリー分析とか)
• プロジェクト計画をとりまとめるソフトウェア(M$-projectとか)

プロジェクトマネジメント情報システム(p.44)
　略してPMIS(project management information system)。「プロジェクトの各タスクの実際の状態を教えてくれるシステム」と理解する。ソフトウェアで自動的に更新→報告してくれるものから(ソフトウェア開発ならRational社など)、ガントチャート、報告書まで、さまざまなものがある。

アーンドバリューマネジメント(p.44)
　プロジェクト計画の策定の際、「ツールと技法」として使われることを心にとめておく。アーンドバリューマネジメント(EVM:earned value management)は、プロジェクトの以下の要素の実績を判断する基準となり、プロジェクトそのものを統合するツールでもある。

• スコープ
  
• リソース
  
• スケジュール
  

プロジェクト計画書(p.45)
　…とは、何か? プロジェクト計画書は何が書いてあるのか?

• プロジェクト憲章
  
• スコープ記述書
  
• WBS
  
• 責任分担マトリクス(RAM:responsibility assignmentg)
  
• ネットワークダイアグラム/主なマイルストーン
  
• 予算
  
• スケジュール
  
• リソース
  
• 変更管理計画/変更管理システム
  
• スケジュールとコストのベースライン(進捗度を測るための基準)
  
• スコープマネジメント計画書
  
• スケジュールマネジメント計画書
  
• コストマネジメント計画書
  
• 品質マネジメント計画書
  
• 要員マネジメント計画書
  
• コミュニケーションマネジメント計画書
  
• リスクマネジメント計画書
  
• 調達マネジメント計画書
  

　ありがちなミスが「ガントチャート」。ガントチャートはプロジェクト計画書に含まれない。ガントチャートはスケジュール上でのタスクの状態を報告するものであり、プロジェクト計画ではないことに注意。

　プロジェクト計画書はチームメンバの助けを借りてプロジェクトマネージャが作成する。場合によると、プロジェクト計画書は上司や他のステークホルダから「与えられる」かもしれない。それでもプロジェクト計画書は、実行段階で、より完全に近づくように発展させていく必要がある。プロジェクト計画は作ったらオシマイではなく、プロジェクトが続く限り進化させる必要がある。

プロジェクト計画の策定(p.42)
　…とは、プロジェクト計画書を作成→承認すること。繰り返すが、一回やってハイおしまいではない。PDCA(Plan,Do,Check,Action)が繰り返されるように、変更が発生するたびに、あるいは定期的にこの作業は必要とされる。

　具体的になされることは、以下の通り。

• (事前に)どのプロジェクト計画法を採用するか決める
  
• 各プロセスの計画のなかでさらに繰り返し調整される(例えば、リスク分析の結果、WBSを変更する必要が出る等)
  
• 資源管理マネージャと調整し、スケジュール上で適切なタイミングに適切な資源(人、モノ)を投入できるようにはからう
  
• リスク対応の予備を繰り入れて、最終的な予算を計上する
  
• ステークホルダーのスキルや知識を調査し、どう活用するかを決める
  
• ステークホルダーがプロジェクトのなかでどんな役割を果たすのか、ミーティングを行い調整する
  
• 他のプロジェクトからの影響がないか、調査する
  
• タスク見積もりを実際のカレンダースケジュールに落とし込んだ最終スケジュール案を、(そのタスクを実際に行う)チームメンバに是認してもらう。人によって「その週はちょっと都合が…」なんてこと、あるだろうし
  
• プロジェクト成果物、プロジェクト憲章のアウトラインを上司にプレゼンする
  
• クラッシング、ファストトラッキングなど、どの選択肢が取れるのか、確認しておく
  
• アーンドバリューマネジメントやプロジェクトマネジメントシステムは、通常ソフトウェアで管理されている。ソフトウェアのセットアップを行っておく
  

プロジェクト計画書の承認
　ぜったいに必要なこと。要はプロジェクト計画書に「OK」の意味でサインしてもらうだけなのだが、必須。サインをもらうのは、プロジェクトマネージャ自身、上司、ステークホルダー、チームメンバ。これにより、プロジェクト計画書が正式に承認されたことになる。
　もしやったことがないのら、試みに次のプロジェクト(タスクレベルでも可)でやってみると良い。サインをもらう段階になって初めて、

• あるステークホルダーに事前説明しておく必要があることに気づいた
  
• 「この優先順位が納得できないのでサインできない」と付き返され、事前調整が不十分なことに気づかされた
  
• 「この問題が起こりうるのに対策がない」と付き返され、リスクの洗い出しが不十分なことに気づかされた
  

etc...
きっと得るものがあるはず。私がそうだったのだから(自嘲w

ベースライン(p.66,90)
　計画に対し変化がおきたことを立証する基準のこと。計画からのブレを推し量るとき、「どれぐらいブレが生じているか?」は、その基となるものがないと、見当すらつかないだろう。だからPMBOKでは、その基準となるものをベースラインと定義している。
　実績に対しベースラインを当てはめることにより、変化をモニタリングすることができる。どの実績に当てはめるのかというと、試験では

• コスト
  
• 時間
  
• 品質
  

が出てくる。ベースラインそのものの変更は、正式な承認のもとに改訂することができるが、変更履歴を必要とする。

キックオフミーティング
　プロジェクト計画フェーズの終了時、実際の仕事を始める最初の時点で開かれるミーティング。
　ステークホルダー間の顔合わせを行い、プロジェクトについてより詳しくなってもらうよう、プレゼンテーションを行う。起きうるリスクやコミュニケーション計画、定期報告会議についてレビューを行う。参加者は、

• 顧客
  
• 営業メンバ
  
• プロジェクトチームメンバ
  
• 上司
  
• 機能マネージャ
  
• スポンサー
  

キックオフミーティングは、顔合わせのための飲み会ではないことに注意(w

作業認可システム(p.47)
　大仰だが、要は「それぞれの作業が適切なタイミングでなされるようにはからう仕組み」のこと。例えば作業指示書。文書で発行される「この期間内にこの作業を○○さんがやってくれ」といった指示。
　これにより、今やっている作業が、プロジェクトを前に進めるために必要な作業なのか、そうでないのかがハッキリする。通常、WBS辞書から発行される。

変更要求(p.47)
プロジェクト計画の実行段階で出てくる、プロジェクト計画書への変更要求のこと。これは、統合変更管理で取り扱う。プロジェクト計画書がいったん文書化され、「承認」されたら、その変更は正式な承認の上でなされるべき。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--