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

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

統合変更管理
スコープ検証
スコープ変更管理
スケジュール管理
コスト管理
品質管理
パフォーマンスを測定する/情報を共有する
リスク監視とリスク管理
リスク監視とリスク管理
よくある変更に対する対処
プロジェクト計画書更新版
コンフィグレーションマネジメント

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

統合変更管理(p.47)
　コントロールフェーズにおいて、4.3統合変更管理は重要な位置を占めている。各知識エリアのコントロールプロセスと複雑にからみあっているが、ここでは両方を述べる。
　PMBOKにおいて各知識エリアの最後がコントロールプロセスであることに注意。スコープ、スケジュール、コスト、品質、リスクのそれぞれのコントロールプロセスが最後に書かれている… が、ここでまとめ出して、各知識エリアでは言及しない。

　「コントロールプロセス」は試験で最も力点が置かれているプロセスである。しかし、リアルで我々はプロジェクトをコントロールしていないので、他のプロセスと比べると一番難しく感じているかもしれない←prep本はキツいこと言うが、少なくとも私にとっては事実だと思う。学ぶべきことが沢山あったから。
　プロジェクトをコントロールするとは、どういうことを指すのか? 統合変更管理の観点でいうならば、

• 実績がベースラインに合うようはからう
  
• 実際に変更する
  
• 変更する際、各知識エリアを横断した調整を行う
  

統合変更管理では、実際には以下のことを行う。

• 総合的な変更管理の視点から、各知識エリアのコントロールプロセスの結果からくる変更をとりまとめる
  
• 是正措置をとる
  
• 変更管理委員会に従う
  
• コンフィギュレーションマネジメントを行う
  
• 変更管理システムを遵守することで、確実なものとする
  
• 変更要素を把握する
  
• 変更管理計画書を定期的に見直すことで確実なものとする
  
• ベースラインに対する3つの制約条件(コスト、時間、スコープ)をコントロールする
  
• どこの変化(ブレ、変動要素)が重要なのかを見極める
  
• データを集める
  
• プロジェクトのコントロールを目的としたミーティングを開く
  
• 書類仕事をコントロールする
  
• 交渉する
  
• コミュニケートする
  
• 利害の不一致を解決する
  
• プロジェクトポリシーに従って進める
  
• 問題の真の要因を特定する
  
• プロジェクト計画書の更新をする
  

スコープ検証

• 変更要素の調査
  
• 成果物に対し正式な承認を得る
  

スコープ変更管理

• 成果物に対し、計画と実績のブレを測定する
  
• 成果物を作り出す実績がベースラインに合うようはからう
  
• 是正措置をとる
  
• 教訓を記す
  

スケジュール管理

• コンティンジェンシー計画の予備時間を使う
  
• アーンドバリューツールを使う
  
• 計画と実績のブレを測定する
  
• 実績がベースラインに合うようはからう
  
• 是正措置をとる
  
• 教訓を記す
  

コスト管理

• EAT(estimate at completion)を再計算する
  
• 必要なら追加予算を組み入れる
  
• コンティンジェンシー計画の予備費を使う
  
• アーンドバリューツールを使う
  
• 計画と実績のブレを測定する
  
• 実績がベースラインに合うようはからう
  
• 是正措置をとる
  
• 教訓を記す
  

品質管理

• 定期的に品質をチェックする
  
• 是正措置の必要性を検討する
  
• 仕事の仕方をチェックして、より効率的に行えるようにする
  
• 要求事項に合うように、仕事のやり直しをしてもらう
  
• 成果物が要求事項に合致しているかを判断し、受け入れる/受け入れないを決める
  
• 是正措置がちゃんと効果をあげているか検証する
  

パフォーマンスを測定する/情報を共有する

• 計画と実績のブレを次のツールを駆使してチェックする→アーンドバリュー、PERT、CPM
  
• 計画と実績のブレ情報を共有する
  
• 是正措置をとる
  
• コミュニケーションマネジメントの結果、必要に応じ変更要求をぶちあげる
  

リスク監視とリスク管理

• リスクトリガーに対し、リスクマネジメント計画書に従ったリスク対応策をとる
  
• コンティンジェンシー計画を実行する
  
• 是正措置をとる
  
• リスク対応計画書を更新する
  
• それでも上手くいかないときは、変更要求をぶちあげる
  

