第10回 プログラムマネジメント実践のための3ステップ

VUCA 時代と呼ばれている現在、その頭文字となっている Volatility(変動性)、Uncertainty(不確実性)、Complexity(複雑性)、Ambiguity(曖昧性)に対応することがビジネスにおける重要な課題となっています。前回までの連載では、ビジネスを変える提案のためのインサイト・コンサルティング手法について解説しました。今回からの連載では、新たにプログラムマネジメント手法を紹介したいと思います。

今や当たり前とも言えるプロジェクトマネジメントは、製品やサービスの開発だけでなく、多くの組織や開発現場などで活用され、多くの成果を挙げています。読者の皆さんの中にも、実際にプロジェクトマネジャーとして活躍し、また、PMP や情報処理技術者試験のプロジェクトマネジャーなどの資格を持っている方も多いのではないでしょうか。その一方で、プロジェクトマネジメント手法を活用している組織や個人であっても、プロジェクトが失敗に終わるケースが数多くあります。その根本原因の1つとして、従来のプロジェクトマネジメントでは VUCA 時代のプロジェクト運営に対応することが難しいことが挙げられます。

プロジェクトマネジメント手法は、個々のプロジェクトを対象にその管理を最適化したものとなっています。ところが、複数のプロジェクトが同時並行して計画され、それらを同時並行して実施する組織に必要となる、「複数のプロジェクトを相互に調整しながら全体最適を目指すための手法」は含まれていません。また、「いくつものサブプロジェクトで構成される大規模プロジェクトに対して、サブプロジェクト相互の複雑な関係を調整して、プロジェクトとして全体最適となる管理手法」も含まれていません。

今や多くの組織では、相互に関連する複数のプロジェクト、もしくは、サブプロジェクトを同時並行に実施しているため、プロジェクト相互の複雑な関係性を調整して、複数プロジェクト総体として全体最適を図る仕組みは必要不可欠と言えるでしょう。つまり、個別プロジェクトの最適化は組織全体の最適化になるとは限らないのです。

このような相互に関係した複数のプロジェクトやサブプロジェクトを統合管理する手法が、プログラムマネジメントです。より大きなスコープで全体最適となるようプロジェクト群を成功に導くための、プロジェクトマネジメントの上位に位置づけられる管理手法ということができます。組織にとっても、また、同時並行に進行するプロジェクトや複数のサブプロジェクトで構成される大規模プロジェクトを担うマネジャーやリーダーにとっても、複数プロジェクトの管理手法であるプログラムマネジメントを実践し活用することが、VUCA 時代には求められているのです。今回から始まる新テーマによって、読者の皆さんには今の時代を乗り切るための強力な武器として、ぜひこのプログラムマネジメントを身に付けていただきたいのです。

 

1.プログラムマネジメントとは

プログラムマネジメントはプロジェクトマネジメントの上位に位置するものですから、まずはプロジェクトマネジメントとの違いから解説しましょう。

 

図1.プログラムマネジメントとプロジェクトマネジメント

プロジェクトとは、個別の達成目標と完了期限があり、コストや品質などの制約条件の下でその目標達成を目指す、繰り返しのない活動です。一方、プログラムとは、プロジェクトを実施する組織における特定の目標達成のために、複数のプロジェクトを有機的に組み合わせた統合的な活動です。

そして、プロジェクトマネジメントは、組織編制、プロセス定義、計画作成、進捗管理、予算管理、品質管理などといった、適切な手段のもとでプロジェクトを効率的、効果的に遂行し、確実に目標を達成するための実践方法です。一方、プログラムマネジメントは、組織目標を達成するためのプログラムを複数定義し、それらを設計、計画、遂行するための実践方法です。

プログラムマネジメントは、全体最適となるように複数プロジェクトを管理し調整するということに加え、組織のミッションやビジョンに基づいたプログラムが達成すべき目標を具体化、具現化することと、そのために必要となるプロジェクトと、それらの相互関係を設計することが、プロジェクトマネジメントとは大きく違う要素です。

