見出し画像

現場で使える!プロジェクト体制図作成のポイント【PMの道具箱 #7】

みなさん、こんにちは!
プロジェクトを計画する際に必要不可欠なもの・・・それは、プロジェクト体制図です。
「プロジェクト体制図を作ったことがあるものの、いつもコピペでなんかしっくりこない」といったもやもやを抱えている方も多いのではないでしょうか。
この記事では、そんな多くの方が抱えているもやもやを解消することを目的にして、体制図の作成ポイントを説明します。また、体制図を効率的に作成するためのテンプレートと、その記載内容がイメージできるサンプルを提供します。



プロジェクト体制図の目的

まず、プロジェクト体制図を作成する目的について説明します。それは「プロジェクト内の役割と指示系統の明確化」です。
プロジェクトは複数組織を横断したメンバーで構成されます。特に、大規模プロジェクトでは、メンバーの所属が社外組織を含む多数の組織にまたがることも珍しくありません。
多くのメンバーが作業を行う際に、役割と指示系統が不明確なままだと、責任の曖昧さが生じます。その結果、問題発生時に責任を持つメンバーの明確化が遅れることにより、対処の開始が遅れる可能性が高まります。そのようなことを防止するため、体制図により役割と指示系統を明確化することが必要です。

体制図では、各ボックスに役割とメンバー名を記載し、直接の指示系統となるボックス間を線で上下につなぎます。
図の上から下に対して指示する関係になり、逆に、図の下から上に対して報告する関係を表現します。

画像
図:体制図における役割と指示系統

ポイント①:下位メンバーは1人の上位メンバーから指示を受ける形で記載する

指示系統を明確するため、下位メンバーは1人の上位メンバーから指示を受ける体制とします。下図の「悪い例」のように、複数の上位メンバーから指示系統があると、下位メンバーは誰の指示に従えばよいかわからず、混乱が生じます。「悪い例」にならないよう、意識して作成しましょう。

画像
図:体制図のよい例と悪い例

💡Tips!:下位メンバーが複数の上位メンバーから指示を受けないといけないケースはどうする?
実際のプロジェクトで下位メンバーの役割範囲が大きく、複数の上位メンバーから指示を受けないといけないケースがあります。その場合、下記図に示す「after」のように、下位メンバーの役割を分割し、指示系統を体制図に記載します。
そのように記載することで、複数の役割を兼務する下記メンバーが作業ごとにどの上位メンバーの指示に従うべきかが明確になり、指示系統が混乱することを防ぎます。また、他メンバーから相談や依頼が必要となった場合、体制図を参照することで依頼先が明確となります。

画像
図:複数の上位メンバーから指示を受ける場合の体制図

ポイント②:必要な役割をもれなく記載する

体制図の役割にもれがあると、責任範囲の曖昧さが発生し、プロジェクト運営に混乱が生じます。
プロジェクトに必要な役割をもれなく記載するために筆者が意識していることは、以下2点となります。
①プロジェクトで設定すべき基本的な役割を記載する
②プロジェクトの判断・調整を行う上で必要な役割を追記する

①プロジェクトで設定すべき基本的な役割を記載する

プロジェクトで設定すべき基本的な役割は下記となります。当該役割は体制図に記載するようにしましょう。

  • プロジェクト責任者(プロジェクトオーナー)
    人、時間(スケジュール)、予算といった経営資源をプロジェクトに投入することを判断する役割を持ちます。

  • プロジェクトマネージャー(PM)
    プロジェクト全体を管理し、プロジェクトの品質、コスト、進捗(QCD)管理を行う役割を持ちます。ステークホルダー間の調整やプロジェクトルールの策定、管理を行います。

  • プロジェクトリーダー(PL)※大規模プロジェクトの場合
    プロジェクトの一部領域に対して、QCD管理を行う役割を持ちます。当該役割は数十人を超える大規模プロジェクトで、プロジェクトマネージャー1人ではQCD管理が難しい場合に設定します。
    例えば、ITプロジェクトでは、基幹システム刷新などで機能別のサブシステムに分割して開発を行う場合、サブシステムのQCD管理を行う役割として設定します。

  • チームリーダー(TL)、サブチームリーダー(STL)
    プロジェクト実作業の管理、推進を行い、現場の作業状況を管理する役割を持ちます。大規模プロジェクトでは、チーム単位での作業範囲が大きくなるため、担当者との間にサブチームリーダーを設定し、役割を細分化します。
    例えば、ITプロジェクトでは、AP開発チーム、インフラ構築チームのリーダーなどが該当します。

  • 担当者
    現場で具体的な作業をする役割を持ちます。

