プロジェクト体制図スライドのデザイン例4つ。大型商談に必ず付いているスライドとは？
何故システム開発などのプロジェクトでは「体制図」を作成する必要があるのでしょうか？
非常に残念なことに、最近はアジャイル開発などの名の下に体制図を作りたがらない会社・組織が意外と多いのですが、やはり作成するからにはちゃんとした意味・目的があります。
はじめてパワポで体制図を作成すると面倒だなと思うかもしれませんが、コツをつかめばデザイン自体はかなり簡単です。そして、資料デザインの裏（土台）にあるより大切なこと「体制図を作る目的・狙い」についても解説したいと思います。
1｜プロジェクト体制図が必要な理由
プロジェクト体制図の作成にはたくさんのメリットがあります。
チームメンバーの役割・責任範囲が明確になる
コミュニケーションルートがわかりやすくなる
コミュニケーションが円滑になる
上司にチームメンバーをわかりやすく報告する･･･etc.
ぱっとこれくらいは思いつくでしょうか。
ですが、そもそも何故コミュニケーションを円滑にしたり、メンバーの役割を定義する必要があるのでしょうか？
はっきりいってしまえば、システム開発なんて極論スーパープログラマーが一人で開発すれば、システム自体はできてしまいます。コミュニケーションルートとかわざわざ体制図で言わなくても、どこの会社でも、部長-課長-メンバーくらい決まっていますよ？
もうわかってきましたね？
ITシステム開発におけるプロジェクトの目的は「システムを作る」ということではないのです。
目的はプロジェクトを成功に導くことであり、開発したシステムを（手段として）使うことで、お客様の業務効率や売上がアップすることです。プロジェクト体制図は、プロジェクトを成功させるために作成します。それには、上述のようなチーム・およびチームメンバーのパフォーマンスを向上させるための体制図が必要なのです。
2｜基本のプロジェクト体制図デザイン
少々難しいお話をしましたが、デザイン例はシンプル！こんな感じです。
①指揮系統・ルートは明確に
作成のコツですが、やはり①指揮系統・ルートは明確にしておきましょう。ここではプロジェクト責任者の下に営業とプロジェクトマネージャー（以下、PM）がぶら下がり、PMの下には各チームリーダー（以下、リーダー）がいることがよくわかります。
つまり、「リーダーが相談する先は隣のリーダーではない、PMだ」「PMには、営業業務に関する指揮はない」（※PMの下に営業も紐づく体制を取る会社も稀に存在します）ということが、この資料だけで理解できます。
②すべて正しく書こうとしない
また、多くを詰め込み過ぎないのも作成のコツでしょうか。この例では思い切ってチームメンバーの名前を記載せず「他○○名」と省略して記載しました。何度も言いますが、正しい体制図を書くことが目的ではありません。プロジェクトを成功に導くのが目的です。
3｜より見やすいデザイン例
基本のデザインはすべて同じ色で作成しましたが、役割に応じて色をまとめて整理するとかなり見やすくなります。
図形も丸四角も使い、一気にポップになりましたね。
しかしながら、プロジェクト体制やメンバーはよく変わることがありますので、多少メンテナンスのしやすさが落ちるのがネックです。どちらかというと「組織図」とか「システム部のメンバー紹介」に使えるデザインかもしれません。
また、基本のスライドと比べて、デザインこそ洗練されていますが記載してある中身自体はまったく差がないことに気づきましたでしょうか？
そのため、わざわざ時間と工数をかけて編集するかは、要相談かと思います。すでに社内にプロジェクト体制図のテンプレートが存在する場合も同様ですね。
4｜PMやPLの言葉の定義について
プロジェクトマネージャー、プロジェクトリーダー、プロジェクトマネジメントオフィス、プロジェクト責任者･･･
似たような言葉が多すぎる（笑）違いがわかりにくい！
私自身もそう思いますので、大体の言葉の定義を解説しておきます。
プロジェクト責任者･･･全体の責任者。システムやより上位の全体方針レベルの最終決定・意思決定（おおむね社長・取締役クラス）
プロジェクトマネージャー･･･システム全般や重要事項について、各リーダーからの要件・意思を統合し、意思決定する。プロジェクト全体の計画、進捗、コスト納期コントロールなど重要な役割を担う（おおむね部長クラス）
プロジェクトリーダー･･･部署/業務/役割別のリーダーになることが多く、それぞれの責任範囲における活動を行う（おおむね課長・係長クラス）
正直なところ、この役割（用語）は、会社によってかなり違います。
PMなんて一番ブレがあるのではないでしょうか。
絶対に社長がPMなる会社もあれば、要件定義ができる人はなんとなくPMみたいな会社も存在します。また、大規模な組織では、PMはコスト計画や責任など重要な部分の責を持ち、PLがプロジェクトマネジメントの実務を行っているということもあるようです。
つまるところ実務においては、皆様所属する会社に合わせて言葉を使っていくしかないので、言葉になれていきましょう。
ちなみにIPAにおいては、以下のようにあります。
プロジェクト全体の意思決定を実行し、品質・コスト・納期に全責任をもち、前提・制約の中でプロジェクトを確実に成功に導き、プロジェクトメンバを成長させるマネージャ･･･（以下、省略）
5｜お客様の体制図を記載する
プロジェクトを成功に導くのが目的であれば、（社内プロジェクトでない限り）お客様の側のプロジェクト体制図も書くべきということがすぐに理解できます。
コミュニケーションを最も円滑にする必要があるのは、社内はもちろんですが、一番はクライアントと自社の間のコミュニケーションだからです。
今でも多くのITシステム開発では「お客様がITに慣れていない」「システム開発をはじめて発注する」なんてことは普通にあります。
そんなときは、お客様もいわゆるプロジェクトというものを組んだ経験がないことが多いため、お客様の社内コミュニケーションを円滑にしてあげるためにも体制図を作成します。
資料作成は面倒でも、最終的には「お客様社内でプロジェクト体制が明確になる⇒コミュニケーションが速く円滑になる⇒自社にも早く返答や回答がもらえる」というメリットがあります。
6｜メンバー・プロフィールを付ける理由
IT営業に従事している方で、特に、コンサルティングやエンタープライズ向けのセールスに従事している方は、以下のようなスライドを見たことがあるかもしれません。
このスライドは、セールス段階の提案資料内に入れます。つまり、営業資料の役割です。大型商談・エンタープライズ営業の資料では、必ずプロジェクト体制図とともに記載されています。
プロフィール内容には学歴/職務経歴/資格/プロジェクト経験年数/特許や受賞歴など花々しいものを記載することで、権威・信頼性をアップさせ、システムという目に見えないもの売る上での強力な武器になります。
また、公共入札案件では、プロジェクトマネージャーに資格や経験年数が定められていることがあります。
エンタープライズセールス・コンサルティング業界の方はもちろん、Saasや小型のパッケージの営業をされている方にも、大型商談を狙いたいといった時等に、参考になると思います！
※逆に言えば、クライアントの皆様は簡単に騙されてはいけません。プロフィールに記載するためだけに、顧問を雇用し、実際のプロジェクトではほとんど出てこないなんて企業もたくさん存在します。
（こんなこと話してしまってよいのでしょうか？笑）
7｜PMBOKよりデザイン例
最後にPMBOKのRACIチャートのデザイン（というかそのまま？）です。
詳しくはPMBOKと呼ばれるプロジェクトマネジメントの体系立てされた方法論やRACIチャートでググっていただければと思います。
実務では、社外向けの資料というより、SEシステム部門の社内資料で使われるような資料かと思います。各業務のR（実行責任者）、A（説明責任者）、C（相談先）、I（報告先）を明確にしておくことで、役割がはっきりします。
8｜まとめ
自分で思いますが、今回の記事ってパワーポイントデザインの話ではなく、どちらかというと、プロジェクト体制図の書き方という"業務の"記事ですよね（笑）
デザインだけをシンプルに解説したいと思う一方で、テンプレートだけ配って使いこなせない人もたくさんいますので、解説もしないととも思い･･･少々方向性に悩み中ですが、今後も皆様の参考になれば幸いです。
以上です。最後までお読みいただきありがとうございました。
＜本日の内容＞星3つ★★★☆～星4つ★★★★☆
「職場の資料作成には困らない」 ～「資料作成を得意スキルに、職場で一目置かれる」
※本記事のパワーポイント元ファイルはポケプレから無料でダウンロード可能です。
この記事が気に入ったらサポートをしてみませんか？