プロジェクトライフサイクルと組織

プロジェクトにおけるライフサイクルの考え方とライフサイクルを回すために必要な組織のあ り方
株式会社三菱総合研究所
情報技術研究センター 澤部直太

今回は、プロジェクトはどういう形をしているのかということを、会社のような組織と対応づけて説明をしていきます。「プロジェクトステークホル ダー」、「プロジェクトライフサイクル」、「組織とプロジェクト」という順で説明します。

【目次】

プロジェクトステークホルダー

slide04.png

プロジェクトのステークホルダーの定義は図の通りです。「プロジェクトに積極的に関与しているか、プロジェクトの実施あるいは完了の結果から、自ら の利益にプラスまたはマイナスの影響を受ける個人や組織」という定義をしています。プロジェクトにはプロジェクトのスポンサーと言われる人や、プロジェク トマネージャーの周りにプロジェクトマネジメントチームというプロジェクトマネジメントを一緒に行う仲間がいます。その外側には実際にプロジェクトを遂行 していくチームがいますし、さらにプロジェクトステークホルダーが周りを取り囲んでいる形になっています。

プロジェクトライフサイクル

slide06.png

プロジェクトライフサイクルの説明をします。プロジェクトライフサイクルの定義はスライドを参照してください。プロジェクトは幾つかのフェーズに分 けられていて、そのフェーズが順番に繰り返して行われることによって1つのプロジェクトのライフサイクルができ上がっているということを表しています。 PMBOKの中では44のプロセスありますが、立ち上げのプロセスから始まり、計画、実行し、実行している間に計画が狂ってきたらまた計画のプロセスに戻 り、また実行のフェーズに移るというようにぐるぐる回りながら、最後にプロジェクトが終わるときに終結のフェーズに移ることをプロジェクトライフサイクル と呼んでいます。

slide07.png

プロジェクトライフサイクルの特性としては、次のようなことが言えます。まず各プロジェクトでどのような技術的作業を実施するのかを決めていきま す。それから、各フェーズでいつ要素成果物を生成し、どのように検証・承認するのかも決めます。3つ目の「各フェーズに参加するのは誰か」では、どの フェーズでだれが参加するのかを決めます。詳しくは人的マネジメントのところで説明をします。

4つ目の「各フェーズのコントロールの方法及び承認方法」では、各フェーズでどのように成果物を作成し、さらにどうやって承認するのかを決める必要 があります。

slide08.png

さらにプロジェクトライフサイクルの特徴をスライドに挙げます。

技術的成果物とは、何かをやったときにでき上がったものです。例えばソフトウエアではソフトウエアの設計書や、実際にプログラムを開発したときの ソースコードが成果物です。

スライドの図にあるように、通常のプロジェクトではプロジェクトの序盤は人もコストもあまりかかりませんが、フェーズが進むにしたがって人もお金も かかってきます。そして、終結時に急激に落ち込みます。

目標が達成できないリスクとは、プロジェクト開始時には全体像がまだ把握できていないことが多いためです。

slide09.png

図はプロジェクトのフェーズとして一般的な、初期段階から中間段階、最終段階に流れるフローだと考えてください。ソフトウエア開発を例にすると、成 果物は最終的にソフトウエアと設計書が成果物になります。そして、プロジェクトの中のフェーズ、あるいはあるプロセスのアウトプットとして生まれたものを 要素成果物と呼んでいます。

なお、設計書にも概要設計から細かい詳細設計まであり、これらをどこまで納品するかは契約によることになります。

slide10.png

フェーズには必ず要素成果物があります。フェーズの目的は要素成果物をつくり上げることであり、承認されないと次のフェーズには進めません。プロ ジェクトが大きくなると、サブフェーズといってフェーズをさらに細かく分割するということもします。サブフェーズに分割した場合には、当然、サブフェーズ にも要素成果物がありますから、サブフェーズの要素成果物を確認して承認することを繰り返すことによって、確実にフェーズを終わらせることができます。サ ブフェーズには監視とコントロールのための特定の要素成果物が割り当てられています。

フェーズの終了時には、遂行された作業と要素成果物のレビューが行われます。終結時のレビューは2つの意味を持っています。そのフェーズを終えるこ とと、次のフェーズを立ち上げる承認の意味です。

各フェーズには要素成果物があり、承認をする必要があるということを覚えておいてください。

slide11.png

プロジェクトライフサイクルとプロダクトライフサイクルの関係について説明します。例えば、新しい電気製品を作る場合、あるプロジェクトが立ち上が り、設計が始まり、実際にものをつくり、最終的な製品ができ上がります。プロジェクトとしてはそれで終わりですが、そこで生まれた製品は実際に販売された り、販売されたものが壊れた場合には修理をするといった、プロジェクトではない定常業務に移ってきます。

