システム開発の体制図の作り方と記載すべき役割

システム開発の体制図は、PM・PMO・SE・発注者側の担当者など、プロジェクトに関わる人と役割の分担を1枚の図に整理したものです。複数のベンダーが関わる開発案件ほど、体制図が実際に機能しているかどうかで、報告の混乱や責任の押し付け合いが起きるかどうかが変わります。本記事では、体制図に記載すべき役割と作成手順に加えて、体制図を形骸化させずに運用するための実務上の工夫を解説します。

体制図とは何か

体制図とは、プロジェクトに関わる人と役割の分担を階層構造で可視化した図のことです。

発注者側の担当者、PM、PMO、SEといった立場の異なるメンバーが同じプロジェクトに参加する開発案件では、誰がどの範囲の意思決定と報告を担うのかが図として共有されていないと、同じ確認事項を複数の窓口に重ねて聞くような無駄が生まれます。体制図は会社の組織図のように固定された人事上の関係を示すものではなく、そのプロジェクトの期間だけ機能する役割の割り当てを表すものと考えると分かりやすくなります。

プロジェクト関係者と役割分担の可視化

体制図の目的は、プロジェクトに関わる全関係者と役割分担を、契約や所属部署をまたいで一目で分かる形にすることです。

独立行政法人情報処理推進機構（IPA）が2013年3月4日に刊行した「共通フレーム2013」は、ソフトウェア・システム・サービスに関わる人々が同じ言葉で工程や役割を語れるよう、構想から開発・運用・保守・廃棄までのライフサイクル全体の作業項目と役割を整理した共通の枠組みです（出典：IPA「共通フレーム2013」）。体制図は、この共通言語を1枚の図に落とし込み、発注者とベンダーが役割の呼び方や範囲について同じ理解を持てるようにするための道具と捉えると位置づけがつかみやすくなります。

体制図に記載すべき主要な役割

体制図には、発注者側の担当者・PM・PMO・SEという、立場も所属も異なる役割を最低限記載します。

それぞれの役割が持つ権限と責任の範囲が図の上で区別されていないと、後述する報告ラインの混乱や責任範囲の曖昧さにつながります。

PM・PMO・SE・発注者側の担当者

PMはプロジェクト全体の意思決定と最終責任を担い、PMOはPMを補佐する立場として体制図に記載します。

PM（プロジェクトマネージャー）は、スケジュール・品質・コストに関する最終的な意思決定を担う役割です。PMOが体制図上で担う業務範囲には案件によって幅があり、進捗確認や報告資料の整備を中心にする支援的な立ち位置から、リスク管理や意思決定の材料整理までPMを補佐する立ち位置まで差があります（ドメイン知識ベース「PMOフリーランスの月額単価相場と役割別レンジ」より）。体制図を作成する際は、PMOがどこまでの権限を持つのかをあらかじめ明記しておくことが、責任範囲の曖昧さを防ぐ土台になります。

SE（システムエンジニア）は設計・実装を担う技術側の責任者で、複数ベンダーが参画する案件では、各社のSEリーダーを個別に体制図へ記載します。発注者側の担当者には、予算承認や要件の最終判断を行うシステム部門の責任者と、日々の業務要件を確認する業務部門の代表者の両方を含めておくと、要件の確認先が明確になります。

PMを担う人材の実務能力を示す資格としては、国内ではPMP（Project Management Professional）の知名度が高く、体制図や提案資料に記載する際の説明コストが低いとされています（ドメイン知識ベース「PM/PMO関連資格の推奨順」より）。ただし、資格の有無よりもプロジェクトの規模や担当したフェーズ・体制の大きさといった実務経験のほうが、実際に担う役割の重さを左右する点には注意が必要です。

以下は、Web層・AP層・DB層の3層構造を持つ架空のWebシステム開発（発注者1社・元請けベンダー1社・協力会社2社の体制）を想定した、体制図の記載例です。

体制図作成の手順

体制図の作成は、関係者の洗い出し、役割と権限の定義、報告ラインの明記、合意形成、更新のサイクルという5つの手順で進めます。

