【初心者必見】システム開発プロジェクトの体制図の書き方とポイントを解説

システム開発のプロマネを任命されたけど、プロジェクトの体制はどうすればいいの？
体制図の目的はなに？なぜ体制図が必要なの？
体制図の書き方がわからない

体制図はプロジェクト運営の大事なガイドのひとつです。

指揮命令系統と役割、そしてエスカレーションのルートを明確にし、課題解決や報告を円滑に行うことが重要です。

今回は、プロジェクトにおける体制図の目的、体制図の書き方とポイントをわかりやすく解説します。

体制図の目的とは
なぜ体制図が必要なのか
体制図の書き方とポイント
- システム開発の体制図サンプル
それぞれの職務と役割
- お客様側の職務と役割
- システム開発側の職務と役割
体制図はプロジェクト運営の大事なガイドのひとつ

体制図の目的とは

プロジェクトが立ち上がると、その統括責任者からプロジェクトマネージャーが任命されます。

プロジェクトマネージャーは、まず最初にプロジェクト計画を作成するわけですが、プロジェクト運営の大事なガイドのひとつとして体制図があります。

体制図の目的は、プロジェクトに参画するすべての方（ステークホルダー）の名前を列挙して、その責任と作業の分担を明確にすることです。

これにより、お客様とシステム開発会社でやるべきことが明確になり、今後発生する課題や報告などをエスカレーションするルートが決まります。

ステークホルダーは、開発メンバーはもちろん、お客様の責任者だけではなく、実際の業務に詳しい担当者も含まれます。

もし、社内・社外問わず、データ連携先があれば、その連携先（社外の場合はその相手会社）の責任者や担当者、システム開発を請け負っているベンダーの方々もステークホルダーです。

ステークホルダーについてもっと詳しく知りたい方はこちらも参照ください。

では、なぜこのような体制図が必要なのでしょうか？

なぜ体制図が必要なのか

これまで、身近な家族旅行を題材にプロジェクトマネジメントとは何かを解説しました。

今回も家族旅行の体制図を作成して、なぜ体制図が必要なのか考えてみたいと思います。
※こちらに家族旅行の設定をまとめていますので合わせて参照ください。

お父さんは、この家族旅行プロジェクトの責任者です。家族旅行が楽しい思い出となるようにプロジェクトを成功させる責任があります。

お母さんは、家族旅行プロジェクトのリーダーとしてメンバーである子供や両親を指揮して円滑に作業を進める責任があります。

今回の家族旅行は商店街の景品でもらった旅行クーポンを利用するため、その旅行会社もステークホルダーになります。窓口担当がＢさん、その責任者がＡさんです。

この体制図では、お父さんと旅行会社のＡさん、お母さんと旅行会社のＢさんを横並びで書いています。これは対等な関係（カウンターパート）を明確にするためで、何か問題が発生した時はカウンターパート同士が話し合って解決する役割を担います。

もし、そのレベルでは解決しない場合は、上位レベルの責任者へエスカレーションし、そのレベル間で話し合って解決することになります。

この縦のメンバー間と横のステークホルダーとの連携がプロジェクトを円滑に運営していく重要なカギとなります。

もしも、家族全員が個別に旅行会社のＢさんと連絡を取り合ってしまったらどうなるでしょうか？

説明するまでもないと思いますが、それぞれの身勝手な要望がＢさんに集まり、思いもしないような旅行プランが出来上がってしまいます。旅行会社のＢさんは家族みんなの要望をできるだけ叶えようと調整した結果、目的から外れた旅行内容で予算も大幅に超えてしまうかもしれません。

つまり、体制図によって指揮命令系統と役割、そしてエスカレーションのルートを明確にし、課題解決や報告を円滑に行うことができるというわけです。

体制図の書き方とポイント

先ほどの家族旅行の例で体制図はどういったものか理解いただけたかと思います。

では、システム開発の体制図はどのようになるでしょうか？

システム開発の体制図サンプル

よくありそうなサンプルを記載します。
※登場人物の名前はすべて架空のものです。
※画像をクリックすれば拡大表示されます。

プロジェクトに参画するすべての方（ステークホルダー）の名前を列挙します
お客様側と開発会社側で対等な関係（カウンターパート）となる責任者を横並びに（横の位置を合わせて）明記します

この例にはありませんが、他社サービスとデータ連携している場合は、連携先の会社もステークホルダーとなりますので体制図に追加する必要があります。

プロジェクトで発生した課題や報告は、この対等な関係のレベル間で行います。例えば、お客様の社長へ現在の進捗状況を報告する場では、システム開発会社の社長も同席する場でなければなりません。

もし担当者間では解決が難しい課題が出てきた場合は、より上位へエスカレーションして早期解決を図りましょう。

それぞれの職務と役割

体制図に加えて、各担当者の役割が分かるように担当する作業内容や権限を明記した一覧表も同時に作成します。

参考に、プロジェクトの体制図によく出てくる職務と主な役割をまとめます。

お客様側の職務と役割

職務	主な役割
プロジェクト統括責任者	・プロジェクト全体の状況把握・重要事項の意思決定・プロジェクトマネージャーへの助言・成果物に対するレビューと承認
プロジェクトマネージャー	・プロジェクト全体の状況把握・重要事項の意思決定における統括責任者への相談、報告・プロジェクトリーダーの情報とりまとめ・プロジェクト運営におけるタスクの進捗管理
プロジェクトリーダー	・プロジェクトの状況把握・ユニットリーダーの情報とりまとめ・プロジェクト運営におけるタスクの情報とりまとめ
ユニットリーダー	・担当する業務の情報とりまとめ・新システムに向けた業務改善案の検討、決定、アナウンス・現行から新システムへの切り替えに関するサポート・メンバーとの情報共有
アドバイザリー	・内部統制の観点からプロジェクト全体の助言・システム開発が間違った方向に進まないように助言

　内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の４つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びＩＴ（情報技術）への対応の６つの基本的要素から構成される。
引用：金融庁｜内部統制の基本的枠組み（案）｜内部統制の基本的枠組み｜１．内部統制の定義（目的）

システム開発側の職務と役割

職務	主な役割
プロジェクトマネージャー	・プロジェクト全体の状況把握・プロジェクト体制の編成・プロジェクト方針やアクションの決定・重要事項の意思決定における統括責任者への相談、報告・プロジェクト推進で発生する問題、リスクへの対処・成果物に対するレビューと承認
プロジェクトリーダー	・プロジェクトのタスク計画とコントロール・プロジェクトの課題の対策・ユニット間のタスク連携と情報共有・ユニットリーダーの情報とりまとめと報告・各種ドキュメントの標準化・各ユニットの内部レビュー参画・各ユニットの成果物に対するレビューと承認・担当する範囲の総合窓口
ユニットリーダー	・担当するアプリケーション全体の情報とりまとめと報告・ユニット内の進捗管理・ユニット内の品質管理・ユニット内の開発要員管理・納品成果物の作成と管理・担当するお客様の窓口
品質保証責任者	・プロジェクトの品質計画管理・進捗、品質、納品、要員の監視とコントロール・工程ごとの品質評価と次工程への承認