要員が集まらない中、クリティカルパスの組み替えで納期を守った事例

この事例は、計画どおりに人が集まらなかったプロジェクトの全記録です。教育サービス会社の受講管理システム刷新で、6月から8月にかけて累計9人月ぶんの要員が不足しました。こういうとき、多くの現場は「足りない分だけ後ろ倒しにする」と判断します。この案件では違う手を打ちました。作業そのものは1日も減らさず、順番だけを組み替えて、納期を1日も動かさずに完了しています。

登場する会社・数字はすべて架空です。ただし、人月・金額・日数・不具合件数は、記事の中で辻褄が合うように作ってあります。ご自分の現場の数字に置き換えながら読んでみてください。

■ 会社と案件の前提

受講者が申し込み、受講し、修了証を受け取るまでを扱う「受講管理」と、動画講義を配信する「オンライン学習基盤」を、同時に入れ替える案件です。学習基盤は外部のSaaSを使い、自社側とはデータ連携でつなぐ構成にしました。

■ 何を「成功」とみなしたか

着手前に、QCDそれぞれの合格ラインを紙に書いて関係者で合意しました。これを決めておかないと、後で判断がぶれます。

この3つのうち、動かせないのはDでした。だからこそ、要員が足りないと分かった時点で「納期を動かす」という選択肢が最初から無く、別の手を探すことになります。逆に言えば、どれが動かせないかを先に決めておいたから、6月に迷わず動けたとも言えます。

■ 立ち上げ時の計画：体制・WBS・マイルストーン

まず体制です。ベンダー側は「6月から設計3名、7月から開発5名」という前提で見積りが出ていました。

次にWBSです。合計108人月を8つの塊に分けました。右端の実績は、この記事の最後に確定する数字です。

マイルストーンは7つです。2つめの「連携I/F仕様確定」は当初は無く、6月の組み替えで追加したものです。

計画時点のクリティカルパスは180営業日、稼働日までに使える営業日は188日でした。つまり余裕は8営業日しかありません。この8日が、後で効いてきます。

■ 4月〜5月：要件は予定どおり。届かなかったのは「要員の返事」だった

要件定義は5月16日に予定どおり完了しました。ここまでは順調です。問題は、別のところで起きていました。

5月の第2週、ベンダーPLから「6月着任予定の設計要員2名のうち、1名の着任が7月にずれそうです」という連絡が入ります。さらに5月末には、もう1名も8月になる見込みだと伝えられました。ベンダー側の別案件が延びていたことが理由です。

ここでPMがやったことは、「困った」と言う前に、遅れが何日になるのかを計算することでした。設計要員2名の着任が2か月ずれると、学習基盤の連携設計の着手が26営業日後ろにずれます。改定前のクリティカルパスは「要件定義 → 受講管理基本設計 → 学習基盤連携設計 → 連携開発 → 結合テスト → 受入」でしたから、この26日はそのまま最終日に効きます。

• 改定前のクリティカルパス：180営業日

• 要員遅れの影響：＋26営業日 → 206営業日

• 稼働日までに使える営業日：188営業日

• 結果：18営業日の超過見通し

「なんとなく遅れそう」ではなく「18営業日足りない」と言えたことが、次の判断を早くしました。数字にすると、関係者が同じ絵を見られるようになります。

■ 6月：足りない9人月を、どの作業に当てるかで決めた

6月から8月にかけて、要員の計画と実績は次のようになりました。

ここでPMが立てた問いは、「どうやって9人月を追加調達するか」ではありませんでした。調達は並行して当たっていましたが、すぐには埋まらないことが分かっていたからです。立てた問いはこうです。

「足りない人手は、どの作業に当てないと納期に響くのか」

言い換えると、いま不足している設計要員がいなくて困るのは、クリティカルパス上の作業なのか、そうでないのか、という問いです。調べた結果、不足しているのは設計要員で、そのしわ寄せが出るのは学習基盤の連携設計でした。そしてその作業は、改定前の計画ではクリティカルパス上にありました。

ここまで分かれば、打ち手は2つに絞られます。（1）その作業に人を入れる、（2）その作業をクリティカルパスから外す。（1）ができないので、（2）を検討することになりました。

■ 組み替えの中身：連携I/F仕様だけを先に確定した

学習基盤の連携設計は、なぜ受講管理の基本設計の完了を待っていたのでしょうか。理由は単純で、「受講管理の設計が固まらないと、連携するデータ項目が決まらない」と考えていたからです。

そこで、この前提を疑ってみました。連携に本当に必要なのは、受講管理の設計すべてではなく、受け渡すデータ項目と方式だけです。受講者ID・講座ID・受講状況・修了判定、そしてどのタイミングでどちらから渡すのか。これは受講管理の内部設計を待たなくても決められます。

6月中旬に業務リーダーとベンダーPLで2回の集中討議を行い、6月27日に連携I/F仕様を確定させました。これを新しいマイルストーンとして立て、そこから学習基盤側を並行で着手しています。

大事なのは、作業量を1日も減らしていないことです。学習基盤連携設計は26日のまま、連携開発も38日のままです。変えたのは着手できる時期、つまり順番だけ。それだけで、いちばん長い道が180日から168日になりました。

■ 組み替えに伴って動かした管理帳票

