◆プログラムマネジメント 連載目次

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

2. プログラムマネジメント成功の鍵

3. 定量データによる総合指標管理

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

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

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

このような相互に関係した複数のプロジェクトやサブプロジェクトを統合管理する手法がプログラムマネジメントです。より大きなスコープでの全体最適となるようプロジェクト群を成功に導くための、プロジェクトマネジメントの上位に位置づけられる管理手法ということができます。本稿は、このプログラムマネジメントについて解説します。

【目次】
1.プログラムマネジメントとは
2.プログラムマネジメントの目的と特徴
3.プログラムマネジメント成功の鍵
　3.1 定量データによる総合指標管理←今回の解説
　3.2 マネジメントの体制と責務
　3.3 組織ミッションとの調和
4.まとめ

【この連載の前回へのリンク】

3.1 定量データによる総合指標管理

プロジェクト状況をタイムリーに適切な数値化された指標（データ）によって可視化するのは、プロジェクトマネジメントにおける重要な仕組みのひとつですが、プログラムマネジメントでも同様の仕組みは必要不可欠です。複数プロジェクトを統合的、総合的に把握できる数値化されたプログラムマネジメント指標を整備することが必要になります。

前述のマトリクス体制における課題に対処するために必要となる指標は、最低限、次のことを満足するものでなければなりません。

• 各プロジェクトの PM が、プロジェクトメンバーの負荷状況（時間の使い方）を把握できる
• 各部署（グループ）の GM が、メンバーが関与している各プロジェクトの進捗状況を把握できる
• 組織全体のプロジェクト全体の状況を把握できる

それでは本題の、プロダクトマネジメントにおける指標の具体例を紹介したいと思います。プロジェクトマネジメントで、各メンバーの工数を収集しているケースが多いと思いますので、工数データを利用した例にしましょう。

図３ あるプロジェクトのメンバーごとの工数推移

図３のグラフは、マトリクス体制で複数実施しているプロジェクトの１つを選んで、そのプロジェクトメンバーの月ごとの工数推移をあらわしています。ある年の 10 月開始して翌年の６月に終了したプロジェクトです。プロジェクトマネジャー（PM）は、このグラフを見て自分のプロジェクトのメンバーの負荷を確認し、各メンバーが計画に合った負荷になっているかを確認します。このグラフは月単位ですが、実施には週単位で各メンバーの工数推移を確かめます。

このグラフを見ると、メンバーによってこのプロジェクトに対する関わり方（使った工数）が違うことがわかります。メンバーによってこのプロジェクトに専念している（多くの工数を使った）時期に差があること、ほとんどのメンバーが月ごとにこのプロジェクトに関わった時間が大きく変わることなどがわかると思います。プロジェクト・メンバーは各部署から選出されたメンバーなので、それぞれの部署での役割・業務を持っていたり、直前まで関わっていたプロジェクトが長引いたり、他のプロジェクトの応援に駆り出されたりしているのですが、メンバーは組織の上では所属している部署のグループマネジャー（GM）の管理下にあるため、PM はプロジェクト・メンバーがどの程度自分のプロジェクトに時間を使っているのかを常時把握することが必要不可欠です。そして、この指標を使うことで、必要に応じて、メンバーが所属する部署の GM とそのメンバーの時間の使い方について要望し、議論するアクションを取るのです。

図４ ある部署のメンバーごとのある１ヶ月間のプロジェクト別工数

図４のグラフは、ある部署に所属しているメンバーのある１ヶ月の工数で、プロジェクト別に色分けしています。たった１ヶ月の間に、多くのメンバーが約５つのプロジェクトに関わっており、中には８つものプロジェクトに関わっているメンバーがいることがわかります。GM は、このような指標を利用することなしには自部署のメンバーの状況を把握することは困難です。このグラフはある月を表示していますが、実際には週単位で GM は自部署のメンバーがどのプロジェクトにどれだけ関わっているのかを確認します。そして、メンバーの健康管理やスキルアップに支障をきたさないように、必要に応じてプロジェクトにおけるメンバーの業務内容や予定を PM と議論するアクションを取るのです。

このグラフを見ると（紙面ではわかりづらいと思いますが）、ほとんどのメンバーが Project７に少しずつ関わっていることがわかるので、特定のメンバーが Project７の業務を集中して担当するように業務調整することで、多くのメンバーにとって担当するプロジェクトが減り、また、Project７も少人数で集中して関わるメンバーとなるので効率的にプロジェクトを進めることができると考えられます。

