プロジェクト要員計画の立て方｜失敗しない人数算出とアサインのコツ
「プロマネを任されたけれど、具体的にどう要員を計画すればいいかわからない」
「プロジェクトの途中で主要メンバーが抜けてしまい、いつもリソース調整に追われている」
システム開発のプロジェクトマネージャー（PM）にとって、要員計画は「誰を、いつ、何人集めるか」という最重要ミッションです。現場で頻発するリソース不足やスキルミスマッチといったトラブルの多くは、初期段階で「いつまでに・何が必要か」をどこまで具体化できていたか、という計画の解像度に起因しています。
要員計画の目的は、単なる人数合わせではなく、プロジェクト終了まで最適な体制を維持するための「確かな指針」を描くことです。今回は、要員計画の基本から具体的な立て方のコツまで、現場目線でわかりやすく解説します。
なぜ「要員計画」がプロジェクトの成否を分けるのか
プロジェクトの規模によっては自社のメンバーだけで完結する場合もあれば、外部パートナー企業に協力を仰ぐこともあります。
要員計画とは、プロジェクトの各工程において「どのようなスキルを持った人が」「いつ」「どれくらい」必要なのかを定義し、確保するための計画です。
「体制図」があるだけでは不十分な理由
プロジェクト計画では必ず「体制図」を作成します。体制図の目的は、ステークホルダー全員の名前を列挙し、責任の所在と報告ラインを明確にすることです。 しかし、体制図はあくまで特定の時点における「静的」な組織図に過ぎません。
これに対し要員計画は、プロジェクトの開始から終了まで、工程の進みに合わせて人数や役割を「入れ替え、変化させていく」ための管理です。「来月、急に忙しくなるのに人が足りない！」という事態を防ぐためには、体制図以上にこの「時間の経過に伴う変化」を捉えることが重要になります。
理想的な「山形」の推移を描く
一般的なウォーターフォール型のシステム開発では、要員数は「山形」の推移を辿るのが理想です。
- 要件定義・設計（立ち上がり）: 業務知識に明るい少数の精鋭メンバーでスタート。
- 開発・単体テスト（ピーク）: 実装ボリュームに合わせて要員数が最大化。
- 結合・システムテスト（収束）: 不具合修正の収束に合わせ、順次リリース。
- 移行・運用フォロー（保守へ）: 最小限の体制で引き継ぎ。
この「山」の形をあらかじめイメージしておくことで、急な増員による教育コストの発生や、逆にリリース直前の「人余り」によるコストの無駄遣いを防ぐことができます。
実践！現場で使える「必要人数」の導き出し方
では、各工程で具体的に何人のメンバーが必要になるのでしょうか。ここでは、どんぶり勘定にならないためのステップを紹介します。
ステップ1：開発規模の見積もり
まずはプロジェクトの全体規模を算出します。 RFP（提案依頼書）や要件定義書をもとに、自社の標準的な手法（ファンクションポイント法や類推見積もりなど）を用いて「総工数（人月）」を導き出します。ここで「根拠のある数字」を持つことが、後の増員交渉でも重要になります。
※具体的な見積方法の詳細は、別記事「システム開発で見積もり失敗を防ぐ5つの要因と根拠ある算出方法」で詳しく解説していますので、あわせて参考にしてください。
ステップ2：工程比率から各工程の工数を割り振る
全体の工数が出たら、次にそれを各工程に割り振ります。 自社の過去実績や、IPAの「ソフトウェア開発データ白書」などの統計値を参考に、工程別の比率を算出します。
| 工程 | 要件定義 | 概要設計 | 詳細設計 | 開発・単体 | 結合テスト | システムテスト | 合計 |
|---|---|---|---|---|---|---|---|
| 工程比率（例） | 6% | 12% | 14% | 43% | 8% | 17% | 100% |
| 工数（人月） | 14.4 | 28.8 | 33.6 | 103.2 | 19.2 | 40.8 | 240.0 |
ステップ3：期間・稼働率・生産性を考慮して人数に変換する
算出した「人月」を「期間」で割り、必要な「人数」を求めます。 例えば、開発・単体テストが103.2人月で、期間が4ヶ月なら、単純計算では1ヶ月あたり約26名です。
しかし、実務では以下の「補正」が必要です。
- 稼働率の考慮: メンバーが他案件と兼務している場合、1人を「0.5人」とカウントする必要があります。
- 立ち上がりコスト: 工程の途中で追加されたメンバーは、仕様理解のために最初の2週間は生産性が落ちます。また、教育にあたる既存メンバーの工数も削られるため、計算上の人数より「＋1〜2名」の余裕を持たせるのが現実的です。
- バッファの確保: 全員が100%の力を出せるわけではなく、急な欠勤や予期せぬ不具合も発生します。5〜10%程度の余力を加味してアサインを確定させましょう。
スキル不足で炎上させない！「適材適所」のアサイン術
「人数」が揃えばいいというわけではありません。工程ごとに求められる「専門性」を無視すると、後で手戻りが発生します。
- 上流工程（要件定義・設計）: 顧客の抽象的な要望を整理し、システム仕様へ具体化する「要件定義スキル」が必須です。また、顧客のビジネスを理解する「業務知識」が不足していると、後で致命的な仕様漏れに繋がります。
- 下流工程（開発・テスト）: 高い「実装スキル」はもちろん、不具合を単に直すだけでなく、他に影響がないかを確認する「影響調査スキル」が求められます。テストにおいても、仕様書の裏を読み取って隠れたバグを見つける「テスタースキル」が重要です。
- 共通スキル（チーム力）: 意外と軽視できないのが「コミュニケーションの質」です。単に話せることではなく、不明点を曖昧にせず確認し、リスクを早期に共有できる誠実さが、計画通りの遂行を支えます。
専門チームと「スポット参画」の考慮
特に注意したいのが、DB設計やインフラ（サーバー・ネットワーク）といった「基盤技術者」の確保です。 これらは開発メンバーが兼務するには荷が重く、専門のスキルが必要です。また、彼らは全期間ではなく「環境構築時」や「移行時」など、特定の期間のみ集中的に必要になる「スポット参画」の形をとることが多いため、工数配分には工夫が必要です。
さらに、近年ではセキュリティ対策やクラウド環境での自動化・運用改善を専門とする「SRE（サイト信頼性エンジニア）」といった枠も、初期段階で予算と要員を確保しておかなければ、リリース直前のボトルネックになりかねません。
攻めと守りの「アサイン・リリース管理」
プロジェクトが順調に進むかどうかは、実は「早めの調整」という泥臭い動きにかかっています。
1〜2ヶ月先の「予約」が現場の常識
工程が進むにつれて必要な人数は増えていきます。直前になって「来週から5人追加」と依頼しても、優秀なエンジニアほど他のプロジェクトで引く手あまたです。 自社内やパートナー企業に対し、少なくとも1〜2ヶ月先を見越した要員計画を共有し、「内諾（予約）」をもらっておく姿勢が、現場を混乱させないための鉄則です。
意外と盲点な「リリース（撤退）」の計画
アサインと同じくらい重要なのが、役割を終えた要員の「リリース計画」です。 特に外部パートナーとの契約では、終了の1ヶ月以上前に通知が必要なケースがほとんどです。
「テストが長引いて人が返せない」という延期はよくありますが、逆に「作業が終わったのに契約期間が残っていて、何もしない人にコストを払い続ける」という事態は絶対に避けなければなりません。 誰を最後まで残し、誰から順に次の現場へ送り出すのか。特に、仕様を熟知しているキーマンのリリース時期は、保守・運用への引き継ぎ期間を十分に考慮して設定しましょう。
まとめ：要員計画は「プロジェクトの品質」を支える土台
プロジェクトマネージャーにとって、要員計画は単なる事務作業ではありません。それは「誰と、どのような旅をするか」を決める、最も重要で戦略的なプロセスです。
あらためて、現場で役立つ要員計画のポイントを振り返りましょう。
- 「変化」への対応: 体制図という固定された「点」ではなく、全工程を通して人数や役割を入れ替えていく「流れ」で捉えること。
- 「現場で生じるロス」の考慮: 理論上の人数だけでなく、稼働率や立ち上がりコストといった「計画通りにいかない現実」を計算に入れること。
- 「一歩先」の調整: 1〜2ヶ月先のアサイン予約と、契約期間を意識した計画的なリリース。
要員計画は一度立てたら終わりではありません。状況の変化に合わせて柔軟に見直し続ける「生きた計画」こそが、チームのパフォーマンスを最大化し、プロジェクトを成功へと導きます。
盤石な要員計画を土台にして、現場のエンジニアが安心して最高のパフォーマンスを発揮できる環境を整えていきましょう。
