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

ゼネラルなプロ (19)

向後　忠明　[プロフィール]　：5月号
　先月号ではプログラム/プロジェクトマネジメントの基本である「体制作り」、「スケジュール」、そして「コスト」について、筆者の経験からの話をすることにしました。

　なを、筆者が仕事をしていた当時は上記に示す「プログラム」や「プロジェクト」と言った区別はありませんでした。そのため、以降の話では、仕事の内容がプログラム的であってもプロジェクトと称して話を進めていくことにします。

　一般的に、プロジェクト案件が発生したら速やかにプロジェクトの識別番号(プロジェクトコード)をとり、そして組織の編成を行い、遅くとも顧客よりRFP(引合書)が出される前にその体制作りは完了していなければなりません。　そして提案書においても“これこれしかじかの組織とこのような経歴・実績を持つスタッフにこのような役割を与え、このプロジェクトをこのようなやり方で実行します“と示す必要があります。このためにはプロジェクトマネジャ(以降PMと言う)およびそのスタッフはプロジェクトの規模や内容(難易度、規模、場所、要素技術、技術的接点)に応じた組織編成のやり方およびその中で働くスタッフの能力や役割を知っている必要がある。このようにプロジェクトマネジメントの基本の基本である体制が確立して初めて、プロジェクトの活動が開始されることになります。
　なお、上記に示すプロジェクト体制はあくまでも提案書作成にかかわるに体制であり、受注後の実際のプロジェクト体制とは異なることもあります。しかし、提案書作成/提出後もできる限り、提案書作成の時の事情を良く知った、関係スタッフは極力残しておくことが必要でしょう。

　ここで少し、プロジェクト組織の役割と目的について筆者の見解を述べておきたいと思います。
　プロジェクト組織の役割はプロジェクトの目的・目標を達成するために、企業の持っている能力を最大限に活用することにあり、企業の定常組織とは別に、そのプロジェクトのみを対象に設立される、一時的(時限的)なプロフェッショナル集団組織です。
　そのため、プロジェクト組織は、プロジェクトに与えられる要求条件や契約条件および仕事の範囲・規模などによりその構造形態も変化します。
　プロジェクトの実行には、その目的を達成するためには関連する社内の組織のみならず、外部の組織、機関の支援も必要となります。このため沢山の人的資源が投入されるが、ただ単に投入するのではなく、プロジェクト組織のもつ機能、すなわち、実行(Execution)と管理(Management)を有機的に結合させた形態でなければならなりません。そのため、プロジェクト実行に必要な計画〈企画〉、設計、調達、システム据付(設備建設)、運用に十分対応できる組織であり、またプロジェクトマネジメントとして必要な指揮・命令系統の確立、責任範囲、権限・義務等の明確化など、目的を持って組織作りを適任者の人選とあわせて行う必要があります。
　プロジェクト組織はプロジェクトの遂行にあたって、その目的・目標を最も合理的・効果的に達成するための一時的組織であり、プロジェクトの規模・特性に従い、人材の選定やその適正配置を含め如何に組織編成するかが重要です。このようにプロジェクトの発生に従いプロジェクト組織をその都度編成する理由は、下記の通りです。


　プロジェクトは全てユニークであり、不確定要素を常に内包し、その上、絶えずプロジェクトを取巻く環境も変化します。このような条件下でのプロジェクトの諸活動を1つの目標・目的に向かって統括するためには、プロジェクト遂行の責任、権限、情報の一点化・集中化が必要であり、それらが各管理レベルに応じて的確に委譲されることが必要です。
　そのため、PMを頂点とするトップダウン階層を形成したピラミッド型の構造となります。このような考え方を図19-1に示すように“責任一点化”の概念と呼びます。

図19-1 責任一点化の概念

　この図19－1から見られるように、プロジェクト実行の組織は一般的にはPMを頂点とするトップダウンの階層を形成したピラミッド型の構造となるのが一般的です。そして対外対応についても全て責任はこのピラミッドの頂点に立つPMが権限に応じて一身に負えるような組織と役割にしなければなりません。
　なお、プロジェクト規模によっては企業の定常組織の中に責任者を置きこの責任者がいくつものプロジェクトをマネジメントするケースもあります。よって、一概に上記のようなプロジェクト編成をしない場合もあります。自分の所属する企業体制およびプロジェクト規模や内容によってそのプロジェクト実行体制は変化すると言うことを知っておく必要があります。

　ここまでで読者諸氏もプロジェクト組織の役割と目的の基本的な考え方が分かったと思います。
　プロジェクトの発足の時期は会社によっていろいろ違いはありますが、提案書作成時にはすでに体制ができている必要があります。その中でもPMの擁立が最もキーとなります。

