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

ゼネラルなプロ (20)

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

 今月号からは具体的なプロジェクトマネジメントの内容の話に入ります。
 先月号にて説明してきたようにプロジェクトマネジャおよびキーとなるスタッフが決まったらまずやらなければならないことはプロジェクト計画書の作成でしょう。
 すでに計画書の重要性とそこに示すべき項目についてはゼネラルなプロ18で説明しています。今月号はその内容について話をしたいと思います。
 まずは計画書作成に当たっては契約書の内容の検討から入りますが、そこに求められているミッションまたは要件を完全に把握することが必要です。
 そして、顧客の要件から自分達がやらなければならない目標や実行に当たっての方針や考えを設定し、それに対する羅針盤を持って、プロジェクトを進めていく必要があります。
 それがプロジェクト計画書です。
 なお、計画書の最初に示すことはゼネラルなプロ18の表18-1の第一番に示しているプロジェクト遂行に関する基本的な考えとその方針です。
 その例をいくつか示すと以下のようになります。

例その1.新技術開発(植物由来の高機能材料)に関するプロジェクトの場合
 本プロジェクトはこれまで石油を原料とした高機能材料を植物由来のものに転換する画期的な技術の開発であり、無限かつ再生産が可能な植物を原料とする製造プラントの開発である。その成果を会社の今後の重要な事業の柱となるべく、全社挙げての支援をもらいその目的を達成することに全力を尽くす。ここでの、開発のキーワードは「環境にやさしい新規性,発展性のある高付加価値材料の開発」とし、特許取得を目標とすることをプロジェクトの開発方針とする。

例その2 戦略的海外金金融システムの開発に関するプロジェクトの場合
 本プロジェクトは開発相手国の中央銀行を中心とした各銀行間との資金のやり取りを瞬時に行い、決済を一箇所で翌日決済を可能にするコンピュータシステムである。
 本プロジェクトのキーワードは「フォールトトレラント」であり、「将来システムへの拡張性」とする。なお、顧客は海外の中央銀行であり、このプロジェクトの成功は当社のシステム構築能力の信頼性を世界に問うものである。
 また、当社としてはじめての海外におけるシステム構築プロジェクトである。
 よって、言語の違いおよび異文化でのシステム構築であることを念頭に顧客との密なコミュニケーションと既存システムとの調和を持ってシステムの構築を行う。

例その3 市民の注視の下で行う土壌および地下水汚染対策プロジェクトの場合
 本プロジェクトは対象エリアの汚染土壌および地下水の環境汚染物質の完全除去による土壌および地下水の改良である。
 そのためには市民はじめ関係者の全員が納得する汚染物質の除去による土壌改良、および地下水からの汚染物質の浄化が必須でありかつ結果の情報の透明化が必要である。
 本プロジェクトのキーワードは「市民目線での汚染対策」とし、以下を本プロジェクトの基本方針とする。
汚染物質による健康被害が皆無となる除去技術の採用とその実証
実証に基づく本格的汚染物質の除去作業
除去した結果の情報の透明化とその公知

 このようにプロジェクトの目標及び求められる要件を念頭に、プロジェクトを取り巻く周辺環境、そしてプロジェクト実行での基本的な考えや方向性を示したものが方針として計画書に示されなければなりません。それが会社の代表として指名されたプロジェクトマネジャの意志表示(思い)であり、プロジェクトメンバーやステークホルダーに対しての宣言でもあります。
 しかし、プロジェクト計画書はゼネラルなプロ18でも説明したように、「基本的にプロジェクトマネジャが責任を負って、プロジェクトチーム全体がさまざまな部分で担当しながらまとめていく」としています。
 方針設定がプロジェクトマネジャの“思い”としていますが実際はこの“思い”もチーム全体の“思い”でありそして顧客の納得したものでなくてはなりません。  よって、方針設定の基本はあくまでもプロジェクトに責任を持ってプロジェクトマネジャが設定し、その内容についてはプロジェクトスタッフの意見も取り入れたものでなくてはなりません。同時に顧客の“思い”をも汲みとったものでなくてなりません。

 このように設定されたプロジェクト方針に基づきプロジェクト計画がなされることになります。
 この方針設定においてプロジェクトに要求される内容や重点を置く役務などは当然のことながら分析された上でのことであり、その前提でまずはプロジェクト組織体制と人材配置が重要な課題となります。
 人材配置や組織に関する体制作りについてはすでにゼネラルなプロ19でその概要は説明しているのでそちらを参照してください。
 しかし、プロジェクトの規模が複雑、大規模になるとプロジェクトに含まれる機能やその役割も複雑多岐にわたるとプロジェクトマネジメントそのものも難しくなります。
 そのため、「プロジェクトの範囲や他システムまたは設備とのインターフェース」、「どの機能を誰が担当し、自社の技術で足りない機能はどこにお願いするのか」そして「誰がそれをチェックするのか」、また「関係各社とのコミュニケーションのための方法や識別はどうするのか」等、プロジェクトマネジメント上の課題が発生してきます。

 そのためにはプロジェクトを構成する「仕事の範囲(スコープ)」、そして「その中の構成要素は何か」を分析する必要があります。これを一般的に“タスクの洗い出し”と言います。
 すなわち、プロジェクトを構成する仕事(タスク)や機能の分解です。これはプロジェクトの構成要素の識別、スケジュール上の各機能の連結(ネットワーク)、各機能とコストの関連、そしてコミュニケーション&コーディネーション要領の基盤となるものです。

 これをWBS(Work Breakdown Structure)と言います。
 WBSについてはすでに読者諸氏は多くの知識を持っているのでここでは関連書籍にその詳細はお任せします。
 なお、プロジェクトの分割方法には業界によってそれぞれ異なった基準、例えばシステムまたは設備基準、職能基準、地理的基準、フェーズ基準そしてそれぞれの組み合わせ等があります。
 要は、プロジェクトによって便利な基準を組み合わせれば良いと思います。なお、会社によってはWBSに関する基準がある場合もあるのでその場合は会社の基準に沿ってWBSの構築は行わなければなりません。

 ところで、WBSの設定の前にやることがあます。 それはプロジェクト名称とプロジェクトの識別番号です。
 会社では多くのプロジェクトが実行されているので自分のプロジェクトを識別しないと自分の関係するプロジェクトの会社内での位置づけが分からなくなってしまいます。
 このことを明確に定義しておかないと関係図書や責任コストそして関係各所とのコミュニケーション上の識別が他のプロジェクトと「ごちゃ混ぜ」になり、プロジェクトの混乱の原因となります。
 それを「プロジェクト名称」と言い、その識別をプロジェクトコードまたはジョブナンバーとも言います。その例を以下に示します。