変更をマネジメントする
　プロジェクトマネージャは変化に対して敏感でなければならない。変化に対してプロアクティブ(proactive)に行動しなければならない。つまり、

• 変化が起きたことを見極めなければならない。変化が1だったら誤差の範囲かもしれない。10だったら「変化が起きた」といえる。じゃぁ4なら? つまり、「対処が必要になる変化」はどの程度のブレからなのかを、予め仮定しておく
  
• 変化が必要なのかを見極めなければならない。変化に対し受身になる必要はない。変化が必要なら、それを起こすのもプロマネの役割。スコープ追加によりコスト超となりそうな場合は、コスト減の是正措置と共に、スコープ削減の変更依頼というオプションもある。変化を避けてはならない
  
• 変化に対し、代替案を想定すること。是正措置も然りだが、まともに取り組むことなく「逃げる」「ガマンする」というのも代替案。リスク対応(p.141)参照
  
• 変化が起きたことを、ステークホルダーに知らせるのも大切な役割。当然のことながら「変化が起きました」と知らせるだけではガキの使い。変化に対し、その影響度を調べ、代替案、是正措置を検討し、「こういう影響を起こす変化が発生しました。対処案としてはこれこれがあります。どういたしますか?」と伝える
  

よくある変更に対する対処
　以下、(ホントはあっちゃいけないんだけど)よくある変更をと、その対処を(PMBOKでのプロマネとしての対処)を問答形式で記述する。これは一例であり、常にそのようにできるとは限らないことにご注意。

　1.資金難

• 問:顧客が「プロジェクトの資金がもう尽きた。提供できない」といってきた。どうする?
  
• 答:リアルなら、その時点で全て止めしまうかもしれない。...が、スコープを大幅に削減するなどして、何か価値あるものを提供できないか検討する。これまで突っ込んできた資源を形あるものにして提供できないか?
  

　2.期間が大幅に切り詰められた

• 問:おバカな営業が「カットインは2ヶ月前倒しできます」と口約束してきた。彼はマリアナ海溝に沈めたが口約束は生きていると顧客は主張している。どうする?
  
• 答:カットインを2ヶ月前倒しすると、どのような影響がでるか調査する(顧客側の影響も含めて)。言い換えると、2ヶ月前倒しすることで得られる「メリット」を調査する。次に2ヶ月前倒しするために必要なことを調査する。スコープ削減、テスト省略(品質への影響)、クラッシング、ファスト・トラッキングetc...調査結果および得られた代替案をステークホルダで検討した後、顧客へ説明する。「前倒しのメリットと、そうするためにどういう対処策があるのか(それぞれの策の影響も含めて)」
  

　3.要求仕様の追加

• 問:ドキュソな営業が後先考えずに要求仕様をホイホイ引き受けてきた。彼は刺される前に別部署へ逃げ出した。当然引き継ぎなんて無し。どうする?
  
• 答:何を約束してきたのか(やる/やらないは別として)顧客に聞き取り調査し、「追加要望」であることを確認する。次に、その追加要望を受けることで発生する影響度を調査する。他のスコープを削減するとか(実装の優先順位付け)、プロジェクト期間の延長、クラッシング、ファスト・トラキングetc...調査結果および得られた代替案をステークホルダで検討した後、顧客へ説明する。「要求仕様の追加により起きうる影響とその対処策(対処策それぞれの影響度を含める)」を説明する。そして、顧客に選んでもらう
  

　注意するべきことは、顧客は「選択する」ことしかできないように追い込むこと。プロジェクト計画プロセスが完了しているのなら、フリーハンドの権限は、顧客であろうと上司であろうと、無い。選ぶのがイヤなら、プロジェクト自体をご破算にして、も一度やりなおすだけ。

　え、リアルと違うって? ...確かに。リアルでは「変更は受け入れろ。ただし他の要素(金・納期・品質)は変えるな」が至上命令としてやってくる。でもそれがおかしいことは言っている本人も分かっている(認めたくないだけ)。

　変化を受け入れるには、相応の影響が発生することを認めてもらうのが、まずひとつ。それから、影響を吸収するためには、なんらかの手を打たなければならないのが、二つ目。

　そして、どの手を打つのかを決めてもらわなければならない。これは「変化に対処せよ」と言ってくる人(顧客・上司・他のステークホルダー)に決めてもらうしかない。そして、どの対処でも「その対処による影響(リスクと言い換えても可)」が付いてまわることを予め知らせておく。

