PMプロの知恵コーナー
先号   次号

ゼネラルなプロ (5)

向後 忠明 [プロフィール] :3月号

 今月号からは、これからのソリューションビジネスに向けて必要と思われるプログラムマネジメントについて「P2M」の内容に従い、筆者の実践してきたプロジェクトマネジメントと対比しながらの説明を試してみます。」と前月号で約束しました。

 しかし、同じPMAJのオンラインジャーナルに、本コーナとは別に「投稿コーナ:私たちのP2Mとは何か、考えてみませんか?」にて、「P2M」の内容について詳しく説明していることが分かりました。よって、「P2M」の内容の詳細についてはこの「投稿コーナ」にお願いすることにします。なお、「P2M」を知らない読者もいると思いますので、その概要について以下に説明します。

「P2M」は大きくプログラムマネジメントとプロジェクトマネジメントから構成されていることはすでにゼネラルなプロ(2)で説明したとおりです。
 P2Mとは与えられたミッション(使命)をスキームモデル、システムモデルそしてサービスモデルと言った一連の業務のプロセスを通してミッション(使命)を完遂するためのマネジメント手法です。
 すなわち、スキームモデルのフェーズ(領域)でプログラムを構成するプロジェクト群が形成され、システムモデルのフェーズ(領域)では、プロジェクト群の各プロジェクトの具現化の設計、システム構築、実証まであり、サービスモデルは構築されたシステムを利用して財を生産し、サービスを提供するフェーズ(領域)を言います。この全フェーズ(領域)を網羅するのがプログラム総合マネジメントと言われるものです。
 また、ミッション(使命)とは「組織体オーナが期待する変革に対応したソリューションの源泉」を意味し、プログラム統合マネジメントの起点となるものです。
 このプログラム統合マネジメトは
ミッション(使命)を各フェーズ(領域)毎に、プログラム戦略マネジメントの要素であるビジネスマネジメントに関する各種技法(例:SWOT分析、ポートフォリオ分析、オプション戦略、KJ法、ケプナートリゴ法等々)を利用し、ミッション全体を戦略的に解釈し、各領域でのなすべき要件を定義する。
その結果を持って下図5.1に示すように、各領域のそれぞれのマネジメント活動に入る。
 なお、図5.1に示す相関図でのミッション定義はあくまでも組織オーナ(顧客)が行う前提で記述しています。

図5.1 プログラム統合マネジメント相関図

図5.1 プログラム統合マネジメント相関図

 この内容から察すると、プログラム統合マネジメントの対象領域はこれまでのプロジェクトマネジメントのよりは幅広いものであることがわかります。特に、図5.1のスキームモデルに特徴があります。
 プロジェクトマネジメントではこの部分は組織オーナ(顧客)の役割として考えていました。しかし、組織をとりまく外部環境や技術革新による技術進化の速さ等を考えると、組織オーナ(顧客)だけではなく、これまで請負企業側においてプロジェクトマネジメントに携わっていた者もこのフェーズ(領域)に関与していかなければならない状況になっています。
 このことはすでにゼネラルなプロ(2)で説明したように一橋大学の伊藤教授も言っていますが、このスキームモデルの内容はまさに、今後の「ゼネラルなプロ」に求められるスキルとして重要なものとおもわれます。  この領域の仕事は内容的には組織オ-ナが行ってきた、いわゆる上流側の職域と考えられていました。
 この領域の中でも上流側の仕事は組織オーナ企業の役員会や経営企画部が行い、この過程で組織としての方向性、いわゆるミッション(使命)が創生されるわけです。その結果をもって組織オーナに雇われたコンサルティング会社がミッションを具体的に戦略として各種ビジネスマネジメント技法を使って実現可能なシナリオ形式に展開し、ミッションをプログラム化します。
 しかし、実際のプログラムの実行は請負会社がプロジェクト計画から、設計、調達、そしてシステム構築または設備建設を行っていくことになります。そして、最終的には組織オーナがそのシステムや設備を運用することになります。
 このような流れがこれまでのプロジェクトと称された事業の実態ですが、この流れを見ると以下のような問題が浮かび上がります。
