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

ゼネラルなプロ (11)

向後　忠明　[プロフィール]　：9月号
　今月号からは見える化された具体的なプロジェクト群の実現に向けた活動について話をします。
　しかし、この話を進める前に、筆者としてこの話を事業主(オウナー)側または請負企業側のどちらの立場で説明したら良いのか！と言った、迷いが出てきました。
　そこで、P2Mについて深い知験を持っている先輩の意見を聞くことにしました。
　先輩は“P2Mの内容はどちらかと言えば顧客である事業主(オウナー)の立場でのマネジメントガイドとして見た方が良いのでは”との指摘がありました。
　プログラムマネジャの立場は一般的に図11-1に示すように事業主(オウナー)の立場で関連プロジェクトを統括する人であり、その配下にそれぞれ個別のプロジェクトマネジャが配置され、実際のプロジェクトが遂行すると言うことで話が定着しています。(プログラムの規模によってはプログラムマネジャが直接プロジェクトに関与していくケースもあります)

図11-1　プログラムマネジャとプロジェクトマネジャ
図11-1　　プログラムマネジャとプロジェクトマネジャ

　これまでのスキームモデルの範囲である「使命」を具現化(見える化)する構想段階は事業主(オウナー)の立場でのプログラムマネジャの役割が非常に大きいです。
　この結果、図11-1に示されるような各種のプロジェクト群が生成されることになるのですから！
　しかし、その後の各プロジェクトの実行に向けたシステムモデルの段階に入るとその役割の多くは配下のプロジェクトマネジャになります。そして、それぞれの請負企業のプロジェクトマネジャ、そしてそのもとで働くメーカや工事業者が実際のプロジェクトを実行します。
　このように考えてくると、先輩の言う通りになるような気もします。
　しかし、すでに前月号のゼネラルなプロ(10)ではP2Mの本質は以下の通りと筆者の考えを述べています。

“これまでの顧客(オウナー)対請負業者と言った対立状態の事業の進め方では現代社会の複雑な課題の解決や新しい仕組み作りに対応していくためには十分な方法ではなくなってきています。これからは、顧客(オウナー)と請負業者双方の得意分野の技術や知識の結合により事業(プログラム&プロジェクト)を進める必要があります。”

　この考え方はプログラムの主導は必ずしも事業主(オウナー)のみにあることではなく、請負企業の能力によってはその役割を代わることもできると言うことを言っています。
　すなわち、プログラムへの参入始点からプロジェクト群の検証並び調整等を含む全体マネジメントをプログラムマネジャとして行う人材であれば事業主(オウナー)側であろうが請負企業側であろうがプログラムマネジャの役割はどちらでも良いと思っています。

　筆者の海外でのPFI事業の経験では、事業主(オウナー)の立場であったが、同様な役割をプログラムマネジャに要求しました。そして、各プロジェクトの実行責任者はプロジェクトマネジャとし、PMBOKのガイドブックに示すような金、技術、スケジュールのマネジメントを、そしてプロジェクト間のインターフェースや所掌範囲の調整、そして全体プログラムのセットアップ、プロジェクト計画、そして個々のプロジェクトの進捗および変更管理等の全体責任をプログラムマネジャとしました。
　そして、その配下のプロジェクトマネジャと請負企業のプロジェクトマネジャがプロジェクト計画書に従って、ある一定の契約条件のもと、プロジェクトを実行することとなります。
　筆者の請負企業側のプロジェクトマネジャとしての経験からでも、事業主(オウナー)の要請があれば事業主(オウナー)側に立ってプログラムを請負企業側の人材がその役割を果たすことは可能と思っています。
　　よって、P2Mに示されプログラム&プロジェクトに関する知識は事業主(オウナー)、請負企業の区別なく、それぞれの立場から必要に応じて利用していけば良いと考えます。
　筆者の期待はこのように双方の立場で顧客または企業の要求に従って活躍できる「ゼネラルなプロ」の出現です。
　P2Mの考え方についての筆者の意見は上記に示す通りで先輩の意見とは大分異なることになってしまいました。
　話がだいぶずれこんでしまいましたが、これから本題に入ります。

