プロジェクト体制図とは？役割・作り方・組織図との違いを図解で解説

プロジェクト体制図とは、そのプロジェクトに誰が・どの役割で関わり、どう報告・連携するのかを1枚にまとめた図のことです。

いわば「このプロジェクトの地図」であり、困ったときに誰へ相談すればよいかが一目でわかります。

この記事では、プロジェクト体制図の意味と役割・登場する立場（オーナー／PM／PMOなど）・種類・5ステップの作り方を図解で押さえます。

あわせて、組織図やWBS・RACIとの違い、よくある失敗、そして作って終わりにせずチームに定着させるコツまでを一気に整理します。

プロジェクト体制図とは？意味と役割をわかりやすく解説

プロジェクト体制図は「誰が・どの役割で・どうつながるか」を1枚で示し、指揮命令と報告の流れを明確にする図です。

一言でいうと「役割と連携を1枚にした図」

プロジェクト体制図は、プロジェクトに関わる人を役割ごとに配置し、線でつないだ図です。

一般的には、上から下へ「オーナー→プロジェクトマネージャー（PM）→リーダー→メンバー」という階層で描き、横に関連部門や外部パートナーを添えます。

目的は、「誰が何の責任を持ち、誰に報告・相談するのか」を全員が共有できる状態をつくること。

プロジェクトは、普段の部署の枠を越えて人が集まることが多いため、肩書きだけでは指揮命令や連絡の経路がわかりません。

その“見えない関係”を図面に書き出し、見える化するのが体制図の役目です。

組織図との違い（恒常の組織 vs プロジェクト単位）

よく混同されますが、組織図は会社の恒常的な部署・役職の構造を示すのに対し、プロジェクト体制図は特定のプロジェクトのために一時的に集まったメンバーの役割と関係を示します。

たとえば、営業部のAさんと開発部のBさんは、組織図では別々の部署にいます。

しかし同じ新製品プロジェクトに参加すれば、体制図の中では同じPMの下で連携する仲間になります。

組織図は“会社単位”、体制図は“プロジェクト単位”だと考えると違いがはっきりします。

プロジェクトが終われば体制図の役割も解散します。
組織図のように恒久的なものではなく、期間限定の設計図です。

なぜプロジェクトに体制図が必要なのか

体制図がないまま走り出すと、「この判断は誰に確認すればいいのか」「この作業は本当は誰の担当なのか」が曖昧になります。

その結果、確認待ちで手が止まる・作業が重複する・重要な関係者への連絡が抜けるといった停滞が起こります。

国際規格をもとにしたプロジェクトマネジメントの手引でも、プロジェクトには目的の達成に向けて役割と責任を割り当てた体制が必要だと整理されています。

体制図は、その役割と責任の割り当てを目に見える形にしたものだと言えます。

プロジェクト体制図に登場する7つの主要な役割

体制図は役割の集合体。
オーナー・PM・PMO・リーダー・メンバー・ステークホルダー・外部パートナーの7つを押さえれば、ほとんどの図が読めます。

ここでは、プロジェクト体制図に登場する代表的な役割を定義・よくある誤解・具体例のセットで押さえます。

すべての役割を必ず置く必要はなく、プロジェクトの規模に応じて兼任・省略して大丈夫です。

大切なのは、それぞれの役割が何に責任を持つのかを理解したうえで配置すること。

下の7つは、上から順に「決める人（オーナー）」「回す人（PM）」「支える人（PMO）」「まとめる人（リーダー）」「つくる人（メンバー）」「関わる人（ステークホルダー・外部パートナー）」という責任の違いで並べています。

プロジェクトオーナー・スポンサー（Owner / Sponsor）とは？

プロジェクトの実施を決め、予算や人などの資源を用意し、最終的な成果に責任を持つ立場の人です。

オーナー（スポンサー）は、そのプロジェクトを「なぜ・何のためにやるのか」という目的とゴールを定め、必要な予算・人員・権限を割り当てる意思決定者です。

多くの場合、経営層や事業部門の責任者が担い、体制図では最上位（または横の後ろ盾）に置かれます。

