PMやPMOが作るべきプロジェクト体制図とは？役割や責任分担表も

PMやPMOとしてプロジェクトに参画すると、キックオフまでにプロジェクト体制図の作成を求められる場面があります。長年、ITエンジニアとして開発に携わってきた方でも、体制図を一から作る機会は多くなく、どこまで書けばよいか迷う方は少なくありません。

プロジェクト体制図は、プロジェクトに関わる人と組織、それぞれの役割、指揮命令や報告の経路を1枚に整理した資料です。あわせて用いられるのが、作業ごとの責任区分を示す責任分担表（RACIチャート）です。

ただ、氏名と部署名を並べただけの体制図では、判断や報告が滞る場面を防げません。たとえば、役割・責任・指揮命令系統をどこまで具体的に書くかが、その後の運用のしやすさを左右する点には注意が必要です。

本記事では、PMやPMOが作るべきプロジェクト体制図について解説します。

プロジェクト体制図とは？作成する目的とメリット

プロジェクト体制図とは、プロジェクトに関わる人と組織、それぞれの役割、指揮命令や報告の経路を1枚の図に整理した資料のことです。これを作成する目的は、「誰が何に責任を持ち、誰の指示で動き、誰に報告するのか」を、関係者全員で共有する点にあります。

このようなプロジェクト体制図がないまま進めてしまうと、判断を仰ぐ相手がわからず、確認が生じてしまったり、ミスが発生してしまったりと、プロジェクトに必要な作業が滞ってしまいます。とくに、発注者・元請け・協力会社が入り混じるプロジェクトでは、認識のずれが大きくなりやすい傾向があります。

上記を踏まえ、プロジェクト体制図は、プロジェクトの進行に欠かせないツールといえるでしょう。

体制図で明確にするプロジェクトの主要な役割

プロジェクト体制図の骨格を決めるのは、プロジェクトに置く役割の定義です。役割名を並べるだけでは足りず、それぞれが何に責任を持ち、どの範囲を判断できるのかまで共有できて、はじめて体制図として機能します。

近年は、社員・派遣・業務委託が同じプロジェクトに混在する体制もめずらしくありません。なかでもPM・PL・PMOは名称が似ており、現場でも混同されがちです。

もし、それぞれの役割があいまいなままプロジェクトを進めてしまうと、承認の重複や指示の食い違いが起こりかねません。

ここでは、体制図で明確にするプロジェクトの主要な役割について、以下3点を解説します。

• PM（プロジェクトマネージャー）
• PL（プロジェクトリーダー）
• PMO（プロジェクトマネジメントオフィス）

PM（プロジェクトマネージャー）

PM（プロジェクトマネージャー）は、プロジェクト全体の責任者です。品質・コスト・納期の達成に責任を負い、計画立案から進捗・予算・リスクの管理、発注者との調整までを担います。

プロジェクト体制図では発注者や上位の会議体の下に置き、各チームの上位に位置づけるのが一般的です。PMを1人に定めることで、判断を仰ぐ先が明確になります。

PL（プロジェクトリーダー）

PL（プロジェクトリーダー）は、担当するチームや工程の現場責任者です。PMが定めた計画にもとづき、メンバーへの作業指示や日々の進捗確認、技術的な判断や課題の一次対応をおこないます。

PMが「プロジェクト全体」を見るのに対し、PLは「担当領域」を見る点が異なります。小規模なプロジェクトでは、PMがPLを兼任する場合もあるでしょう。

プロジェクト体制図においては、PMの下に担当領域ごとのPLを置き、その下にメンバーを配置する形が基本となります。

PMO（プロジェクトマネジメントオフィス）

PMO（プロジェクトマネジメントオフィス）は、プロジェクトマネジメントを支援する組織・機能です。進捗や課題の情報集約、標準やテンプレートの整備、会議体の運営、報告資料の作成などを担い、PMが意思決定に集中できる状態をつくります。

PMOには支援型・コントロール型・指揮型といった形態があるとされ、どこまでの権限を持つかは組織によって異なります。

プロジェクト体制図では、PMの意思決定を支える位置に置き、指揮命令の線とは区別して描くと役割が伝わりやすくなります。

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

プロジェクト体制図は、”作ってあること”自体が目的ではありません。形骸化しているプロジェクト体制図はプロジェクトの進行を妨げる要因になってしまいます。

