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

不確実性が高く、変化の激しい VUCA 時代といわれる今、従来のプロジェクトマネジメント手法は単独のプロジェクトの最適化を狙う手法であることから、期待の効果を手にすることが難しくなっているという話を、前回記事でしました。VUCA 時代には、組織やビジネスの全体最適を目的とした複数プロジェクトを並行して管理する仕組みが必要とされており、そのための管理手法であるプログラムマネジメント手法について、新テーマで解説しています。

前回は、主にプロジェクトマネジメントとの違いを中心に、プログラムマネジメント手法がどういうものなのかを解説しました。今回からは、プログラムマネジメントの導入にあたって重要になると考えている以下の3ステップについて、通信設備関連の開発を行っている組織での実施例とともに実践方法を紹介したいと思います。

紹介するのは、開発部門の多くが採用しているマトリクス体制での実施例です。理解していただきやすくするために、前回ご紹介した図を下に再掲します。マトリクス体制は、前回解説したように、複数のプロジェクトが複数の部署を横断して実施される組織形態であり、通常のプロジェクトマネジメントによる管理が難しいという本質的な特徴があるため、プログラムマネジメント手法が有効となるケースの1つです。

組織上、各メンバーは GM（グループマネジャー）に属しており、GM が業務管理をする役割を持っています。PM（プロジェクトマネジャー）は各 GM がアサインしたメンバーで構成された自分のプロジェクトを計画・実行する役割です。プロジェクトでのメンバーの具体的な役割や仕事内容は PM の責任となりますが、残業過多などのメンバーの健康管理やプロジェクトへの追加や交代などは GM の責任となります。

今回は、「定量データによる統合指標管理」として、実際に使ったグラフを紹介しながら、プログラムマネジメントの観点からどのような判断とアクションを取ったのかを解説します。実データなので詳細なグラフになっている反面、実名称を隠しているのでわかりにくい部分もありますが、各グラフによって何が観測・分析できるのかといった、指標化/可視化の観点を意識しながら読んでいただきたいと思います。

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

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

図3は、プロダクトマネジメントにおける指標の具体例の1つです。すでにプロジェクトマネジメントで各メンバーの工数を収集しているケースが多いと思いますので、工数データを利用した例です。このグラフは、マトリクス体制で複数実施しているプロジェクトの1つを選んで、そのプロジェクトメンバーの月ごとの工数推移をあらわしており、グラフ下の＜概要＞に記載したような特徴が見て取れます。

＜概要＞

プロジェクトマネジャー（PM）は、このグラフを見て自分のプロジェクトのメンバーの負荷を把握し、各メンバーが計画に合った負荷になっているかを確認します。このグラフは月単位ですが、実施にあたっては週単位で各メンバーの工数推移を確かめました。

このグラフを見ると、メンバーによって、このプロジェクトに専念している（多くの工数を使った）時期に差があること、ほとんどのメンバーが月ごとにこのプロジェクトに関わった時間が大きく変わっていることがわかります。これがマトリクス体制での特徴の1つです。

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

図4のグラフは、ある部署に所属しているメンバーのある1ヶ月の工数で、参加しているプロジェクト別に色分けしています。 このグラフでも、以下の＜概要＞に記載したような特徴が見て取れます。

＜概要＞

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

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

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

＜概要＞

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

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

＜概要＞

このように主要なプロジェクトの状況を一覧することで、開発部門全体としてリソースが破綻することがないようにしたり、急激に工数が増大しているプロジェクトが他のプロジェクトに影響を及ぼしていないか、工数を投入できていないプロジェクトはないかなど、全体の調和やトレードオフを考えながら、全体最適となるように各プロジェクトの進め方を工夫したりします。このグラフからは、開発期間を通じて主要プロジェクト（Project10, 9, 8）が大きな工数を占めており、その変動幅も大きいために、組織全体の総工数が大きく上下していることがわかります。これは、メンバーの負荷（残業時間）が大きく変動していることを意味します。

このような状況は、GM にとってはメンバーの業務管理、とくに主要プロジェクトではないPM にとっては進捗に関する問題なので、組織全体（マトリクス体制全体）で対策を検討しなければならない課題となります。実際、部門長などのシニアマネジャーも含めて時間をかけて議論しました。しかし、この時には有効な対策を実施することができず、マネジャーやメンバー全員の頑張りで何とか乗り切ったという結果でした。ただ、この反省を活かし、計画段階における仕組み作りに活かすことになりました。この仕組みは次回に紹介する予定です。

図7は、ある1ヶ月間での各部署におけるプロジェクト別の工数です。図6とは違い全プロジェクトを表示しています。 これも＜概要＞に観測できることを記載しています。

＜概要＞

図6でみた 巨大 Project10 はこのグラフでは Project1 なのですが、グラフからこの巨大プロジェクトの影響は部署によって違うことわかります。たとえば、この月は、Group3 や Group12 はほとんどのメンバーがこのプロジェクトに関与しており、他のプロジェクトにアサインされているメンバーが適切に工数を投入できているか注意する必要があります。つまり、Project1以外にアサインされているメンバーに負荷のしわ寄せがいっていないかといったことです。マトリクス体制におけるプログラムマネジメントでは、このようにして各部署におけるプロジェクトの実施状況を把握することが大切になります。

今回は、プログラムマネジメント実践における3つの重要なステップのうちの最初のステップである、定量データによる統合指標を使った管理を紹介しました。ある製品開発組織での実例なので、プロジェクト名や部署名など隠している部分もあり、グラフは見にくかったかと思いますが、マトリクス体制の開発組織で、同時並行して実施するプロジェクト群をどういった視点で可視化し、どのようなアクションをとったのかを示した具体例ですので、自分の組織においてどのような指標化/可視化ができるのかをイメージしていただけたのではないかと思います。

次回は、プログラムマネジメントにおける計画作成の事例として、図6の解説で言及したマトリクス体制におけるプロジェクト計画の仕組みを紹介したいと思います。また、3ステップの残りの2ステップについて解説する予定です。ご質問やご意見は、以下のフォームでも受け付けていますので、ご記入いただければと思います。

プログラムマネジメント（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