　まずはプログラムを構成するプロジェクトの開始からの話から始めます。この時点では、プログラム全体のプロジェクト間の調整や大まかな各プロジェクトの実施計画はすでに出来上がり、各プロジェクトが担当プロジェクトに移行しているとの前提とします。

　プロジェクトの開始に当たって必ず行わなければならないことは、プロジェクト体制のセットアップおよびプロジェクト計画です。

　この作業はプロジェクトを効果的に達成するための重要なステップでありP2Mではこれを“プロジェクトシステムズマネジメント”と称しています。
　しかし、残念ながらその内容は余りにも難解で学術的な内容となっていますので自分なりの解釈で話を進めます。
　例えば、
　“P2Mでは、“プロジェクト全体の枠組みを明らかにし(WBS：Work Breakdown System)そしてプロジェクトを構成する諸要素の集まりを明確にし、その要素間の関係を明らかにし、その細部を具体的に考察する”
　そして
　“プロジェクト活動だけではなく、プロジェクトが提供する成果物やサービスの仕組みを含めて、プロジェクトの取り組むべき課題と範囲を明らかにし、プロジェクト活動を計画し、管理することを可能にしようとしているものである”
　としています。

　これを見ると “プロジェクト体制のセットアップおよびプロジェクト計画”のことを言っているように筆者には思えます。
　因みに、プロジェクトの成功率の50%以上がプロジェクト計画の良し悪しで決まると言って過言ではありません。このように与えられた目的に対してプロジェクト計画を策定することは非常に重要なことなのです。
　このような事実から、事業主(オウナー)も請負企業もそれぞれの立場に立ってのプロジェクト計画を立てる必要があります。
　しかし、事業主はプロジェクトを実際に行うのは請負企業側と考え、プロジェクト計画の多くを請負企業に任せることが多いのが現実です。そのため、IT業界などでは顧客(オウナー)がプロジェクト計画を含めた要求条件を整えることもなく要件不備のまま、プロジェクトを依頼することが多いようです。　その結果として、多くのITプロジェクトが失敗していると言うことが多くで伝えられています。
　すなわち、プロジェクトの命運はこのプロジェクト計画のでき具合により大きく左右されることになると言うことです。

　図11-2はプロジェクト計画書の作成までの手順を示しています。プロジェクトに関する前提条件や作成する内容もその立場によって異なってきますが、この手順は基本的に事業主(オウナー)にも請負企業にも利用できる一般的な手順です。

図11-2　プロジェクト計画の手順
図11-2　　プロジェクト計画の手順

　一般的な話ですが、事業主(オウナー)側の作業で技術的な検討と調達にかかわる作業が最も人手と時間のかかるものです。また、プロジェクト条件の確認以降の作業もかなり調達にかかわる作業でプロジェクト計画の内容も変更せざる得ないことも出てきます。
　なぜなら、プロジェクトの実行は発注する側は受注する側の技術や事情のすべてがわかっているわけではないでしょう。また、発注側の要件にすべての事を網羅的に示すことも、また、受注者側にもそのプロジェクトを受注するにあたっての条件もあります。
　よって、調達にかかわる作業が図11-2に示す手順で出来上がったプロジェクト計画書は契約交渉を通して修正され、契約書の一部として最終版が出来上がることになります。
　よって、事業主側(オウナー)側の技術やプロジェクトに関する要件はプログラム要件(プログラム計画書または事業化検討書)に示される内容に沿って、まずは調達にかかわる作業から入るのが定番と言ってよいでしょう。
　今月号は契約の話をする予定でしたが、プロジェクト計画、調達そして契約は三位一体の関係であり、切り離して話をすることができません。

　よって、来月号では調達に関する話をしてから契約の話に入って行きたいと思います。
ページトップに戻る