もし、課題を抱えたまま運用を続けてしまうと、承認の遅れや作業の重複が積み重なり、スケジュールの遅延につながるおそれがあります。

動き出してからプロジェクト体制図を作り直すことは、負担が大きいことから、作成の段階で典型的なミスや課題を把握しておくようにしましょう。

ここでは、改善の必要なプロジェクト体制図の例と問題点について、以下4点を解説します。

1. 責任や役割がはっきりしていない
2. 指揮命令系統が不明瞭である
3. 責任の所在が複数にわかれている
4. チーム内の体制が見えづらい

1. 責任や役割がはっきりしていない

体制図に氏名と所属だけを並べてしまう背景には、役割名を書けば担当範囲まで伝わるという思い込みがあります。

しかし、実際には、「開発担当」とだけ書かれていても、設計まで含むのか実装だけなのかは読み取れません。このように、範囲があいまいなまま進むと、想定していた作業が誰の担当でもないまま残り、終盤で発覚するおそれがあります。

上記を踏まえると、プロジェクト体制図には、役割名・担当範囲・氏名（所属）をセットで記載し、担当範囲は工程や機能の単位で書くようにしましょう。

2. 指揮命令系統が不明瞭である

線が引かれていなかったり、線が複雑に交差したりするプロジェクト体制図では、指示を出す側と受ける側の関係が読み取れません。

もし、指揮命令があいまいな状態が続いてしまうと、複数の相手から異なる指示が届き、優先順位の判断がぶれかねません。とくに、業務委託のメンバーへ発注者が直接指示を出す運用は、実態として労働者派遣にあたると判断されるおそれがあります。

このような点を踏まえると、指揮命令の線と、連絡・情報共有の線は分けて描きましょう。契約形態で経路が異なる場合は、凡例に区別を明記してください。

3. 責任の所在が複数にわかれている

1つの作業に、複数の役割が並列で責任を負う形になっているプロジェクト体制図があり、関係部署への配慮から、承認者を並べて書いてしまうケースが存在します。

このような体制図は、最終責任者が定まっておらず、意見が割れたときに判断が下りず、作業が止まってしまう事態を引き起こしてしまいます。加えて、全員が「誰かが対応する」と考え、対応そのものが漏れる事態も起こり得るでしょう。

このような事態を避けるためには、作業ごとの最終責任者は1人に絞りましょう。

4. チーム内の体制が見えづらい

全体図にチーム名だけを置き、内部の構成を省いてしまうプロジェクト体制図も見かけます。

ただ、詳細があいまいになってしまうため、内部が見えない状態が続き、「誰が、どの作業を持ち、どの程度の負荷を抱えているか」を把握できません。増員や交代が必要になった際も、判断材料が足りず、対応が後手に回るおそれがあります。

上記を踏まえ、全体図とは別に、チーム別の詳細図を用意しましょう。協力会社やフリーランスが入る場合は、所属と契約形態もあわせて示すと実態が伝わります。

【4ステップ】わかりやすいプロジェクト体制図の作り方

プロジェクト体制図は、図を描く前の整理で、その内容やクオリティが決まります。

もし、役割の洗い出しと指揮命令の整理を飛ばして作図から入ってしまうと、あとから修正が続き、関係者への再共有にも手間がかかってしまいかねません。

このような点を踏まえると、作成にあたっては、順序を決めて進めることが大切です。手順をわけておけば、途中で関係者の確認を挟みやすくなります。

ここでは、わかりやすいプロジェクト体制図の作り方について、以下4ステップで解説します。

1. プロジェクトに必要な役割・メンバーを洗い出す
2. 指揮命令系統を整理する
3. ツールを使って図に落とし込む
4. 関係者と合意形成し、共有する

1. プロジェクトに必要な役割・メンバーを洗い出す

最初におこなうのは、プロジェクトの目的・スコープ・工程の確認です。この作業が必要なのは、「何を、どこまで作るのかが定まらない」と、必要な役割も決まらないためです。

そのうえで、プロジェクトに必要な洗い出しの作業は、人ではなく役割から始め、各役割に誰を当てるかを検討します。社内要員だけで埋まらない役割は、協力会社やフリーランスへの依頼も視野に入れるとよいでしょう。