組織オーナと経営企画部自身がスキームモデルに示す作業を単独で行い、直接に請負企業に委託し、次フェーズ(領域)のシステムモデルに示す作業を行うことができなかったのでしょうか?
特に情報通信系のプロジェクトで“要件定義の曖昧なプロジェクト”と言われ、これがプロジェクトの失敗の原因となってきていると良く言われています。
このことを考えると、スキームモデルの作業が曖昧であったということになります。
そのため、組織オーナはコンサルタントに上記に示したようなスキームモデル領域の仕事をコンサルタントを委託し、プロジェクト計画に必要な要件の仕様化を作成させていました。
しかし、コンサルタントの役割の多くは上記で示したスキームモデルの領域までの作業がほとんどであり、実際のシステム構築や設備建設の役割とその結果責任はそのプロジェクトを遂行する請負企業となります。 よって、最もリスクの大きな領域でのシステムモデルでの結果責任は一切コンサルタント会社にはありません。
それでは組織オーナ側でのシステムや設備の運用や運転による結果として、その投資対効果や運用がうまくいかなかった場合は誰が責任を持つことになるのでしょうか?
当然、それはスキームモデルやシステムモデルの中でのプログラム評価やシステム構築または設備建設に関する検討が不十分だったことに起因します。

 このように、プログラムの流れの中で介在する組織体がいくつも入り込むと、プログラムに関連するリスクが、複雑になればなるほど大きくなります。
 もちろん、関係者は契約や業務運営において極力自組織のリスク極小化を図る手段をとるでしょう。
 それでも結果的に事業が目的通りにいかなかった場合はそれぞれの担当組織の責任となるがプログラム全体としての責任は、組織オーナ(顧客)に帰ってきます。
 このようなことを防ぐには、プログラム総合マネジメントを組織オーナやコンサルタント会社がプログラムに全責任を持って行うことが理想的です。
 しかし、現状では組織オーナ側やコンサルティング会社にはプログラム総合マネジメントに示されるようなプログラム全般に責任を持って実行できる人材が育っていないのが現状です。
 それではこれまでシステム構築や設備建設関連プロジェクトにおいてプロジェクトマネジメントに関する実績を多く持つ請負会社はどうであろうか?
 一つの案としては 以下のような3つの方法があります。
組織オーナ(顧客)側が単独で上流側部分の業務をスキームモデルに従い要件を作成し、プロジェクト群を請負会社に発注し、プログラム全体を組織オーナ(顧客)がマネジメントする。
(組織オーナ(顧客)側が請負企業にプロジェクトを発注し、プログラム統合マネジメントの責任を持ってプログラムの全行程に責任を持って実行する)
請負企業が顧客と共同または一部分担で全行程を上流部分からプログラム全体をマネジメントする。(請負企業がコンサルタント会社部分を兼務する)
コンサルタント会社がシステムモデルに属するプログラムの実行までの責任を持ってプログラムをマネジメントする。

 上記の中でどのケースが理想的か?と聞かれれば①が最良のケースと言えるでしょう。ただし、現実的には②または③のケースと思われます。
 しかし、上記のいずれのケースをとっても、スキームモデルとシステムモデルの双方をマネジメントできるプログラムマネジャと称する人材が必要となります。

 このようなことを考え、上記で言うところのプログラムマネジャに相当する「ゼネラルなプロ」に必要なスキルを前回のゼネラルなプロ(3)で示したわけです。
 なお、ここで前回の「ゼネラルなプロ」にて示したスキル項目について少し変更をしたいと思います。なぜなら、タイミングも良く、情報処理に関するPM人材育成で、「これからのハイレベルPMに必要なスキルとは?」と言う内容の議論がされました。そのスキル全体像を図5.2のように示されました。

図5.2 ハイレベルPMのスキル全体像

図5.2 ハイレベルPMのスキル全体像

 上記の図5.2で前回と異なる表現がいくつかありますが、基本的には前回と大きな違いはありません。必要スキルについて、大きく変わっている部分はパーソナルスキルが追加され、個人特性が行動特性となっただけです。
 個人特性は用語の違いはあるがもともと行動特性と同じ意味として使用していました。しかし、その中でもパーソナルスキルに属するネゴシエーション、コミュニケーション、リーダシップは行動特性とは異なり、資質特性(aptitude)と考え、育成可能と判断し、ここに位置付けました。
 問題のスキームモデルに相当する上流領域のスキル項目としてはビジネスマネジメントがその対象となると考えられます。
 この図は情報処理業界関連でのハイレベルPMのスキル全体像ですが、他の分野での事業、例えば社会インフラ、生産設備、製品開発、建設、エンジニアリング、事業/組織改革等々にも応用可能と考えています。
 特にスキームモデルに示される領域に関連するビジネスマネジメントスキルがこれからのハイレベルPM、すなわち「ゼネラルなプロ」には必要なスキル項目と考えられます。

 次回は、今はやりの「海外インフラの輸出」を図5.1に示すプログラム統合マネジメントの各フェーズ(領域)に沿って筆者の経験談を書いてみます。
ページトップに戻る