ITエンジニアや社員のスキル管理ツールfapi（ファピー）を提供する株式会社エフ・ディー・シーのDXサービス事業推進部 佐々木舞美が、200名以上のITエンジニアのアサインに25年以上携わってきた経験から「プロジェクトのチーム構成」を解説します。
プロジェクトの成否は、始まる前のチーム構成でほぼ決まります。進行のスムーズさも成果物の品質も、誰をどの役割に置くかで大きく変わるからです。
この記事では、プロジェクトチームの構成要素と各役割、体制図の作り方、チームを編成する5つの手順、成功のポイントと注意点を整理しました。「毎回なんとなくメンバーを集めている」「構成の根拠を説明できない」という方は参考にしてください。
プロジェクトチームとは
プロジェクトチームとは、特定の目的を期限内に達成するために、社内外から必要な人材を集めて編成する一時的な組織です。チームを構成する一人ひとりをプロジェクトメンバーと呼びます。
部署のような常設組織と違い、プロジェクトチームは「目的を達成したら解散する」ことが前提です。そのため、目的に対して必要なスキルと人数を過不足なく揃えることが、構成の出発点になります。
システム開発では、数か月から数年の期間で、要件定義・設計・開発・テストといった工程ごとに必要な人材が変わります。構成は一度決めて終わりではなく、工程に合わせて見直すものだと考えてください。
プロジェクトチームを構成するメリット
既存の部署で対応するのではなく、プロジェクト専用のチームを組むメリットは次の3つです。
| メリット | 内容 |
|---|---|
| 目的に最適な人材を集められる | 部署の枠を越えて、必要なスキルを持つ人だけを招集できる。新規アプリ開発なら、ゼロから設計できるエンジニアだけでチームを組める |
| 意思決定と連携が速い | 目的を共有したメンバーだけで構成されるため、確認や調整の手数が少なく、コミュニケーションが取りやすい |
| 仕様変更に対応しやすい | チームのリソースをそのプロジェクトに集中させているため、顧客からの急な要望変更にも対応しやすい |
プロジェクトチームの構成要素と各役割
システム開発のプロジェクトチームは、一般に次の役割で構成されます。
| 役割 | 担当すること | 求められる力 |
|---|---|---|
| プロジェクトマネージャー（PM） | プロジェクト全体の責任者。計画の策定、QCD（品質・コスト・納期）の管理、顧客や経営層との折衝 | 全体を見る力、交渉力、リスク判断 |
| プロジェクトリーダー（PL） | 現場のリーダー。工程ごとにメンバーへ指示を出し、進捗を管理しながら自らも実務を担当 | 技術力、現場の調整力 |
| プロジェクトメンバー | 設計・開発・テストなど、割り当てられたタスクを実行。チームの大半を占める | 担当領域の専門スキル、報告・連携の姿勢 |
| PMO（必要に応じて） | PMを支援し、進捗や品質の標準化、会議体の運営、資料作成を担当 | 管理手法の知識、調整力 |
PMとPLの違いは「何に責任を持つか」です。PMはプロジェクト全体の結果に、PLは担当工程が計画どおりに進むことに責任を持ちます。小規模なプロジェクトではPMがPLを兼ねることも珍しくありません。
プロジェクト体制図の作り方
役割を決めたら、誰が誰に報告し、誰が判断するのかを体制図にまとめます。体制図が曖昧だと「誰に確認すればよいか分からない」という状態が生まれ、確認待ちで作業が止まります。
体制図は、上から「顧客・経営層 → PM → PL → メンバー」の順に階層を置き、各階層に役割名・担当者名・所属を書くのが基本形です。表にすると次のようになります。
| 階層 | 役割 | 担当者（例） | 報告先 |
|---|---|---|---|
| 1 | プロジェクトオーナー（顧客・経営層） | ○○部長 | — |
| 2 | プロジェクトマネージャー | A（自社） | プロジェクトオーナー |
| 3 | プロジェクトリーダー（設計・開発） | B（自社） | PM |
| 3 | プロジェクトリーダー（テスト） | C（協力会社） | PM |
| 4 | 開発メンバー | D・E・F（自社2名＋協力会社1名） | 設計・開発PL |
| 4 | テストメンバー | G・H（協力会社） | テストPL |
体制図を作るときのポイントは4つです。指揮系統を一本化する（1人のメンバーに複数の上長を置かない）、役割分担を明記する、変更があったらすぐ更新する、顧客を含めて誰が見ても分かる形にする、です。
プロジェクトチームを編成する5つの手順
チームの編成は、計画→必要スキルの洗い出し→体制図→人選→タスク割り当ての順で進めます。
1. プロジェクト計画を固める
PMが中心となり、プロジェクトの目的・目標、スケジュール、主要タスク、QCDの基準を明確にします。ここが曖昧なまま人を集めると、後から「このスキルの人が足りない」が必ず起こります。
2. 工程ごとに必要なスキルと人数を洗い出す
計画をもとに、要件定義・設計・開発・テストの各工程で「どのスキルを持つ人が・何人・いつからいつまで」必要かを一覧にします。
| 工程 | 必要なスキル（例） | 人数・期間（例） |
|---|---|---|
| 要件定義 | 業務知識、顧客折衝、ドキュメント作成 | PM1名＋上流経験者1〜2名、1〜2か月 |
| 設計 | アーキテクチャ設計、DB設計 | PL1名＋設計担当2名、1〜2か月 |
| 開発 | 該当言語・フレームワークの実装経験 | 開発者3〜5名、3〜4か月 |
| テスト | テスト設計、自動テスト | テスト担当2名、1か月 |
この表があるかどうかで、次の人選の精度が決まります。人数だけでなく「期間」まで書いておくと、他プロジェクトとの掛け持ちや空き状況の調整がしやすくなります。
3. 体制図に役割の箱を置く
洗い出した役割を、前章の形式でPM・PL・メンバーの指揮系統に沿って体制図に落とします。この時点では担当者名は空欄で、「役割の箱」だけで構いません。
4. 体制図の箱に人を当てはめる（アサイン）
各役割に対して、スキル・経験・稼働状況の3つを見て人を割り当てます。候補者のスキルと空き状況が一覧で見える状態になっていないと、ここで最も時間がかかります。
人選で見るべきポイントの詳細は、以下の記事で解説しています。
5. タスクを割り振り、キックオフで共有する
体制図に沿って各メンバーにタスクを割り振り、キックオフで目的・体制・スケジュールを全員に共有します。誰が何を担当しているかを全員が知っていれば、トラブル時の協力がスムーズになります。
チーム構成でプロジェクトを成功させる5つのポイント
| ポイント | 具体的にやること |
|---|---|
| 1. 部門を越えて人を集める | 自部署の手が空いている人ではなく、必要なスキルを持つ人を他部署からも招集する。日頃から全社のスキルを把握しておくことが前提 |
| 2. スキルと稼働で人選する | 「空いているから」ではなく「このスキルが必要だから」で選ぶ。スキルのミスマッチは手戻りと遅延の最大の原因 |
| 3. 認識を揃える場を持つ | 目標や方向性のズレは進行中に広がる。定例やレビューで、PM・PLが意見交換の場を設ける |
| 4. 経営層の支援を取り付ける | 他部署への協力依頼やリソースの確保は経営層の後押しが必要。PMは必要なリソースと問題を速やかに報告する |
| 5. 進捗と目的を繰り返し確認する | 進捗を把握しながら目的を再確認し、不明点や問題を放置しない。放置はコストと信頼の両方を失う |
5つのうち1と2は、メンバーのスキルと稼働状況が「見える」状態になっていなければ実行できません。Excelの台帳が部署ごとにバラバラだと、部門を越えた人選は現実的に難しくなります。
チーム構成で注意したいポイント
| 注意点 | 起こること | 対策 |
|---|---|---|
| バッファの取りすぎ | 予備の人員や余裕のある工数を「なんとなく」で積むと、待機コストが膨らみ利益を圧迫する | メンバーの力量と工程ごとの所要時間を把握したうえで、根拠のあるバッファを設定する |
| 納期遅延 | スキルを正確に把握せずに構成すると、想定より作業が進まず遅延する。顧客からの信用に直結する | 一人ひとりのスキルと稼働状況を把握し、トラブル時に交代・補充できる候補を用意しておく |
| 特定メンバーへの依存 | エース級に仕事が集中し、離脱した瞬間にプロジェクトが止まる | 稼働率に上限を設け、体制図で偏りを可視化する |
| 構成の固定化 | 工程が進んでも初期の構成のままで、不要な人員が残る・必要な人が足りない | 工程の切り替わりごとに構成を見直す |
プロジェクトのチーム構成に関するよくある質問
プロジェクトチームの適正人数は何人ですか？
決まった正解はありませんが、1人のリーダーが直接見られるのは5〜8名程度が目安です。それを超える場合は、PLを複数置いてサブチームに分けると指揮系統が崩れにくくなります。
体制図と組織図は何が違いますか？
体制図はプロジェクト内の役割と指揮系統を示す図、組織図は会社全体の部署と役職を示す図です。プロジェクトでは体制図を作り、必要に応じて各メンバーの所属部署を併記します。
チーム構成をExcelで管理する限界はどこですか？
プロジェクトが同時に複数走り、メンバーが数十名を超えると、誰がいつ空くか・どのスキルを持つかをExcelで追うのが難しくなります。その段階で、スキルと稼働状況を一元管理できるアサイン管理ツールの導入を検討するとよいでしょう。
まとめ
プロジェクトのチーム構成は、PM・PL・メンバーの役割を押さえたうえで、計画を固め、工程ごとに必要なスキルと人数を洗い出し、体制図を作ってから人を当てはめる、という順序で進めます。成功のポイントは「空いている人」ではなく「必要なスキルを持つ人」を部門を越えて選ぶことです。
そのためには、メンバーのスキルと稼働状況が常に見える状態が欠かせません。プロジェクトや人数が増えてExcelでの把握に限界を感じたら、アサイン管理ツールの比較から始めてみてください。