2. 指揮命令系統を整理する

役割が並んだ段階では、まだ誰の指示で動くのかが決まっていません。

そのため、次の手順として、指示・報告・承認の3つの経路を、役割の対応関係として整理します。

整理する際の原則は、1人のメンバーに対して指示者を1人に定めることです。指示者が複数になると、優先順位の判断が現場任せになり、負荷の偏りを招きかねません。

あわせて、契約形態ごとの違いも確認しましょう。業務委託では、発注者からメンバーへの直接指示は避け、受託側の責任者を経由する経路にするのが基本です。

3. ツールを使って図に落とし込む

整理した内容を図にする段階では、更新のしやすさと共有のしやすさを基準にツールを選びます。

この際に、作図の美しさを優先するのではなく、変更が発生した際にすぐに直せるかどうかを優先することが大切です。もし、すでに使い慣れているツールがあれば、使いやすさを重視しても問題ないでしょう。

4. 関係者と合意形成し、共有する

図が完成しても、関係者の認識が一致していなければ意味がありません。作成者の理解だけで固めてしまうと、運用の途中で「聞いていない」という食い違いが生じます。

このような点を踏まえて、キックオフの前に、発注者・協力会社・チームリーダーへ内容を確認し、役割と指示経路の合意を取りましょう。この場で出た指摘は、そのまま体制図の精度向上につながります。

共有後は、保管場所・版数・更新日を明示し、最新版がどれかわかる状態を保ちましょう。

プロジェクト体制図を作成する際のポイントと注意点

プロジェクト体制図を効果的に作成するためには、細かなポイントを理解し、一つひとつ実行していく姿勢が欠かせません。

たとえば、作成したことに満足しているだけで、メンテナンスが一切なされていない場合には、役割や人員の変更が生じた際にプロジェクトの進行そのものに支障を来してしまいます。

上記のような点を踏まえ、本記事で解説するポイント・注意点をおさえ、実行できることから着実に進めていきましょう。

ここでは、プロジェクト体制図を作成する際のポイントと注意点について、以下の4点を解説します。

1. 一目で理解できる情報量に抑える
2. 大規模プロジェクトでは全体図とチーム別でわける
3. コミュニケーションパスを明記する
4. 適切なタイミングで見直しをおこなう

1. 一目で理解できる情報量に抑える

プロジェクト体制図に情報を足したくなってしまうのは、抜け・漏れをおそれてしまうためです。

ただ、担当業務やスキル、稼働率まで書き込むと、肝心の役割と指示経路が埋もれてしまいます。

このような点を踏まえると、1枚に載せる項目は、役割名・担当範囲・氏名（所属）・指示経路の4点程度に絞りましょう。詳細は、責任分担表やメンバー一覧に切り分けると読みやすさを保てます。

2. 大規模プロジェクトでは全体図とチーム別でわける

関係者が数十名を超えるプロジェクトを1枚に収めようとすると、文字は小さくなり、線も複雑になります。無理にまとめた図は、どの立場から見ても読みづらくなりがちです。

結果、全体像が伝わらなくなってしまい、ほかチームとの接点や上位の承認経路がわからず、調整先を探す時間が増えかねません。

上記のような事態を避けるためにも、全体図とチーム別の詳細図に階層をわけましょう。全体図と詳細図で内容をわけて補完し合えば、目的に応じて使い分けられます。

3. コミュニケーションパスを明記する

指揮命令の線だけでは、日々の連絡や課題のエスカレーションがどの経路を通るのかがわかりません。

経路が不明なままな状態では、課題の報告が遅れ、対応の初動が鈍るおそれがあります。

このような課題を踏まえると、プロジェクト体制図には、窓口・報告頻度・エスカレーション先を書き添えましょう。「誰に、何を、どの頻度で伝えるか」が明記されていれば、参画したばかりのメンバーも迷わず動けます。

4. 適切なタイミングで見直しをおこなう

プロジェクト体制図は、プロジェクトの進行とともに実態から乖離してしまいます。要員の交代、スコープの変更、フェーズの移行が重なるほど、当初の図とのずれは広がるためです。

このような古い体制図で運用を続けてしまうと、すでに離任した担当者に確認が飛び、対応が滞るおそれがあります。

