【実践】要員計画の立て方｜必要人数の算出と現場の罠

「プロマネを任されたけれど、具体的にどう要員を計算すればいいかわからない」
「プロジェクトの途中で主要メンバーが抜けてしまい、いつもリソース調整に追われている」

システム開発において、要員計画は「誰を、いつ、何人集めるか」というプロジェクトマネージャー（PM）の最重要ミッションの一つです。現場で頻発するリソース不足やスキルミスマッチの多くは、初期段階での「計画の解像度（どんぶり勘定）」に起因しています。

この記事では、単なる人数合わせではない、プロジェクトを完走させるための「必要人数の計算ステップ」と、現場で陥りがちなアサインの罠について解説します。

「そもそも要員計画とは何か？」「顧客との役割分担はどうすべきか」といった全体像をおさらいしたい方は、まずは以下の「基礎編」をご覧ください。
【基礎】プロジェクト要員計画｜炎上を防ぐ人員配置と役割分担

体制図は「点」、要員計画は「流れ」である
- 理想の推移：なぜ要員は「山形（ベルカーブ）」を描くのか
- 山積み表（リソースヒストグラム）で「無理・無駄」をチェックする
【実践】どんぶり勘定を防ぐ「必要人数」算出の3ステップ
適材適所を見極める「スキル評価マトリクス」
- 【重要】専門チームの「スポット参画」を忘れない
【プロの視点】現場で陥りやすい「1.0人」の罠
- 「新人＝1.0人」の罠
- 「エース＝1.5人」の罠
PMの最重要ミッション：アサインとリリースの泥臭い管理
まとめ：要員計画はプロジェクトの品質を支える土台

体制図は「点」、要員計画は「流れ」である

プロジェクト計画書に必ず含まれる「体制図」と「要員計画」。この2つの違いを正しく理解しているでしょうか。

体制図（静的）：特定の時点における「組織の形」を示すもの。責任の所在と報告ラインを明確にするのが目的です。
要員計画（動的）：開始から終了まで、時間軸に沿った「要員の入れ替え」を示すもの。リソースの過不足を防ぐための管理図です。

「体制図に名前を並べて満足」してはいけません。プロジェクトは生き物であり、工程の進みに合わせて必要な人数やスキルは常に変化します。この「流れ」を捉えることこそが、要員計画の本質です。

理想の推移：なぜ要員は「山形（ベルカーブ）」を描くのか

一般的なウォーターフォール開発では、要員数は以下のように「山形」の推移を辿るのが理想的です。

要件定義・設計（立ち上がり）：業務知識に明るい少数精鋭でスタート。
開発・単体テスト（ピーク）：実装ボリュームに合わせて要員数を最大化。
結合・システムテスト（収束）：バグ修正の収束に合わせ、順次メンバーをリリース（離脱）。
移行・運用フォロー（保守へ）：最小限の体制へ引き継ぎ。

あらかじめこの「山」の形をイメージしておくことで、急な増員による教育コストの爆発や、リリース直前の「人余り」によるコストの無駄遣いを防ぐことができます。

山積み表（リソースヒストグラム）で「無理・無駄」をチェックする

要員計画を月別・週別のグラフ（山積み表）にした際、以下の3つのポイントで計画の妥当性を判断し、調整を行います。

平準化ライン（リソース・レベリング） グラフ上の目に見えない「チームが無理なく稼働できる基準線」です。PMはこのラインに沿って要員の増減をなだらかに抑えることで、急な採用や教育コストの負担を最適化します。
「山」が高すぎる時期（過負荷） グラフが平準化ラインを大きく突き抜けている場合、メンバーが物理的に対応不可能な業務量を抱えています。作業を前後にずらすか、他チームからのスポット増員が必要です。
「谷」が深い時期（アイドル） グラフが極端に低い時期は、人員の手が空いてしまっています。他プロジェクトへの応援や、次工程の前倒し作業を割り当ててコストの無駄を省きます。

【実践】どんぶり勘定を防ぐ「必要人数」算出の3ステップ

では、各工程で具体的に何人のメンバーが必要になるのでしょうか。感覚値に頼らないための3つのステップを紹介します。

前提：要員計画はフェーズに合わせて「段階的に詳細化」する

大前提として、プロジェクトの初期段階から「完璧な必要人数」は出せません。以下のように、情報が増えるごとに計画をアップデートし、誤差を縮めていくプロセスが重要です。

プロジェクト立ち上げ時【精度：低（±50%程度の誤差）】
過去の類似案件に基づき「概算」で算出。予期せぬトラブルを考慮し、あらかじめリスク（バッファ）を織り込んで予算枠を確保します。
要件定義完了後【精度：中（±15%程度の誤差）】
「何を作るか」が確定し、不透明な部分が減った段階で工数を精査。本格的なアサインを開始します。
設計完了・開発着手時【精度：高（±5%程度の誤差）】
タスクが細かく分解された段階で、個々のメンバーの稼働を確定させます。

この前提を持った上で、以下の計算ステップを進めます。

ステップ1：開発規模の見積もり（総工数の算出）

まずはプロジェクトの全体規模を算出します。RFP（提案依頼書）や要件定義書をもとに、標準的な手法（ファンクションポイント法や類推見積もりなど）を用いて「総工数（人月）」を導き出します。（例：全体で240人月と算出）

ステップ2：工程比率から各工程の工数を割り振る

全体の工数が出たら、次にそれを各工程に割り振ります。自社の過去実績や、IPAの「ソフトウェア開発データ白書」などの統計値を参考に、工程別の比率を算出します。

【工程別の工数割り振り例（全体240人月の場合）】

工程	要件定義	概要設計	詳細設計	開発・単体	結合テスト	システムテスト	合計
工程比率（例）	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名」の余裕を持たせる。
バッファの確保：急な欠勤や予期せぬ不具合に備え、5〜10%程度の余力を加味してアサインを確定させる。

適材適所を見極める「スキル評価マトリクス」

人数が揃えばいいわけではありません。アサイン前に以下のマトリクスを用いて、各フェーズで求められるスキルの「質」を可視化し、体制図と連動させてミスマッチを防ぎましょう。

評価項目	上流工程（設計）で重視するポイント	下流工程（開発）で重視するポイント
業務知識	顧客のビジネスを理解し、潜在ニーズを汲み取れるか。	仕様書の意図を正確に読み取り、データの整合性を判断できるか。
技術スキル	システム方式設計や非機能要件の定義ができるか。	言語の習熟度は高いか。二次バグを防ぐ調査能力があるか。
ソフトスキル	顧客との交渉やヒアリングを円滑に行えるか。	不明点を曖昧にせず、リスクを早期にアラートできるか。

体制図へのアサイン時のポイント 体制図の各ボックスに名前を当てはめる際は、急な離脱に備えた「バックアップ（副担当）」も併せて検討しておくことが、属人化によるリスク軽減につながります。

【重要】専門チームの「スポット参画」を忘れない

DB設計、インフラ構築、セキュリティ対策（SRE）といった「基盤技術者」を開発メンバーに兼務させるのは炎上の元です。特定の期間のみ集中的に必要になる「スポット参画」として初期段階で計画に組み込み、早めに確保へ動きましょう。

【プロの視点】現場で陥りやすい「1.0人」の罠

要員計画を立てる際、PMが必ず心に刻んでおくべき「計算上の人数」の落とし穴があります。

「新人＝1.0人」の罠

新人はアウトプットが出ないだけでなく、教育役となる先輩エンジニアの工数も奪います。実質的にはチーム全体で「0.5人分以下」の戦力ダウンになることも珍しくありません。人数の計算には「育成コスト（マイナス分）」を必ず含めましょう。

「エース＝1.5人」の罠

優秀なエースエンジニアは高い生産性を持ちますが、1日は24時間しかありません。彼らを「1.5人分」として計算してスケジュールを組むと、彼らがパンクした瞬間にプロジェクトの核が崩壊します。計画はあくまで「1.0人」とし、余力はレビューや若手のフォローに充てさせるのが鉄則です。

PMの最重要ミッション：アサインとリリースの泥臭い管理

プロジェクトの安定稼働は、計算後の「早めの調整」にかかっています。

1〜2ヶ月先の「予約」が現場の常識
開発ピークに向けて人を増やす際、直前になって依頼しても優秀な人材は確保できません。自社内やパートナー企業には、少なくとも1〜2ヶ月前から「内諾（予約）」を取っておくのが鉄則です。
意外と盲点な「リリース（撤退）」計画
役割を終えたメンバーの契約を適切に終了させる計画です。外部パートナーの場合、1ヶ月以上前の通知が必要なケースが多いため、保守への引き継ぎ期間を逆算し、「作業が終わったのにコストを払い続ける」事態を避けましょう。