製品が定常業務に移ると、今度は改善・改良要望が生まれてきます。このようなニーズが生まれてくると、そのニーズを取り入れるか否かということで計 画が始まり、また新しいプロジェクトが立ち上がります。

このサイクルをぐるぐる回し、例えば最終的に撤退ということで販売を終了した後に、しばらく期間を置いた後でサポートも終了となります。プロダクト のライフサイクルはこの時点で終了となります。

組織とプロジェクト

slide13.png

さて、ここからプロジェクトと組織という話をします。組織にはさまざまなものがありますが、PMBOKで名前をつけているものに大きく3つありま す。機能型とプロジェクト型とマトリクス型です。

slide14.png

機能型の組織は、社長等いわゆる経営者という人が上にいて、その下に部やセクションといった部署があり、各部署にマネージャーがいるというタイプで す。部署にはメンバーやスタッフがいます。プロジェクトにはさまざまなセクションの人が関わってきます。プロジェクトマネージャーに関しては、機能部門の マネージャーの人々が調整をしてプロジェクトマネージャーの代わりになります。

slide15.png

続いて、プロジェクト型の組織です。これはプロジェクトのために組織が特別につくられます。組織のあるセクションの中にプロジェクトマネージャーが いて、その下にそのスタッフがいます。この場合、1つのプロジェクトはおおよそこの組織の中で閉じています。これをプロジェクト型の組織と言います。先述 の機能型組織と大きく違うのは、機能型組織は機能によって組織を縦に分割していましたが、プロジェクト型組織はプロジェクトごとに変わります。このような 組織ではプロジェクトが終わればこのまとまりはなくなって、また違うところに人が移っていきます。

slide16.png

さらに少し複雑になるのが、マトリクス型の組織です。これは機能型の組織と非常によく似ているのですが、特徴としてはプロジェクトマネージャーの役 割を、機能部門マネージャーではなく、このプロジェクトに入っているスタッフの中で調整して行うタイプです。これを弱いマトリクス型の組織といいます。 「弱い」とついているのは、明確なプロジェクトリーダーがいないことを意味しています。

slide17.png

次はバランス・マトリクス型の組織です。これはマトリクス型の組織の中で「中間ぐらい」という意味です。先ほどと同じように各機能部門の中からばら ばらにスタッフが出てくるのですが、その中にプロジェクトマネージャーが明確に存在します。存在するので、プロジェクトマネージャーがこのプロジェクトの 管理に責任を持つことが決められています。これがバランス・マトリクス型の組織です。

slide18.png

弱いマトリクス型とは反対に強いマトリクス型組織もあります。非常に特徴的なのは、プロジェクトマネージャーだけのチームがあることです。あるプロ ジェクトをやろうとしたときに、このプロジェクトマネージャーの部門からプロジェクトマネージャーが出てきてほかの組織のスタッフを束ねてプロジェクトを 遂行します。バランス・マトリクス型の組織にプロジェクトマネージャーがいるのと似ていますが、プロジェクトマネージャーだけの組織があるのでさらにプロ ジェクトマネジメントを強力に進めることができるという特徴があります。

slide19.png

組織の構造を様々な観点で見たのがこの表になります。

プロジェクトマネージャーの権限についてですが、機能型の場合にはプロジェクトマネージャーがそもそもいない状態なので権限はありません。それに対 してプロジェクト型ではしっかりプロジェクトマネージャーが組織としていて機能していますので非常に強くなります。マトリクス型では、強いマトリクス型は より権限が強く、弱いマトリクス型ではあまりないという特徴があります。このように組織構造とプロジェクトは密接な関係があります。

slide20.png

PMO(プロジェクト・マネジメント・オフィス)について説明します。プロジェクトマネージャーをサポートする組織がPMOになります。両者の関係 は、プロジェクトマネージャーに対してPMOという組織が権限を委譲していることになります。つまり、PMOは、プロジェクトマネージャーがプロジェクト に関する物事を決めて良いという権限を、プロジェクト憲章のような形で与えます。プロジェクトマネージャーはPMOに対して報告を上げます。報告をもらっ たPMOは、そのプロジェクトマネージャーが管理しているプロジェクトに対して、作業が遅れていないか、十分な品質が保たれているか、コストがオーバーし ていないかといったことを監視します。

チームのメンバーは、プロジェクトマネージャーに報告し、さらにPMOに上げます。一方、PMOはプロジェクトマネージャーだけではなくプロジェク トメンバーに対しても、仕事が順調に進んでいるかどうか、うまくいっていないとすれば何が問題なのかを検討してフィードバックする役割を持っています。