現場を日々動かすのはプロジェクトマネージャーですが、重要な方針転換や資源の追加を最終判断するのはオーナー。

オーナーが不在・曖昧なプロジェクトは、意思決定が滞りがちです。

「誰に相談すれば予算や人を動かせるのか」がはっきりしないと、現場は判断を待つ時間で消耗します。

体制図でオーナーを明記する最大の意味は、問題が起きたときに“最後にボールを持つ人”を全員が共有できることにあります。

誤解されやすい点：オーナーは「口を出す偉い人」ではありません。
日々の運営はPMに委ね、方針と資源で支えるのが本来の役割です。

プロジェクトマネージャー（PM）（Project Manager）とは？

プロジェクトの計画・進行・調整の全体に責任を持ち、現場を日々動かす司令塔です。

PMは、スケジュール・予算・品質・要員・リスクといったプロジェクトの管理全般を担う中心人物。

オーナーが定めた目的を、具体的な計画とタスクに落とし込み、メンバーやリーダーに割り当てて進捗を管理します。

体制図では中心（オーナーの下、各リーダーの上）に置かれることが多く、報告・連絡・相談の結節点になります。

PMの仕事は「自分が手を動かすこと」ではなく「チーム全体が動く状態をつくること」。

誰が何をいつまでにやるかを整理し、遅れや抜け漏れを早期に見つけて手を打ちます。

そのため、体制図と並んでタスクの一覧（誰が・何を・いつまでに）を常に最新に保てるかが、PMの成否を大きく左右します。

誤解されやすい点：PMは「いちばん技術が高い人」である必要はありません。
求められるのは調整力と、全体を俯瞰して段取りを組む力です。

PMO（プロジェクトマネジメントオフィス）（Project Management Office）とは？

PMを横から支え、複数プロジェクトの進め方や様式を標準化・支援する専門チーム（または担当）です。

PMOは、進捗報告のフォーマット統一、スケジュールやコストの取りまとめ、リスクの横断的な把握など、プロジェクト運営の“事務局・仕組みづくり”を担います。

1つの大規模プロジェクト内に置かれることもあれば、全社の複数プロジェクトを横串で支援する組織として置かれることもあります。

体制図ではPMの横（支援ライン）に配置されるのが一般的。

PMOは「管理のための管理」に陥ると煙たがられますが、本来の価値は、PMが本来やるべき意思決定に集中できるよう、報告や集計といった定型業務を巻き取り、様式をそろえる点にあります。

小規模なプロジェクトではPMがPMO機能を兼ねることも多く、必ず専任者を置く必要はありません。

誤解されやすい点：PMOは「PMの上司」ではありません。
指揮命令をする立場ではなく、支援・標準化する横のラインです。

チームリーダー・サブリーダー（Team Leader）とは？

PMの下で特定の班（サブチーム）をまとめ、担当領域の実務と進捗に責任を持つ役割です。

リーダーは、設計班・開発班・営業班といった機能や工程ごとの小チームを率いる立場。

PMが全体を見るのに対し、リーダーは担当領域のタスクを具体的に割り振り、メンバーの状況を把握してPMへ報告します。

体制図では、PMの下に複数のリーダーがぶら下がり、その下に各メンバーが連なる階層になります。

リーダーは、PMとメンバーをつなぐ“翻訳者”の役割を担います。

全体方針を現場の具体作業に落とし、現場の実情や無理を上へ返す往復ができるかどうかで、チームの回り方が変わります。

人数が少ないプロジェクトでは、PMがリーダーを兼ねてこの階層を省くこともあります。

誤解されやすい点：リーダー＝役職者、とは限りません。
プロジェクト内の役割であり、通常の職位とは別に任命されることも多くあります。

プロジェクトメンバー（Team Member）とは？

実際に手を動かして成果物をつくる、プロジェクトの実行を担う担当者です。

メンバーは、割り当てられたタスクを実行し、成果物を仕上げる中心的な担い手。

体制図では最前線（リーダーやPMの下）に置かれ、担当領域・氏名・役割を明示します。

