プロジェクトマネジメント

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

記事内に商品プロモーションを含む場合があります

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

体制図はプロジェクト運営の大事なガイドのひとつです。指揮命令系統と役割、そしてエスカレーションのルートを明確にし、課題解決や報告を円滑に行うことが重要です。

今回は、システム開発の体制図の目的、体制図の書き方とポイントをわかりやすく解説します。

前回のおさらい(プロジェクト計画の書き方)

これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。

プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。

これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。

  1. プロジェクト概要
  2. マスタースケジュール・WBS
  3. プロジェクト体制 今回はここ
  4. 成果物
  5. 変更管理
  6. 欠陥管理
  7. 課題管理
  8. コミュニケーション計画(会議体)
  9. 要員計画
  10. リスク管理
  11. プロジェクト標準

今回は、プロジェクト体制を解説します。

体制図の目的とは

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

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

体制図の目的は、プロジェクトに参画するすべての方(ステークホルダー)の名前を列挙して、その責任と作業の分担を明確にすることです。これにより、お客様とシステム開発会社でやるべきことが明確になり、今後発生する課題や報告などをエスカレーションするルートが決まります。

ステークホルダーは、開発メンバーはもちろん、お客様の責任者だけではなく、業務を詳しく知る担当者も含まれます。 もし、社内・社外問わず、データ連携先があれば、その連携先(社外の場合はその会社)の責任者担当者、開発を請け負っているシステム開発会社の方々もステークホルダーです。

ステークホルダー(stakeholder)とは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指す。日本語では利害関係者(りがいかんけいしゃ)という。具体的には、消費者(顧客)、労働者、株主、専門家、債権者、仕入先、得意先、地域社会、行政機関、利益団体(業界団体・労働組合・当事者団体等)の構成員など。

引用:ウィキペディア|ステークホルダー

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

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

なぜ体制図が必要なのか

これまで、身近な家族旅行を題材にプロジェクトマネジメントとは何かを解説しました。今回も家族旅行の体制図を作成して、なぜ体制図が必要なのか考えてみたいと思います。
こちらに家族旅行の設定をまとめていますので合わせて参照ください。

家族旅行の体制図

お父さんは、この家族旅行プロジェクトの責任者です。家族旅行が楽しい思い出となるようにプロジェクトを成功させる責任があります。
お母さんは、家族旅行プロジェクトのリーダーとしてメンバーである子供や両親を指揮して円滑に作業を進める責任があります。

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

この体制図では、お父さんと旅行会社のAさん、お母さんと旅行会社のBさんを横並びで書いています。これは対等な関係(カウンターパート)を明確にするためで、何か問題が発生した時はカウンターパート同士が話し合って解決する役割を担います。もし、そのレベルでは解決しない場合は、上位レベルの責任者へエスカレーションし、そのレベル間で話し合って解決することになります。 この縦のメンバー間と横のステークホルダーとの連携がプロジェクトを円滑に運営していく重要なカギとなります。

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

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

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

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

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

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

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

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

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

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

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

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

それぞれの職務と役割

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

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

お客様側の職務と役割

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

 

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

引用:金融庁|内部統制の基本的枠組み(案)|内部統制の基本的枠組み|1.内部統制の定義(目的)

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

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

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

体制図は、プロジェクトを運営するための大事なガイドのひとつと言えます。指揮命令系統と役割、そしてエスカレーションのルートを明確にし、課題解決や報告を円滑に行うことができます。

繰り返しになりますが、目的とポイントをまとめます。

体制図の目的
  • プロジェクトに参画するすべての方(ステークホルダー)の責任と作業の分担を明確にすること
  • お客様とシステム開発会社でやるべきことが明確になり、今後発生する課題や報告などをエスカレーションするルートが決定
  • プロジェクトに参画するすべての方(ステークホルダー)の名前を列挙します
  • お客様側と開発会社側で対等な関係となる責任者を横並びに(同じレベルに合わせて)明記します
  • もし担当者間では解決が難しい課題が出てきた場合は、より上位へエスカレーションして早期解決を図りましょう

プロジェクト体制の解説はこれで終わりです。

引き続き、プロジェクト計画でやるべき11項目のガイドを解説します。これらをプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。

  1. プロジェクト概要
  2. マスタースケジュール・WBS
  3. プロジェクト体制
  4. 成果物 次回はこちら
  5. 変更管理
  6. 欠陥管理
  7. 課題管理
  8. コミュニケーション計画(会議体)
  9. 要員計画
  10. リスク管理
  11. プロジェクト標準

次回は成果物について解説します。よろしければ次の記事もお読みください。

【初心者必見】プロジェクトマネジメントの成果物とは?プロジェクト計画で管理すべき成果物のポイントを解説成果物はプロジェクト活動の対価です。何を成果物とするか、プロジェクト開始前にお客様と合意しておく必要があります。成果物の量によって費用が変わるため、プロジェクト計画時点で取り決めておく必要があるわけです。今回は、成果物とは何か?プロジェクト計画で管理すべき成果物、具体的な成果物をわかりやすく解説します。...
ABOUT ME
hidechi
メーカーに入社し、その後IT部門が分社独立、情報システムエンジニアとして30年以上勤務しています。これまで多くのプロジェクトに携わり、それらの経験から得た知見を覚え書きとして記録することで、厳しい現場で奮闘しているSEの皆さんの一助となれば幸いです。
関連記事はこちら