スカパー！のおすすめ映画はこちら
今なら初月無料！【PR】

プロジェクト・インテグレーション・マネジメントと「鉄の三角形」

プロジェクト・マネジメントの世界で最も広く普及している標準書PMBOK GuideⓇには、ご存じの通り以下のような、10の知識エリアが規定されている。

・プロジェクト・インテグレーション （Project integration）
・スコープ （Scope）
・スケジュール （Schedule）
・コスト （Cost）
・品質 （Quality）
・人的資源 （Human resource）
・コミュニケーション （Communication）
・リスク （Risk）
・調達 （Procurement）
・ステークホルダー・エンゲージメント （Stakeholder engagement）

各知識エリアは、それぞれが”xx Management"と題されている。つまりQuality ManagementとかCost Managementといったたぐいだ。もっとも上記10個には多少の変遷があり、最初は9個だった。途中からステークホルダー・マネジメントが追加され、さらに最新版ではステークホルダー・エンゲージメント・マネジメントにかわった（ステークホルダーは外部の利害関係者なので、プロマネが直接はマネージできないためだろう）。またスケジュール・マネジメントの用語も、第5版まではタイム・マネジメントだった。

PMBOK Guideには、PMをプロフェッショナルな職域として確立しようとした、先達の叡智がつまっている。中でも一番偉かったのは、最初に「プロジェクト・インテグレーション・マネジメント」なる領域をおいたことだと思う（日本語版では「プロジェクト統合マネジメント」と訳されている）。プロジェクトという複雑な活動の集合を、一種のシステムとしてとらえ、そのIntegrityを保つ必要があるという問題意識から、この概念が生まれたのだろう。ちなみにIntegrityという英語には、全体性、統合性、整合性などのほかに、誠実さ・品位といった意味もあり、非常に高い価値が込められている。

ところで、プロジェクトのインテグレーション・マネジメントというのが何を指しているのか、ここが意外と分かりにくい。

PMOBK Guideはプロセス中心の記述になっていて、Project integrationの中には５つのプロセスが定義されている。(1)Project charterの作成、(2)プロジェクト・マネジメント計画書の作成、(3)プロジェクト作業の指揮・マネジメント、(4)プロジェクト作業の監視・コントロール、(5)統合変更管理、(6)プロジェクトやフェーズの終結、の６つである。

このうち、(1)と(2)は立ち上げフェーズと計画フェーズでの、いわば全体計画立案作業なので、明確だろう。遂行フェーズに入ると、プロジェクトのマネジメントとコントロールを行う。どちらもプロジェクトの全体が対象だ。

ただ、マネジメントとコントロールの二つが、別々のプロセスになっているのは、英語ではmanagementとcontrolがレベルの違う概念として、区別されるからだ（「わたしはなぜ、「プロジェクト管理」という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ 参照のこと）。実際、大規模プロジェクトでは、両者はプロジェクト・マネージャー（PM）とプロジェクト・コントロール・マネージャー（PCM）という風に、職種が分かれて分担する。もちろん、PMはPCMの上位職である。

さて、問題は『統合変更管理』（Integrated change control）である。日本語訳では「管理」となってるが、原語はContorlであることに注意してほしい。これはいったい何をするのか。

PMBOK Guideはプロセス中心、つまり手続き主義の記述になっている。そして「変更要求」だとか「承認済み変更要求」だとかが、インプット/アウトプットに出てくる。

米国流のプロジェクト遂行では、発注者と受注者の間で、変更要求Change Requestと変更指示Change Orderが、やりとりされる。通常は受注者から変更のリクエストが提出され、発注者がそれを審査・承認して正式なオーダーを切る。オーダーには変更作業の詳細と共に、追加費用や納期延長が記載されている。もちろん現実には、提出から承認までの間に、「これは高すぎるだろ」と値切られたり、「これは追加じゃないはずだ」と言われて押し問答したり、といった交渉がはさまるのだが、そういう商慣習のプロトコルを知らないと、ここら辺の記述は分かりにくい。

また、自社内で完結する自発型プロジェクトの場合も、予算権限を持っているプロマネと、社内のステークホルダとの間で、似たようなやりとりが行われる。だからPMBOK Guideでは「承認済み変更要求」という用語になっているのだろう。