同じ人が複数のプロジェクトを兼務することも多いため、体制図には「稼働割合」や「主担当・副担当」を添えると、負荷や属人化が見えやすくなります。

メンバー欄をただ名前の羅列にしてしまうと、「誰が何の責任者か」が曖昧になりがち。

一人ひとりに担当領域（役割）を紐づけておくと、問い合わせや引き継ぎのときに“この件はこの人”がすぐ分かり、抜け漏れや二重作業を防げます。

誤解されやすい点：メンバーは「言われたことをやるだけの人」ではありません。
担当領域では最も詳しい当事者であり、報告や改善提案の起点になります。

ステークホルダー（顧客・関連部門）（Stakeholder）とは？

プロジェクトの結果に影響を与える・影響を受ける、社内外の利害関係者のことです。

ステークホルダーには、成果物を受け取る顧客・利用部門、意思決定に関わる経営層、連携が必要な他部門、承認・監査を行う立場などが含まれます。

直接の実行部隊ではないものの、要望や承認がプロジェクトの進行を左右するため、体制図では「関連部門」「顧客窓口」として枠外や横に明示し、誰が窓口かを示します。

ステークホルダーを体制図に描く目的は、「この件は誰の合意が必要か」「どの部門に事前連絡すべきか」を可視化すること。

巻き込むべき人が抜けたまま進むと、終盤で大きな手戻りが発生します。

特に社内の関連部門は忘れられやすいため、窓口担当を1人決めて図に載せるのが有効です。

誤解されやすい点：ステークホルダー＝社外の顧客だけ、ではありません。
経理・法務・情シスなど社内の関連部門も重要なステークホルダーです。

外部パートナー（協力会社・ベンダー）（Partner / Vendor）とは？

自社の外から専門領域を担う、委託先や協力会社などの社外メンバーです。

外部パートナーは、開発の一部委託、デザイン、インフラ、コンサルティングなど、社内だけでは足りない専門性や人手を補う存在。

体制図では、自社チームと区別できるよう別枠や別色で示し、「どの会社が・何を・誰を窓口に担当するか」を明記します。

契約や指揮命令の範囲が社内メンバーとは異なるため、線の引き方に注意が必要。

外部パートナーを体制図に載せるときは、「自社の誰がその窓口（発注・調整の担当）か」をセットで描くことが重要です。

窓口が曖昧だと、複数のメンバーがバラバラに依頼して指示が食い違い、パートナー側が混乱します。

指揮命令系統を明確にすることが、外注をうまく回す前提になります。

誤解されやすい点：外部パートナーに社内と同じように直接指示を出せるとは限りません。
契約範囲と窓口を通した依頼が原則です。

プロジェクト体制図の主な種類（階層型・マトリクス型ほか）

体制図の型は、プロジェクトの規模と、メンバーが専任か兼任かで選びます。
代表的なのは階層型・マトリクス型・フラット型の3つです。

階層型（ピラミッド型）

最も一般的な型で、オーナーを頂点にPM・リーダー・メンバーが上から下へツリー状につながります。

指揮命令と報告の流れが一直線でわかりやすく、役割分担がはっきりしている中〜大規模プロジェクトにおすすめ。

一方で、階層が深くなりすぎると、現場の声が上まで届くのに時間がかかります。

リーダー層を増やしすぎず、報告の経路が長くなりすぎないように注意しましょう。

目安として、1人のリーダーが直接みるメンバーは5〜7人程度までに収めると、進捗の把握やフォローが行き届きやすくなります。

これを超えそうなときは、班を分けてサブリーダーを立て、階層を1段増やすことを検討しましょう。

ただし増やしすぎは報告の遅延を招くため、「把握できる人数」と「経路の短さ」のバランスで階層の深さを決めるのがポイントです。

マトリクス型

縦に部門、横にプロジェクトを置き、メンバーが「所属部門」と「参加プロジェクト」の両方に線でつながる型。

一人が本来の部署の仕事をしながらプロジェクトにも参加する、兼任が多い組織で使われます。

メリットは、部門の専門性を活かしつつ横断プロジェクトを動かせること。