　変化に対応するポイントをまとめると、以下のとおり。

• あるブレを「変化」が発生したと認める。どれぐらいブレたら変化だとするのかは基準・経験による。大切なのは、先行的に決めること
  
• その「変化」がプロジェクトにどう影響するか想定する
  
• その「変化」に対し、代替案を検討する
  
• 「変化」「変化のインパクト」「代替案」「代替案の影響(メリット/デメリット)」を擁して上司、スポンサー、他のステークホルダーと内部ミーティングを行う
  
• 必要であれば顧客とミーティングを行う
  

　変化への対応では、第一に「変化の影響度を検証すること」が重要。何に対する影響を検証するのかというと、時間・コスト・品質(*)の3点。

*3つの制約条件(triple constraint)について。前出では3つの制約条件を「時間」「コスト」「スコープ」と言い切ったが、この文脈だと3番目は「品質」の方が妥当。「結局どっちだよ」という悪罵が聞こえるが、あまり気にしない(PMBOKには記述すらされていないしな)

　「代替案」とは、クラッシング、ファストトラッキング、再見積もりのこと。さらに、「もしこの手を打ったならどうなるだろう」と考えられるもろもろのこと。

　変化への対応の話題で、非常によるある質問はがある。「スコープへの変更要望があり、時間・コスト・品質への影響が無いことが分かった。次に何をすればよい?」

　この答えを出す前に、「3つの制約条件への影響が無い、ということは、変化の影響度の検証は済んでいる」ことに注意。以下の順に正解に近い。

• まだ見つかっていないリスクを考慮した代替案を探す
  
• 上司・スポンサーに変化およびその影響を報告する
  

　上記の後に、顧客に報告する。だから「顧客に報告する」という選択肢はダミー。

　「どこに変更が発生するのか?」によって、承認を求める相手が異なることに注意。例えばプロジェクト憲章に変更が必要なのであれば、その承認は最終的にプロジェクト憲章にサインした人に求めるべき。

　プロジェクト計画書に対し変更が発生するのであれば、プロジェクトマネージャが扱える範囲といえる。ただし、ファストトラックやクラッシングなどのオプションが取れる範囲だったり、予備資源が使える場合に限る(なんでもかんでも、というわけではない)。

　変更が、品質、時間、コスト、スコープに影響を及ぼすことが分かっている場合には、上司を巻き込んで検証する必要がある。プロジェクトマネージャは、状況を鑑みて、クラッシング、ファストトラッキングなどの対策をとる。

　クラッシング、ファストトラッキングについては、6章「タイムマネジメント」を、変化への対策については、9章「人的資源マネジメント」に同様な設問が出てくる。

　コンティンジェンシー計画の資源は、識別されたリスク(リスクマネジメント計画書に記述されたリスク)が顕在化した場合にのみ、適用できることに注意。リアルとはチョト違う。予想もつかないリスクに易々と使ってはいけない。

プロジェクト計画書更新版(p.49)
　リアルとかなり違うところがここ。プロジェクト計画書は作ってオシマイ、ではない。プロジェクト計画書に対する変更(WBS、ネットワークダイアグラム、リスクマネジメント計画書etc...)への変更が発生した場合は、影響度を調べて、(必要に応じて)代替案を検討し、変更を行い、変更を承認してもらう。

　変更は「変化が発生したことを知らしめて」→「その影響度を調べて」「どう対応するかを決めて」→「それを承認してもらう」ことまでやって初めて、「変更をコントロールした」といえる。プロジェクト計画書の更新はコントロールフェーズで行われるが、それは「変更をコントロールする」ことば通りの意味だととらえて欲しい。

コンフィグレーションマネジメント(p.49)
　コンフィギュレーションマネジメント(configuration management)…いい訳語が思いつかないし、説明(p.49)読んでもよく分からん… 自分なりの理解をまとめると、「構成変更マネジメント」とでも名づけるべきか。

• 仕様書・設計書を文書化する
  
• 仕様書・設計書の変更要素を把握する
  
• 仕様変更、設計変更の実施状況を記録・報告する(あとから追いかけられるようにする:traceability)
  
• 変更した結果、変更要求に合致していることを検証する
  

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