例:
プロジェクトの名称は全てのプロジェクト関係者間で交換される図書類およびコミュニケーションに統一したプロジェクト名称を以下のように設定する。
○○対策プロジェクト
なお、本プロジェクトの識別番号はYYYYとする。これにより、プロジェクトにて発生する図書類およびタスクの識別を行い他のプロジェクトとの仕分けの基盤とする。

 この識別番号(プロジェクトコードまたはジョブコード)はWBSの上位の番号として常に使用され、あらゆる図書類や役務(タスク)の識別の頭に利用されます。
 なお、プロジェクト識別番号は会社としてプロジェクト種類毎にプロジェクト識別番号の台帳を作っておく必要があります。

 さて、プロジェクト方針、タスクの洗い出し、WBSの設定そしてプロジェクト体制も決まったところで、いよいよゼネラルなプロ18の表18-1に示す具体的プロジェクト目標(プロジェクト始まりと完了時期、実行予算の設定、および技術性能の達成目標)の設定に入ります。

 プロジェクトはユニークで有期的な一過性の事業であることは読者諸氏も周知のことと思います。そのことから、組織はプロジェクト毎にクロススファンクショナル組織で構成されます。当然、プロジェクト毎に参加する人も異なってきます。
 プロジェクトマネジャは初めて一緒に仕事をする人また考え方の違う人たちと、一緒に仕事をしていくことになります。
 そのためには、すでに説明した方針設定、WBS、各種手順等は共通の基盤として重要なことであり、プロジェクトを進めるうえでの基礎的知識です。
 それと同じくらい重要なのはプロジェクト目標の設定です。
 一般的にプロジェクト目標と言うと「スケジュール」、資金(コスト)」、そして「品質」であり、契約で求められるすべての条件をこの3つの目標を最適にマネジメントして達成していく必要があります。
 これら相反する目標を適切にプロジェクトに要求される各種要件や取り巻く環境条件をクリアーしながら全責任を持ってプロジェクトをまとめていくのがプロジェクトマネジャの役割です。このことはすでにゼネラルなプロ19の図19-1に示す“責任一点化の概念”で説明した通りです。プロジェクトマネジャの責任はこのように非常に重いものでこれがゼネラルなプロの仕事です。
 特に中途半端な権限が付与されてプロジェクトマネジャを依嘱された人が不幸な状況に追い込まれることを良く聞きます。

 人はエンパワーメントされ試行錯誤を繰り返しながら成長していくものです。新たな権限を与えることによりバケる人もいます。プロジェクトマネジャの育成を速めなければと良く聞きますが、それを指名する人が権限移譲に臆病であればこれも無理です。
 プロジェクマネジャを育成したいと思う経営者は権限付与のあり方を自問自答し、またプロジェクトマネジャを志す人は権限を与えられるのを待つのではなく自ら奪いに行くべきでしょう。
 この双方ができて初めてゼネラルなプロが育成されるのです。

 来月号からはプロジェクトの目標について話を進めていきたいと思います。
ページトップに戻る