プロジェクト体制図の書き方【2026年版】登場する役割・線の引き方・よくある欠陥6つ

「プロジェクト計画書に体制図のページがあるが、箱に部署名を入れる以上のことが分からない」——プロジェクトの立ち上げを任された方から、こうした相談をよく受けます。誰を書けばよいのか、線は何を意味するのか、決裁者や兼任はどう扱うのか。テンプレートを探しても箱と線の形しか手に入らず、中身は自分で決めるしかありません。

結論から言うと、プロジェクト体制図が定義するのは3つです。参加者の役割と責任、指揮命令系統、報告経路。この3つを1枚で決めて関係者と合意し、記録として残すための成果物であって、計画書を埋めるための飾りではありません。だからこそ、登場人物は発注者側と受注者側を枠で分け、線は実線(指揮命令)と点線(報告・連絡)で意味を分けて描く必要があります。

書き方が決まれば、体制図は「止まったときに誰へ上げるか」を着手前に決めておく道具になります。逆に、決裁者の欄が空白のまま、兼任が注記なしに2つの箱に入ったまま進めると、決めていないことが図の中に隠れたまま残り、判断が必要になった瞬間に表面化する。体制図の欠陥は、たいてい図の問題ではなく、決めていないことの問題です。

本記事では、体制図の3つの目的と作成タイミング、登場する役割(発注者側5つ・受注者側5つ)、線の引き方と社外との境界、よくある欠陥6つと直し方・更新のタイミング、オフショアや社外チームを含む場合の書き方、よくある質問の順に解説します。発注者側と受注者側を分けた作例を1枚、悪い体制図を直したビフォー・アフターを1枚、図解で示します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。見せていただく体制図でつまずきが多いのは、決裁者の書き方と、社外メンバーへの線の引き方の2つです。この記事を読み終えるころには、自社のプロジェクトで1枚を作りきり、他社から提示された体制図の欠陥も指摘できるようになるはずです。

プロジェクト体制図とは——3つの目的と、いつ・誰が作るのか

プロジェクト体制図は、そのプロジェクトに関わる人と組織を箱で並べ、箱と箱を線でつないだ1枚の図です。プロジェクト計画書の一部として作られ、キックオフで説明されるのが一般的です。ただし「計画書のフォーマットに体制図のページがあるから、とりあえず埋めた」という作り方をすると、本来の役目を果たしません。まずは、この1枚が何を決めるための図なのかを押さえてください。

体制図が定義する3つのこと——役割と責任、指揮命令系統、報告経路

体制図の目的は3つに整理できます。プロジェクトに参加するメンバーとそれぞれの役割を定義すること、メンバー間の指揮命令系統を定義すること、そして報告経路を定義することです。定義した内容を関係者間で共有し、認識を統一するところまでが体制図の役目になります。本記事ではこの3つの観点で体制図を捉えます。当社の現場感覚でも、この3つで見ると実務で使いやすくなります。

3つに共通しているのは、いずれも「着手前に決めて、関係者で合意する」ための項目だという点です。体制図は組織を描く絵ではなく、止まったときに誰へ上げるかを先に決めておく合意書だと考えてください。この視点を持つと、後述する欠陥の直し方がすべて同じ理屈で説明できます。

組織図・役割分担表(RACI)との違い——1枚に詰め込まず、表に逃がす

似た図として、組織図と役割分担表があります。3つの使い分けは次のとおりです。

体制図でよくあるのが、役割の説明を箱の中に詰め込んでしまい、文字が小さくなって誰も読まなくなるパターンです。情報を詰め込むほど図は読めなくなるので、役割の細かい割り当てはRACI図などの役割分担表に逃がしてください。本記事では、体制図と役割分担表はセットで用いるものとして扱います。

判断の目安はシンプルです。箱の中は「役割名+氏名(+所属)」までにとどめ、2行以上の説明が必要になったら役割分担表に逃がす。 1枚で全部を語ろうとしないことが、読まれる体制図の条件です。

いつ・誰が作るか——目的とメンバーが決まった直後、プロジェクト計画書の一部として

作成のタイミングは、プロジェクトの目的とゴールが定義され、参加するメンバーが選定された直後です。この時点なら指揮命令系統と役割を正確に描けます。逆に、メンバーが決まる前に作ると部署名だけの箱が並び、決まった後に作り直すことになります。

作るのはPMまたはPL、承認するのはプロジェクトオーナーです。発注者側にPMがいない場合は、受注者側のPMが原案を作って発注者側が確認する形でも構いませんが、その場合でも発注者側の箱の中身は発注者が決めるようにしてください。自社の決裁者と業務責任者を外部に決めてもらうのは、本末転倒です。

次章では、この1枚に登場する役割を、発注者側と受注者側に分けて具体的に見ていきます。

体制図に登場する役割——発注者側5つ、受注者側5つを枠で分けて書く

体制図で最初につまずくのが「誰を入れるか」です。一般的な解説では、プロジェクトオーナー、PM、PL、チームメンバー、ステークホルダー、顧客、サポートスタッフといった並びが示されます。ただ、社外に開発を委託するプロジェクトでこの並びをそのまま使うと、発注者側と受注者側が混ざって境界が読めなくなります。おすすめは、枠を2つ用意して、発注者側と受注者側を分けてから中身を埋める方法です。役割は肩書きではなく「何を決めるか」で定義してください。

発注者側の5つの役割(表)——プロジェクトオーナー(決裁者)、業務責任者、情報システム、PMO、実務担当

この表で意識してほしいのは「決めないこと」の列です。役割を決定権で定義すると、同じ「責任者」という肩書きが2人並んでも混乱しません。逆に肩書きだけを並べると、プロジェクトマネージャーと進捗管理責任者が同列に記載されていて、どちらにどの権限があるのか読めない、という状態になります。

なお、発注者側の5つのうちどれを社内に残し、どこまで外部に任せるかは、体制図を描く前の判断です。この線引きは「システム開発の外注 丸投げ」の記事で詳しく整理しています。ここでは、社内に残すと決めた判断は、必ず発注者側の枠の中に箱として現れるという点だけ押さえてください。箱がないのに社内で決めているつもりなら、それは決まっていないのと同じです。

受注者側の5つの役割(表)——PM、BrSE、テックリード、開発メンバー、QA

受注者側で省略されがちなのがQAです。品質・運用と基盤のように異なる役割の担当者を同じ箱にまとめてしまうと、それぞれの役割も指示命令系統も読めなくなります。テスト担当を開発チームの箱に含めてしまうと、品質の責任が実装者と同じ人に戻り、リリース前の確認が形だけになります。

品質に関わる役割は、体制図の中で誰がどの確認をするかまで見えている状態が理想です。当社の場合は、日本人PMによる設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前のダブルチェックという3点を体制の中に組み込んでいるため、体制図でもレビューの担い手が箱として現れます。

発注者側と受注者側を分けた体制図の作例——4階層で描く

役割が決まったら、4つの階層に並べます。発注者側を左、受注者側を右に置き、それぞれを枠で囲み、枠と枠をつなぐ線は推進層どうしの1本だけにします。

この形にすると、3つのことが一目で分かります。1つ目は決裁の上げ先、2つ目は社外との接点がどこか、3つ目はどの箱が誰の指示で動くかです。逆に、この3つが読み取れない体制図は、階層の設計か線の引き方のどちらかに問題があると考えてください。具体的な作例は次の図のとおりです。

線の引き方——指揮命令の実線と、報告・連絡の点線を分ける

箱を並べ終えたら線を引きます。ここが体制図の書き方で最も差が出るところです。多くの体制図は、すべての関係をひとしなみに1本の線で結んでしまっており、その線が「指示を出す」のか「報告する」のか「相談してよい」のかが読めません。線の種類を分けるだけで、体制図は一気に使える1枚になります。

実線=指揮命令。1つの箱に入る実線は1本に絞る

実線は指揮命令を表します。原則は単純で、1つの箱に向かって入ってくる実線は1本だけにします。よくある悪い例が、担当SEに対して別のSEとチームリーダーの2方向から線が伸びていて、どちらの指示に従えばよいのかが分からない状態です。1つの箱に入ってくる線は複数書かずに原則1本にすること、線どうしが重ならないように配置すること。この2つを作図の原則としてください。

現場で起きるのは、単なる混乱ではありません。2人から違う優先順位が届けば、担当者は片方を後回しにします。後回しにされた側は「依頼したのに動いていない」と受け取り、翌週にもう一度同じ依頼を出す。指示の重複は、そのまま手戻りと不信になります。線を1本に絞るのは図の作法ではなく、手戻りを減らすための設計です。

線を1本に保つには、箱の並べ方も重要です。指揮命令の線は上から下へ一方向に描き、横方向や斜めの実線は作らない。同じ階層の箱どうしを実線でつながないこと、と覚えておくと迷いません。

点線=報告・連絡・相談。多くの線が集まる箱は要注意

指揮命令ではないつながり——進捗の報告、情報の共有、必要に応じた相談——は点線で描きます。点線は複数あって構いませんが、1つの箱に集まりすぎていないかは必ず確認してください。複数の担当者から一人の担当者に向けて多くの線が集まっている場合は注意が必要です。報告経路が複雑になるほど情報は正確に伝わらなくなり、重要な決定や対応が遅れます。

点線が集中する箱は、たいてい兼任か、引き受けすぎている人です。体制図の段階でそこが見えていれば、着手前に分担を見直せます。線を引いたあとに一度引いて眺め、いちばん線が集まっている箱の名前を確認する。この作業だけで、3か月後に起きる詰まりの多くは予測できます。

会社の境界を枠で囲む——発注者から受注者の個々のメンバーへ実線を引かない(実務上の注意)

社外に開発を委託する場合、発注者側と受注者側をそれぞれ枠で囲み、枠と枠をつなぐ線は推進層どうしの1本にします。そして実務上の注意として、発注者から受注者の個々のメンバーへ、指揮命令の実線を引かないでください。発注者が伝えたいことは受注者側のPMへ渡し、PMが自社のメンバーに指示を出す。この形が、業務委託(準委任・請負)で開発を依頼するときの基本形です。

理由は2つあります。実務上の理由は前節のとおりで、指示の出し手が増えるほど手戻りが増えるからです。もう1つは、労働者派遣事業と請負により行われる事業との区分に関する基準(いわゆる37号告示)と厚生労働省の疑義応答集で、業務の遂行に関する指示その他の管理を自ら行っているかが区分の判断要素とされているためです。体制図は運用の宣言として読まれる資料なので、図の上で発注者から現地メンバーへ実線が伸びていると、実態の説明を求められたときに不利に働きます。なお本記事は作図の実務を扱うもので、法的な助言ではありません。個別の契約や運用が適法かどうかの判断は、弁護士や社会保険労務士にご確認ください。契約と指揮命令の論点そのものは「業務委託契約で行ってはいけない行為」の記事にまとめています。

私が相談で見せていただいた体制図の中に、発注者の担当者からベトナム側の各エンジニアへ直接矢印が引かれているものがありました。速く伝わるはずが、受注者側のPMが把握していない作業が走り、優先順位が毎週入れ替わる。窓口を1点に絞ると伝達が遅くなると思われがちですが、実際には戻りが減って早く終わります。

線と箱の表記ルール(表)——実線・点線・二重枠・注記の使い分け

ここまでで、体制図の部品と線の意味は揃いました。では、あなたの手元にある体制図は、この原則をいくつ満たしているでしょうか。次章では、実際によく見る欠陥を6つ挙げ、それぞれの直し方を示します。

よくある欠陥6つと直し方、そして更新のタイミング

ここからは、実際の体制図でよく見る欠陥を6つ挙げます。共通しているのは、どれも作図の巧拙ではなく、決めていないことを図の中に隠してしまった状態だという点です。裏を返せば、直し方はいずれも「決める」の一手に集約されます。

欠陥6つと直し方(表)

欠陥1〜3は発注者側で起きやすく、欠陥4〜5は受注者側の提案書で起きやすい傾向があります。欠陥6はどちらにも起きます。手元の1枚を、この6つで点検してみてください。

決裁者の空白と隠れた兼任——私が相談でいちばん多く見る2つ

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、見せていただく体制図で最も多いつまずきは、欠陥1と欠陥2です。

欠陥1の典型は、最上段に「経営会議」とだけ書かれた体制図です。一見きちんとして見えますが、開発の途中で追加費用の判断が必要になったとき、次の経営会議まで待つことになります。月1回の開催なら、その時点で最大1か月、稟議の準備を含めれば2週間から1か月が止まる。これは判断が遅いのではなく、判断の入口を決めていなかったのが原因です。直し方は、会議体の手前に「一次判断者」を1人置き、一定金額までは即断、それを超えるものだけ会議体へ上げる、というルートを図に描くことです。

欠陥2は、氏名が2つの箱に入っているのに注記がないケースです。兼任そのものは現実によくあることなので、否定する必要はありません。問題は、注記がないと読む側が「2人いる」と誤解し、稼働が二重に見積もられる点にあります。兼務するのであれば、兼務であることを図の上に明記してください。とくにリーダーは担う役割が多いため、当社では兼務を前提にした体制はお勧めしていません。注記を入れた瞬間に「この人に寄りすぎている」と気づけるのが、体制図の効用です。

更新のタイミング(表)——増員・交代、フェーズ移行、決裁者の異動、契約変更

体制図は作って終わりではありません。更新のきっかけをあらかじめ決めておくと、形骸化を防げます。

更新した体制図は、必ず版数と更新日を付けて配り直してください。差し替えを配らないと、現場は最初に配られた1枚を見続けます。

公開前の点検リスト8項目

• 最上段に決裁者が氏名で書かれているか。会議体名だけになっていないか
• 同じ氏名が複数の箱にある場合、兼任の注記があるか
• 発注者側と受注者側が枠で分かれ、契約形態が注記されているか
• 1つの箱に入る実線が1本になっているか。線が重なっていないか
• 「開発チーム」の中に役割の異なる人がまとめられていないか。QAは独立しているか
• 進捗・課題・リスクの報告先と頻度が、点線と注記で読み取れるか
• 箱の中の説明が2行を超えていないか。超える分は役割分担表に逃がしたか
• 欄外に版数・更新日・作成者・承認者があるか

8項目すべてに「はい」と答えられる体制図は、そう多くありません。1つでも「いいえ」があるなら、それは図の不備ではなく、まだ決まっていないことが1つ残っているという合図です。

オフショア・社外チームを含む体制図の書き方と、当社の体制

海外の開発チームが加わると、体制図には会社の境界に加えて国の境界が重なります。枠が二重になるぶん、書き方の原則は変わりませんが、追加で書くべき情報が増えます。当社がホーチミンで受けてきた相談でも、発注者・日本側の窓口・海外拠点が1枚に載る体制図は、もはや特殊な形ではありません。

海外チームを含む場合に追加で書く4項目——窓口、拠点と時差、稼働日、言語

さらに、海外チームを含む体制図では前章の原則がいっそう効きます。発注者から現地の個々のエンジニアへ実線を引かず、日本側の窓口を1点に保つ。この形を崩すと、時差と言語の分だけ誤差が増幅します。日本人PMを置くかどうかの判断そのものは「オフショア開発 日本人PM」の記事で詳しく扱っていますので、要否を検討中の方はそちらをご覧ください。

当社の体制——日本人PMがフロント、専属チーム、2,000名以上の人財データベースから直接アサイン

当社の標準的な体制も、この原則に沿っています。日本人PMがフロントに立ち、発注者側との窓口を1点に保ったまま、現地の専属チームへ指示を通します。メンバーは2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社を挟まず、体制図の階層が増えません。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

構成は2パターンあり、日本人PM/BrSE+エンジニアのパターンA(推奨)と、エンジニアのみのパターンBがあります。1名から契約でき、開始は最短2週間、増員は約1週間、縮小・交代は1か月単位です。品質は日本人PMの設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点で担保しており、体制図の上でもレビューの担い手が箱として現れます。介護記録SaaS「CareViewer」では、日本語BrSE1名+フルスタックエンジニア2名という小さな体制で、週次の優先順位判断だけを発注側に残す形で継続開発しています。

向く案件・向かない案件——体制図が1枚で収まるか

体制図を描いてみると、オフショアが向く案件かどうかも見えてきます。発注者側の決裁者と業務責任者が決まっていて、受注者側の窓口が1点に絞れて、全体が1枚に収まるなら、体制として成立しています。一方、決裁者が空白のまま、あるいは発注者側に判断できる人がおらず、現場のメンバーへ直接指示するしか回し方が思いつかない案件は、体制図を描いた時点で無理が見えます。その状態で海外チームを足すのは、失敗のもとです。

そうした案件は、まず社内の推進体制を整えるか、上流から伴走できる体制(当社ならパターンAで、日本人PMが要件整理から入る形)を選ぶことをおすすめします。合わない案件であれば、その旨も率直にお伝えします。

プロジェクト体制図に関するよくある質問

体制図について、相談の場で繰り返し聞かれる質問を5つにまとめました。計画書のレビューやベンダー選定の場面でお使いください。

Q1. 体制図は誰が作るのですか?

原案を作るのはPMまたはPLで、承認するのはプロジェクトオーナーです。発注者側にPMがいない場合は、受注者側のPMが原案を作っても構いませんが、発注者側の枠の中身(決裁者・業務責任者・情報システム)は発注者が決めてください。自社の決定権の所在を社外に決めてもらうのは、本末転倒です。

Q2. 何人規模から作るべきですか?

社外が1社でも入るなら、人数にかかわらず作ることをおすすめします。3人のプロジェクトでも、決裁者が誰かと、窓口が誰かは決めておく必要があるためです。当社の案件でも、エンジニア1名の小規模な体制から体制図を共有します。増員は約1週間、縮小・交代は1か月単位で動くため、更新の手間も小さく収まります。

Q3. 氏名は必ず書くべきですか?

決裁層と推進層は氏名を書いてください。ここが役職名や部署名だけだと、判断を上げる先が特定できません。メンバー層は、社外公開用の資料であれば役割名と人数(例: フロントエンド2名)にとどめ、社内・関係者向けの版で氏名を書き分ける運用が現実的です。

Q4. ベンダーから提示された体制図は、どこを見ればよいですか?

3点です。1つ目は、担当予定のPM・BrSEが氏名で書かれているか(「アサイン予定」だけなら契約前の面談を依頼する)。2つ目は、同じ氏名が複数の箱にないか。3つ目は、実装担当が自社の社員か協力会社かが読み取れるか。この3点を質問の形で投げると、指摘にならずに確認できます。

Q5. 何で作るのがよいですか?

PowerPointやExcelなど、関係者全員が開けて更新できるものであれば十分です。専用の作図ツールは見た目が整いますが、更新できる人が1人に限られると、かえって古い1枚が出回ります。大切なのは作図ツールの機能ではなく、版数と更新日を付けて配り直す運用。

まとめ: 体制図は絵ではなく合意——役割を分け、線の意味を分け、更新し続ける

プロジェクト体制図が定義するのは、役割と責任、指揮命令系統、報告経路の3つです。作るときは発注者側(プロジェクトオーナー=決裁者、業務責任者、情報システム、PMO、実務担当)と受注者側(PM、BrSE、テックリード、開発メンバー、QA)を枠で分け、役割は肩書きではなく「何を決めるか」で定義します。箱の中は役割名と氏名までにとどめ、2行以上の説明が必要になったら役割分担表(RACI)に逃がしてください。

線は、実線=指揮命令、点線=報告・連絡・相談で意味を分けます。1つの箱に入る実線は1本に絞り、会社の境界は枠で囲む。そして実務上の注意として、発注者から受注者の個々のメンバーへ指揮命令の実線は引かず、受注者側のPMを経由させてください(適法性の個別判断は専門家にご確認ください)。よくある欠陥は、決裁者の空白、隠れた兼任、曖昧な境界、二重の指揮命令、省略されすぎたチーム、更新されない図の6つ。いずれも図の不備ではなく、決めていないことが1つ残っている合図です。増員・交代、フェーズ移行、決裁者の異動、契約変更のたびに版数と更新日を付けて配り直せば、体制図は形骸化しません。

海外チームを含む場合は、窓口・拠点と時差・稼働日・言語の4項目を追加で書き、日本側の窓口を1点に保ちます。当社は日本人PMをフロントに置き、2,000名以上の人財データベースから直接アサインした専属チームで、体制図の階層を増やさずに開発を進めています。外注先にどこまで渡すかの線引きはシステム開発の外注を丸投げにしない線引き、日本人PMを置くかどうかの判断はオフショア開発の日本人PMもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、体制図の形に落とした体制案と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。