第12回 プログラムマネジメント実践のための３ステップ（最終回）

このコラムでは VUCA 時代の製品やサービスの開発に関係する技法・手法を紹介しています。前々回からのシリーズでは、複数プロジェクトを並行して管理する仕組みであるプログラムマネジメント手法の導入にあたり、キーポイントとなる以下の3ステップについて解説しています。

前回は、(1) の「定量データによる総合指標管理」について、通信設備関連の製品開発を行っている組織での実施例とともに解説しました。プログラムマネジメント手法の最終回となる今回は、事例とともに計画作成の指標化を紹介し、残りのステップである「マネジメントの体制と責務」と「組織ミッションとの調和」について解説します。

1. 定量データによる総合指標管理（続き）

前回と同様に、通信設備関連の製品開発をマトリクス体制で実施している組織での実例を使って解説を続けます。

マトリクス体制では、プロジェクト軸と部署軸の両方の視点で、全プロジェクトの状況を総合的に把握し、管理することが求められるわけですが、そもそも、プロジェクトのスケジュールと確保できるメンバー（工数）の計画に乖離があり、その乖離が大きければ大きいほど調整をとるための対処は困難なものになります。そして、複数プロジェクトを同時並行に実施する場合は、その調整はより困難なものになってしまいます。この開発部門のようなマトリクス体制を取っている組織の場合は次のような状況になります。

プロジェクト計画は PM（プロジェクトマネジャー）が作成しますが、メンバーは各自が所属している部署（グループ）の GM（グループマネジャー）が管理しているので、 リソース管理は GM の役割となります。そして、PM が要求されている仕様や機能、期限などから作成したプロジェクト計画におけるリソースプランと、プロジェクトに必要なメンバーを提供する GM が作成するリソースプランとには、大きな乖離が生じるのが普通です。PM が作成する計画は、他のプロジェクトのことを考慮せず、自分が担当しているプロジェクトだけの最適化を図ったものとなるため、すべてのプロジェクトのリソースプランをとりまとめたものは、組織が供給できるリソース（工数）を大幅に超過したものになるのです。

この乖離をできるだけなくすことが、プログラムマネジメントにおける計画作成のポイントとなります。図8は、この事業部で実施した事例です。PM は自分のプロジェクトのリソース計画を作成して、GM は自分の部署のリソース計画を作成し、両者の乖離の時間経過を可視化するという仕組みです。あるプロジェクトの PM が作成したリソースプラン（ピンク色）と、各 GM がそのプロジェクトにアサインする自部署メンバーの工数合計を元に作成したリソースプラン（紺色）を示しています。

＜概要＞

当初、両者の間に大きな計画工数の乖離があり、開発部門として看過できない問題であることが明らかになりましたが、PM と GM が継続して調整を続けることによってその乖離が徐々に解消されていることがわかります。本来であれば、プロジェクト開始までに調整を終えておくべきことですが、ここまで実践できるようになるまでには、全プロジェクトで同様の調整を実施することも含めて、この仕組みの運用開始から約1年を費やしてしまいました。この事実でもわかるように、この仕組みの実践は簡単ではありませんが、このような計画の可視化・指標化は効果的で、とても重要なものであることがおわかりいただけると思います。

2. マネジメントの体制と責務

ここまで、適切な指標化・可視化を行うことで、PM（プロジェクトマネジャー）とGM（グループマネジャー）とが、それぞれ各種指標を使ってプロジェクトと部署（グループ）との相互の状況を把握する事例と、組織全体でその両方の状況を把握する事例を紹介しました。

これらの指標を使って同時並行に実施する複数プロジェクトを、組織全体最適の観点で相互調整するのが、プログラムマネジメントの次のステップとなります。しかし、PM は自分のプロジェクトが滞りなく進捗して計画している目標を達成できることを最優先し、GM は自分の部署のメンバーが過重労働で心身の健康に問題をきたすことなく、担当している業務を通じて成長することを最優先することがそれぞれの基本的な責務です。そのために、どうしても相容れない状況が生まれ、両者が交渉や調整を通じて組織全体の最適化を目指すことは簡単ではありません。

したがって、プロジェクトと部署の両方の観点から組織の全体最適を考慮した判断と調整を行う責任者が明確になっていなければ、各種指標はその価値を発揮することができません。その役割を担うのがプログラムマネジャーです。

PM、GM という呼び名は組織によっては違っているかもしれませんが、マトリクス体制をとっている組織の多くが、PM、GM に相当するマネジメントの役割・責任が曖昧な状態のまま複数プロジェクトを進めています。そのため、プロジェクトマネジメント手法を導入していてもプロジェクト運営に支障を来しているケースが少なくありません。そこで、まずは PM、GM の役割を表2に示しておきたいと思います。

そして、このような役割・責任を持つ PM と GM を助けながら、プロジェクトや部署の個別最適ではなく、組織の全体最適のための調整や介入をする役割・責任を持つのがプログラムマネジャーです。プログラムマネジャーは、組織の全体最適となる明確な判断基準に基づいて PM と GM との相互調整・介入を実施するのです。

