PMOの作るプロジェクト体制図の悪い例と改善例｜PMの役割や責任分担表も解説

「PMOやPMのそれぞれの役割って？」
「PMやPMOのメンバーが作る「体制図」とは？」
「プロジェクト体制図の改善例とポイントって？」

このように、PMOの役割やPMOの作るプロジェクト体制図について詳しく知りたいと考えている人も多いのではないでしょうか。

本記事では、PMOとPMそれぞれの役割やプロジェクト体制図について紹介しています。本記事を読むことで、PMOの作るプロジェクト体制図がどのようなものなのか把握できるでしょう。

また、プロジェクト体制図の改善例とポイントについても解説するため、プロジェクト体制図がうまく作成できないと考えている人も参考になります。

PMOの作るプロジェクト体制図について知りたい人は、ぜひ参考にしてみてはいかがでしょうか。

PMOとPMのそれぞれ役割

PMOとは「プロジェクトマネジメントオフィス」、PMとは「プロジェクトマネージャー」を略した言葉です。両者は同じようにプロジェクトマネジメントに携わる仕事ですが、その役割は異なっています。

PMはプロジェクトの責任者としてプロジェクトマネジメントを指揮する役職となりますが、PMOはPMの下についてプロジェクトマネジメントの支援を行うことが仕事です。ここではPMOとPMのそれぞれの役割について解説していきます。

PMの役割

PMはプロジェクトの総責任者としてプロジェクトのマネジメントを行う役職です。クライアントが抱えている課題をどのように解決するのかというプロジェクトの目的を設定し、プロジェクトを完遂するために必要なプロジェクトメンバーの任命を行いチームを結成します。

また、PMにとってもっとも重要な責務はプロジェクトを完遂させることであるため、PMはプロジェクトメンバーや予算など、プロジェクトに関わる全ての管理責任を担います。

PLとの違いは？

PLは「プロジェクトリーダー」を略した言葉で、プロジェクトを成功へ導くという役割を持っています。PLは現場のリーダーとしてプロジェクトを実行し、プロジェクトメンバーの管理を行います。

一方、PMはプロジェクトにおける全ての責任を負う役割があり、プロジェクトメンバーだけでなくすべてのステークホルダーの管理を行うなどの違いがあります。そのため、PLはPMの下に配置されるケースが多いです。

PMOの役割

PMOはプロジェクトマネジメントを支援することが主な役割となっています。ひと口にPMOと言っても、その業務は役割ごとに「PMOアドミニストレーター」「PMOエキスパート」「PMOマネージャー」の3つの種類にわかれています。

たとえば、PMOアドミニストレーターは主にプロジェクトに関するプロセスを円滑化するための役割を担うPMOで、事務的な業務が仕事です。

PMOの設置される位置による役割や目的の違い

PMOを設置する目的はプロジェクトマネジメントの支援ですが、どのような位置にPMOを設置するのかによっても得られる効果は変わってきます。

ここではPMOの設置される位置による役割や目的の違いについて解説していきます。

全社タイプ

全社タイプとは、複数のプロジェクトを横断するようにPMOを設置するタイプです。この場合、PMOは自社のIT部門の責任者を補佐するように配置されることになります。

全社タイプのPMOは、複数のプロジェクトの進捗状態を確認してコントロールしたり、プロジェクトが自社の管理基準に沿って運営されているかどうかを確認したりする役目を担います。

プロジェクト事務局タイプ

プロジェクト事務タイプとは、それぞれ個別のプロジェクトを支援するためにPMOを設置するタイプです。この場合、PMOはPMの直下に配置されることになります。

大規模プロジェクトの場合、多くのステークホルダーとの調整や進捗管理といった事務作業が発生するため、プロジェクト事務局タイプのPMOを設置することが多いでしょう。プロジェクトの規模が大きいとPMだけでは全体の管理を行うことは困難であるため、PMOの導入が有効です。

ハイブリッドタイプ

ハイブリッドタイプとは、全社タイプとプロジェクト事務局タイプ両方の位置にPMOを設置するタイプです。つまり、IT部門の管理者の下と、各プロジェクトのPMの下にPMOが設置されることになります。

前述のとおり、大規模なプロジェクトの場合は複数のプロジェクトの品質を担保するためにプロジェクト事務局タイプでPMOを設置します。このような場合、よりプロジェクト管理を強化するためにハイブリッドタイプを選択するケースがあるのです。

PMやPMOのメンバーが作る「体制図」とは？

PMやPMOのメンバーが作るプロジェクト体制図とは、プロジェクトのステークホルダーの役割をわかりやすく階層構造で表現した図のことです。ステークホルダーの役割や責任などを明確にすることで、合意形成を行うために用いられます。

プロジェクト体制図はプロジェクトの計画を行う段階でPMなどが作成し、プロジェクトの責任者が承認を行います。プロジェクトの運営がうまくいかない場合、プロジェクト体制図に問題があるケースも多いです。

改善の必要なプロジェクト体制図の例と問題点

前述のとおり、プロジェクト体制図に問題があるとプロジェクトの運営自体がうまくいかない可能性があります。そのため、プロジェクトがうまくいっていない場合は、体制図に改善の必要があるかどうかきちんと判断できるようになっておくことが大切です。

ここでは改善の必要なプロジェクト体制図の例と問題点について解説していくため、参考にしてみてはいかがでしょうか。

責任や役割がはっきりしない名前のチームがある

図では「調整チーム」というチームが存在していますが、調整チームでは責任や役割がはっきりしていません。調整チームがプロジェクトの中でどのような役割を果たすのかも不明確になっています。

このように責任や役割のはっきりしないチームがあると、他のチームが調整チームに求める役割も異なるため、調整チームに対する評価自体が低くなる可能性があります。