また、表1にプロジェクトマネジメントとプログラムマネジメントの主な違いをまとめました。ただし、プログラムマネジメントは、プロジェクトマネジメントを置き換えるものではなく、プロジェクトマネジメントを包含するものであり、個々のプロジェクトはプロジェクトマネジメントによって自律的に運営されることが前提であることに注意してください。

 

表1.プロジェクトマネジメントとプログラムマネジメントの比較

 

2.プログラムマネジメントの目的と特徴

プロジェクトマネジメントは、長年にわたる研究と実績の積み重ねによる実行プロセスを重視した知識体系となっており、実際に多くの成果を出してきました。しかし一方で、ステークホルダー(関係者)間の調整不足や利害対立などによって失敗に終わったプロジェクトも少なくありません。その原因は、プロジェクトの成功事例が増えるとともにプロジェクトの対象領域が急激に拡大したことが関係していると考えられます。

対象がエンジニアリングや製造業、エンジニアリングや製造業、IT 関連などの領域だけでなく、ビジネス創出、経営改革、要素技術開発、行政、コミュニティといった非常に多くの領域にわたっているため、プロジェクトは「ステークホルダーが増えると同時に多様化して、その相互調整が複雑化したこと」と、「社会環境の変化が早く、不確実性が高くなったこと」の2つの要因の影響を直接受けることになりました。その結果、プロジェクトの真のオーナー、もしくは、スポンサーである経営者に代表されるトップとの意思疎通やミッションの設定が複雑化し、失敗プロジェクトとなってしまったと考えています。

このような問題に対処することを目的として生まれたのがプログラムマネジメントです。プロジェクトマネジメントを進化させたものといえるでしょう。したがって、プログラムマネジメントは次のような特徴を持っています。

プログラムとして達成する目標とその組織における価値を具体化、具現化する
目標達成に必要なプロジェクト群とそれらの相互関係で定義されるプロジェクト構成を設計する
オーナー/スポンサーやステークホルダーと確認、提案、合意を継続的に繰り返しながら不確実性に対するリスクを最小化する
プログラムの目標達成に向けて、構想、構築/実装、運用というプロジェクトのライフサイクル全般にわたってプロジェクトを監視し、その相互関係を調整して、必要に応じて介入する
環境や状況の変化などに伴う不確実性に対処するため、広い視野と深い洞察力を持つ人材(プログラムマネジャー)を育成するための能力体系を整備する

 

3.プログラムマネジメントの実践例

プログラムマネジメントには数多くの要素が含まれています。本稿では、多くの組織でプロジェクトを進める際に採用しているマトリクス体制での製品開発を例にとって、プログラムマネジメントにおける以下の項目について解説したいと思います。

定量データによる統合指標管理
マネジメントの体制と責務
組織ミッションとの調和

ちなみに、マトリクス体制での製品開発プロジェクトの典型的な形態は、電気、機械、ソフトというような専門技術や機能ごとに部署が分かれている組織のもとで、各部署のメンバーが集まって製品開発などのプロジェクトを複数実施するというものです。

図2.マトリクス体制

マトリクス体制において、プロジェクト単体を対象とするプロジェクトマネジメントだけでプロジェクトを管理するのは、以下のような理由から難しいものになりがちです。