ただし部門長とPMの二人から指示が来る（指揮命令の二重化）という弱点があるため、どちらの指示を優先するか、稼働割合をどう決めるかを事前に取り決めておく必要があります。

マトリクス型では『稼働率（例：本プロジェクトに50%）』を体制図に添えると、兼任による負荷の偏りが見えやすくなります。

フラット型（少人数・スタートアップ型）

数人規模のプロジェクトでは、階層をつくらずPMとメンバーが横並びになるフラット型が向きます。

意思決定が速く、情報共有もしやすいのが最大の利点。

一方で、人数が増えると誰が何の責任者か曖昧になりやすいため、拡大したら早めに階層型やマトリクス型へ切り替えるのが定石です。

なお、これらの型はきっちり1つを選ぶというより、実際には組み合わせて使うことがほとんど。

全体は階層型でも、特定の横断課題だけマトリクス的に人を集める、といった形は珍しくありません。

型の名前を覚えることより、自分たちのプロジェクトで指揮命令と報告がスムーズに流れる形を選ぶことが本質です。

プロジェクト体制図の作り方【5ステップ・図解】

体制図は「目的の確認→関係者の洗い出し→役割の割り当て→階層と報告線→窓口の明記」の5ステップでつくります。

作成の全体像（5ステップ）

いきなり図を描き始めず、まず関係者と役割を洗い出してから配置するのがコツ。

順番は次のとおりです。

1. 目的・ゴール・期間を確認する：何のためのプロジェクトで、いつまでに何を達成するのかを決める。ここが役割設計の前提になる。
2. 関係者を洗い出す：社内の担当・関連部門・顧客・外部パートナーまで、関わる人と組織をすべてリストにする。
3. 役割を割り当てる：オーナー・PM・PMO・リーダー・メンバーなどの役割に、洗い出した人を当てはめる（兼任・省略も検討）。
4. 階層と報告線を引く：誰が誰に報告・相談するかを線でつなぎ、指揮命令の流れを一本化する。
5. 社内外の窓口を明記する：関連部門・顧客・外部パートナーの窓口担当を図に載せ、連絡経路をはっきりさせる。

ステップの要：役割の割り当てと兼任の整理

つまずきやすいのがステップ3の役割割り当てです。

小規模なプロジェクトでは、1人が複数の役割を兼ねるのが基本で、PMがリーダーやPMOを兼任することもあります。

このとき、兼任していても「役割」としては分けて書くことが大切。

役割を同一人物にまとめてしまうと、その人が抜けたときに何が引き継がれるべきかが分からなくなります。

「Cさん（PM兼フロント班リーダー）」のように、人と役割を分けて書いておくと、増員や交代のときに調整しやすくなります。

作成に使うツール（エクセル・パワーポイント・作図ツール）

体制図は、エクセル・パワーポイント・ワードの図形機能でも十分に作れます。

まずは手元のツールで四角と線を並べ、役割・氏名・報告線を描いてみるのがおすすめ。

関係者が多い場合は、専用の作図ツールやテンプレートを使うと、階層の変更や体裁の統一がラクになります。

ツール選びで大切なのは、見た目の完成度よりも更新のしやすさ。

体制図は一度で完成せず、メンバーの交代や役割変更のたびに手を入れます。

共有ドライブ上で誰でも直せる形にしておくと、「最新版がどれか分からない」という体制図あるあるを避けられます。

凝った図にする必要はありません。
『役割・氏名・つながり』の3点が正しく伝われば、シンプルな四角と線で十分です。

プロジェクト体制図の作成のポイントとよくある失敗

良い体制図の条件は「責任の所在が空白なく埋まっている」「社内外の関係者が漏れていない」「最新に保たれている」の3つです。

良い体制図の3つの条件

特に大切なのが「役割ごとに責任者を1人に決める」こと。

「なんとなく複数人で見ている」状態は、いざ問題が起きたときに誰も動かない“責任の空白”を生みます。

主担当と副担当を分けて書くのは良いですが、最終的に誰が判断するかは1人に絞っておきます。

よくある3つの失敗

なかでも多いのが3つ目の「作りっぱなし」。

