プログラム要員配分計画のテンプレート

プロジェクト単位の要員計画は、それぞれ正しく作られていることが多いものです。それでも足りなくなるのは、同じ人が複数のプロジェクトから必要とされているからです。しかもこの重なりは、プロジェクトの計画書を1本ずつ読んでも見えません。

この記事では、プログラム全体の要員配分計画のテンプレートを紹介します。ポイントは、総人数の山より先に、希少スキルの山を割ることです。記入例は、加美乃フーズ（架空）の「生産・供給改革プログラム」（2年半・承認枠5億2,000万円・構成4本）です。

■ 1. 背景・よくある課題

よくある状態	何が起きるか
プロジェクトごとに要員計画を作っている	同じ人が複数に計上され、実態より多く見える
総人数だけで山を見ている	人数は足りているのに、特定のスキルで詰まる
兼務を1.0人月として数えている	実際には0.4人月しか出ておらず、計画が最初から破綻する
業務部門の工数が計画に入っていない	要件レビューの時間が取れず、要件確定が遅れる
山が超えたときの打ち手が「増員」しかない	人を増やしても、希少スキルのところで止まる
供給の上限を決めていない	いくらでも積める計画になり、実行段階で崩れる

3つめと4つめは、プログラムの要員計画でとくに見落とされやすい点です。業務部門のメンバーは本業を持ったまま参加します。「週16時間」と決めておかないと、実際には週4時間しか出てきません。

■ 2. テンプレート作成の目的

目的	具体的にどうなることか
プログラム全体で山を見る	プロジェクトを積み上げ、時期ごとの総量を出す
希少スキルを別に管理する	数名しかいないスキルを、個人単位で山積みする
供給の上限を決める	社内・ベンダーそれぞれの上限を、先に合意しておく
兼務を実働で数える	0.4人月なら0.4と書く。1.0で数えない
山を割る順番を決める	スキル→着手時期→増員、の順に検討する

■ 3. テンプレートの全体像

シート	役割	粒度	更新の頻度
① 総量の山積み	プロジェクト別に積み上げ、供給上限と比べる	四半期	四半期ごと
② 希少スキルの山積み	数名しかいないスキルを、個人単位で見る	月	月次
③ 要員台帳	1人1行。所属・スキル・参加期間・稼働率	―	参加・離任のつど
④ 供給上限の定義	社内・ベンダー・業務部門の上限と根拠	―	年度ごと

■ 4. 総量の山積み

図プログラム全体の要員の山

加美乃フーズの例では、供給上限32名に対して、2024年4Qに33名、2025年1Qに36名と、2四半期だけ超えています。超えているのが一部の期間だけなら、打ち手は限られます。

打ち手	効果	副作用
後続プロジェクトの着手を後ろへずらす	山が下がる。追加費用なし	ベネフィットの実現が遅れる
ベンダーを増やす	すぐ人数は増える	費用が増え、立ち上がりに時間がかかる
プロジェクトの範囲を削る	山も費用も下がる	ベネフィットが落ちる
上限そのものを上げる	計画は通る	実行段階で必ず崩れる。最後の手段

加美乃フーズが選んだのは1つめでした。C2（需給計画高度化）の着手を1四半期うしろへずらすことで、2025年1Qの山が36名から27名に下がっています。

■ 5. 希少スキルの山積み

ここが、プログラムの要員計画でいちばん大事な部分です。総人数が上限内でも、希少スキルの山が割れていなければ止まります。

加美乃フーズでは、生産管理の業務知識をもつ社内要員が4名しかいませんでした。この4名が必要になる作業は、次のとおりです。

時期	C1	C2	C3	必要人数	判定
2024年10〜12月	要件確認（3名）	―	―	3名	可
2025年1〜3月	受入テスト（4名）	需給ロジック設計（2名）	―	6名	不足2名
2025年4〜6月	定着支援（2名）	需給ロジック設計（2名）	原価配賦ルール（2名）	6名	不足2名
2025年7〜9月	―	受入テスト（2名）	原価配賦ルール（2名）	4名	可

この表を作ると、総人数の山とは違う時期に不足が出ることが分かります。加美乃フーズの場合、総人数の山は2025年1Qですが、希少スキルの不足は1Qと2Qの両方で起きていました。

打った手は次の3つです。

