【プロマネ】ゾウさんとプログラム管理の関係性 ～プロジェクト、プログラムとポートフォリオ～

大きなゾウさんがいる部屋

What's the elephant in this room?（ウワッツ　エレファント　イン　ディスルーーム）

（エレファント？象？聞き間違いじゃないよね？えええええぇぇ・・・）

私がとあるグローバル企業でプログラムマネージャにアサインされ、最初にグローバルCEOに報告した時に、そのCEOから発せられた言葉です。

"Ah,, Uhh,,,"とつまっていると、私が意味を理解できていないと察したのか、プロジェクトオーナーのAPAC（アジアパシフィック）リーダーが割って入ってくださいました。

"Elephant in the room"とは英語のイディオムで、「その部屋にいる人が気づいてはいるが、触れるのを避けたいと感じている重大で物議をかもす問題」です。

つまり、私はきれいなリカバリプランと、ロードマップを描いてプレゼンしたのですが、それに対して「本当にそれだけ？」「何か潜んでいる課題やリスクはないの？」という確認でした。

プログラムマネージャになった経緯

ある製造業のグローバル企業では、30年近く稼働したメインフレーム（1950年代に開発され、1980年から1990年代に全盛を迎えた、大型の汎用コンピュータ）のリプレースを目指していました。

そのメインフレームは複数の事業部で利用されていましたが、グローバル組織が事業単位の縦割りであったため、事業部ごとに別々の切替プロジェクトが走っていました。

私は当初、IT側で一つの事業部担当のプロジェクトマネージャとして稼働していましたが、複数事業部が国内もグローバルもうまく連携できておらず、計画も管理もバラバラでした。

さらに、グローバルでも複数地域への導入が並行で動いており、グローバルでの単一インスタンスのシステムに対する、地域向けのカスタマイズがバラバラに入れられているという状況でした。

そんなある日、思い通り進まない状況に業を煮やしたマネジメントにより、複数プロジェクトを束ね、さらにビジネスとITを統括したプログラムマネージャの設置が検討されました。

そこで白羽の矢に刺さってしまったのが私です。

プログラムマネージャになって何をしたか？

最初にプロジェクトとプログラムのPMBOKでの定義を紹介します。

プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務である。（PMBOK Guide 6th edition - プロジェクトの定義）

プログラムは、プロジェクトの個別的なマネジメントでは得ることのできないベネフィットを得るために、調和の取れた方法でマネジメントされるプロジェクト、サブプログラム、及びプログラム活動のグループである。（PMBOK Guide 6th edition - プログラムの定義）

プログラムマネジメントでは、複数のプロジェクトやサブプログラムをまとめて、一つのプログラムとして管理します。

私がプログラムマネージャになり一番最初に着手したのは、ステークホルダーとレポートラインの整理です。そこでは、意思決定が必要な方には漏れなく、CEOを頂点としたプロジェクトコミッティボードに入って頂きました。

この組織では、プロジェクトマネージャが私にレポートする形でした。

（後日、報告用にまとめた、体制の簡易イメージ）

そしてプログラムとしてのゴールと、そのサクセスファクターを定義し、それに対しての課題やリスクとマッピングをしていき、必要なリソースの割り当てを行いました。

そこまでしてから、マスタースケジュールを再整理しました。

Microsoft Projectを利用して、レベル１の矢羽レベルでパワーポイント1枚で描いていた全体スケジュールから、成果物・アウトプットを最小単位としたタスクまで構造化して洗い出していきました。

次にIntegration Pointとして、プロジェクト間で共通もしくは依存・関連するタスクを関連付け、共通のマイルストーンを設定、さらに、そこをターゲットにした会議体を整理しました。

ここまで整理してからグローバルのボードメンバーに報告したのが冒頭の会議で、そこでゾウさんの質問を頂いたというわけです。

ゾウさんの質問に対して、あるボードメンバーからオブジェクションがあったのが、プログラム進捗の透明性（Transparency）です。

そして、プロジェクトごとに別々でステータス管理がされていた状態から、報告フォーマットをあわせたうえで、マスタスケジュールに対する進捗をDay to dayで更新し、Single Source of Truthからステータスを報告する形に変えました。

プログラムとして再編成された後、全体スケジュールを策定したところから、その計画に対してのOn time & On budget（期限死守、予算厳守）がマネジメントからの厳命でした。

そのため、クリティカルな活動として位置付けていたIntegration Testのタイミングでは、シナリオの進捗と、発生したIncident数を毎日ダッシュボード化してボードメンバーに報告していました。

プログラムマネージャからポートフォリオマネージャになった

色々とありましたが、プログラムとしてGo-Liveして、Hypercare期間（稼働直後の安定化するための期間）を経てBAU（Business As Usual: 運用保守チームへの移管）に移行しました。

稼働後は、プログラム/プロジェクトメンバーを母体として、新しい基幹システムの上で、デジタライゼーションを行う部署が新設されました。

そこに横滑りのような形で、私が部長として就任しました。

日本語だと部長ですが、PMBOK的な解釈で言えば、役割としてはポートフォリオマネージャです。

（プロジェクト、プログラム、ポートフォリオの目的）

ポートフォリオの定義をPMBOK Guide 6th editionから引用します。

ポートフォリオは、戦略目標を達成するためにグループとしてマネジメントされたプロジェクト、プログラム、サブポートフォリオ、および定常業務が収集されたものである。（PMBOK Guide 6th edition - ポートフォリオの定義）

デジタル部門の部長職についたときには、IT組織からビジネスの事業本部に異動になっています。

このことからも分かることは、ビジネスの戦略目標を達成するためのマネジメントを行うことが、ポートフォリオマネージャとしての役割ということです。

具体的に言うとビジネスで立てた中長期計画に対して、ビジネス戦略にアラインしたデジタル/ITの中長期計画を立てます。デジタル/ITの中長期計画では、ROIを計算したうえで、それをビジネスの計画にも反映します。

そして計画実現のために、配下にプログラム/プロジェクトを組織し、推進していくイメージです。

運用移管も行いましたが、移行期間中は同一のポートフォリオ下に定型運用保守をおこなうチームもありました。

（ポートフォリオ、プログラム、プロジェクト、定常業務の関連）

ポートフォリオマネジメントの重要性

プロジェクトがどういうものかはご存知のかたが多いと思いますが、プログラムとポートフォリオは聞きなれない方もいらっしゃるのではないかと思います。

こちらの記事では、プロジェクト、プログラムとポートフォリオのイメージを掴んでいただくために、実際の例を織り込んで説明きました。

当たり前のことですが、ほとんどの組織では人的資源、予算、時間が限らています。

その中で戦略目標に基づいて、どういうプライオリティ、順序で戦略を実行していくのか見ていくことが重要になります。

また、プロジェクトがどうしても個別最適になりがちなところに対して、組織の包括的な目標から全体最適をはかっていく必要もあります。

プロジェクトには始まりがあり、終わりがありますが、ポートフォリオで重要なことは監視とコントロール、そしてプログラム/プロジェクトの実行評価です。

ポートフォリオマネージャとしての役職を設けることは日本の組織ではあまりないかもしれません。ただし、ここで必要とされる任務とスキルは、組織の中では主にCXOに近しい部分で必要とされるものとオーバーラップがあると感じます。

ポートフォリオマネジメントの重要性は、組織の規模が大きくなり、ビジネスが複雑になればなるほど、増していくものと思います。