プロジェクト体制図の書き方 記載項目と役割定義・よくある失敗例と作成手順を解説

課題が出たときに誰へ相談すればよいか分からない。決めてほしい件を持っていったら「それは私の範囲ではない」と言われた。ベンダーからの問い合わせが、社内の別の人にも同じ内容で届いている。プロジェクトが進むほど、こうした行き違いが増えていきます。

プロジェクト体制図は、誰がどの役割を担い、どこへ報告し、誰が判断するのかを1枚で示した図です。プロジェクト計画書の中でも重要な要素で、ここの書き方が甘いと、図はあるのに機能しないという状態になります。

本記事では、体制図の役割と組織図との違いから、記載する要素、主な役割の定義、図だけでは足りない部分の補い方、よくある失敗例、作成手順までを順番に整理します。

確認したいポイント	結論	詳細
プロジェクト体制図とは？	役割と指揮命令系統を示す図	誰がどの役割を担い、誰の指示で動き、誰が判断するのかを1枚で表したものです。
会社の組織図との違いは？	対象がプロジェクトか会社か	体制図はその案件に限った役割、組織図は恒常的な所属と上下関係を表します。
図だけで足りますか？	役割定義とセットにする	図では役割の中身まで表現できないため、責任と権限を書いた定義を別紙で添えます。
よくある失敗は？	名前だけの連絡網になる	役割や権限が読み取れない図、発注側が描かれていない図は機能しません。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• プロジェクト体制図の役割と、会社の組織図との違い
• 図に載せる5つの要素と、発注側・受注側の描き分け
• PMやPMOなど主な役割の定義と、期待する責任範囲の書き方
• 「ただの連絡網」で終わる体制図に共通する失敗パターン
• 目的の設定から合意・配布までの作成5ステップ

▼ プロジェクトの進め方や体制づくりを整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

プロジェクト体制図とは何を表す図か

まず役割を整理します。組織図と混同されがちですが、目的も対象も異なります。違いから押さえます。

役割と指揮命令系統を示す

プロジェクト体制図とは、そのプロジェクトに関わる人が、どの役割を担い、誰の指示のもとで動き、誰へ報告するのかを視覚的に表した図です。各リーダーの配下にメンバーを配置し、担当領域や職種を記載するのが基本形になります。

プロジェクト計画書に含まれる要素の1つで、立ち上げ時に作成して関係者で合意します。書き方が悪いと本来の目的を果たせず、進行が滞る要因にもなります。

名前を並べるだけの図では意味がありません。役割、責任、報告経路が読み取れて初めて、体制図として機能します。

規模が小さいプロジェクトでも、体制図を省略しないでください。人数が少ないほど兼務が増え、かえって役割が曖昧になりやすいためです。

会社の組織図との違い

組織図は、会社における恒常的な所属と上下関係を表します。対して体制図は、そのプロジェクトに限った役割と指揮命令系統を表します。

そのため、組織図では部長である人がプロジェクトではメンバーとして参加する、といったことが起こります。普段の上下関係とプロジェクトでの関係は別だという点を、図の中で明示しておく必要があります。

この違いを共有しないまま進めると、「なぜ自分より下の役職の人から指示を受けるのか」という摩擦が生じます。キックオフの場で説明しておいてください。

何のために作るのか

目的は主に2つです。1つ目が指揮命令系統の明確化。誰の指示で動き、誰が判断するのかを決めることで、意思決定が滞らなくなります。

2つ目がコミュニケーション経路の整理です。誰が誰に何を報告し、課題が出たときにどこへ上げるのか。この経路が決まっていないと、同じ話が複数のルートで伝わったり、逆にどこにも届かなかったりします。

どちらを主目的にするかで、図の描き方も変わります。階層構造を示したいのか、連絡ルートを示したいのかを先に決めてください。

社外へ提出する提案書や契約の付属資料としても使われます。その場合は、どこまでを図に載せるかを判断してください。個人名を伏せて役割だけを示す版を別に用意することもあります。

いつ作るのか

プロジェクトの立ち上げ時、計画書を作成する段階で作ります。関係者が確定していなくても、役割の枠だけ先に定義しておくことができます。

人が決まっていない箇所は「調整中」と明記してください。空欄のままにすると、誰かが担うと思い込んだまま誰も担わない状態が生まれます。

体制図に記載する要素

ここからは中身です。必要な要素は5つで、これらが揃っていれば実務で使える図になります。

役割と担当者

各枠には、役割名と担当者の氏名、そして所属を記載します。役割名だけでは誰に連絡すればよいか分かりませんし、氏名だけでは何を担う人か分かりません。

所属部署や所属会社も書いてください。社外の人が混ざる体制では、どの会社の誰なのかが分からないと連絡すらできません。