プロジェクトメンバーは、プロジェクト活動ではプロジェクトマネジャー(図2の PM)の指揮下にあるが、各メンバーの組織上の上長は各部署(グループ)のマネジャー(図2の GM)となっているため、両マネジャーからの指示や要求を受けることになる。両マネジャーからの指示・要求が個別・独立している場合、メンバーは両者の指示・要求の優先順位を判断できず、一方、あるいは、どちらの指示・要求にも対応できなくなる。そして、複数のプロジェクトを兼務しているメンバーは、より複雑な状況に陥ってしまう。
PM は、プロジェクトメンバーが GM から受けている指示や、組織における業務を把握していない/できていないため、各メンバーがプロジェクトの業務に使える時間(工数)を把握できない。その結果、プロジェクトが遅れる。
GM は、自部署のメンバーが関与しているプロジェクトがメンバーごとに異なるために、部署としては複数のプロジェクトに関与することになり、関係しているプロジェクトの状況とメンバー個人のプロジェクトにおける状況を把握しなければならない。しかし、そのための仕組みやツールがないために、メンバーの負荷を調整することができない。
あるプロジェクトに進捗の遅延が生じた場合、PM は遅延の原因となっているメンバーの GM に増員などの要望を出し、GM はその要望に応えるために増員やメンバーの業務アサインの調整などを行うことになる。しかし、その対応によって、増員や業務調整したメンバーがもともと関わっていた別のプロジェクトへの時間(工数)が減少することになり、別のプロジェクトの進捗を遅らせることになる。その結果、この遅延が他のプロジェクトに連鎖することになる。

複数のプロジェクトを統合的に管理する視点や機能が不足していることが、これらの問題を引き起こしています。特に、1つのプロジェクトの遅延が他のプロジェクトに連鎖するという問題は、1つのプロジェクトの問題が、動いているほとんどのプロジェクトの問題となりえるため、組織にとって致命的な問題に発展する可能性があります。

 

今回は、プロジェクトマネジメントとの違いを中心に、プログラムマネジメントの概要を紹介しました。VUCA といわれる複雑で不確定性が高く、変化の激しい時代において、単独のプロジェクトの最適化が、必ずしも組織やビジネス全体の最適化にはならないことは必然です。そこで、プロジェクトマネジメントに加えて、プログラムマネジメントを実践することが求められています。

次回から、プログラムマネジメントを実践するための基本となる3つのステップを事例と共に紹介する予定です。

 
執筆者プロフィール
日本ヒューレット・パッカード(HP)に入社し、R&D で半導体テスターなどの製品開発に従事した後、HP全社の開発・製造のデジタル化と仕組み改革にプロジェクト・リーダーとして参加。大幅な開発効率化を実現し、日本科学技術連盟石川賞を受賞。その経験をもとに開発マネジメントやプロジェクト管理、設計プロセスなどのコンサルティングを実施している。
コンサルティングを続ける中で、業務の仕組み改善は、個人の成長を伴うものであるべきとの思いが強くなり、コーチングや心理学を学び、組織と個人の両方に働きかけるコンサルティングを実施するために株式会社 RDPi を設立。組織と個人の両方に働きかけるコンサルティングを実施している。現在、日本ポジティブ心理学協会の理事を務めている。

株式会社 RDPi : http://www.rdpi.jp/
仕組みと意識を変える RDPi:https://www.facebook.com/rdpi.jp
やる気の技術:https://www.facebook.com/motivation3.0
Email : ishibashi@rdpi.jp
 
関連記事
第9回 インサイト・コンサルティング – ストーリー作成の編
VUCA時代の自己開発と組織開発
第9回 インサイト・コンサルティング – ストーリー作成の編
第8回 インサイト・コンサルティング ‐「結」の編
VUCA時代の自己開発と組織開発
第8回 インサイト・コンサルティング ‐「結」の編
第7回 インサイト・コンサルティング -「転」の編(その4)
VUCA時代の自己開発と組織開発
第7回 インサイト・コンサルティング -「転」の編(その4)
第6回 インサイト・コンサルティング -「転」の編(その3)
VUCA時代の自己開発と組織開発
第6回 インサイト・コンサルティング -「転」の編(その3)
第5回 インサイト・コンサルティング -「転」の編(その2)
VUCA時代の自己開発と組織開発
第5回 インサイト・コンサルティング -「転」の編(その2)