ところで、どうしてこれに、あえて『統合』という修飾語がついているのか？　何かの事情で仕様の追加や変更等が必要になり、それで予算が増えるなら予算追加要求、納期が延びるなら納期変更要求、それだけの話ではないか。

ところが、そうではないのである。

プロジェクトを取り巻く制約条件には様々なものがありうるが、通常、その中でも
• Scope（役務範囲）
• Cost（予算）
• Schedule（納期）
はProject の三大制約条件である。まあ、だからこそPMBOK Guideでは最初の方の章に、この3つのエリアがあげられている。

ところで、この三大要素を図にすると、三角形で表される。三角形は、知っての通り、他の2辺に影響を及ぼさずに1辺だけをかえることができない。どれか、ある要素を変更するには、他の要素の変更も必要になるのだ。
e0058447_15161741.jpg
たとえば、何か仕様上の追加が必要になったとしよう。その場合、作業（Activity）が増える訳だから、スコープの1辺が長くなる。この場合、
・期限（スケジュール）を延ばして作業を完了
・人員（コスト）を増やして作業を完了
のいずれかが必要になる、という具合だ。

図を見てほしい。三角形の底辺であるスコープを長くすると、どちらかの斜辺を同時に長くせざるを得ない。いや、しばしばあることだが、スケジュールとコストの両方が増大したりする。

似たようなケースとして、遅れつつあるプロジェクトで、納期を間に合わせる工夫が必要だとしよう。その場合、
・人員を追加して（＝コスト追加）、仕事を完了する
・スコープを減らして、期限までの作業量を減らす
のいずれかの方策が必要になる。

あるいは、予算内（コスト）で終わらせる場合ならば、こうなる：
・残業などはせず、プロジェクトの納期を延長する
・スコープを減らして、コストを削減する

プロジェクトには、変更がつきものである。だが、その影響範囲や必要性を考える際には、コストならコストだけ、スケジュールならスケジュールだけでは、判断できない。プロマネは、上述のように、つねにスコープ・コスト・スケジュールの3辺を制約条件として意識しながら、変更をコントロールしなくてはならないのだ。だから、「統合」変更管理 Integrated change control と呼ばれるのである。

英国の初期のPM研究者マーティンは、1970年頃、Scope/Cost/Scheduleからなるこの三辺を、「鉄の三角形」と名付けた。鉄の三角形は、プロマネをとじこめる束縛、あるいは牢獄のようなものだ。プロマネは、とくにプロジェクトの中盤以降、つねにこの三角形の制約条件と戦い続ける。なにか予期せぬ事が起きても、なんとかしてこの三角形の内部で解決すべく努力する。どれか一辺でも破ると、三角形全体の形が変わってしまう。

プロジェクトの成功には、いろいろな定義が可能だが、一番短期的に測りやすいのは、「スコープ・コスト・納期が、当初の予定通り完遂できた」である。外部コンサルタントなども、よくこの指標を用いる。それはつまり、鉄の三角形の内部で完結できたか、を問うている訳だ。

そして、逆に言うと、プロジェクト・マネージャーが首尾良く仕事を完遂するためには、スコープ・コスト・スケジュールのいずれについても、判断し実行する権限を持たなければならない。プロマネは結果に責任を持て、とか、プロマネは結果が全てだ、といった標語をよく耳にする。だが、もしも組織がプロマネにそうした仕事ぶりを期待するなら、それなりの権限を与える必要がある。

「ウチの会社ではプロマネは進捗管理係でしかない」とか、「○○業界のプロマネは、コスト管理の権限がない。発注権は、その上の部課長級が握っている」といった話を、ときどき耳にすることがある。それなりの理由があって、そうした慣習ができあがっているのかも知れない。だが、3辺に対する権限もなしに、3辺の結果責任だけを問われるのは、フェアなマネジメントのやり方ではないと、わたしには思えるのである。


＜関連エントリ＞
「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ （2017-12-18）

by Tomoichi_Sato | 2018-02-25 15:45 | プロジェクト・マネジメント | Comments(0)
「プロジェクト＆プログラム・ア... >>

ファン申請

※ メッセージを入力してください

外部サイトRSS追加

URL :
※対応しているRSSフィードのURLをご入力ください。

RSSフィード詳細