このようなチームがプロジェクトに混ざっていると、プロジェクトにも悪影響を及ぼす可能性があるでしょう。

左右のボックス同士を繋ぐ線があり指揮命令系統が不明確

通常であれば、ボックスの上下に線が伸びているため、指揮命令系統がはっきりしています。しかし図の「調整チーム」のように左右のボックス同士を結び付ける線がある場合、どちらの意思決定が優先されるべきなのかがわからなくなり、指揮命令系統も不明瞭になります。

このようにボックス同士をつなぐ線の意味を成していない場合、指揮命令系統がわからなくなり、プロジェクトがうまくいかなくなるケースがあるでしょう。

プロジェクトの責任が複数の系統に分かれている

プロジェクトにおける責任者が複数の系統に分かれている場合、プロジェクトがうまくいかないケースがあります。

たとえば最終的な意思決定を行う人材がプロジェクト内に2人いる場合、一度決定した内容が変わるということが頻繁に発生するため、プロジェクトの進行にも支障をきたす可能性があります。

最終的な意思決定者は、プロジェクト全体を俯瞰する視点を持った一人に集約する必要があるでしょう。

各チームのメンバーがまとめて記載されていてチーム内の体制が不明瞭

図を見ると、各チームのメンバーがボックス内にまとめて記載されているため、チーム内での体制が不明な状態になっています。このようにチーム内での指揮系統や役割分担が明確化されていない場合、プロジェクト開始後に混乱が発生する可能性が高いです。

プロジェクト体制図を作成する場合は、メンバーの分担を明確にしておきましょう。

プロジェクト体制図の改善例とポイント

さきほどの問題のあるプロジェクト体制図を改善した体制図がこちらです。ここでは改善後の体制図をもとに、プロジェクト体制図の改善例とポイントについて解説していきます。

指揮命令の系統が複数に分かれないようにする

プロジェクト体制図を作成する場合は、指揮命令系統を一本化することが大切です。指揮命令系統が複数にわかれてしまうことを防ぐためには、同一方向から同一ボックスにつながる線は1本であるように気をつけるようにしましょう。

また、線が重なっているとどこへ向かう線なのかわかりにくくなるため、矢印や線は重ならないように記載しましょう。

それぞれの役割が明確になるようにする

プロジェクトでのチームの役割が明らかになるように、曖昧な書き方は避けるようにしましょう。プロジェクト体制図を見ただけで、それぞれの役割がわかるような名称を意識することが大切です。

シンプルにするときでも必要な記載は省略しないようにする

プロジェクト体制図をシンプルにしたい場合でも、必要な記載は省略せずに分けて記載する方がよいでしょう。たとえば、並列関係にある役職やチームがある場合は役割ごとに分けて記載するなど、異なる役割や異なるチームを安易にまとめて記載しないようにしましょう。

よりよいプロジェクト管理に役立つ責任分担表「RACIチャート」とは

RACIチャートとは、プロジェクトメンバーの役割と責任を「RACI」の順番に適用するものです。RACIチャートを作成することで、それぞれの責任範囲を明確化することが可能になります。

ここでは最後に、よりよいプロジェクト管理に役立つ責任分担表「RACIチャート」について紹介します。一例として下記のようなRACI図による責任分担表について解説していくため、参考にしてみてはいかがでしょうか。

実行責任(Responsible)

「実行責任者（Responsible）」とは、直接タスクを実行し、責任を担う役割です。実行責任者をタスク1つに対して1人にすることで、業務に対する質問や報告先が誰なのかわかるようにしておくことができます。また、実行責任者は複数人存在してもよいとされています。

ただ、実行責任者が複数人存在する場合、報告先が誰になるのかわからなくなるため、現場が混乱する可能性があるでしょう。そのため、他にも関係者を追加する場合は、RACIの中で1名以上設定しても問題ない他の役割に割り当てることをおすすめします。

説明責任(Accountable)

「説明責任者（Accountable）」とは、タスクの完了を統括する責任を担う役割です。ただし、実際にタスクを実行するメンバーと同一とは限りません。

説明責任者はプロジェクトマネージャーを務めている場合と、管理職のリーダーや役員である場合の2つのパターンがあります。前者の場合、仕事を問題なく遂行させることが説明責任者の責任だと言えるでしょう。

責任の所在が曖昧になるため、説明責任者は原則として1つのタスクに1名のみに限定されます。また、実行責任者と兼務する場合もあります。

協業先(Consulted)

「協業先（Consulted）」とは、実行責任者の相談先になり、アドバイスをする役割のことです。タスクを進める際に相談者となり、双方向のやり取りを行う関係者です。

協業先は1名だけでなく、複数名の関係者が置かれるケースもあります。また、各タスクやプロジェクトのマイルストーン、成果物ごとに複数名が置かれるケースもあります。

報告先( Informed)

「報告先（Informed）」とは、タスクの進捗状況や完了などの報告を受ける役割です。人もしくはグループであり、成果物に関する他の側面に関わることはありません。

タスクを進める際には一方向的なやりとりを行うことになります。

体制図の適切な形や責任分担表について知ってよりよいプロジェクト管理をしよう

PMOが作成するプロジェクト体制図の出来によって、プロジェクトの運営がうまくいくかどうかも変わってきます。

ぜひ本記事で紹介したPMOとPMの役割やプロジェクト体制図の改善例とポイントなどを参考に、プロジェクトをスムーズに運営するためにもプロジェクト体制図について理解を深めてみてはいかがでしょうか。

＼簡単60秒／無料登録して案件を紹介してもらう24時間以内にご連絡いたします。※土日祝日を除く