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

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

プロジェクト計画の実行
変更管理委員会
変更管理システム
是正措置

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

プロジェクト計画の実行

　このフェーズでは、プロジェクト計画書に書かれた内容を実行に移す。予算を最も使うフェーズも、ここ。作業を成し遂げること、変更要望がないかチェックすること。

　ありがちな誤りは、「各担当に何をするべきか告げてまわる」ことをプロジェクト計画の「実行」だと考えていること。スケジュールもタスク割当も責任分担も、「プロジェクト計画の策定」の時点で明確化されているため、プロジェクトマネージャは、「よろしくねっ」というだけでいいはず。実経験を元に解答しようとすると、ここで引っかかる。

　プロジェクト計画を実行するということは、具体的には以下のようなことを行う。

• プロジェクト計画を履行/実行する
• ワークパッケージを完成させる
• 仕事の結果を得る
• プロジェクト計画に従ってリソースを使用する
• 予防措置を打つ
• ガイドする、アシストする、コミュニケートする、導く、交渉する、手助けする、コーチングする、先手を打つ
• (そのプロジェクトにとって技術的な)専門知識を適用する(プログラミング言語の知識や、コンクリート強度の知識など)
• 作業認可システムを使って、作業を承認する
• プロジェクトベースラインを基に進捗度合いを監視する
• 是正措置を実行する
• メンバ定例会議を開催する
• プロジェクトマネジメント情報システムを使い、情報を得る
• 「ちがい」に目を向ける。プロジェクト計画と実行中のプロジェクトで「例外的なもの」や「差がでたところ」がないか、探す。各担当の仕事ぶりをチェックしたりめんどうを見たりするのは、二の次
• 統合変更管理を使って、洗い出された変更点を把握する

　「プロジェクト計画の実行」には含まれず、他の知識エリアでの実行プロセスで記されているものがある。それは、

• 8.2 品質保証(プロジェクト品質マネジメント)
  
• 9.3 チーム育成(プロジェクト人的資源マネジメント)
  
• 10.2 情報の配布(プロジェクトコミュニケーションマネジメント)
  
• 12.3 引き合い(プロジェクト調達マネジメント)
  
• 12.4 発注先選定(プロジェクト調達マネジメント)
  
• 12.5 契約管理(プロジェクト調達マネジメント)
  

　重要なのは「ちがいに目を向ける」こと。プロジェクト計画と実際のプロジェクトの進捗の、違い/差異/例外 を探すこと。これはプロマネのみならず、メンバ、ステークホルダーも同様。

　ありがちな間違いの選択肢は次の通り。プロジェクト計画を実行するということは何か? の設問に対し、

• プロジェクト計画書を作成する(誤り。プロジェクト計画書はプロジェクト計画プロセスで作成する)
  
• リソースを託する(誤り。プロジェクト計画に従って、リソースを使うが正解)
  
• プロジェクトを進行させる(誤り。プロジェクト実行プロセスだけが、プロジェクトが進行しているわけではないから)
  

　反対に、次のキーワードが入っていれば正解に近いといえる。

• プロジェクト計画に従って作業を行う
  
• 先手を打つ
  
• 先行的
  
• 適用させる
  
• ガイドする(導く)…何に従って? もちろんプロジェクト計画書に従って
  

変更管理委員会
　変更要求を承認するのか/却下するのかを決定するのがここ。さらに、変更要求に対し、もっと影響調査が必要かどうかをレビューする役割も併せ持つ。
　変更管理委員会は、プロジェクトマネージャ、顧客、専門家、スポンサー等で構成される。

変更管理システム(p.48)
　プロジェクトの文書を変更する際に必要となる、以下の要素をまとめたものを、変更管理システムと呼ぶ。

• 事務処理の手順書
  
• 変更追跡システム
  
• 変更を認可するのに必要な職位をもつ担当
  

　変更管理システムはハード面とソフト面の両面を併せ持ち、以下を含む。

• プロジェクト計画書に含まれる変更管理計画書。これにより、変更どどのようにマネジメントするかの概要が分かる
  
• 変更に対し承認してもらうため、変更管理委員会を開く
  
• 変更管理の手順(どうやって、だれがその変更を組み入れるのか?)
  
• プロジェクト実績の統計
  
• 各種レポート(変更管理ソフトのアウトプット、マイルストーン表、リソースの使用具合などのレポート)
  
• 変更する手順
  
• 変更に対する専門家のレビュー
  
• 是正措置の計画
  

是正措置(p.46および他の知識エリアのコントロールプロセスで行われるマネジメントプロセス)
　プロジェクト計画どおりに実績が出ないことが予想されるとき、計画通りになるように打つ手はずのこと。是正措置は以下の二つを行うことによってはじめて実行することができる。

• プロジェクトの実績を測定する
  
• (計画と実績のブレがある場合)その根本原因を突き止める
  

　従って、プロジェクト変更管理システムがキチンと機能していないと、是正措置をとることは不可能。
　ちょっと先走るが、紹介しておく。他の知識エリアのコントロールプロセスでは、「是正措置」はこう扱われる。他の知識エリアでは「是正措置」はアウトプットであることに注意。

• スコープマネジメント知識エリア:5.4スコープ検証により成果物がどの程度完了したかを測り、5.5スコープ変更管理によりスコープ変更に対し、計画からブレないような是正措置がアウトプットされる
  
• タイムマネジメント知識エリア:6.5スケジュールコントロールのアウトプットとして、是正措置を出す。予期できる将来のスケジュール(要は遅れやね)に対し、プロジェクト計画に沿ったものとして引き戻すべく、問題点の分析→挽回計画を立てる
  
• コストマネジメント知識エリア:7.4コストコントロールのアウトプットとして、是正措置が打ち出される。要は見積もりよりも高くつきそうだと分かったとき、計画どおりになるような手をここでひねり出す
  
• 品質マネジメント知識エリア:8.3品質管理プロセスの結果、ダメ出しとして「手直し」の指示が出てくる。これは、欠陥品や不適合貧を、要求事項や仕様書に適合するように取られる措置である
  
• コミュニケーションマネジメント知識エリア:10.3実績報告のアウトプットとして出てくる、ステークホルダーからの変更要求。これが他の変更管理プロセス(例:スコープ変更管理、スケジュールコントロール)へのインプットとなる。
  
• リスクマネジメント知識エリア:11.6リスクの監視・コントロールプロセスのアウトプットとして是正措置が出てくる。識別されたリスクを追跡・分析し、そのリスクに対しどう手を打つのか(コンティンジェンシー計画や迂回策等)を決める
  

　では、上記の「是正措置」は、どこで実行されるのか? そう、各知識エリアプロセスからアウトプットされた是正措置→→→プロジェクト計画の実行プロセスのインプットになるのであり、プロジェクト計画の実行プロセスにおいて各是正措置は遂行される。
　プロジェクト計画の実行プロセスにおいて、

• 仕様書どおりの成果物になるような方策が実行される(スコープ)
  
• スケジュール遅れを取り戻す秘策が実行される(タイム)
  
• 計画通りのコストに収めるための手段が実行される(コスト)
  
• 手戻りを作り直す(品質)
  
• 変更要求に従い、変更する(コミュニケーション)
  
• 迂回策を実行する(リスク)
  

　「タイムリーな是正措置」はどうすればタイムリーになるなのか? それは、

• 偏差を見抜く。計画と実績のブレを予見する
  
• 問題が「問題化」、即ち顕在化するのを待たない。問題化する前に見つけ出す
  
• アーンドバリューなどのツールを使い定量的分析を定期的に行うことで、問題の先回りをする
  
• どれぐらいブレが出たら「それは問題である」と見なすのか、予め分かっている
  

　是正措置は、プロアクティブ(proactive)な作業ともいえる。

　是正措置の説明(p.46)をちょっと引くと、

効果的なプロジェクトマネジメントを実施する上で必要なフィードバック・ループを完結させるため

…とあるが、翻訳ソフトそのまんま。重要なところなのにこの説明ではわけわからん。
　PMBOKで言いたいのは、「その是正措置を実行したのはいいけれど、上手くいったのか? どれぐらい上手くいったのか/いかなかったのか?」を自問し、測定し、必要であれば再度是正措置を取る、ということ。まとめると、

• 是正措置の必要性を洗い出す
  
• 是正措置を実行する
  
• 是正措置の効果を見極める
  
• 是正措置のおかげでどれくらい効果がでたか測定する
  
• さらに是正措置が必要かを決める
  

　是正措置は、やってオシマイではない。プロジェクト計画と実績と同様、「その是正措置でどれぐらいの効果を上げられそうか」と「その是正措置でどれぐらいの効果があったか」の違いに目を向ければ、さらに措置が必要なのか、それとも別の是正措置を必要とするのかが、分かる。
　是正措置、PMBOKでもリアルでも、重要ですな。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--