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

プロジェクト・マネジメントの世界で最も広く普及している標準書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の中には5つのプロセスが定義されている。(1)Project charterの作成、(2)プロジェクト・マネジメント計画書の作成、(3)プロジェクト作業の指揮・マネジメント、(4)プロジェクト作業の監視・コントロール、(5)統合変更管理、(6)プロジェクトやフェーズの終結、の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)
<< スコープ・組織・スケジュール・... 「プロジェクト&プログラム・ア... >>