”かんしこんとろーる”
と読む人がほとんどですが、そんなPMBOK用語はありません。

正しい読み方は、
”監視” （１拍）”コントロール”　。
（笑）

監視とコントロールの間には点があって、これは二つの活動だということです。

原文は、モニター　アンド　コントロール。

普通に、「監視 “と” コントロール」でいいと思うんだけど、なんで　and を　”・”にしちゃったんでしょ・・・。

ま、いいでしょう。

監視・コントロール・プロセス群の役割を確認します。

ベースラインを基準にした、実行中のプロジェクト活動の監視を行う。
＜PMBOK®ガイド5版＞

ベースラインというのは、計画プロセス群が策定したコントロールのための基準です。

監視とは、このベースラインと、実行プロセス群から出力される実績情報を比較することです。

計画の変更が必要な分野を特定し、それらの変更を開始するプロセスからなる。
＜PMBOK®ガイド＞

監視によって、計画と実績を比較した結果、差異があれば、差異を解消すべく何かをしないといけません。

この何かのことを、変更要求といいます。

計画は、計画に沿って進むことが前提になっていますので、計画と実績とのズレを直すために行うことは、当初の計画にはありません。

つまり、程度の差はあれど、差異を解消するための対策はすべて”計画の変更”となるわけです。

変更には、方向性の異なる二つのアプローチがあります。

一つは、
実績をベースラインに近づけること。

もう一つが、
ベースラインを実績に合わせることです。

”変更を開始するプロセスからなる。”　とありますね？

こういう表現も、実にPMBOK的なんです。

つまり、差異が発生したからといって、あわてて、すぐに何かをやるわけでは無いんです。

変更　”要求”　とあるように、まずは、変更を提案するところから始まるわけです。

で、次にどうするかというと、
その出された変更要求の提案に対して検討を加えます。

その変更は本当に実施すべきなのか。？

ん？
計画との差異を埋めるために必要な変更じゃないの？

そうなんですが、
あくまで、その差異に対してということでしかありません。

どういうことかというと、一つの変更は、それだけにとどまりません。
変更を行うことによって、どこに、どんな影響があるのか？

ここは、プロジェクトマネジメント・プロセスの相互作用をしっかりと、漏れなく働かせて、競合（急げばミスをする）する条件を中心に多面的に検討されなければいけないわけです。

プロジェクトが進んでいれば進んでいるほど、この検討にコストがかかることは、序論で確認しました。

その上で、監視・コントロールプロセス群は、変更要求の承認、あるいは却下を、公式に決定するわけです。

次に、承認された変更については、確実に反映されるように、マネジメントしていかなければなりません。

変更が予想外の影響を及ぼしていないかなどを注意深く追跡します。
こうした一連の手続きを、変更のコントロール、統合変更管理と言います。

承認された変更だけが実施されるように、統合変更管理を経由しない可能性のある要因への、働きかけを行う。
＜PMBOK®ガイド5版＞

”統合変更管理を経由しない可能性のある要因への働きかけ”
というのは、そうした公式な変更ルートから外れた、未承認の変更を受け入れないということです。

急いでるから、
どうしても必要だから、
などの理由をつけた強引な変更要求。

あるいは、権限を持たないスタッフによる勝手な変更。

公式な手続きによる変更の却下や、変更の言い出しっぺが費用の負担を嫌がって、こうした様々な動きがあるわけです。

そうした動きからプロジェクトを守るということです。

実行プロセス群と異なり、監視・コントロールプロセス群は各知識エリアにあります。

監視・コントロールの対象が、
スコープであれば、スコープ･コントロール、
時間であればスケジュール･コントロール、
お金であれば、コスト・コントロール。

これらは管理対象が違うだけで、その活動の本質は、同じです。

・実績をモニタリングすること。
・必要に応じて変更を提案すること。
・変更をマネジメントすること。

これが監視・コントロールプロセス群の各知識エリアに共通する３つの役割です。