上記を踏まえ、見直しのタイミングをあらかじめ決めておきましょう。フェーズ移行時、要員の増減時、体制に関わる課題が発生したときを基準にすると、更新の判断がぶれません。

「責任分担表（RACIチャート）」とは？4つの役割

責任分担表（RACIチャート）とは、作業ごとに関係者の責任区分を示した表のことです。責任分担マトリックス（RAM）の代表例として知られています。

プロジェクト体制図において、役割と指揮命令系統を示しても、個々の作業を誰が実行し、誰が承認し、誰に相談するかまでは表現できません。作業の粒度が細かくなるほど、体制図だけでは補いきれない場面が増えます。

このような課題から、責任分担表を併用すると、この空白を埋められ、プロジェクトの進行をよりスムーズにおこなうことが可能です。

行に作業、列に役割を並べ、交点にR・A・C・Iを記入するのが基本の形です。記入例は次のとおりです。

ここでは、上記表に使われるRACIチャートの4つの役割について、解説します。

1. 実行責任
2. 説明責任
3. 協業先
4. 報告先

1. 実行責任

実行責任（Responsible）は、その作業を実際に進める役割です。設計書の作成、コードの実装、テストの実施といった作業の遂行そのものを担います。

1つの作業に複数人を割り当てられますが、その場合は担当範囲を分けておきましょう。範囲が重なると、作業の重複や抜けが生じやすくなります。

2. 説明責任

説明責任（Accountable）は、その作業の成果に最終的な責任を負い、完了を承認する役割です。作業を実行するとは限らず、実行責任者に委ねたうえで、結果に責任を持ちます。

1つの作業につき、説明責任者は1人に限定するのが原則です。複数人に置くと最終判断が分散し、承認が滞りかねません。

3. 協業先

協業先（Consulted）は、作業を進めるにあたって意見や助言を求める相手です。専門知識を持つ担当者や、成果物に影響を受ける部署が該当します。

やり取りは双方向で、作業の完了前に意見を聞く点が特徴です。設定しすぎると確認の手間が増え、意思決定が遅くなるため、本当に意見が必要な相手に絞りましょう。

4. 報告先

報告先（Informed）は、作業の進捗や結果を知らせる相手です。判断や助言を求める立場ではなく、情報を受け取る側にあたります。

この報告先には、発注者の管理職や、関連する他チームのリーダーなどが該当します。あらかじめ、「誰に、何を伝えるか」を決めておくと、報告漏れや過剰な連絡を防げるでしょう。

プロジェクト体制図や責任分担表で円滑な管理を！

本記事では、PMやPMOが作るべきプロジェクト体制図について、役割や責任分担表も交えて解説しました。

プロジェクト体制図は、関係者の役割・責任・指揮命令系統を1枚に整理し、判断と報告の経路を共有するためのツールです。プロジェクトの進行を支える大切なものであるため、長期的な視点を踏まえて丁寧に作成する必要があります。

一方で、作業単位の責任までは、体制図だけでは表現しきれません。本記事で解説した「責任分担表（RACIチャート）」を併用し、実行責任・説明責任・協業先・報告先を作業ごとに割り当てることによって、体制図では表現できない内容も示せます。

もし、これからPMやPMOとしてプロジェクト体制図や責任分担表の作成をする際には、本記事で解説した役割やポイントをしっかりとおさえるようにしてください。

よくある質問

プロジェクト体制図と組織図の違いとは？

プロジェクト体制図と組織図の違いは、対象と目的にあります。体制図はプロジェクト単位の役割と指揮命令系統を示し、組織図は会社の恒常的な組織構造を示します。

PMとPMOの役割の違いとは？

PMとPMOの違いは、意思決定の権限にあります。PMは成果に責任を負って判断を下し、PMOは情報の集約や標準化を通じてPMの判断を支えます。

小規模なプロジェクトでも体制図は必要？

小規模なプロジェクトでも、体制図は作成しておくと役立ちます。人数が少なくても、役割と報告先を1枚で示すことで、指示の重複や確認漏れを防ぎやすくなります。

責任分担表の「説明責任」は複数人に設定してもよい？

責任分担表の説明責任は、1つの作業につき1人に絞るのが基本です。複数人に置くと最終判断が分散し、承認が滞るおそれがあります。