[2]プロジェクトの組織とプロジェクト・ライフサイクル

スポンサーリンク
スポンサードリンク

プロジェクトの組織構造

組織においてさまざまなタイプの組織構造があり、これによってプロジェクトマネージャの権限が変わってくる。プロジェクトを推進することを前提とした組織形態は、プロジェクトベース組織(PBO)と呼ばれる。

プロジェクトを実施するときの組織構造には以下のようなものがある。

機能型組織

古典的であるが最も一般的な組織構造である。人事、経理、営業、技術、製造などの部門に区分され、技術や製造部門の中においても、機械、電気などのグループに細分化される。機能部門によって細分化されており、機能部門のマネージャが統括しており、マネージャ間で仕事や人員の調整が行われる。

機能部門のマネージャが責任者となり、機能部門のマネージャの指示によってプロジェクトメンバーは仕事を行う。プロジェクトマネージャは独立した権限を持っていない。

【機能型組織の特徴】
  プロジェクトマネージャの権限が弱い。
  指揮命令系統が明確である。
  責任者の権限が強い。

プロジェクト型組織

業務がプロジェクトとして遂行される組織構造で、各プロジェクトがプロジェクトメンバーを統率するプロジェクトマネージャによって推進される。

各プロジェクトマネージャは独立した権限を持ち、経営幹部に直接報告する立場となる。プロジェクト型組織の場合、機能部門のマネージャはプロジェクトに関与しない。

プロジェクトメンバーは、プロジェクトの専任メンバーとなり、プロジェクトの開始や終了にともなって移動となる。組織構造もプロジェクトともに変わる。

【プロジェクト型組織の特徴】
  プロジェクトマネージャの権限が強い。
  プロジェクトの知識や経験が生かされない(※組織構造が変わるため、プロジェクトの経験やノウハウを残せない)

マトリックス型組織

マトリックス型組織とは、機能型組織とプロジェクト型組織が同時に成立する中間的な組織であり、3つのタイプに分類される。なお、マトリックス型組織の欠点としては、機能部門のマネージャとプロジェクトマネージャの両方が権限を持ち、指揮命令系統が複数になるので、異なった指示をすることで対立が生まれる可能性があるということである。

弱いマトリックス型組織

機能型組織を踏襲するが、機能を横断するメンバーによるプロジェクトが編成され、別機能のメンバーと共同で実行するプロジェクトとなる。プロジェクトマネージャの権限が弱く、プロジェクト内での機能間の調整などの役割を持つ。

バランス・マトリックス型組織

中間的なマトリックス型組織で、機能を横断するメンバーによるプロジェクトが編成され、ある程度の強い権限を持ったプロジェクトマネージャが任命される。ただし、マトリックス型組織であるため、機能部門のマネージャの権限が強く経営幹部に直接報告する立場にはない。

強いマトリックス型組織

プロジェクト型組織と同様に、独立した権限をもった専任のプロジェクトマネージャが存在する。プロジェクトメンバーは機能部門にも所属しているが、機能型組織とは異なり機能部門のマネージャではなく、プロジェクトマネージャの指示を受ける。

【マトリックス型組織の特徴】
 プロジェクトマネージャと、機能部門マネージャで対立が生じやすい。
 プロジェクト内外のリソースの増減が行いやすい。
 プロジェクトメンバーには、プロジェクトマネージャと、機能部門マネージャの上司が2人存在する。

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

プロジェクト・ステークホルダーとは、プロジェクトに関わりがあるか、利害関係のある人のことを指す。

主要なものを「一次ステークホルダー」と呼び、プロジェクトマネージャ、プロジェクトメンバー、顧客、ユーザー、スポンサー、会社の組織、PMO、など「契約上またはプロジェクト組織上の関係者」がある。

「二次ステークホルダー」は「一次ステークホルダー」以外の家族、住民、メディア関係者などがある。

プロジェクトスポンサー

スポンサーは2種類の役割がある。

  • プロジェクトに対して、現金などの金銭的な資源を提供する
  • プロジェクトマネージャが対応できない大きな問題のエスカレーションを受ける

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

プロジェクトは、プロジェクトの開始から終了までさまざまな活動が行われる。これをプロジェクト・ライフサイクルと呼ぶ。そして、プロジェクト・ライフサイクルの中には、フェーズと呼ばれる作業の区切りがある。フェーズとフェーズの区切りのところでは、なんかしらの成果物の完成を行うことで、フェーズの終了と定義している。

図のように、要件定義工程の成果物を要件定義書とした場合は、要件定義書の完成ができたら要件定義フェーズの完了とし、次の設計フェーズの開始をする。

プロジェクト・フェーズ

フェーズは一つの活動のかたまりで、成果物の完成で区切りをもうける。なお、顧客側へ成果物の受け入れがある場合は、受け入れレビューを行い、フェーズの終結とする。IT開発のフェーズは、一般的に、要件定義、設計、製造、試験、運用などを使う。

フェーズの終結

フェーズの終了段階では、そのフェーズの成果物の作業を再評価、レビューを行い、次のフェーズに進んでよいかの判断を行う。必要に応じて、プロジェクトそのものの修正、方針変更、中止といったことの判断を行う場合もある。(プロジェクトを継続するリスクが大きくなった、プロジェクトが不要になったなど)

フェーズの関係

フェーズは、一般的には直列で1つが終わると次のフェーズに移行するが、重複関係で、後工程の作業を前倒しで実施する場合(ファースト・トラッキング)もある。また、反復関係で、フェーズ内の繰り返し(アジャイル型)もある。

プロジェクト・ライフサイクルの一般的な関係

コストや要員数は、プロジェクトの開始時は少なくプロジェクトの中盤の製造工程で最大となる。プロジェクト終了に近づくにつれて、徐々に減少していく。

リスク・不確実性は、プロジェクトの開始時が最大となり、プロジェクトの進行に伴、リスク・不確実性は減少していく。

(仕様)変更や(不具合)エラーの修正コストは、プロジェクトの開始時が最も少なく、プロジェクトが終了に近づくにつれて増加していく。

(Visited 11 times, 1 visits today)
スポンサーリンク
スポンサードリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサードリンク