人が足りないときの打ち手は5つしかない
「この体制では間に合いません」。計画を立てている途中で、そう気づくことがあります。あるいは走り出してから、要員の抜けや想定外の作業で足りなくなることもあります。
このとき、PMが取れる打ち手は実は5つしかありません。どれを選ぶかではなく、どの順番で検討するかが重要です。
■ ① スコープを削る（段階リリース）
最初に検討すべき打ち手です。人を増やすより先に、本当に全部を同時に出す必要があるかを確認します。
ポイントは、「全部を後ろ倒しにする」のではなく「必要な分を先に出す」形にすることです。発注元にとっても、全部が遅れるより一部でも早く使えるほうが価値があります。
業務が回る最低限の機能は何かを、業務側と一緒に決める
第2弾でやるものを明記する（「やらない」ではなく「いつやる」を示す）
第1弾だけで運用が成立するかを確認する（手作業で代替できるか）
削る提案は言い出しにくいものですが、遅れてから謝るより、早い段階で相談するほうが受け入れられます。
■ ② 期限を延ばす
効果はすぐ出ますが、動かせるかどうかは条件次第です。法令対応の期限、契約更新日、業務の繁忙期などが絡んでいると動きません。
だからこそ、立ち上げ期に「動かせない条件は何ですか」と聞いておくことが効いてきます。動かせる納期なのか、絶対に動かせないのかを知っていれば、判断が早くなります。
■ ③ 並行して進める
前の工程が終わる前に、次の工程を始める方法です。ただし、前提が固まる前に着手するため、手戻りが出るリスクがあります。
依存関係が弱い部分にだけ使う（他の機能と独立している画面など）
クリティカルパス上では慎重に。ここで手戻りが出ると全体が遅れます
「どこまで確定していれば着手できるか」を先に決めておく
■ ④ 人を増やす
いちばん思いつきやすい打ち手ですが、効果が出るまでに1〜2か月かかります。その間、教える側の手が止まります。
ソフトウェア開発の世界には「ブルックスの法則」という有名な言葉があります。「遅れているプロジェクトに人を投入すると、さらに遅れる」というものです。理由は3つです。
新しい人が戦力になるまで時間がかかる（業務知識、既存の仕様、開発環境）
教えるために、既存メンバーの作業が止まる
人が増えると連絡経路が増え、調整の手間が増える
それでも人を増やすなら、条件があります。
効果が出るまでの期間を待てる時期であること 終盤に足しても間に合いません
切り出せる独立した作業があること 「手伝って」では動けません。担当を丸ごと渡せる作業が要ります
受け入れる側の工数を計画に入れること 教育に2週間かかるなら、それを工程に書きます
■ ⑤ 品質基準を下げる
「テストの回数を減らす」「レビューを省く」という選択です。これは実質的に、問題を後ろに送っているだけです。
省いた分はテスト工程で戻ってきます。テストでも見つからなければ、稼働後の障害対応になります。そのときのコストは、省いたときの何倍にもなります。
やむを得ず行う場合は、必ず次をセットにします。
対象を明確にする（この機能のこのテストだけ、と限定する）
いつ取り戻すかを決める（稼働後1か月以内に実施、など）
発注元に説明して合意を取る。黙ってやらない
■ 検討する順番
実務では、次の順で検討します。
まず①スコープを見る。出す範囲を分けられないか
次に②期限を確認する。動かせる納期か
それでも足りなければ③並行化と④増員を、時期を見て組み合わせる
⑤品質は、原則として選択肢に入れない
■ 報告のしかた
「人が足りません」とだけ伝えても、話は進みません。次の形にすると、相手が判断できます。
いまの体制で進めた場合、いつ、どれだけ遅れる見込みか
打ち手の選択肢と、それぞれの効果・副作用
PMとしての推奨案と、その理由
いつまでに決めてほしいか
問題ではなく選択肢を持っていくのが、決裁者に判断を仰ぐときの基本です。
■ まとめ
人が足りないときの打ち手は、スコープ・期限・並行化・増員・品質の5つだけです。順番はこのとおりで、増員は思っているより効果が遅く、品質を下げるのは打ち手ではありません。
足りないと気づいた時点で、すぐに選択肢を整理して相談する。それが結果的にいちばん早い解決になります。