稼働の割合も書いておくと実態が伝わります。専任なのか兼務なのか、週に何日関わるのか。ここが曖昧なまま進めると、想定していた作業量をこなせないことが後から判明します。

指揮命令系統

誰の下に誰がいるのかを線で示します。この線は、指示を出す関係を表すものです。相談する相手や情報共有する相手とは区別してください。

点線を使って「協力関係」や「情報共有」を表す方法もありますが、その場合は凡例で意味を明記します。線の意味が読み手に伝わらない図は、かえって混乱を招きます。線の本数が多すぎる図も読みにくくなります。全員を線でつなごうとせず、主要な指揮命令の線だけを残し、細かな連携は役割定義の側で補うほうが見通しが良くなります。また、階層を深くしすぎるのも問題です。判断が上まで届くのに何段階も経由する構造は、意思決定を遅らせます。必要最小限の階層に抑えてください。

発注側と受注側の両方を描く

外部のベンダーに委託する場合、受注側だけの体制図では不十分です。発注側にも責任者と窓口を置き、その体制も図に含めてください。

IPAが公開するモデル契約書の検討でも、ITベンダーのプロジェクトマネジメント義務とユーザー企業の協力義務について、裁判例を踏まえた議論が行われ、双方の役割に関する記述が見直された経緯があります（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。役割は一方だけの問題ではありません。

発注側の体制が空白の体制図は、「こちらは何もしません」と宣言しているようなものです。情報提供や意思決定を担う人を明示しておいてください。

外部の関係者と境界

見落とされやすいのがこれです。データ連携先となる他社のベンダー、既存システムの保守を担当しているチーム、インフラを管理している事業者。こうした関係者も体制図に記載しておきます。

トラブルの多くは、システムやチームの境界線で起きます。誰が境界の向こう側の窓口なのかが図に書かれているだけで、問題発生時の初動が早くなります。

自社の管理範囲と、そうでない範囲は枠線で区切って示してください。責任の境界が図の上で見えることが重要です。

連絡先とエスカレーション経路

課題が発生したとき、どこへ上げるのかを図に含めておきます。現場で判断できない案件が滞留するのは、この経路が決まっていないことが原因です。

連絡先を図に書くかどうかは判断が分かれますが、少なくとも別紙として一覧を用意しておいてください。移行作業や障害対応など、時間帯を問わず連絡が必要な場面では必須になります。

▼ プロジェクトの立ち上げからご相談いただけます 体制の組み方、役割分担の設計、社内の合意形成まで含めて、実務目線でご一緒に整理します。 ＞ 相談予約はこちら

主な役割とその定義

体制図に登場する代表的な役割を整理します。同じ名称でも組織によって担う範囲が違うため、自社での定義を決めておくことが前提になります。

プロジェクトマネージャーとプロジェクトリーダー

プロジェクトマネージャーはプロジェクト全体を統括します。スコープ、スケジュール、コスト、品質、リスクの管理と、最終的な意思決定が役割です。

プロジェクトリーダーは、その下で実際の推進を担います。特定の領域やチームを受け持ち、日々の作業の調整と進捗の管理を行います。規模が小さければ両者を兼ねることもあります。

重要なのは、どちらがどの判断を下すのかを明示しておくことです。「予算に影響する変更はPM、それ以外はPL」といった線引きを役割定義に書いておきます。

規模が大きい場合は、領域ごとにリーダーを置きます。その際も、リーダー同士の調整を誰が行うのかを決めておかないと、領域をまたぐ課題が宙に浮きます。

PMO

PMOはプロジェクトの推進を支援する役割です。進捗の集計、課題の管理、会議体の運営、文書の整備などを担い、マネージャーが判断に集中できるようにします。

注意したいのは、PMOは支援であって判断する立場ではないという点です。ここを曖昧にすると、誰が決めたのか分からない状態が生まれます。

業務側の責任者とユーザー代表

発注側で最も重要な役割です。業務要件を出し、優先順位を決め、成果物を承認するのがこの立場になります。現場の代表として、実際に業務を行う担当者も参加させてください。

部署をまたぐプロジェクトでは、部署ごとに代表を立てます。利害が対立したときに調整する上位の責任者も、あわせて決めておく必要があります。

情報システム部門と社内SE

既存システムとの整合、セキュリティ方針の確認、社内の技術標準の適用を担います。開発ベンダーと業務部門の間を取り持つ役割も期待される立場です。

業務部門だけで進めると後から実現不可能だと判明することがあるため、早い段階から関与させてください。ただし、業務の要件まで情報システム部門が決めるのは無理があります。

情報システム部門が存在しない、あるいは人数が限られる企業では、この役割を外部の支援に頼る選択肢もあります。その場合も、最終的な判断は自社が担うという構造は変わりません。

