プロジェクト体制図は誰がいつ描くもので、どんな役に立つのか

プロジェクトに参加したときに最初に目にするのが、自分の名前が書いてあるプロジェクト体制図です。

プロジェクトの構成やメンバーの名前が分かる便利な図ですが、会社の組織図と同じでそれ以上とくに気に留めなかったかもしれません。

しかし、プロジェクトの勉強をすると、体制図の描き方とか意味についていろいろ書かれています。体制図が悪いと、情報が伝わらなかったり伝わるのに時間がかかったりして、仕事の効率が悪くなるとも注意されます。

この記事では、プロジェクト体制図の意味や描き方の注意点、良し悪しの違いなどを基本から分かりやすく解説しています。

プロジェクト体制図はいつ作るの？

プロジェクトに参加したときにキックオフ会議で説明されるプロジェクト体制図は、誰がいつ作ったものなのでしょうか？

• プロジェクト体制図とは
• 体制図作りはプロジェクトマネジャーの最初の仕事
• PMBOKでの体制図の位置づけ

プロジェクト体制図とは

サラリーマンなら一度は「会社の組織図」を見たことがあると思います。

それを見ると「オレのボスは誰で、ボスのボスは誰で、そのまたボスが誰か」が分かります。

自分が所属する部署以外にどんな部署があるのかも、やっていることはよく分からないにしても、分かります。

プロジェクト体制図も会社の組織図と似ていますが、プロジェクトは臨時の組織ですからボスの名前が変わっています。個人名も末端まで具体的に書かれているのも違う点です。

臨時の新しい組織であるがゆえに、メンバーの所属チームや指揮系統を明らかにするために作られるのがプロジェクト体制図です。

体制図作りはプロジェクトマネジャーの最初の仕事

プロジェクト体制図は、プロジェクトの目的とゴール（達成すべき品質）が決まったときに、プロジェクト計画の初期段階から作り始めます。

作るのはプロジェクトマネジャー（PM）です。

目的とゴールが決まれば、仕事の範囲（スコープ）のおおよそが見えてくるので、必要なワーキンググループと調達すべき人材も見えてきます。そのグループと人材を書きだして図にしたものが体制図です。

したがって、体制図はスコープ計画を作りながら、必要な機能（グループ）や人材を想定し、足したり削ったりしながら作っていく「計画立案との並行作業」になります。

PMBOKでの体制図の位置づけ

PMBOKの10の知識エリアでいうと、プロジェクト体制図は「人的資源マネジメント」エリアの「人的資源計画」にあたります。

何についてもたいそうな用語で説明するPMBOKなので、人的資源マネジメントは、まず人的資源マネジメント計画を立てて、プロジェクト・チーム編成⇒プロジェクト・チーム育成
⇒プロジェクト・チーム・マネジメントというプロセスで行なうとしています。

このプロセスは言い換えると、先ほど述べたPMのプロジェクト立ち上げ時の頭の中のプロセスです。

プロジェクト体制図は何のために作るの？

プロジェクト体制を図にして「可視化」すると、どんなメリットがあるのでしょうか？

• 立ち上げのときの関係者の理解を助ける
• 良い体制図と悪い体制図
• 体制図にあまり多くを求めない

立ち上げのときの関係者の理解を助ける

プロジェクトに必要なグループや人材は箇条書きのリストより図の方が、全体が一目で見渡せ、プロジェクトの構造（各要素の関係性）も理解しやすくなります。

このような体制図は、PMがプロジェクト計画を立てるときの頭の整理に役立ち、キックオフ会議で提示することでチームメンバーや関係者のプロジェクトへの理解を助けてくれます。

体制図の役割は上記のようなシンプルなものですが、「体制図が悪いとプロジェクトの進行でトラブルが生じる」という人もいます。

それはどんなトラブルで、体制図を作るときにどんなことを注意したら良いのでしようか？

良い体制図と悪い体制図

「進行がぎくしゃくしているプロジェクトは体制に問題がある場合があり、それは体制図を見るとすぐに分かる」という記事を読んで興味を持って読み進めると、その体制（図）とは「プロジェクト責任者が2人いた」というものでした。

そりゃそうだろう、という気がしないでもありませんが、ステークホルダーが多くお互いの立場がややこしいプロジェクトでは、いろいろ気をつかって体制を考えるうち、気がついたら責任者が2人いた、なんてことがあるのかもしれません。

これは体制図の問題というより、そもそも体制づくりに問題があったわけです。

またある人は、体制図にあるグループ名の付け方を注意しています。

例えば「支援チーム」というような漠然とした名称だと、何を支援するのかが分からず人によって支援チームに求めることが違ってくるというのです。

確かにグループ名はできるだけその仕事内容が分かるように具体的につけるべきでしょう。しかし「図」にあまり長々とは書けないので、最初の補足説明でチーム内の了解を取っておけば誤解を防げそうです。

ただし、そもそも「支援チーム」の概念があいまいだった場合は補足説明もあいまいになり、やはり体制そのものの問題になります。

このように「悪い体制図」の原因が「悪い体制」にある場合があります。

PMは体制図を作るときにどこかしっくりこないときは、体制そのものを見直してみる必要があります。

体制図にあまり多くを求めない

プロジェクトのような特別な業務、臨時の組織は、図にしてみないと情報の流れや責任範囲がよく分からない、といわれます。

しかし、体制図で「情報の流れ」や「責任の範囲」がどこまで分かるのでしょうか？

「情報・指示・報告は図の線に従って流れる」といいますが、体制図といういわば「配管」の中にきっちり納まらない情報の流れもあるはずです。

「一目でわかる」ことが趣旨の体制図に、あまり機能的な役割を期待するのは無理があります。

プロジェクト体制図が役に立つのはどんなとき？

プロジェクト体制図は具体的にどんな場面で約に立つのでしょうか？

• PMがプロジェクト計画の構想をまとめるとき
• キックオフ会議で関係者に説明するとき
• 体制図を作ることで情報の抜けを防げる？
• 体制に変更が生じたときに、それを周知させる

PMがプロジェクト計画の構想をまとめるとき

プロジェクト体制図を描くのがPMの初期段階の仕事であることから分かるように、体制図を描くというのは、決まっている体制や人員のリストを図にすることではなく、「このプロジェクトはどんな体制が必要か」を構想することです。

プロジェクト計画書の作成と平行してその構想を固めていき、計画書が経営上層部とクライアントに承認されたときに、プロジェクトスタート時点での体制図もできあがります。

キックオフ会議で関係者に説明するとき

描きあげた体制図が最初に役に立つのが、キックオフ会議です。

PMは、会議に参加した関係者に体制図を使って、チームの編成やメンバーの割り振りを示し、各チームやセクションの任務を説明します。

説明を聞く出席者は、まず自分の名前が体制図のどこにあるかを見て、自分の業務がプロジェクト全体のどこに位置付けられているかを確認します。

体制図を作ることで情報の抜けを防げる？

体制図を作ることで、トラブルの原因になる「情報の抜けや滞留」を防げる、ともいわれています。

たしかに、可視化された図を確認することで「この情報はどこに届けるべきか」を忘れたり勘違いしたりすることは少なくなるかもしれません。しかし、1枚の図でどこまでその役目を果たせるかは疑問です。

この点で筆者が納得できたのは、「東からの放浪者」というフリーランス・プログラマーのブログの次のような考えでした。

「情報の抜け・漏れを抑えるには「図」を描くべきだ」とまで言えるのでしょうか。体制図は、コンタクト・パーソンも明確にしてくれます。しかし、次の図をみれば分かりますが、情報経路をすべて示してくれるわけではありません。

上の図で、アプリケーション設計者とソフトウェアＱＡ担当者は、お互いリーダを通してやり取りを行うのか？というと、それは非現実的です。外注先との連絡も、すべて事務局を通していたのでは時間がかかりすぎます。コミュニケーション方法の確立は、別途行う必要があります」

引用元:「体制図の意味｜東からの放浪者」
※強調は引用者

体制図はたしかにプロジェクトの構成を可視化してくれますが、それで情報の流通経路が明確になるほど雄弁ではありません。

体制に変更が生じたときに、それを周知させる

プロジェクトは進行の途中で新しいワークチームが必要になるなど、体制が変更されることがあります。

その際にメンバー全員に変更点を周知させるのに「一目でわかる」体制図はとても便利です。

プロジェクト体制図　まとめ

プロジェクト体制図は、PMが与えられた課題を達成するためにどのような体制が良いかを構想するときに、必ず描かなければいけないものです。

キックオフ会議で関係者にプロジェクトの概要を説明する時にも、体制図は必須です。

プロジェクトがスタートしたら体制図の出番はそれほどありませんが、メンバーがときどき見直して自分の立ち位置を確認するのはわるいことではありません。