打ち手	内容
C2の着手を1四半期うしろへ	需給ロジック設計を2025年4〜6月へ移し、1Qの重なりを解消
C3の原価配賦ルール策定を7〜9月へ	2Qの重なりを解消。C3の稼働日は変えずに済んだ
4名のうち1名を、期間限定で他業務から外す	2025年1〜6月のみ、専任に近い状態にする（部門長の承認）

■ 6. 兼務は実働で数える

要員台帳では、稼働率を実働で書きます。ここを1.0で数えると、計画は最初から破綻します。

参加の形	よくある計上	実際に出る時間	台帳に書く値
専任（プログラム以外の業務なし）	1.0	週40時間	1.0
兼務（部署の業務を持ったまま）	0.5	週8〜12時間	0.25
業務部門のレビュー参加	計上していない	週4〜8時間	0.15
管理職（承認・判断のみ）	計上していない	週2〜4時間	0.08

とくに業務部門のレビュー参加は、計上されていないことが多い工数です。しかしここが出てこないと、要件が確定しません。プログラムの要員計画には、必ず業務部門の行を入れてください。

加美乃フーズでは、業務部門のレビュー工数を「週16時間（0.4人月）×6名」として体制表に明記し、各部門長の承認を取っています。

■ 7. 運用ルール

ルール	内容	理由
山を割る順番を守る	①希少スキル → ②着手時期 → ③増員	逆にすると、人を増やしても希少スキルで詰まる
供給上限を先に決める	社内・ベンダー・業務部門それぞれの上限を合意しておく	上限が無いと、いくらでも積める計画になる
兼務は実働で数える	0.25や0.4のように、小数で書く	1.0で数えると計画が最初から破綻する
希少スキルは月次で見る	総量は四半期、希少スキルは月次	不足が出る時期が、総量とずれる
離任の予定も台帳に書く	「2025年6月に異動予定」まで記録する	異動で希少スキルが抜けると、代替が効かない
上限超過は運営委員会に上げる	PgMの判断で上限を超えない	上限を動かすのは、人を出す部門の判断

■ 8. 活用シーン

場面	使い方
プログラムの計画時	構成プロジェクトの順序を、山が上限内に収まるように決める
プロジェクト追加の判断	追加した場合の山を描き、上限を超えないかを確認する
四半期の見直し	実績と計画の差を見て、次の四半期の配分を調整する
ステージゲートの判定	次フェーズの要員が確保できているかを、判定項目に入れる
異動・離任が出たとき	希少スキルの山を見て、どの作業が止まるかを特定する
ベンダー調達の検討	不足の時期と量を根拠に、調達の規模と時期を決める

■ 9. よくある失敗と直し方

失敗	起きること	直し方
総人数だけで判断している	人数は足りているのに、特定スキルで止まる	希少スキルの山積みを、別シートで月次に持つ
兼務を1.0で数えている	計画上は足りているが、実際は半分も出ない	実働で小数で書く。過去の実績から係数を決める
業務部門の工数が入っていない	要件レビューが進まず、要件確定が遅れる	週何時間かを体制表に書き、部門長の承認を取る
上限を超えたら増員、で済ませている	費用が増え、立ち上がりにも時間がかかる	まず着手時期の調整を検討する
上限を決めていない	実行段階で必ず崩れる	社内・ベンダー・業務部門の上限を、年度ごとに合意する
離任の予定を把握していない	希少スキルが突然抜ける	台帳に離任予定の列を作り、四半期に1回確認する

■ 10. 導入効果

観点	プロジェクト別に作っていたとき	プログラムで山積みしたとき
重なりの把握	実行段階で分かる	計画時に、2四半期の超過が見える
希少スキル	見えない	4名の山が、月単位で見える
打ち手	増員（費用増・立ち上がり遅れ）	C2の着手を1四半期ずらす（追加費用なし）
業務部門の工数	計上されていない	週16時間×6名として、部門長の承認つきで確保
2025年1Qの山	36名（上限+4）	27名（上限内）

■ まとめ

プログラムの要員計画は、プロジェクトの山積み表を足し合わせるところから始まります。しかし本番はその先で、数名しかいない希少スキルを、個人単位で山積みすることです。

まずは「このプログラムで、いちばん代わりがきかない人は誰か」を挙げてみてください。たいてい3〜5名です。その人たちの山を月単位で描くと、総人数の山とは違う時期に不足が見えてきます。