開発ベンダーと外部パートナー

受注側の体制も、責任者、リーダー、各担当の役割まで確認しておきます。誰が窓口で、誰が技術的な判断をするのかが分からないと、やり取りが非効率になります。

再委託がある場合は、その範囲も把握しておいてください。実際に作業する会社が別にあるのに体制図に現れないと、問題が起きたときの経路が追えません。

図だけでは足りない部分を補う

体制図の限界を理解しておくことも重要です。図という形式だけでは、役割の中身まで定義できません。

体制図と役割定義はセットで用意する

四角の中に役割名を書いても、その役割が何をどこまで担うのかは表現できません。そのため、体制図とセットで役割の定義を文書として用意します。

役割ごとに、担当する業務、持っている権限、報告する相手、稼働の想定を書き出します。1ページの表で十分です。

この定義があると、参加を依頼する際の説明にも使えます。「週2日、この範囲を担ってほしい」と具体的に示せれば、上長の合意も取りやすくなります。

役割定義は、契約や発注の内容とも整合させておいてください。契約上は含まれていない作業が役割定義に書かれていると、後から追加費用の話になります。

責任と権限を書き分ける

見落とされやすいのが権限です。責任だけを与えて権限を与えないと、その人は動けません。「品質に責任を持つ」と書くなら、リリースを止める権限も明記してください。

判断できる金額の範囲、承認できる変更の種類、止められる工程。これらを役割定義に書いておけば、判断のたびに上へ確認する非効率がなくなります。

作業単位まで落とし込む

さらに細かく整理するなら、作業ごとに誰が実行し、誰が承認し、誰に相談し、誰に報告するのかを表にまとめる方法があります。いわゆる役割分担表です。

すべての作業について作る必要はありません。責任の所在が曖昧になりやすい作業だけを選んで整理すれば、実務では十分に機能します。

担当者が不在になったときの代理も決めておきます。長期の休暇や急な離任は必ず起こるため、誰が引き継ぐのかを事前に書いておくと現場が止まりません。

兼務は必ず明記する

1人が複数の役割を担う場合、兼務であることを図に明記してください。同じ人物が2つの箱に登場していて説明がないと、別人だと誤解されます。

あわせて、兼務の負荷も確認しておきます。特にリーダー職は担う範囲が広いため、兼務は本来あまり望ましくありません。やむを得ず兼務する場合は、稼働の見込みを役割定義に書いておいてください。

▼ 体制と役割分担の設計をご一緒に整理します 誰をどこに置くか、何を外部に任せるか、社内の合意をどう取るか。立ち上げ段階からご相談いただけます。 ＞ 相談予約はこちら

よくある失敗例

体制図が機能しない理由は、いくつかのパターンに集約されます。事前に知っておけば避けられるものばかりです。

名前だけ並んだ連絡網になっている

最も多い失敗です。氏名と所属が並んでいるだけで、役割も権限も報告経路も読み取れない図になっています。これでは体制図ではなく名簿です。

回避するには、各枠に役割名を必ず入れること。そして、その役割が何を担うのかを別紙で定義すること。この2点で大半は解決します。

異なる役割を同じ箱に入れている

1つの枠の中に、品質担当、運用担当、一般メンバー、サポートといった異なる役割の人をまとめて記載してしまう例です。それぞれの役割も指揮命令系統も分かりません。

人数が多くて枠に収まらない場合は、役割ごとに枠を分けるか、代表者だけを図に載せて残りは別紙の一覧に回してください。

発注側が描かれていない

ベンダーが提案書に載せる体制図で起きがちなのが、受注側の体制しか描かれていないというパターンです。発注側が何をするのかが見えません。

発注側としてこの図を受け取ったら、自社の体制も追記してください。情報提供や意思決定を誰が担うのかが決まっていないと、後から工数の問題が表面化します。

判断できる人が図にいない

現場の担当者だけで構成された体制図では、部署間で意見が割れたときに決着をつけられません。上位の責任者や、判断を仰ぐ先を図に含めておいてください。

経営層が関与する体制にしておくと、トラブルになってから初めて登場する事態を避けられます。定期的に報告する場も、あわせて設計しておきます。

作った後に更新されない

人の異動や増員があっても図が更新されず、実態と合わなくなるのもよくあるパターンです。古い体制図を見て、すでに離任した人に連絡してしまうという事故が起こります。

体制に変更があったら図も更新する、という作業を運用に組み込んでください。版数と更新日を記載し、共有場所を1か所に決めておくことも必要です。

体制図の作成手順

実際に作る流れを整理します。目的の確定から始めるのが、遠回りに見えて最短です。

STEP1：目的を決める

まず、何のために作るのかを明確にします。目的によって図の内容も見せ方も変わるためです。