図５ ある部署のメンバーのあるプロジェクトでの業務別工数

図５のグラフは、あるプロジェクトの PM から進捗が思わしくないので、メンバーの交代、増員などを要求されたため、自部署のメンバーがそのプロジェクトでどのような業務を行っているのかを調べるためのものです。図５は、このプロジェクトの全期間の工数合計としていますが、実際には必要に応じて期間を指定して確認しています。

この部署はソフトウェア技術者の部署なのですが、このグラフを見ると、多くのメンバーがプロジェクト管理業務を実施していることから、要求してきた PM は自分の役割であるプロジェクト管理業務を何人ものソフトウェア担当メンバーに任せていると考えられます。この部署の GM はこのプロジェクトの PM に対して、PM 自身の業務を含めて、プロジェクト・メンバーの業務アサインを見直すことを提案することになると考えられます。

図６ プロジェクト別工数推移

図６は、この開発部門全体のある２年間におけるプロジェクト別工数を示しています。実際にはもっと多くのプロジェクトを実施しているのですが、すべてのプロジェクトを総合的に管理するプログラムマネジメントの観点から、工数の多いトップ 10 のプロジェクトについて状況を一覧することにしています。グラフは月単位の工数推移ですが、実際には週単位で工数推移を見ています。

主要なプロジェクトの状況を一覧することで、開発部門全体としてリソースが破綻することがないようにすることや、急激に工数が増大しているプロジェクトが他のプロジェクトに影響を及ぼしていないか、工数を投入できていないプロジェクトはないかなど、全体の調和やトレードオフを考えながら、全体最適となるように各プロジェクトの進め方を工夫します。このグラフからは、Project10 が大きな工数を占めており、その変動幅も大きいことがわかります。

図７ ある１ヶ月間の部署ごとのプロジェクト別工数

図７は、ある１ヶ月間で各部署におけるプロジェクト別の工数です。マトリクス体制をとっているこの開発部門は部署（グループ）が多いことがわかりますが、どの部署も相当な数のプロジェクトをこなしていること、そして、関与しているプロジェクト数や投入している工数が部署によって大きく違うことがわかります。図６でみた 巨大 Project10 はこのグラフでは Project1 なのですが、この巨大プロジェクトの影響は部署によって違うことがわかります。たとえば、このグラフで見ているこの月は、Group3 や Group12 はほとんどのメンバーがこのプロジェクトに関与しており、他のプロジェクトにアサインされているメンバーが適切に工数を投入できているのかに注意する必要があるでしょう。マトリクス体制におけるプログラムマネジメントでは、このようにして各部署におけるプロジェクトの実施状況を把握することが大切になります。

図８ プロジェクト軸と機能軸との計画乖離

ここまでは、実績工数を様々なグラフでプログラムマネジメントの指標を紹介してきましたが、最後に、計画工数の事例を紹介したいと思います。

マトリクス体制では、プロジェクト軸と部署軸の両方の視点で、全プロジェクトの状況を総合的に把握し、管理することがプログラムマネジメントに求められるわけですが、そもそもプロジェクトの計画とメンバーというリソース（ここでは工数）計画に乖離があり、その乖離が大きければ大きいほど、調整や調和を取るための対処は困難なものになります。

この開発部門の場合、プロジェクト計画は PM が作成しますが、メンバーは各自が所属している部署の GM が管理しているので、リソース管理は GM の役割です。そのため、PM が仕様や機能、期限などから作成したプロジェクト計画におけるリソースプランと、プロジェクトに必要なメンバーを提供する GM が作成するリソースプランは、当初大きな乖離があります。図８は、あるプロジェクトの PM が作成したリソースプラン（ピンク色）と、各部署の GM がそのプロジェクトにアサインするメンバーをもとに作成したリソースプランの合計（紺色）を示しています。当初、両者の間に大きな乖離がありましたが、プログラムマネジメントによる調整によってその乖離が徐々に解消されていることがわかります。

この事例の場合、プロジェクトが開始した後に、リソースプランを含むプロジェクト計画のアップデートを繰り返して、PM と全 GM との間のリソースプランの乖離を解消させていますが、すべてのプロジェクトの実施計画が組織全体で現実的で実現可能なものにすることも、プログラムマネジメントの重要な仕組みであること、そのためには、このような指標を活用することが大切であることをわかっていただけると思います。

次回は、3.2 マネジメントの体制と責務から解説します。