体制図は一度描いて終わりではなく、メンバーの追加・交代・役割変更のたびに更新して初めて機能します。

古いままの体制図は、実在しない担当に問い合わせが飛ぶなど、かえって混乱の原因になります。

属人化を防ぐ書き方の工夫

体制図を属人化の防止に役立てるには、各役割に主担当・副担当を書き添えるのが有効です。

主担当が休んだり離任したりしても、副担当がすぐに引き継げる状態を図で示しておけば、特定の人しか分からない業務（ブラックボックス化）を減らせます。

副担当は「常に一緒に作業する人」である必要はありません。

いざというときに引き継げるよう、進め方や状況を共有しておく相手を決めておくだけでも効果があります。

体制図に副担当まで書き込む習慣をつけると、休暇や急な離任があってもプロジェクトが止まらない体制を自然につくれます。

組織図・WBS・RACIとの違いと関係

体制図・組織図・WBS・RACIは競合しません。
人の配置・会社構造・作業の分解・責任の割り当てで役割が分かれています。

4つの違いを一覧で整理

体制図は「人と役割の配置」を示す図です。

これと混同されやすい3つを何を表すかで並べると、役割の違いがはっきりします。

→ 表は横にスクロールできます

ざっくり言えば、体制図が「役割の構造図」、WBSが「作業の構造図」、RACIが「作業と人を結ぶ責任の対応表」。

体制図で全体の役割を決め、WBSで作業を洗い出し、RACIで「どの作業を誰が担うか」を細かく割り当てる、という関係になります。

この4つは、どれか1つだけあれば足りるものではありません。

体制図だけでは具体的な作業が見えず、WBSだけでは誰がやるのかが決まりません。

役割・作業・責任をそれぞれの図で補い合うことで、「誰が・何を・どんな責任で担うのか」が初めて隙間なくつながります。

体制図とWBS・RACIの使う順番

実務では、体制図 → WBS → RACIの順で結びつけると整理しやすくなります。

まず体制図で大きな役割分担を決め、次にWBSで作業を分解し、最後にRACIで作業一つひとつに担当を割り当てます。

標準的なプロジェクトマネジメントの考え方は、日本規格協会（JSA）の『プロジェクトマネジメントの手引』などの規格でも整理されています。

体制（人と役割）と、スコープ（作業）を分けて設計する、という発想はこれらの規格に共通しています。

組織図と体制図はどう使い分けるか

よく混同されますが、組織図は会社の恒常的な部署・役職の構造を示すのに対し、プロジェクト体制図は特定のプロジェクトのために一時的に集まったメンバーの役割と関係を示します。

たとえば、営業部のAさんと開発部のBさんは、組織図では別々の部署にいます。

しかし同じ新製品プロジェクトに参加すれば、体制図の中では同じPMの下で連携する仲間になります。

組織図は“会社単位”、体制図は“プロジェクト単位”だと考えると違いがはっきりします。

プロジェクトが終われば体制図の役割も解散します。
組織図のように恒久的なものではなく、期間限定の設計図です。

プロジェクト体制図を「作って終わり」にしないチーム運用

体制図は静的な設計図です。
役割を決めたら、それを日々の「誰が・何を・いつまでに」というタスク管理につなげて初めて機能します。

体制図（役割）とタスク管理（実行）をつなぐ

体制図はあくまで役割の設計図であって、それ自体が仕事を進めてくれるわけではありません。

「誰がどの役割か」を決めたら、次はその役割の人が「どのタスクを・いつまでに」持つのかを日々更新し、チームで共有する必要があります。

ここが抜けると、立派な体制図があっても現場は動きません。

役割（体制図）と実行（タスク管理）がつながって初めて、プロジェクトは回り始めます。

体制図で決めた責任分担を、日々のタスクの持ち主として落とし込めるかどうかが分かれ目です。

たとえば体制図で「フロント班リーダー：Cさん」と決めたなら、フロント関連のタスクは基本的にCさんが持ち主になり、そこから各メンバーへ具体的な作業が割り振られていく、という流れが自然につながります。

この「役割→タスク」の橋渡しが弱いと、図の上では役割があるのに、実務では誰も拾わないタスクが生まれてしまいます。