この事例の場合は、全体というのは事業部全体となるので、全体最適の判断基準は、事業部が設定している目標を達成することに合致しているかどうかということになります。設定する目標は、通常は、ビジネスの拡大や業務の適正化といったことを、事業部の状況に合わせて具体化したものとなるでしょう。したがって、プログラムマネジャーは、ビジネスの責任者である事業部長と協力して、その目標達成のために必要な複数プロジェクトの構成を設計、実行し、設定した目標を達成することを目指すことになります。

つまり、プログラムマネジメントを実施する場合の組織体制では、プログラムマネジャーはビジネスの責任者である事業部長を直接サポートするポジションで、GM や PM を直接指揮できるポジションとなる必要があります。たとえば、次のような形となるでしょう。

専任のプログラムマネジャーがアサインされていることが理想ですが、組織によっては、事業部長がプログラムマネジャーを兼務することも少なくありません。その場合は、事業部長はプログラムマネジメントの責任者であることを自覚し、プログラムマネジメント手法を習得している必要があります。勘・経験・度胸（KKD）という属人的な方法でプログラムマネジメントを実施するのは組織のためにはなりません。持続的なビジネスの成功を担っているのですから、仕組み化された実施・実践にする責任があります。

3. 組織ミッションとの調和

プロジェクトマネジメントでは、プロジェクトの達成目標は上位から与えられるものであり、PM（プロジェクトマネジャー）は与えられた目標を達成する際のリスクを管理する責任はあるものの、目標そのものが組織目標と整合がとれているかどうかという事業リスクに対する責任を負うことはありません。一方、プログラムマネジメントは、組織目標を達成するためにプログラムを計画し、実施するのですから、組織目標とプログラムの達成目標は整合がとれていることが大前提となります。

全体最適とは、多くの場合は組織が担当しているビジネスの拡大や業務の適正化などの目標を達成することが基準になります。また、プログラムマネジメントは全体最適を目指すものですから、その達成のために必要となるプロジェクト構成を設計し、各プロジェクトの具体的な達成目標を設定することになります。そして、ビジネス（事業）は、本質的に企業理念や経営戦略に基づきながら、多くの不確実性がある社会環境の中で実践するものですから、ビジネス拡大や業務適正化といった目標設定は、戦略性を有する具体的なものにする必要があるのです。

つまり、プログラムマネジメントにおける目標設定は、ビジネスにおける経営戦略と密接に結びついている必要があるのです。これは、事業評価に基づいた組織の戦略目標の具体化や、ビジネスにおける不確実性を考慮したリスク管理、計画更新管理というような組織の戦略目標策定に関与する仕組みを整備することが、プログラムマネジメントを構成する要素だということです。

したがって、プログラムマネジャーは、単にプログラム群を監視し、調整・介入をする役割を持つだけでなく、組織のミッション、それをブレークダウンしたプログラムの達成目標、さらに、それらの実現のために構成した各プロジェクトのゴールを、外部状況・環境の変化に合わせて調整し、組織ミッションに基づいた具体的な価値を創出するという役割と責任を持っているのです。そのために、プログラムマネジャーは次のような行動をとることになります。

4. まとめ

プロジェクトマネジメントによって、プロジェクト管理を最適化する手法が明確になったものの、プロジェクト単体の個別最適が、必ずしも組織全体の最適化に結びつかないという課題が一般化してきました。そして、複数プロジェクトを総合的、統合的に管理する手法としてプログラムマネジメントが生まれ、今も発展し続けています。

プログラムマネジメントの構成要素は広範囲にわたっているため、その導入、実践は簡単なことではありませんが、実践のポイントを3つに絞って解説してきました。事例として紹介したマトリクス体制は多くの組織において採用している組織形態ですので、プログラムマネジメントの導入、実施の参考にしていただければ幸いです。

そして、プログラムマネジメントによって、複数プロジェクトを監視し、介入することで、複数プロジェクトを統合管理し、組織レベルでの全体最適を目指すことができた後は、組織のミッション遂行のため、事業評価、ビジネス戦略策定、戦略目標定義、プロジェクト要件定義といったビジネスの最上流工程に関与する仕組み構築に挑戦してください。このビジネスの最上流工程への関与の仕組みも、実はプログラムマネジメントの重要な要素なのです。

プログラムマネジメントについての解説は今回で終了し、次回からは、また別の新しいテーマの解説をしたいと思っています。プログラムマネジメントの解説に対するご質問やご意見は、引き続き以下のフォームでも受け付けていますので、ご記入いただければと思います。

プログラムマネジメント（Google Forms）
https://docs.google.com/forms/d/e/1FAIpQLScOkHZIz7b5xy9E5NuY8iTDfDg_h6C4sO05FOOA-sPzJJ81XA/viewform

執筆者プロフィール 日本ヒューレット・パッカード（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