統合マネジメントが現場で「見えなくなる」理由
PMBOKを学んだ人なら、統合マネジメントという言葉は知っているはずです。しかし実際の現場で「今、自分は統合マネジメントをやっている」と実感できる人は少ないんですよね。私自身、PMOとして10年以上プロジェクトに関わってきましたが、最初の数年は統合マネジメントが何なのか、正直よく分かっていませんでした。
スコープ管理、スケジュール管理、コスト管理、品質管理。これらは「やっていること」が目に見えます。WBSを作る、ガントチャートを更新する、品質チェックリストを埋める。でも統合マネジメントは何をすればいいのか。プロジェクト憲章を作ること?統合変更管理をすること?教科書にはそう書いてありますが、現場では「それって具体的に何?」となるわけです。
私が統合マネジメントの本質を理解したのは、あるプロジェクトで大きな方向転換を迫られたときでした。顧客の経営方針が変わり、開発中のシステムに大幅な機能追加が必要になった。スコープは膨らみ、スケジュールは圧迫され、品質基準も見直しが必要。メンバーは混乱し、ベンダーは追加費用を要求し、経営層は「なんとかしろ」と言うだけ。
私はPMOとして10年以上、複数の大規模プロジェクトで統合マネジメントを担当してきました。特に印象的だったのは、2023年の保険登録システムのクラウド化プロジェクト(9ヶ月、PMO、200名規模)です。プロジェクト憲章の作成から始まり、統合計画書の策定、フェーズゲート管理、変更管理まで、すべてを一貫して回す司令塔役割でした。当初、各ベンダーが独自に走り始めそうになった局面がありましたが、統合計画書を軸に『各社の作業をプロジェクト全体の中でどう位置づけるか』を明確にすることで、方向性を揃えられました。統合マネジメントの本質は『プロジェクトを止めない』こと。そのためには、全体像を掴んで細部を調整する視点が不可欠だと、身を持って学んだ案件でした。
そのとき私が実際にやったのは、各知識エリアの管理者を集めて「今、何が起きているのか」を可視化することでした。スケジュール担当は納期への影響を、スコープ担当は変更範囲を、コスト担当は予算超過額を、それぞれ持ち寄る。そして私はそれらを統合して、経営層に「このプロジェクトは今どういう状態で、どこに向かおうとしているのか」を説明しました。
これが統合マネジメントなんだと、そのとき腹に落ちたんです。各知識エリアは縦割りで専門的に管理されますが、プロジェクト全体を一つの生き物として見て、バランスを取り、方向を調整し、止めずに前に進める。それが統合マネジメントの本質です。
教科書と現場のギャップ
PMBOKでは統合マネジメントに7つのプロセスがあります。プロジェクト憲章の作成、プロジェクトマネジメント計画書の作成、プロジェクト作業の指揮・マネジメント、プロジェクト知識のマネジメント、プロジェクト作業の監視・コントロール、統合変更管理、プロジェクトやフェーズの終結。
これを見て「分かった」という人は、正直言って現場を知らない人です。私は2023年にPJM-A(プロジェクトマネジメント・アソシエイト)を取得しましたが、試験勉強で学んだ内容と、実際の現場で求められることの間には、まだまだ大きなギャップがあります。
例えばプロジェクト憲章。教科書では「プロジェクトの正式な承認文書」と説明されます。でも現場では、誰が書くのか、いつ書くのか、どこまで詳しく書くのか、書いた後どう使うのか、そもそも本当に必要なのか。こういう実務の疑問には答えてくれません。
中堅企業のPMOやPMは、大企業のように専任のPMOチームがいるわけではありません。PMBOKの知識は持っていても、それを自社のプロジェクトにどう適用すればいいのか、手探りで進めている人が大半です。私自身がそうでした。
統合マネジメントが機能しないとき
統合マネジメントが機能していないプロジェクトには、共通の特徴があります。私が10年間で関わった数十のプロジェクトを振り返ると、だいたい以下のような状態になっています。
- 各担当者が自分の領域だけを守ろうとして、全体最適が失われる
- 変更が発生しても、誰も全体への影響を評価しない
- プロジェクトの「今」がどういう状態なのか、誰も説明できない
- 問題が起きたとき、その場しのぎの対応が繰り返される
- プロジェクトの方向性が、いつの間にかズレている
こうなると、プロジェクトは「動いているけれど進んでいない」状態に陥ります。全員が忙しく働いているのに、ゴールに近づいている実感がない。最悪の場合、プロジェクトが止まります。文字通りの中止もあれば、形だけ続いているけれど実質的に死んでいる、というケースもあります。
なぜ統合マネジメントは難しいのか
統合マネジメントが現場で機能しにくい理由を、私は30年のIT業界経験から3つの構造的な問題として整理しています。これは教科書には書いていない、現場にいた人間だから見えてくる本質です。
問題1:統合マネジメントは「見えない仕事」だから
スケジュール管理なら、ガントチャートという成果物があります。コスト管理なら、予算表があります。でも統合マネジメントには、これといった「目に見える成果物」がありません。
プロジェクト憲章も統合変更管理も、それ自体は書類です。しかし統合マネジメントの本質は、その書類を作ることではなく、プロジェクト全体を調整し続けるという「行為」にあります。これは目に見えません。
私がPMOとして評価されるのは、プロジェクトが無事に完了したときです。でもそれは、スケジュールを守った、予算内に収めた、品質を確保した、という「目に見える成果」で評価されます。その裏で私が統合マネジメントをやっていたことは、ほとんど評価されません。見えないから、理解されないんです。
これは日本企業特有の問題でもあります。欧米のプロジェクトマネジメントでは、PMの役割が明確に定義され、統合管理の責任者として認識されています。しかし日本では「プロジェクトは皆で進めるもの」という意識が強く、統合マネジメントという専門職能が軽視されがちです。
問題2:縦割り組織と横串管理の構造的矛盾
統合マネジメントは、横串で全体を見る仕事です。しかし日本の中堅企業の多くは、縦割りの機能組織で動いています。開発部、インフラ部、総務部、経理部。それぞれが自部門の論理で動き、プロジェクト全体を見る視点が弱い。
私が金融系のシステム開発プロジェクトに参加したとき、変更管理の仕組みが非常に厳格でした。小さな変更でも、必ず変更管理委員会にかけ、全体への影響を評価し、承認を得る。当時は「面倒だな」と思いましたが、今振り返ると、これは縦割り組織でも統合管理を機能させるための仕組みだったと分かります。
しかし中堅企業では、そこまで厳格な仕組みを作る余裕がありません。結果として、統合管理は「PMOやPMの個人技」に依存することになります。その人がいなくなったら、統合管理も消えてしまう。これが現実です。
問題3:統合マネジメントは「政治」と「技術」の両方が必要
統合マネジメントの難しさは、技術的なスキルだけでは足りないことです。ステークホルダー間の利害調整、経営層への説明、現場との交渉。これらは政治的なスキルです。
私が経験した中で最も難しかったのは、顧客の経営層が「予算は増やせないが、機能は増やしたい」と言ってきたケースです。技術的には、スコープを増やせばコストも増えるのは自明です。しかし政治的には、顧客の要求を単純に断ることはできません。
このとき私がやったのは、スコープを3つの優先度に分けて、コア機能は予算内で確実に作り、追加機能は次フェーズに回すという提案でした。これは技術的な判断であると同時に、政治的な落としどころでもありました。統合マネジメントは、こういう「交渉の技術」を求められます。
プログラマーやSEから昇格してPMやPMOになった人の多くは、この政治的スキルに苦労します。私もそうでした。コードは論理で動きますが、プロジェクトは人間で動きます。統合マネジメントは、技術と政治の両方を理解していないと、機能しません。
現場で本当に使える統合マネジメントの手法
PMBOKの教科書的な説明ではなく、私が10年間のPMO経験で実際に使ってきた統合マネジメントの手法を紹介します。これらは大企業の豊富なリソースを前提としたものではなく、中堅企業のPMOやPMが明日から使える実践的なものです。
手法1:プロジェクト憲章は「契約書」ではなく「羅針盤」として作る
PMBOKでは、プロジェクト憲章は「プロジェクトを正式に承認し、PMに権限を与える文書」と定義されています。しかし中堅企業の現場では、そんな大層なものは作れません。というか、作っても誰も読みません。
私がプロジェクト憲章で本当に重視しているのは、以下の3点だけです。
- このプロジェクトは何のために存在するのか(目的)
- 成功とは何か(成功基準)
- 誰が最終的な判断をするのか(意思決定者)
これだけです。A4で1枚。多くても2枚。これを最初に関係者全員で確認します。そしてプロジェクトの途中で判断に迷ったとき、この憲章に立ち返ります。「このプロジェクトの目的は何だったか」「この判断は成功基準に合っているか」。羅針盤として使うんです。
私が使っているプロジェクト管理ツールはBacklogです。BacklogのWiki機能に、プロジェクト憲章を書いて、全員が見られるようにしています。大げさなドキュメント管理システムは不要です。大事なのは、いつでも参照できること、そして実際に参照されることです。
手法2:統合変更管理は「変更を防ぐ」のではなく「変更を制御する」
変更管理というと、変更を防ぐための仕組みだと誤解されがちです。違います。変更は必ず起きます。起きない前提でプロジェクトを計画するのは、現実を見ていません。
統合変更管理の本質は、変更が起きたときに、その影響を評価し、優先度を判断し、適切に対応することです。私が実務でやっているのは、以下のステップです。
- 変更要求を受けたら、まず「止まらずに進める」ことを最優先に考える
- スコープ、スケジュール、コスト、品質、リスクへの影響を、それぞれの担当者に確認する
- 影響の大きさに応じて、判断のレベルを変える(小さい変更はPM判断、大きい変更は経営層判断)
- 判断した内容は、必ず記録に残す(Backlogの課題として記録)
変更管理で最も重要なのは、「誰が判断するか」を明確にすることです。これがないと、変更要求が宙に浮いて、プロジェクトが止まります。私は小さな変更(工数1人日以内、スケジュール影響なし)は自分で判断し、それ以上はステアリングコミッティ(経営層を含む意思決定会議)にかけるというルールを作っています。
手法3:週次の統合レビューで「プロジェクトの今」を可視化する
統合マネジメントの最も重要な活動は、プロジェクトの監視とコントロールです。私は毎週金曜日の午後に、30分の統合レビュー会議を開いています。参加者は、スケジュール担当、スコープ担当、品質担当、リスク担当の各リーダーです。
この会議で私が確認しているのは、以下の5点です。
- 今週、計画に対して何が進んだか、何が遅れたか
- 来週、何をやる予定か、何がリスクか
- 今、プロジェクト全体で最も重要な課題は何か
- その課題に対して、誰が、いつまでに、何をするか
- プロジェクトは今、ゴールに向かって進んでいるか
この会議の議事録は、Backlogの課題として記録し、全員が見られるようにしています。これが統合マネジメントの「見える化」です。会議で話した内容が記録に残り、次の週に振り返られ、アクションが追跡される。このサイクルが、プロジェクトを止めずに前に進める力になります。
私が実践している統合マネジメントは、特別な道具やツールを必要としません。BacklogとExcelとメールがあれば、十分です。大事なのは、プロジェクト全体を一つの生き物として見る視点と、それを継続する仕組みです。
ツールに頼りすぎない統合管理
最近は統合プロジェクト管理ツールがたくさんあります。AsanaやMonday.com、Wrikeなど。これらは確かに便利ですが、ツールを導入すれば統合マネジメントができる、というわけではありません。
私が現場で見てきたのは、高機能なツールを導入したのに、結局Excelに戻ってしまったというケースです。理由は単純で、ツールの学習コストが高すぎて、現場が使いこなせなかったからです。
統合マネジメントは、ツールではなく人間の仕事です。ツールは補助にすぎません。私が30年のキャリアで学んだのは、シンプルな仕組みを確実に運用することの方が、高機能なツールを中途半端に使うよりも、はるかに効果的だということです。
30年現場にいた私が思うこと
統合マネジメントは、PMBOKの10の知識エリアの中で最も難しく、最も重要です。私が10年以上PMOとして働いてきて、最も実感しているのは、「統合マネジメントができるかどうかで、プロジェクトの成否が決まる」ということです。
統合マネジメントは「止めない技術」
プロジェクトは、放っておけば止まります。問題が起きて止まる、判断ができなくて止まる、関係者の合意が取れなくて止まる。統合マネジメントは、これらの「止まる理由」を先回りして潰し、プロジェクトを前に進め続ける技術です。
私が金融系のプロジェクトで学んだのは、「止まらないための仕組み」を最初に作っておくことの重要性です。変更管理の仕組み、意思決定の仕組み、エスカレーションの仕組み。これらは面倒に見えますが、プロジェクトが止まるコストに比べれば、圧倒的に安いんです。
中小企業がいきなり大企業と同じ仕組みを作る必要はありません。しかし考え方は取り入れるべきです。プロジェクトを止めないために、今できる最小限の仕組みは何か。それを考えることが、統合マネジメントの第一歩です。
PMBOKを「使える形」に翻訳する
私はPJM-A資格を取得しましたが、資格を取ったからといって、現場で統合マネジメントができるようになるわけではありません。PMBOKは優れたフレームワークですが、教科書です。それを自社のプロジェクトに合わせて「翻訳」する作業が必要です。
私が中堅企業のPMOやPMに伝えたいのは、PMBOKを全部やろうとしないことです。統合マネジメントの7つのプロセスのうち、自社のプロジェクトで本当に必要なのはどれか。まずそれを見極めてください。
多くの場合、必要なのは以下の3つです。
- プロジェクトの目的と成功基準を明確にすること(プロジェクト憲章)
- 変更を制御すること(統合変更管理)
- プロジェクトの今を把握し続けること(監視とコントロール)
これだけでも、十分に統合マネジメントは機能します。完璧を目指すよりも、小さく始めて継続することの方が、はるかに重要です。
明日から始められる小さな一歩
もしあなたが今、プロジェクトの統合管理で悩んでいるなら、まず以下のことを試してみてください。
プロジェクトの目的と成功基準を、A4で1枚にまとめてください。難しい言葉は不要です。「このプロジェクトは何のためにやっているのか」「成功とは何か」を、中学生にも分かる言葉で書く。そして、それを関係者全員に共有する。
これだけです。これが統合マネジメントの出発点です。目的が明確になれば、判断の軸ができます。判断の軸があれば、変更にも対応できます。変更に対応できれば、プロジェクトは止まりません。
私は30年のIT業界経験の中で、数えきれないほどのプロジェクトを見てきました。成功したプロジェクトには、必ず「プロジェクト全体を見ている人」がいました。その人が統合マネジメントを担っていたんです。肩書きがPMOであろうとPMであろうと、リーダーであろうと、役割は同じです。
統合マネジメントは特別な能力ではありません。プロジェクト全体を見る習慣と、止めない意志があれば、誰にでもできます。あなたのプロジェクトが明日も前に進むことを、現場の一人として願っています。
コメント