以前、複数社しかも５社近くのシステム開発ベンダーやコンサルティング会社が関わったプロジェクトを経験しました。
その時、プロジェクト体制図をいつも通り書こうとしましたが、なかなか表現が難しく、苦戦した思い出があります。
そこで、今回は、複数社が関わるシステム開発プロジェクトにおける体制図の書き方について、その際のポイントや注意点とともにまとめたいと思います。さらに、複数社が示す範囲というのは、プロジェクト全体だけではなく、システムベンダーの中に閉じた体制の中でも同じことが言えます。そこで２種類の体制図についても解説していきます。
スポンサーリンク
プロジェクト体制図の目的
そもそもプロジェクト体制図を書くことの目的を抑えておく必要があります。これは、複数社が関わる場合であっても、１社だけが関わる場合であっても、プロジェクト体制図が果たす目的は同じです。
したがって、プロジェクト体制図の目的さえ、外さなければ、複数社が関わるプロジェクト体制図もポイントを外すことはなく描くことができます。
プロジェクト体制図は次の２つの目的のためにプロジェクトが始まる際に必ず書く必要があります。
- 役割を定義する
- コミュニケーションラインを定義する
スポンサーリンク
目的①役割を定義する
プロジェクトに参画する人たちの役割を定義します。誰がリーダーで、誰がチームリーダーなのかを定義していきます。
体制図を整理することで、プロジェクト全体における役割が整理され、「この課題は誰と検討すればよいか」「誰の責任なのか」ということが明確になります。
役割分担表、役割一覧というそれぞれの役割がどういった仕事の責任を担うポジションなのかを定義するものをプロジェクト体制図とは別に作成することもおすすめです。
目的②コミュニケーションラインを定義する
プロジェクト体制図では、指揮命令系統をはっきりさせることも重要です。
システムベンダー側のリーダーと相対する発注者側のリーダーは誰なのか、また、リーダーの指揮命令の下で動くメンバーは誰なのか、これらを明確にします。
もしコミュニケーションライン、つまりは指揮命令系統が明確でなければ、情報が交錯してしまい、混乱を招きます。プロジェクトメンバーからすれば、AさんとBさんとで言ってることが違うけど、どっちに従えばよいの？と混乱することになってしまいます。
複数社が関わるプロジェクト体制図
私は２種類のプロジェクト体制図を使い分けることをお勧めしています。
１つ目はプロジェクト全体における体制図、２つ目はシステムベンダー内（自社内）の体制図です。前者は対外的な体制図、後者は内部的な体制図となります。
どちらも複数社が関わるという点では同じであり、どちらもプロジェクトを成功に導くためには必要となる重要な体制図となります。
プロジェクト全体の体制図
１つ目は、プロジェクト全体にかかわる体制図です。一般的に、プロジェクト体制図といって思い浮かべるのはこちらかと思います。
複数社が関わる場合のプロジェクト体制図のサンプルは次の通りです。
１つの大きなプロジェクトにおいて、自分達（緑）が開発するシステムとそのシステムと連携をする別システムがあるということをイメージしてください。
重要なことは次の２点です。
- 自分達のプロジェクト体制と相対する発注者側の人は誰か明確か
- 連携先システムのベンダーとコミュニケーション取るためのコミュニケーションラインは整っているか
これら２つが整っていることが複数社が関わるプロジェクト体制図を書くうえでは欠かせません。
例えば、自身がPL（緑）だった場合で、連携先システムとシステム設計について打合せをしたいとなった場合は、まずは自分の上司であるPMにその旨を依頼し、PMから発注者側のPMに掛け合い、発注者側のPMから連携先システムの発注側PMにお願いをし、そこから連携先システムのベンダーであるPMへ、そして、PLへという流れでアポイントを取ることとなります。
勿論これは杓子定規にいった場合です。最初のアポ取りはこのような流れでアポイントを取ることとなり、それ以降は直接（公の場、記録が残る形で）やり取りすることとなります。
このように複数社関わるようなプロジェクトにおいて、プロジェクト全体の体制を俯瞰できる体制図はプロジェクトを円滑に進めるうえで必要不可欠なものとなります。
スポンサーリンク
システムベンダー内の体制図
２つ目はプロジェクトの内部向け体制図となります。
システム開発、特にSIerの場合、ビジネスパートナーBPと呼ばれる会社からエンジニアを提供してもらい、複数社を束ねて１つのプロジェクトとして遂行していきます。
そのため、前述した対外的なプロジェクト体制図も重要ですが、内部的な体制図も同じくらい重要です。
複数社が関わるシステムベンダー内のプロジェクト体制図のサンプルは次の通りです。
このように、システムベンダーといってもその中には、複数のBPが関わっています。もし、内部的なプロジェクト体制図がない場合、やはり責任の所在であったり、指揮命令系統であったりがはっきりしない状態となってしまいます。
内部的なプロジェクト体制図を書く時の注意点は次の２点です。
- BPのリーダーは明確になっているか
- BPのメンバーまでの指揮命令系統は明確か
これらは、コンプライアンスの観点から重要となります。
具体的には、偽装請負になってはいけないということです。偽装請負とは簡単にいえば、システムベンダーからBPのメンバーに対して直接作業指示することであり、これを行うとコンプライアンス違反となります。
偽装請負については詳しくはこちらをご覧ください。
例えば、自身がPL（緑）だった場合で、BP①のメンバーであるAさんに作業指示をしたい場合は、BP①のリーダーを介して指示をしなければいけません。
勿論、実務上、BP①のリーダーから伝言ゲームのようになっていては仕事が進まない点もあると思います。そのため、BP①のリーダーも同席の下で、BP①のメンバーに作業をお願いするといったように、あくまでBP①社に対する作業指示を行いつつ、詳細の仕事内容の説明をメンバーには行うといったようなかたちで進めることとなります。
このように、システム開発においては必ずといってよいですが、複数社が関わります。前述のように連携システムが存在しないようなシステム開発であってもプロジェクトの内部としては１社だけ完結していることはありえません。そのため、コンプライアンス遵守の観点からもプロジェクト体制図は必須ということができます。
スポンサーリンク
まとめ
今回は、プロジェクト体制図について解説しました
特に複数社が関わるプロジェクト体制図について、対外的なプロジェクト体制図と、内部的なプロジェクト体制図の両面を解説しました。
今回の内容が少しでもプロジェクトをうまく進めるためのヒントになれば嬉しいです。
コメント