プログラムマネジメント実践のための３ステップ（第１回）
PMBOK の普及に伴い、今や当たり前とも言えるプロジェクトマネジメント手法は、製品やサービスの開発だけでなく、多くの組織や開発現場などで活用され、多くの成果を挙げています。読者の皆さんの中にも、実際にプロジェクトマネジャーとして活躍し、また、PMP や情報処理技術者試験のプロジェクトマネジャーなどの資格を持っている方も多いのではないでしょうか。その一方で、プロジェクトマネジメント手法を活用している組織や個人であっても、プロジェクトが失敗に終わるケースが数多くあります。その根本原因の１つとして、従来のプロジェクトマネジメントでは VUCA 時代のプロジェクト運営に対応することが難しいことが挙げられます。
プロジェクトマネジメント手法は、個々のプロジェクトを対象にその管理を最適化したものとなっています。ところが、複数のプロジェクトが同時並行して計画され、それらを同時並行して実施する組織に必要となる、「複数のプロジェクトを相互に調整しながら全体最適を目指すための手法」は含まれていません。また、「いくつものサブプロジェクトで構成される大規模プロジェクトに対して、サブプロジェクト相互の複雑な関係を調整して、プロジェクトとして全体最適となる管理手法」も含まれていません。
多くの組織では、相互に関連する複数のプロジェクト、もしくは、サブプロジェクトを同時並行に実施しているため、プロジェクト相互の複雑な関係性を調整して、複数プロジェクト総体として全体最適を図る仕組みが必要となります。個別プロジェクトの最適化が組織全体の最適化にならないからです。
このような相互に関係した複数のプロジェクトやサブプロジェクトを統合管理する手法が、プログラムマネジメントです。より大きなスコープで全体最適となるようプロジェクト群を成功に導くための、プロジェクトマネジメントの上位に位置づけられる管理手法ということができます。組織にとっても、また、同時並行に進行するプロジェクトや複数のサブプロジェクトで構成される大規模プロジェクトを担うマネジャーやリーダーにとっても、複数プロジェクトの管理手法であるプログラムマネジメントを実践し活用することが、VUCA 時代には求められているのです。
プログラムマネジメントとは
プログラムマネジメントはプロジェクトマネジメントの上位に位置するものですから、まずはプロジェクトマネジメントとの違いから解説しましょう。
プロジェクトとは、個別の達成目標と完了期限があり、コストや品質などの制約条件の下でその目標達成を目指す、繰り返しのない活動です。一方、プログラムとは、プロジェクトを実施する組織における特定の目標達成のために、複数のプロジェクトを有機的に組み合わせた統合的な活動です。
そして、プロジェクトマネジメントは、組織編制、プロセス定義、計画作成、進捗管理、予算管理、品質管理などといった、適切な手段のもとでプロジェクトを効率的、効果的に遂行し、確実に目標を達成するための実践方法です。一方、プログラムマネジメントは、組織目標を達成するためのプログラムを複数定義し、それらを設計、計画、遂行するための実践方法です。
プログラムマネジメントは、全体最適となるように複数プロジェクトを管理し調整するということに加え、組織のミッションやビジョンに基づいたプログラムが達成すべき目標を具体化、具現化することと、そのために必要となるプロジェクトとのその相互関係を設計することが、プロジェクトマネジメントとは大きく違う要素です。
また、表１にプロジェクトマネジメントとプログラムマネジメントの主な違いをまとめました。ただし、プログラムマネジメントは、プロジェクトマネジメントを置き換えるものではなく、プロジェクトマネジメントを包含するものであり、個々のプロジェクトはプロジェクトマネジメントによって自律的に運営されることが前提であることに注意してください。
プログラムマネジメントの目的と特徴
プロジェクトマネジメントは、長年にわたる研究と実績の積み重ねによる実行プロセスを重視した知識体系となっており、実際に多くの成果を出してきました。しかし一方で、ステークホルダー（関係者）間の調整不足や利害対立などによって失敗に終わったプロジェクトも少なくありません。その原因は、プロジェクトの成功事例が増えるとともにプロジェクトの対象領域が急激に拡大したことが関係していると考えられます。
エンジニアリングや製造業、IT 関連などの領域だけでなく、ビジネス創出、経営改革、要素技術開発、行政、コミュニティといった非常に多くの領域がプロジェクトの対象となっており、それが、ステークホルダーが増えると同時に多様化して、その相互調整が複雑化したことや、社会環境の変化が早く、不確実性が高くなったことの影響を直接受けることになりました。その結果、プロジェクトの真のオーナー、もしくは、スポンサーである経営者に代表されるトップとの意思疎通やミッションの設定が複雑化し、失敗プロジェクトとなってしまったと考えています。
このような問題に対処することを目的として生まれたのがプログラムマネジメントです。プロジェクトマネジメントを進化させたものといえるでしょう。したがって、プログラムマネジメントは次のような特徴を持っています。
プログラムとして達成する目標とその組織における価値を具体化、具現化する
目標達成に必要なプロジェクト群とそれらの相互関係で定義されるプロジェクト構成を設計する
オーナー／スポンサーやステークホルダーと確認、提案、合意を継続的に繰り返しながら不確実性に対するリスクを最小化する
プログラムの目標達成に向けて、構想、構築／実装、運用というプロジェクトのライフサイクル全般にわたってプロジェクトを監視し、その相互関係を調整して、必要に応じて介入する
環境や状況の変化などに伴う不確実性に対処するため、広い視野と深い洞察力を持つ人材（プログラムマネジャー）を育成するための能力体系を整備する
プログラムマネジメントの実践例
プログラムマネジメントには数多くの要素が含まれていますが、本稿では、多くの組織でプロジェクトを進める際に採用しているマトリクス体制での製品開発を例にとって、プログラムマネジメントにおける以下の項目について解説したいと思います。
定量データによる統合指標管理
マネジメントの体制と責務
組織ミッションとの調和
ちなみに、マトリクス体制での製品開発プロジェクトの典型的な形態は、電気、機械、ソフトというような専門技術や機能ごとに部署が分かれている組織のもとで、各部署のメンバーが集まって製品開発などのプロジェクトを複数実施するというものです。
マトリクス体制において、プロジェクト単体を対象とするプロジェクトマネジメントだけでプロジェクトを管理するのは、以下のような理由から難しいものになりがちです。
プロジェクトメンバーは、プロジェクト活動ではプロジェクトマネジャー（図２の PM）の指揮下にあるが、各メンバーの組織上の上長は各部署（グループ）のマネジャー（図２の GM）となっているため、両マネジャーからの指示や要求を受けることになる。両マネジャーからの指示・要求が個別・独立している場合、メンバーは両者の指示・要求の優先順位を判断できず、一方、あるいは、どちらの指示・要求にも対応できなくなる。そして、複数のプロジェクトを兼務しているメンバーは、より複雑な状況に陥ってしまう。
PM は、プロジェクトメンバーが GM から受けている指示や、組織における業務を把握していない／できていないため、各メンバーがプロジェクトの業務に使える時間（工数）を把握できない。その結果、プロジェクトが遅れる。
GM は、自部署のメンバーが関与しているプロジェクトがメンバーごとに異なるために、部署としては複数のプロジェクトに関与することになり、関係しているプロジェクトの状況とメンバー個人のプロジェクトにおける状況を把握しなければならない。しかし、そのための仕組みやツールがないために、メンバーの負荷を調整することができない。
あるプロジェクトに進捗の遅延が生じた場合、PM は遅延の原因となっているメンバーの GM に増員などの要望を出し、GM はその要望に応えるために増員やメンバーの業務アサインの調整などを行うことになる。しかし、その対応によって、増員や業務調整したメンバーがもともと関わっていた別のプロジェクトへの時間（工数）が減少することになり、別のプロジェクトの進捗を遅らせることになる。その結果、この遅延が他のプロジェクトに連鎖することになる。
複数のプロジェクトを統合的に管理する視点や機能が不足していることが、これらの問題を引き起こしています。とくに、１つのプロジェクトの遅延が他のプロジェクトに連鎖するという問題は、１つのプロジェクトの問題が、動いているほとんどのプロジェクトの問題となりえるため、組織にとって致命的な問題に発展する可能性があります。
●
今回は、プロジェクトマネジメントとの違いを中心に、プログラムマネジメントの概要を紹介しました。VUCA といわれる複雑で不確定性が高く、変化の激しい時代において、単独のプロジェクトの最適化が、必ずしも組織やビジネス全体の最適化にはならないことは必然です。そこで、プロジェクトマネジメントに加えて、プログラムマネジメントを実践することが求められています。
次回から、プログラムマネジメントを実践するための基本となる３つのステップを事例と共に紹介する予定です。
この記事が気に入ったらサポートをしてみませんか？