1. 関係者を洗い出す：発注者側の各部門、元請けベンダー、協力会社など、プロジェクトに関わる組織と人をすべてリストアップします。
2. 役割ごとの権限を定義する：誰が何を最終承認できるのか、役割ごとの意思決定の範囲を言葉で定義します。
3. 報告ラインを明記する：誰が誰にどのタイミングで報告するのかを、図の線として明示します。
4. 関係者全員で合意形成する：キックオフの場で体制図を共有し、記載内容に認識のずれがないかを確認します。
5. フェーズの変わり目で見直す：要件定義から設計、テストといった工程の切り替わりや、担当者・ベンダーの交代があったタイミングで体制図を更新します。

体制図は工程が進むにつれて参照される頻度や見るべき箇所が変わっていきます。体制図を使う工程を理解すると、どのタイミングで体制図を見直すべきかが判断しやすくなります。

体制図がプロジェクトの混乱を防ぐ理由

体制図が機能していると、報告のたらい回しと責任範囲の押し付け合いという、複数ベンダー案件で起きやすい2つの混乱を防げます。

コンサルタントの歩み編集部が複数のPMO経験者への取材で確認したところ、体制図が形骸化する現場に共通していたのは、体制図をキックオフ資料の1枚として作成した後、プロジェクトの進行中に一度も更新していないケースでした。逆に機能し続けていた現場では、体制図を定例会議の出席者リストや課題管理表と連動させ、担当者の交代やベンダーの追加があった時点でその場で図を書き換える運用を徹底していました。体制図は作成した瞬間が完成形ではなく、更新され続けることで初めて実務上の効力を持ちます。

報告ラインの明確化

報告ラインを体制図に明記すると、誰が誰にどのタイミングで報告するかが固定され、同じ内容を複数の窓口に重ねて説明する手戻りが減ります。

複数ベンダーが参画する案件では、統括PMを経由せずに各社のSEリーダーが発注者側へ直接報告してしまい、発注者側で情報が重複したり食い違ったりする場面が起こりやすくなります。体制図上で報告ラインを線として固定しておくと、どの情報がどの経路で誰に届くべきかが関係者全員の共通認識になり、こうした重複や食い違いを未然に防ぎやすくなります。

責任範囲の曖昧さの解消

責任範囲を体制図上の担当欄に書き分けておくと、トラブル発生時に「誰が最終判断するか」で足踏みする時間を短くできます。

経済産業省とIPAが公開する「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）は、見直しのポイントの一つとして「プロジェクトマネジメント義務及び協力義務」を明記しており、発注者とベンダーの双方が開発を円滑に進めるための役割を果たす義務を負うという考え方を示しています（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。体制図で責任範囲をあらかじめ可視化しておくことは、この協力義務を実務レベルで果たすための土台になります。体制整備とプロジェクト管理の関係を理解した上で体制図を運用すると、単なる図解ではなくプロジェクト管理全体の一部として位置づけやすくなります。

まとめ

体制図は、発注者側の担当者・PM・PMO・SEといった役割の分担と報告ラインを可視化し、複数ベンダーが関わる開発案件の混乱を防ぐための図です。

• 体制図は固定的な組織図ではなく、そのプロジェクトの期間だけ機能する役割の割り当てを表すものです。
• 発注者側の担当者・PM・PMO・SEという4種類の役割を最低限記載し、権限と責任の範囲を区別します。
• 関係者の洗い出しから合意形成、フェーズごとの見直しまでの手順で作成します。
• 報告ラインと責任範囲を明記することで、たらい回しや押し付け合いを防げます。
• 体制図は作成した時点で終わりにせず、担当者やベンダーの変更に合わせて更新し続けることで初めて機能します。

体制図は一度作って共有すれば役目を終えるものではなく、プロジェクトの進行に合わせて更新し続けることで、複数のベンダーが関わる開発案件でも報告と責任の所在を明確に保つ道具になります。

出典・参考情報

1. IPA「共通フレーム2013」（2026-09-12参照）
2. 経済産業省・IPA「情報システム・モデル取引・契約書（第二版）」（2026-09-12参照）

本記事は2026年9月時点の情報に基づいています。