　そのPMの選定の時期や人材選定はプロジェクトの規模や難しさによって異なります。
　時期についてはプロジェクトの引合いが出た時点でプロポーザルマネジャとして選定されるケースとプロジェクトの契約がなされた時点の早い時期の選定の2つのケースがあります。また、その人選は会社によって異なると思いますが、プロジェクトの重要度や規模によって社長であったり担当役員またはPMの直属上司であったりします。
　ここで問題はPMに与える権限の範囲です。
　筆者の経験範囲での知見ですが、プラント関連会社ではPMの権限は図19-1で示した責任の一点化の概念でも示すような形態をとる場合が多いです。すなわち、プロジェクト体制作り、スケジュール、プロジェクトコスト、そして変更管理や交渉等を含むプロジェクトの全範囲にまたがります。
　しかし、IT関連会社での多くは上記とは異なり、PMの権限にはプロジェクトコストや変更交渉にかかわることは含まれていません。また、契約前の積算や契約交渉そして契約についても、PMが関与しないケースもあると聞いています。
　しかし、プロジェクト実行中に変更が発生した場合、技術、スケジュール、プロジェクトコストそして契約内容ともと大きくかかわることになり、問題が発生すればPMも関与せざる得なくなります。
　一般的にはPMには“責任一点化”と言う概念があるので対顧客に対してはプロジェクト実行中ではPMはプロジェクトの責任者としてすべてに対応していく必要があります。
　その点では、PMへの権限移譲のあり方では、IT関連会社のケースでは中途半端な気がします。
　以上がPM選定の時期および与えるべき権限についてプラント関連企業とIT関連企業の違いについて筆者の見聞です。
　さて、PMが選定されたら、プロポーザル提出段階またはプロジェクト実行段階においてもそれぞれの作業に関する計画書の作成がPMの最初の仕事になります。
　しかし、計画作成ではPMが決まっていても最初の仕事である計画書作りでは対象となる作業の規模や複雑さによりPM単独では能力的にも問題があります。
　そこでPMは計画作りから参加してもらうスタッフの人選を行うことになります。

　プラントエンジ会社の場合では：
　一般的に、スタッフとはPMを補助する技術系(エンジニアリング)、建設系(コンストラクション)、法務/業務系(アドミ)、調達そして各それぞれの補助員を言います。これらのスタッフを含むプロジェクト組織の一例を図19-2に示します。
図19-2　プロジェクト組織例

　筆者のいたプラントエンジ会社は会社組織そのものがプロジェクト遂行を目的とした組織であり、プロジェクトに関する人材の登録もされているので人材の選定では迅速な対応が可能となっていました。
　すなわち、PMはプロジェクトの内容、顧客の質、そして要件の確定度合い、リスク等々を考え、名指しをして適合する人材を集めることができるようになっていました。
　但し、この場合でも、優秀な人材は多くのプロジェクトからの指名が来るので、人材獲得には多くのPMは苦労します。
　人選される方から見れば、できるだけリスクの少ないプロジェクトに行きたいと思うのが人情です。しかし、重要プロジェクトではわがままを言っていられないケースも出てきます。この場合は、PMは社長や担当役員にその必要性をプレゼンして、関連部署の上司に交渉することで必要人材の選出をしてもらうこともあります。
　もう一つは、PMの人柄や実績も重要になります。なぜなら、経験豊かで、人柄も良く、多くのプロジェクトを経験したPMには誰もが一緒に仕事をしたいと思うのが人情です。
　良いPMには良い人材が集まる。その結果、プロジェクトの成功事例が多いPMには多くの優秀な人材が集まることになります。

　一方、IT関連会社では：
　プラントエンジ会社のようにプロジェクトオリエンテッドな体制が構築されているIT企業はそれほど多くないと聞いています。筆者の所属したIT会社もそのような体制にはなっていませんでした。この会社も他のIT関連企業と同じく、営業が受注から契約までの活動を行い、その後PMを人選するようにしていました。その人選も、プロジェクトの規模や与えられる権限範囲によっては社長であったり直属の事業部長であったりしました。

　以上、プラント関連会社とIT関連企業のPMの選定と権限の違いについて述べてきました。筆者としては、PMにはプロジェクトの規模、内容に応じた責任と同時に権限を持たせる必要があると思っています。
　しかし、日本の多くの企業では権限は組織の職位に与えられているのが一般的です。このミスマッチが“PMに責任ばかりで権限が無い”と言う現象が起き、迅速な問題処理や業務のスムーズな運営を難しくしています。これは顧客満足を得られないばかりか、PMの意欲をそぎ、結局、PMの能力アップばかりか、PMを希望する人も少なくなってしまっている原因でもあります。実際IT系の関連企業ではそのような話を多く聞きます。

　今月号はプロジェクトのセットアップ、プロジェクト組織の目的そしてPMについての話をしました。来月はプロジェクトの基盤計画であるWBSとプロジェクト実行計画について話します。
ページトップに戻る