組織づくりの出発点としての体制図

チームの生産性を上げる土台には組織図の作成をはじめとした「組織の構築」が欠かせません。

誰がどの役割と責任を持つのかを明確にし、それを運用し続けることが、チームが機能する前提です。

プロジェクト体制図は、これをプロジェクト単位で行うものだと言えます。

組織の構築とあわせて「チームのタスク管理」による見える化も生産性向上の鍵となります。

体制図で役割を描いたら、その役割を日々のタスクの見える化につなげることが、“作って終わり”から抜け出す近道になります。

よくある質問（FAQ）

プロジェクト体制図について、実務でよく出てくる疑問をまとめました。

プロジェクト体制図と組織図は何が違いますか？

組織図は会社の恒常的な部署・役職の構造を示すのに対し、プロジェクト体制図は特定のプロジェクトのために集まったメンバーの役割と関係を示します。組織図は“会社の地図”、体制図は“そのプロジェクトの地図”で、体制図はプロジェクトが終われば役目を終える期間限定のものです。

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

数人規模でも、役割と窓口を1枚にしておく価値はあります。厳密な階層は不要でも、「誰が最終判断するか」「顧客や関連部門の窓口は誰か」を明確にしておくと、確認待ちや連絡漏れを防げます。少人数ならフラット型のシンプルな図で十分です。

体制図に必ず入れるべき役割は何ですか？

最低限、意思決定するオーナー、全体を進めるプロジェクトマネージャー（PM）、実行するメンバーの3つは押さえます。規模に応じてPMO・リーダー・ステークホルダー・外部パートナーを追加します。すべてを置く必要はなく、兼任・省略しながら実態に合わせます。

体制図はどのツールで作ればよいですか？

エクセル・パワーポイント・ワードの図形機能でも十分に作れます。役割・氏名・報告線の3点が正しく伝われば、シンプルな四角と線で問題ありません。関係者が多い場合は、専用の作図ツールやテンプレートを使うと階層変更や体裁統一がラクになります。

PMとPMOはどう違いますか？

PM（プロジェクトマネージャー）はプロジェクトを進める責任者で、指揮命令の中心です。PMO（プロジェクトマネジメントオフィス）はPMを横から支援し、進捗報告の様式統一や複数プロジェクトの取りまとめを担う支援・標準化のラインで、PMの上司ではありません。

体制図はいつ更新すればよいですか？

メンバーの追加・交代、役割の変更、外部パートナーの参画など、体制に変化があったタイミングで都度更新します。作りっぱなしにすると実態とずれ、存在しない担当に問い合わせが飛ぶなど混乱の原因になります。常に最新に保つことが前提です。

まとめ：プロジェクト体制図と「見える化」で属人化を防ぐ

プロジェクト体制図とは、そのプロジェクトに誰が・どの役割で関わり、どう報告・連携するかを1枚にまとめた図のことです。

オーナー・PM・PMO・リーダー・メンバー・ステークホルダー・外部パートナーといった役割を、規模に応じて配置し、指揮命令と報告の線でつなぎます。

作るときは「目的の確認→関係者の洗い出し→役割の割り当て→階層と報告線→窓口の明記」の5ステップで進め、責任者を空白にしない・関連部門を漏らさない・最新に保つの3点を守ることが大切です。

そして体制図は、描いて終わりではありません。

役割（体制図）を、日々のタスク管理（実行）につなげて初めて、プロジェクトは動き出します。

まずはシンプルな1枚から、チームで役割と責任を共有するところから始めていきましょう。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9
• JIS Q 21500:2018 プロジェクトマネジメントの手引
• 日本規格協会（JSA）：JIS Q 21500:2018 プロジェクトマネジメントの手引
• 日本規格協会（JSA）：ISO 21502:2020 Project, programme and portfolio management
• IPA（独立行政法人 情報処理推進機構）
• IPA：DX動向・IT人材や体制に関する調査
• 公益財団法人 日本生産性本部
• 中小企業庁
• 中小企業庁『中小企業白書』
• 経済産業省
• デジタル庁
• 総務省