計画を変えるときは、絵を描いて終わりにせず、帳票まで直さないと元に戻ります。この案件で実際に直したのは次の5点です。

• WBSのベースライン再設定：5.0と6.0の開始日・終了日を変更。人月の配分は変えていない（6/27にPMが実施）

• マイルストーンの追加：「連携I/F仕様確定（2025/6/27）」を正式なマイルストーンとして登録

• 課題の起票：I-018「連携I/F仕様をどこまで先に決めるか」を起票し、期限を6/20に設定

• リスクの見直し：R-03の対応欄を「要員の追加調達を依頼」から「連携I/F仕様を先に確定し、学習基盤側をクリティカルパスから外す」に書き換え

• TODOの追加：連携I/F項目一覧のドラフト作成（ベンダーPL・6/18期限）

特に2つめのマイルストーン追加は効果がありました。「6月27日に何が決まっていないとまずいのか」が一目で分かる状態になり、週次の会議で自然に進捗が追われるようになったからです。帳票に載っていない約束は、忘れられます。

■ 9月〜1月：組み替え後の進捗（EVM）

9月に要員がようやく揃い、以降は計画を上回る人数を受講管理の開発に集中させました。4つの時点の数字です。

ここで1つ、読み間違えやすい数字があります。8月末のCPIが1.12という点です。CPIが1を超えているので「予算に対して順調」に見えますが、実態は違います。予定した人数が入っていないから、お金も使われていないだけです。

CPIだけを見ていると、このプロジェクトは8月末時点で「コスト良好・スケジュールやや遅れ」に見えます。SPIが0.88であることと合わせて見ると、正しい読み方は「人が入っていないので、出来高もコストも両方とも計画より少ない」になります。CPIが良いときほど、人月の実績とセットで見てください。

9月以降はCPIが下がっていきますが、これは計画を上回る人数を投入した結果なので、想定どおりです。最終的なCPIは0.96、金額にして計画比＋328万円（＋3.7%）でした。

■ 結合テストと受入テスト：品質の数字

納期を守るために人を集中投入したプロジェクトでは、品質が落ちていないかを別途確認する必要があります。新規開発規模52KStepに対する検出件数は次のとおりです。

結合テストの基準が「1.00以上」になっている点に注目してください。これは少なすぎたら疑うという基準です。結合テストで不具合が出ないのは、品質が良いからではなく、テストが甘いからであることが多いためです。この案件では1.31件/KStepが出たので、テストは効いていると判断しました。

受入テストで出た9件のうち、7件は画面表示の文言や並び順に関するもので、2件が修了判定のロジックに関するものでした。後者2件は、連携I/F仕様を6月に先に決めたときに、修了判定をどちら側で行うかの記述があいまいだったことが原因です。先に決めたことの副作用が、ここで出たことになります。

■ 結果（QCD）

コストは計画の8,856万円に対して9,184万円、328万円の超過でした。これは9月以降に計画を上回る人数を投入したぶんです。動かせないDを守るために、動かせる幅のあったCを使った、という結果になります。どれを守り、どれを差し出すかを先に決めておいたので、この超過は事後報告ではなく事前の合意で処理できました。

■ 管理帳票の実物

この案件で実際に回していた課題・リスク・TODOの中身です。件数は多くありません。多く起票することより、載っているものが毎週動いていることのほうが大事だと考えていたためです。

課題管理表

影響の欄に必ず日数を書くようにしていました。「重要」「大」と書くより、「＋26日」と書いたほうが、読んだ人が動きます。

リスク管理表

R-03は、6月の組み替えで対応欄を書き換えたリスクです。当初は「要員の追加調達を依頼する」と書いてありました。これは相手任せの対応で、自分では結果をコントロールできません。組み替え後は、自分たちの判断だけで実行できる対応に置き換わっています。

TODO

■ 振り返りと、自分の現場で使うなら

このプロジェクトで効いたのは、次の4つでした。

• 遅れを日数に換算してから相談する：「要員が足りません」ではなく「18営業日足りません」。数字にすると、相手も判断できる

• 問いを「人をどう集めるか」から「どの作業に当てないと響くか」に変える：後者なら、自分たちだけで答えを出せる

• 依存関係の前提を1つずつ疑う：「設計が終わらないと連携は決まらない」は、本当に全部が必要なのかを確かめる

• 計画を変えたら帳票も変える：WBSのベースライン、マイルストーン、リスクの対応欄まで直して初めて、変更が定着する

逆に、うまくいかなかった点もあります。連携I/F仕様を急いで決めたことで、修了判定をどちら側で行うかの記述があいまいになり、受入テストで2件の不具合になりました。先に決めるときほど、決めた内容の穴を誰かに読み返してもらうべきでした。

最後に、明日から使える形にまとめます。スケジュールが厳しくなったとき、まず1枚の紙にこう書いてみてください。

1. いま遅れているのは、何営業日ぶんか

2. その遅れは、クリティカルパス上の作業で起きているか

3. クリティカルパス上でないなら、放っておいてよい（他に手を打つ）

4. クリティカルパス上なら、その作業の「待っている理由」を書き出す

5. 待っている理由のうち、本当に全部が必要かを1つずつ確かめる

この5行で、かなりの場面が整理できます。作業を減らさなくても、順番を変えるだけで間に合うことは、思っているより多いです。