開発会社から提案書が届いて、その中に体制図が入っていた。名前と役割が並んだ組織図のような図で、なんとなくきちんとして見えるけれど、どこを見て良し悪しを判断すればいいのか分からない。そういう状態で調べている方が多いと思います。
システム開発の体制図を検索すると、書き方や作り方の解説がずらりと出てきます。ただ、そのほとんどは図を作る側であるプロジェクトマネージャーに向けて書かれたものです。発注側が知りたいのは作り方ではなく、出てきた図をそのまま承認していいのかどうかのはずです。
この記事では、体制図に載る役割の一覧と読み方を押さえたうえで、承認する前に確かめておきたい点を発注側の目線で整理します。特に、会社をまたぐ体制図は社内の組織図と同じようには書けません。ここを知らないまま進めると、後から面倒なことになります。
この記事のポイント
- 体制図はこのプロジェクト限定の役割と連絡経路を示した図
- 開発会社側の顔ぶれより先に自社側の欄が埋まっているかを見る
- 会社をまたぐ線は指揮命令ではなく連絡と報告になっている必要がある
- 承認前に兼任と稼働率、再委託、要員交代の3点を確かめる
目次
システム開発の体制図に載る役割と読み方
まずは図に何が書かれているのかを押さえます。役割の名前を覚えることが目的ではなく、この図から自社が読み取るべき情報は何か、という順番で見ていきます。
体制図が示すのは役割と連絡の経路
システム開発の体制図は、そのプロジェクトに関わる人の役割と、誰が誰に報告や連絡をするのかを図にしたものです。会社の組織図と形は似ていますが、性質は違います。組織図が会社の常設の枠組みを示すのに対して、体制図はこのプロジェクトが終われば解散する、期間限定の集まりを示しています。
発注側にとっての体制図の意味は、ひとことで言えば「困ったときに誰へ言えばいいか」が分かることです。仕様を変えたくなった、進みが遅い気がする、現場から質問が来た。そのたびに誰に言えばいいのか分からないと、判断が止まります。図はその宛先を先に決めておくためのものです。
ですから、きれいに描けているかどうかより、次の3つが読み取れるかを見ます。誰がどの役割で入るのか。誰が誰に報告するのか。そして、どこからどこまでが開発会社で、どこからが自社なのか。この3つ目が、社内のプロジェクトでは意識しなくてよかった、外注ならではの部分です。
開発会社側に並ぶ役割と人数
開発会社側の欄には、だいたい次のような役割が並びます。会社によって呼び方は変わりますが、担っている仕事は大きくは変わりません。
| 役割 | 担当する仕事 | 発注側との関わり |
|---|---|---|
| PM（プロジェクトマネージャー） | 全体の進捗、費用、品質の責任を持つ | 窓口になることが多い |
| PL（プロジェクトリーダー） | 担当チームの作業を回す | 仕様の詳細を詰める場に出る |
| SE（システムエンジニア） | 要件を整理して設計に落とす | 要件定義の打ち合わせに出る |
| プログラマ | 設計にもとづいて実装する | 直接やり取りしないことが多い |
| テスト担当 | テストの計画と実施 | 受入テストの前に結果を受け取る |
| インフラ担当 | サーバーやネットワークの構築 | 社内のネットワーク条件を聞かれる |
ここで見てほしいのは、肩書がいくつ並んでいるかではなく、実際に手を動かす人が何人いるかです。役割名だけが立派に並んでいて、実装とテストを担当する人数が極端に少ない図は、期間の見立てが甘い可能性があります。
もうひとつ、体制図の形は開発の進め方によっても変わります。工程を順番に進めるやり方なら、設計の時期と実装の時期で並ぶ人が入れ替わります。繰り返しながら作るやり方なら、少人数のチームが最初から最後まで同じ顔ぶれで並びます。図を見て人の入れ替わりが多いと感じたら、それが進め方によるものなのかを確かめておくと安心です。
発注側の欄に置く3つの役割
提案に付いてくる体制図は、開発会社側だけが細かく書かれていて、自社側が「お客様」の一箱で終わっていることがよくあります。私の感覚では、ここが空白のまま進んだプロジェクトほど、後半で判断が止まります。
発注側に必要なのは、次の3つの役割です。予算と仕様の最終判断をする人。現場の業務を答えられる人。日々のやり取りをする窓口。この3つが誰なのかを、体制図の自社側の欄に書き込んでもらいます。
3つを1人が兼ねること自体は、小さな会社ならよくあります。問題になりやすいのは、判断する人だけが別で、しかも会議に出てこない形です。窓口が持ち帰るたびに一週間止まる、という状態はここから生まれます。逆に、業務を答えられる人と窓口を同じ人が兼ねるのは、実務上はうまく回ることが多いです。役割ごとに誰を置くかの決め方や、発注後に何を管理するかはシステム開発の外注管理で発注者がすべきことで詳しく整理しています。
兼任と稼働率は注記まで見る
体制図で見落としやすいのが、名前の横に小さく書かれた稼働率です。「PM 30%」と書かれていれば、その人はこのプロジェクトに週1.5日しか入りません。他の案件と掛け持ちしているということです。
掛け持ち自体は珍しくありませんし、それだけで悪いわけでもありません。確かめたいのは、その稼働率で見積もりの工数と計算が合うかどうかです。人数と稼働率と期間を掛け合わせた数字が、見積書に書かれた工数とかけ離れているなら、どちらかが実態と違います。
同じ人が図の複数の場所に出てくる場合も同じです。記載ミスなのか、本当に兼任しているのかが図から読み取れないと、後で「その人は別の作業に入っていた」という話になります。注記があるか、なければ口頭で確認して議事録に残しておきます。
複数社から提案を受け取っている段階なら、体制の条件を同じ軸で並べておくと各社の差が見えます。ベンダー選定比較表テンプレートには体制や実績を含む比較項目が入っているので、体制図を見る観点を揃えるのに使えます。
システム開発の体制図を承認する前の確認点
ここからは、図を見て承認していいかを決める段階の話です。上位に出てくる解説記事の多くは作り方で終わっているので、この部分は自分で確かめる必要があります。
発注側から直接指示する線は引かない
社内のプロジェクトなら、体制図の線は上から下への指揮命令で構いません。ところが発注側と開発会社は別の会社なので、同じ書き方はできません。請負や準委任で頼んでいる場合、開発会社のメンバーに指示を出す権限を持っているのは、発注側ではなく開発会社側だからです。
この線引きは、思っているより厳しく見られます。厚生労働省の労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集では、発注者が請負事業主つまり会社に対してやり直しや作業工程の見直しを求めるのは問題ないとされています。一方で、発注者が直接メンバーに作業の指示を出した場合は、直接の指揮命令にあたり偽装請負と判断される、と明記されています。仕様の軽微な変更を直接伝える場合も同じ扱いです。
この考え方がシステム開発にも当てはまるのかは、以前は判断が分かれていました。厚生労働省は令和3年5月13日の事務連絡で、該当する項目の考え方はシステム開発を請負業務とする場合にも当てはまる、と回答しています。国が名指しで整理している論点だということです。
実務に落とすと、体制図の見方はこうなります。自社の窓口から線が伸びる先は、開発会社の窓口役ただ1人になっているか。図の上で自社の担当者から相手の実装担当へ直接線が引かれていたら、その運用は避けたほうが無難です。また、開発会社側の作業者が1人しかいなくてその人が窓口も兼ねている体制は、事実上こちらの依頼がそのまま本人への指示になるため、疑義応答集でも問題があるとされています。契約の形ごとに指揮命令が誰にあるかは受託開発と派遣・業務委託・客先常駐の違いで整理しているので、自社の契約がどれに当たるかと合わせて確認してください。
図に出てこない会社が作業していないか
体制図に並んでいる名前が、全員その会社の社員とは限りません。協力会社のメンバーが自社の社員と同じ書き方で並んでいることは、実際にあります。悪意があるとも限らず、そういう書き方が慣習になっている会社もあります。
確かめ方は単純で、それぞれの欄に所属会社を書いてもらうだけです。正直な会社は「この工程は自社、この部分は長く組んでいる協力会社」とその場で説明してくれます。言葉を濁されたときは、契約書で再委託の可否と範囲をどう決めるかまで踏み込んで話す必要があります。
再委託そのものが悪いわけではありません。問題になるのは、どこまで再委託されているかを発注側が把握できていない状態です。見抜き方と契約での止め方は受託開発の多重下請けと丸投げを見抜く確認点にまとめています。
契約後の要員交代を先に決めておく
提案のときに紹介されたPMが、契約後もそのまま入るとは限りません。提案には経験豊富な人を立てて、着手後に別の人へ引き継ぐ、という進み方は残念ながらあります。
これを完全に防ぐ方法はありませんが、交代の手続きを先に決めておくことはできます。主要な担当者を交代させるときは事前に通知すること、引き継ぎ期間を設けること、後任の経歴を提示すること。この3つを契約書か議事録に残しておけば、黙って人が入れ替わる事態は避けやすくなります。
体制図を承認する前に確かめる4点
- 自社側の欄に判断する人・業務を答える人・窓口が書かれているか
- 稼働率と人数が見積もりの工数と計算上つながるか
- 各欄に所属会社が書かれ、再委託の範囲が説明されているか
- 主要な担当者を交代するときの通知と引き継ぎが決まっているか
システム開発の体制図についてよくある質問
- Q. 体制図は誰が作るのですか？
- A. 開発会社側のプロジェクトマネージャーが作るのが一般的で、提案書か契約後のキックオフ資料に含まれます。ただし自社側の欄を埋められるのは自社だけなので、そこは発注側が誰を置くかを決めて伝えることになります。出てきた図をそのまま受け取るのではなく、自社側を書き足してもらう前提で見てください。
- Q. 体制図に個人名は必要ですか？
- A. 少なくとも主要な担当者は個人名まで入っているほうが安心です。役割名だけの図でも進められますが、その場合は誰が入るか決まっていないか、決まっていても交代する前提のことがあります。全員分が難しくても、PMと自社の窓口が話す相手は名前で確認しておきたいところです。
- Q. 提案段階で体制図が出てこない場合はどうすればいいですか？
- A. 出してもらうよう依頼して構いません。金額と機能だけの提案書は珍しくありませんが、体制が書けないのは要員の目処が立っていない可能性があります。着手時期をずらせば出せるのか、受注してから集めるつもりなのかで、意味がまったく変わります。
- Q. 発注側の担当は何人必要ですか？
- A. 決まった人数はありませんが、判断する人と現場を答えられる人が別々に必要になる場面は必ず来ます。1人体制でも小規模なら回りますが、その1人が休んだ日に開発が止まる構造になっていないかは見ておいてください。