②プロジェクトの判断・調整を行う上で必要な役割を追記する

プロジェクトの判断・調整を行う上で、基本的な役割以外にプロジェクト特有の状況に合わせて必要な役割があれば、追記します。
例えば、大規模プロジェクトの場合、ステークホルダー間での調整役(ユーザ部門/IT部門間の調整)やPMO(プロジェクト内のルール作成、管理役)などのプロジェクトマネージャーを支援する役割の追加を検討しましょう。

💡Tips!:役割分担の整理は体制図だけで大丈夫?
メンバーが初顔合せのプロジェクトであったり、関係者が多い大規模プロジェクトでは、チーム間、メンバ間で認識ずれの可能性が高いため、体制図に加えてタスクレベルでの役割分担を整理できるRASICチャートを作成するのがよいでしょう。
詳細は現場で使える!RASICチャート【PMの道具箱 #1】|現場で使える!コンサル道具箱 (note.com)を参照ください。

ポイント➂:一目で理解できる情報量とする

チームの役割や他チームの役割を一目で理解できる情報量で記載します。
階層が深すぎたり、メンバーが多すぎる体制図はわかりにくいため、1つの体制図で3~5階層、体制図ボックスも最大20個程度で表現するのが望ましいと筆者は考えます。
メンバー全員を1つの体制図に記載するのが難しい大規模プロジェクトでは、全体体制図としてチーム単位で、チームリーダー(TL)までの記載にとどめ、チーム体制図は必要に応じて、別途作成するのがよいでしょう。

画像
図:大規模プロジェクトにおける体制図分割イメージ

ポイント④:発注者/受注者の上位層を横並びで記載する

ITプロジェクトで、ユーザ企業がSIerなどを外注するケースの場合、発注者/受注者双方の役割を体制図に記載します。
また、プロジェクト上位層(プロジェクト責任者、プロジェクトマネージャー)を横並びで記載し、指示系統とは別にコミュニケーションパス(カウンターパート)として、点線の矢印で結びます。
プロジェクトへの影響度が大きい問題(プロジェクト終了時期の変更やコスト追加など)が発生した場合、同じレベルで調整・判断できるプロジェクト上位層が誰なのか明確にしておくことで、調整・判断を遅らせることなく問題解決が図ることができます。

画像
図:受注者/発注者を含めた体制図

ポイント⑤:適切なタイミングで見直しをする

体制図は1度作成したら終わりではありません。プロジェクト実行時、適宜見直しが必要です。見直しは以下で行うことが一般的です。

  • 作業が大きく変化するタイミング
    スケジュール上で、作業が大きく変化するタイミングでは必要な役割が変わるため見直しを実施します。例えば、開発フェーズが変わるタイミングでは体制を見直すことが一般的です。

  • 問題解決のために体制変更が必要と判断したタイミング
    プロジェクト状況と体制が整合せず、体制に起因する問題が頻発する場合、体制見直しが必要です。
    例えば、以下のような状況となっている場合、体制見直しが必要です。

    • 各チームで作業項目の洗い出しを行った際、自チームで実施すべき作業かの判断ができず、チーム間で作業分担に関する認識合わせが頻発する。

    • 発生した課題について、誰が担当すべきかが決まらず、プロジェクトマネージャーに確認を求める機会が頻発する。

テンプレートとサンプル

テンプレートとサンプルの利用規約はこちらを参照してください。

おわりに

プロジェクト体制図の作成ポイントについて記載しました。いかがでしたでしょうか?
プロジェクト体制図作成時に気を付けるポイントが多いと感じた方も多いのではないでしょうか?この記事で気づきを得られ、多くの方のもやもやが少しでも解消できれば嬉しいです。

この「現場で使える!コンサル道具箱」では、その名の通りすぐに現場で使えるコンテンツを無料でご提供している note です。あなたの欲しい道具が探せばあるかも?ぜひ他の記事もご覧ください!

ウルシステムズでは「現場で使える!PM道具箱」でご紹介したコンテンツにまつわる知見・経験豊富なコンサルタントが多数在籍しております。ぜひお気軽にご相談ください。

ピックアップされています

コンサル直伝!PMの道具箱

  • 10本

コメント

コメントするには、 ログイン または 会員登録 をお願いします。
現場で使える!プロジェクト体制図作成のポイント【PMの道具箱 #7】|現場で使える!コンサル道具箱
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1