階層構造と指揮命令系統を明確にしたいなら階層型の構造、コミュニケーション経路を整理したいなら連絡ルートと報告ラインを中心に描きます。この判断を飛ばすと、どちらも中途半端な図になります。

STEP2：関係者を洗い出す

プロジェクトに関わるすべての人と組織を列挙します。社内の部署、外部のベンダー、連携先、保守担当。直接作業しない承認者も忘れずに含めてください。

この段階で、氏名、所属、担う役割、想定の稼働を一覧にしておくと、次の作業が楽になります。

洗い出しの際は、稼働を確保できるかも同時に確認してください。名前を置いただけで実際には動けない体制は、図の上でだけ成立している状態になります。

STEP3：構造とひな形を決める

プロジェクトの規模や目的に応じた構造を選びます。階層構造、フラットな構造、機能別の構造など、特性に合った形式を使うことで情報が視覚的に伝わりやすくなります。

社内にひな形があるならそれを使ってください。案件ごとに形式が違うと、読み手が毎回構造を読み解くことになります。

STEP4：図にして役割定義を添える

収集した情報をもとに、役割、責任、報告経路を視覚的に配置します。全体の構造を一目で理解できるよう、できるだけシンプルな構成にしてください。

図が完成したら、前述の役割定義を別紙として添えます。図と定義がセットになって初めて、体制として機能します。

STEP5：合意して配布する

関係者に確認してもらい、特に役割と権限について合意を取ります。「この範囲を担う」という認識が本人と上長にあるかどうかが、実効性を左右します。

キックオフの場で全員に共有し、質問を受け付けてください。配布して終わりにせず、疑問をその場で解消しておくことが重要です。

▼ 「この体制で回るか」を第三者視点で確認します 体制の妥当性、役割の抜け、外部との分担まで含めて、実務目線でご相談いただけます。 ＞ 相談予約はこちら

体制図を運用で活かす

作った図が実際に使われる状態にするための工夫を整理します。参照されない図は、更新もされません。

変更があったら更新する

人の追加、離任、役割の変更。体制が変わったら図を更新する作業を、変更管理の手順に組み込んでください。担当者と更新のタイミングも決めておきます。

版数、更新日、変更内容を履歴として残しておくと、いつ誰が関わっていたのかを後から追えます。長期のプロジェクトでは特に役立ちます。

保管場所も決めておいてください。すぐに開けない場所にあると、連絡先を探す場面で使われません。関係者が誰でも参照できる場所に正本を置きます。

会議体とセットで設計する

体制図と、定例会議の構成を対応させておくと運用が安定します。誰がどの会議に出て、何を報告し、何を決めるのか。この対応が取れていると、情報の流れが整います。

会議に出ていない人への情報共有の方法も決めておいてください。会議体だけで完結させると、現場のメンバーに情報が届きません。

エスカレーションが実際に機能するか確かめる

経路を決めただけでは足りません。実際に課題を上げてみて、想定した時間内に判断が返ってくるかを確認してください。

判断が返らない経路は、実質的に存在しないのと同じです。プロジェクトの序盤で試しておけば、本当に困る場面の前に修正できます。

役割の考え方を組織に残す

案件ごとにゼロから体制を考えるのは非効率です。役割の定義、ひな形、判断基準を組織の標準としてまとめておけば、次のプロジェクトでも使えます。

発注側と受注側がお互いの役割と立場を認識し、協力して進めるための考え方は、IPAが公開する原理原則にも整理されています（出典：IPA「実務に活かすIT化の原理原則17ヶ条」）。社内で共通言語をつくる際の土台として使えます。

あわせて、体制を設計できる人を増やす取り組みも進めてください。業務全体の整理の仕方は業務効率化アイデア55選の記事、人材面の育て方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

プロジェクト体制図は、誰がどの役割を担い、誰の指示で動き、誰が判断するのかを示す図です。会社の組織図とは異なり、そのプロジェクトに限った役割と指揮命令系統を表します。

記載する要素は、役割と担当者、指揮命令系統、発注側と受注側の両方、外部の関係者と境界、そしてエスカレーション経路の5つです。特に発注側の体制と、連携先など境界の向こう側の窓口は忘れずに描いてください。

図だけでは役割の中身まで表現できないため、役割定義を別紙としてセットで用意します。責任と権限を書き分けること、兼務を明記することが、実効性を左右します。

そして、名前だけ並んだ連絡網にしないこと。判断できる人を図に含めること。変更があったら更新すること。この3点が守られていれば、体制図はプロジェクトを支える道具になります。

▼ プロジェクトの立ち上げと推進を、社内に定着する形で支援します 株式会社ネクストスケールでは、業務の棚卸しから要件の整理、体制づくり、システム化・AI活用の設計と定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら