--- title: "体制図の書き方：システム開発の体制図と役割分担表、発注者・PMO・ベンダーの報告線" url: "https://www.issoh.co.jp/column/details/19784/" published: 2026-11-14 updated: 2026-11-14 categories: ["DX"] publisher: "株式会社一創" --- # 体制図の書き方：システム開発の体制図と役割分担表、発注者・PMO・ベンダーの報告線 体制図は、システム開発のプロジェクトで「誰が判断し、誰が誰に指示を出し、誰に報告するか」を1枚で示す図です。この記事では、発注者・PMO・ベンダーそれぞれの役割と体制図への載せ方、5つの手順と受発注システム刷新を例にした記入例を示します。あわせて、体制図だけでは表せない作業ごとの責任を補う役割分担表（RACI）の作り方と、請負・準委任の契約で偽装請負にならない線の引き方まで整理しました。 ## まとめ：体制図は判断者と報告線を示し、作業ごとの責任は役割分担表で補う 体制図に載せるのは、役職の上下ではなく判断と報告の経路です。発注者側はプロジェクトオーナー・プロジェクト責任者・窓口担当・利用部門代表、ベンダー側はPMと開発チームの責任者を名前で置き、両者の間にステアリングコミッティとPMOを配置します。 線は2種類に分けます。指示と報告の実線は、発注者の責任者からベンダーのPMへの1本に集約してください。発注者がベンダーの開発担当者へ直接指示する線を描くと、契約が請負でも準委任でも、実態によっては偽装請負と判断されます。 体制図は人と線の図なので、要件定義書の承認やテスト計画の作成といった作業ごとの責任は表しきれません。成果物と承認行為を行に並べた役割分担表を1枚添え、承認者を1作業に1人だけ置くと、体制図とあわせて責任の空白がなくなります。 ## 体制図とは：プロジェクト計画書に載せる図と組織図・システム構成図との違い ### 体制図が示すのは指示と報告の線、組織図・システム構成図と混同しない区別 体制図という言葉は、会社の組織図やシステムの構成図と混同されがちです。違いは「何の関係を描くか」で見分けられます。 | 図・表 | 描く関係 | 単位 | 寿命 | | ------- | ------------ | ------ | ---------- | | 組織図 | 会社の部署と職位の上下 | 部署 | 組織改編まで | | 体制図 | 判断・指示・報告の経路 | 人と役割 | プロジェクト終了まで | | 役割分担表 | 作業ごとの責任の割り当て | 作業と役割 | 工程ごとに改定 | | システム構成図 | サーバーや機能のつながり | 機器とソフト | システム廃止まで | 体制図は会社をまたぎます。発注者の部長とベンダーのPMが同じ図の中で線でつながるのは、組織図にはない特徴です。体制図はプロジェクト計画書の体制欄に収める図で、計画書全体の項目は[プロジェクト計画書の書き方と発注者・受託側の分担](https://www.issoh.co.jp/column/details/19762/)で扱っています。機器やソフトの関係を描く図は[システム構成図の書き方の手順と例](https://www.issoh.co.jp/column/details/13136/)を参照してください。 ### 体制図を作る時期：提案書・計画書の承認・工程の切り替わりで描き直す運用 体制図が最初に登場するのはベンダーの提案書です。ただし提案時点の図はベンダー側の体制が中心で、発注者側は「ご担当者様」の箱しかないことが多く、そのまま使うと発注者側の判断者が空欄になります。 正式な体制図は、ベンダーが決まった後にプロジェクト計画書の一部として作り、双方の責任者の承認を取ります。要件定義から設計・開発へ移るときは、利用部門の関与が減りテスト担当が加わるなど顔ぶれが変わるため、工程の切り替わりで版数を上げて描き直してください。 ## システム開発の体制図に載せる役割：発注者・PMO・ベンダーの立場と責任範囲 ### 発注者側の役割：プロジェクトオーナー・責任者・窓口担当・利用部門代表の4つ 発注者側で最低限そろえる立場は4つです。プロジェクトオーナーは投資を決めた経営層で、目的の変更や中止を判断します。プロジェクト責任者は予算と仕様を最終決定する人、窓口担当はベンダーとの日々の連絡を受け持つ人、利用部門代表は業務ルールを説明し受入テストを行う人です。 政府情報システムの整備ルールである[DS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日決定）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715%5Fresources%5Fstandard%5Fguidelines%5Fguideline%5F01.pdf)は、第3編第2章の体制準備で、プロジェクトを推進する組織を情報システム部門だけでなく制度所管部門と業務実施部門が参画するよう組織すると定めています。民間でも、情報システム部門だけで体制図を描くと利用部門の箱が抜け、受入テストの担当者が決まらないまま開発が進みます。 ### ベンダー側の役割：PM・PL・品質管理責任者と開発チーム、再委託先の書き方 ベンダー側は、PM（プロジェクトマネージャー）を頂点に、チームごとのPL（プロジェクトリーダー）、その下にSEやプログラマーの開発チームを置くのが基本形です。品質管理の責任者やテストチームをPMの直下に別系統で置くと、開発チームとテストの判断が分かれていることが図から読み取れます。 再委託先がある場合は、再委託先の会社名と責任者を箱にして、元請けのPLとの間に線を引きます。再委託先を省いた体制図は、障害対応やメンバー交代の連絡が誰に届くのかを発注者が把握できない原因になります。人数が多いチームは個人名ではなく「開発チーム（5名）」のように人数で書いて構いません。 ### PMOとステアリングコミッティの置き場所、発注者側か中立かで変わる線の向き ステアリングコミッティは、プロジェクトオーナーと双方の責任者が出席し、仕様変更・追加費用・日程の見直しを判断する会議体です。体制図では発注者とベンダーの最上段をつなぐ横長の箱として描き、月次など開催頻度を添えます。 PMOは置く場所で役割が変わります。発注者側に置くPMOは、発注者の立場でベンダーの進捗と品質を確認し、プロジェクト責任者を補佐する役割です。ベンダー側に置くPMOは、ベンダー内部の進捗集計や会議運営を担います。複数ベンダーが関わる案件では、発注者側か中立の位置に置き、各ベンダーのPMから報告を受ける線を引く形です。PMOの種類と外部に任せる判断は[PMOの役割・種類とPMとの違い](https://www.issoh.co.jp/column/details/19156/)で整理しています。 ## 体制図の書き方：5つの手順と、受発注システム刷新を例にした記入例 ### 体制図を作る5つの手順：判断者の特定から線の確認と双方の承認まで 体制図は箱を並べるところから始めると、肩書きの序列を写しただけの図になります。次の順で作ると、判断と報告の経路が先に固まります。 1. 目的の変更・予算・仕様をそれぞれ誰が決めるかを書き出し、判断者を特定する 2. 発注者側の4つの立場とベンダー側のPM・PLに個人名を当てる 3. 指示と報告の実線を引き、発注者からベンダーへの実線を責任者とPMの間の1本にまとめる 4. 相談・情報共有の点線と、会議体（定例・ステアリングコミッティ）を書き加える 5. 双方の責任者が図を確認し、プロジェクト計画書の体制欄に版数つきで収める 手順1で判断者が決まらない項目があれば、それは図の問題ではなく体制の問題です。図の作成を止め、プロジェクトオーナーに判断者の指名を依頼してください。 ### 記入例：従業員80名の卸売業が受発注システムを刷新する場合の体制図 FAXと表計算で回している受発注を刷新する卸売業を想定した記入例です。図にする前の段階として、層ごとに誰を置き、どこへ報告するかを表で整理します。 | 層 | 発注者側 | ベンダー側 | 報告先 | | ---- | ----------- | -------------- | --------- | | 最終判断 | オーナー：取締役 | 事業部長 | 月次の運営会議 | | 責任者 | 責任者：営業管理部長 | PM | オーナー／事業部長 | | 管理 | 窓口：情シス担当1名 | PL（開発）・PL（テスト） | 責任者／PM | | 実務 | 利用部門代表：受注課長 | 開発チーム（5名） | 窓口／PL | この例では、受注課長は業務ルールの説明と受入テストを担いますが、ベンダーの開発チームへ直接作業を頼む線は引きません。要望は窓口担当を通じてPMに渡し、PMが開発チームへの割り振りを決めます。図にするときは、この表の左右を2列の箱にし、中央の最上段に運営会議の横長の箱を置きます。 ### 線の種類を分ける：指示・報告の実線と相談・情報共有の点線の使い分け 体制図の線を1種類で描くと、誰が誰に指示できるのかが読み取れなくなります。実線は「指示を出し、報告を受ける」関係だけに使い、相談・情報共有・技術的な質問のやり取りは点線で描きます。 受発注システムの例では、利用部門代表とベンダーの開発チームの間は点線になります。業務ルールの質問に答えたり、画面の試作を見て意見を伝えたりするのは情報共有の範囲だからです。点線であることを図で示しておくと、利用部門の担当者が開発チームに作業の優先順位まで指示してしまう事態を防ぎやすくなります。 ## 役割分担表（RACI）の作り方：体制図で表せない作業ごとの責任を表にする方法 ### RACIの4区分と、役割分担表で承認者を1つの作業に1人だけ置く理由 役割分担表でよく使われる型がRACIです。Rは実行責任者（作業する人）、Aは説明責任者（承認し結果に責任を持つ人）、Cは事前に相談を受ける人、Iは結果の報告を受ける人を表します。行に作業、列に役割を並べ、交点に記号を入れます。 | 作業 | 責任者 | 窓口 | 利用部門 | PM | | -------- | --- | -- | ---- | -- | | 要件定義書の作成 | I | C | C | R | | 要件定義書の承認 | A | R | C | I | | 受入テストの実施 | I | A | R | C | | 仕様変更の承認 | A | R | C | C | Aは1つの作業に1人だけ置きます。Aが2人いる作業は、意見が割れたときに誰も決められません。反対にAが空欄の作業は、問題が起きたときに責任を負う人がいないことを意味します。表を作り終えたら、まずAの列を縦に見て、空欄と重複がないかを確かめてください。 ### 役割分担表に載せる作業の粒度：工程の成果物と承認行為を行に並べる方法 役割分担表の行を細かくしすぎると、WBSの写しになって誰も読まなくなります。行に置くのは、工程ごとの成果物の作成と承認、発注者側の作業（テストデータの準備・利用者への説明会）、仕様変更や課題の判断といった、責任の所在が争点になりやすい行為です。業務システムの開発なら20〜40行に収まります。 作成と承認は別の行に分けます。「要件定義書」の1行にまとめると、ベンダーが作成のR、発注者が承認のAという関係が1つのセルに収まらないためです。課題やリスクの判断者を決める行は、[課題管理表の項目とステータス設計](https://www.issoh.co.jp/column/details/19764/)の担当者欄とそろえておくと、表の間で判断者が食い違いません。 ## 契約形態で変わる体制図の線：請負・準委任と偽装請負にならない指示系統 ### 発注者からベンダーの担当者へ直接線を引くと偽装請負と判断される理由 システム開発の体制図で最も注意が要るのは、発注者からベンダーの開発担当者へ伸びる線です。労働者派遣と請負の区別は、昭和61年労働省告示第37号（いわゆる37号告示）に基づき、契約の形式ではなく実態で判断されると[厚生労働省の37号告示関係疑義応答集のページ](https://www.mhlw.go.jp/bunya/koyou/gigi%5Foutou01.html)が示しています。 [疑義応答集（第3集）](https://www.mhlw.go.jp/content/001704257.pdf)のQ1は、準委任契約であっても、発注者と受注者側の労働者の間に実態として指揮命令関係があれば労働者派遣に該当すると答えています。Q3は、受注者が管理責任者を選任していても、発注者側が受注者側の開発担当者へ直接、仕事の割り付けや順序の指示を行えば偽装請負と判断されるとしています。体制図の実線を発注者の責任者とベンダーのPMの間に集約するのは、この指示系統を図の上で明示するためです。請負と準委任の違いは[委任・請負・受託の違いと契約の選び方](https://www.issoh.co.jp/column/details/13189/)、常駐型の契約は[SESの契約形態と派遣との違い](https://www.issoh.co.jp/column/details/13188/)で整理しています。 ### アジャイル開発の体制図：プロダクトオーナーと開発チームを対等に描く書き方 アジャイル型開発では、発注者側のプロダクトオーナーとベンダーの開発担当者が1つのチームとして日常的にやり取りします。第3集のQ2によれば、双方が対等な関係で協働し、受注者側の開発担当者が自律的に判断して開発を進めている実態があれば偽装請負にはあたらないという整理です。Q4ではプロダクトオーナーによるバックログの説明、Q6では双方の全員が参加する会議やチャットについて、それだけで直ちに偽装請負とはならないと示されています。 体制図では、プロダクトオーナーと開発チームを上下ではなく横に並べ、間を点線で結びます。業務の進め方や労働時間に関する指示が必要になったときの実線は、ベンダーの管理責任者から開発担当者へ引く形です。第3集のQ2は、役割と権限、チーム内の業務の進め方をあらかじめ明確にして発注者と受注者で合意しておくことを例に挙げており、体制図と役割分担表はその合意を残す文書になります。 ### 発注者側に体制を組める人がいない場合のPMO支援と外部への任せ方 中堅・中小企業では、発注者側の4つの立場を埋める人がそろわないことがあります。窓口担当が責任者を兼ね、利用部門代表も同じ人が務めると、体制図の上では箱が3つあっても判断する人は1人です。その人が不在の週は仕様の確認が止まります。 この場合は、発注者の立場で体制図と役割分担表を組み、ベンダーの体制案と工程案を確認する外部支援を入れる選択肢があります。一創の[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)では、受託ベンダーとは別の立場で発注者側の体制づくりと会議体の設計に関わる支援です。外部のPMOを入れる場合も、予算と仕様の最終判断は発注者の責任者に残し、体制図ではPMOを責任者の補佐として横に置きます。 ## 体制図の失敗パターンと、図を整える前に体制そのものを見直すべき場面 ### 名前のない箱・兼務の隠れ・決裁者不在、使われなくなる体制図の3つの型 最も多いのは、箱に役職名だけが書かれ、個人名がない体制図です。「情報システム部」と書かれた箱には、誰に連絡すればよいかという情報がありません。発注者側の箱は個人名と連絡手段まで書いてください。 兼務が図から読み取れないのも典型的な失敗です。同じ人が窓口担当とテスト責任者を兼ねているのに別の箱に別の肩書きで書かれていると、その人に作業が集中していることに誰も気付きません。兼務は同じ箱にまとめるか、箱に「兼務」と明記します。 決裁者が図にいないパターンもあります。プロジェクト責任者の上に、実際に予算を決める役員が載っていない体制図では、ステアリングコミッティで決めた内容が後から覆ります。炎上した案件をたどると、この型に行き着くことが少なくありません。 ### 小規模案件は体制図1枚で十分、役割分担表まで作るべき案件の条件 関係者が社内の1部門とベンダー1社だけで、期間が3か月以内の案件なら、役割分担表は不要です。発注者側の責任者と窓口、ベンダーのPMの3人を実線で結んだ体制図1枚と、仕様変更の承認者の1行で運用できます。 反対に、利用部門が2つ以上ある案件、再委託先を含めて複数のベンダーが関わる案件、アジャイル型で発注者側の担当者が開発チームと日常的にやり取りする案件では、体制図だけで済ませてはいけません。部門間で要件が割れたときの判断者と、指示系統の合意を役割分担表で残しておかないと、責任の空白と偽装請負の両方のリスクを抱えたまま開発が進みます。 ## 体制図のよくある質問：テンプレートの入手先から個人名の記載・更新時期まで 体制図と役割分担表について、発注担当者から寄せられることの多い質問をまとめました。 ### 体制図のテンプレートはどこで手に入りますか？ PowerPointのSmartArt（階層構造）や、作図ツールの組織図テンプレートで体制図の形は作れます。ただしテンプレートが用意するのは箱と線の形だけで、実線と点線の区別や会社をまたぐ配置は自分で加える必要がある部分です。本記事の記入例の表をそのままExcelに写し、層ごとに発注者側とベンダー側を左右に並べる形から始めると、図にする前に抜けている立場に気付けます。 ### 体制図は発注者とベンダーのどちらが作るものですか？ 図として清書するのはベンダーのPMが多いものの、発注者側の箱の中身は発注者が決めます。ベンダーが発注者側の判断者を推測で書くと、実際の決裁者が抜けた図になります。発注者側の4つの立場とその担当者を発注者が先に示し、ベンダーが自社側の体制と線を加え、双方の責任者が承認する流れにしてください。 ### 体制図にベンダー側の担当者の個人名を書くべきですか？ PMやPLなど、発注者との窓口になる人は個人名で書きます。一方で開発チームのメンバーは「開発チーム（5名）」のように人数で書くのが無難です。第3集のQ7は、発注者が特定の者を指名して業務に従事させたり、特定の者の就業を拒否したりすると適正な請負とは認められないとしています。体制図の個人名を根拠にメンバーの交代や指名を求める運用は避けてください。 ### 役割分担表と体制図はどちらを先に作りますか？ 体制図が先です。体制図で役割と担当者が決まらないと、役割分担表の列を立てられません。体制図で判断者と線を固め、その列を使って役割分担表の作業ごとの責任を埋めます。役割分担表を作る途中で、承認者のいない作業が見つかったら、体制図に戻って立場を追加します。 ### 体制図はいつ更新すればよいですか？ 工程の切り替わりと、メンバーの交代があった時点が更新の目安です。要件定義から設計・開発へ移るとき、テスト工程に入るとき、稼働後の保守体制へ移るときは、関わる人と線が変わります。更新したら版数と改定日を表紙に残し、定例会議で新しい図を共有してください。古い図が共有フォルダに残っていると、交代前の担当者に連絡が届く事故が起きます。 ## 関連記事 - [プロジェクト計画書の書き方：システム開発で書く項目とテンプレート、発注者と受託側の分担](https://www.issoh.co.jp/column/details/19762/)：体制図を収める計画書全体の項目と書き分け - [PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断](https://www.issoh.co.jp/column/details/19156/)：体制図に置くPMOの種類と外部に任せる判断 - [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】](https://www.issoh.co.jp/column/details/15670/)：体制を組んだ後の進捗・品質・リスク管理 - [リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用](https://www.issoh.co.jp/column/details/19780/)：キーパーソンの不在など体制のリスクを管理する表 - [炎上プロジェクトとは：システム開発が炎上する兆候と原因、発注者側の立て直し手順](https://www.issoh.co.jp/column/details/19782/)：決裁者不在の体制がたどる経過と立て直し --- 出典: [体制図の書き方：システム開発の体制図と役割分担表、発注者・PMO・ベンダーの報告線]()（株式会社一創）