開発が遅れたら、予定をどう引き直す？

元の計画・現在の見込み・変更案・改訂版を分ける

工程表の「予定」を一つの欄で済ませると、前の合意を消したのか、現状の見込みを書いたのか、まだ相談中の案なのかが分からなくなります。再計画では、まず記録の役割を分けます。

元の合意済み計画

進み具合や変更の影響を比べるため、保存しておく計画です。この例は以前に合意した計画という架空の設定です。現在の見込みに合わせて過去の日付を消すと、どこを変える判断をしたのか追えなくなります。

現在の事実と見込み

確認できた実績、待っている判断、残作業から、今どうなっているかを示します。見込みは、新しく得た回答によって変わることがあります。見込みを書いただけで、元の計画の変更を承認したことにはしません。

未承認の変更案

これから選ぶ候補です。何を待ち、何を先に進め、どの担当や費用が変わるかを示します。開始日が書ける場合も、それが提案か、承認された日付かを明記します。

承認後の改訂版

案件の変更手続に沿って決定された内容を反映する計画です。選ばれた案、変える範囲、適用時点、残す条件が対応して初めて、実行と次の進捗確認に使えます。この例ではまだ作成済み・承認済みではありません。

APMは、承認済み基準への変更を記録・評価し、承認・却下・保留の判断を経て、承認時に計画を更新する管理として説明しています。本稿でも、作業状況の更新と、合意した基準を変える判断を分けます。APMの変更管理の定義と手順

元の予定と、11月6日に分かっている事実を並べる

以下は説明用の架空例です。扱う範囲は、受注画面の権限確認から業務受入までです。システム全体の進捗や実際の契約・顧客成果の記録ではありません。まず元の計画を、そのまま比較用に残します。

実際の契約に記載された日付は未確認です。表の日付を、この会社の契約納期や契約違反の判定へ読み替えません。

11月6日時点で確認できること

確認時点は架空の11月6日です。権限表は未承認で、元の承認予定11月5日を過ぎています。一方で、下書きの権限表は存在します。下書きがあることは、権限の内容が承認されたこととは別です。

承認済み権限に基づく実装は未着手です。ただし、この一文を「すべての開発作業が止まっている」という報告には広げません。権限決定から独立した画面配置の検討は可能と記録されていますが、配置を実装し終えた結果や、その先行案の承認を意味しません。

まだ分からないのは、権限表の承認見込み日が未確認、遅れの原因が未確認、残作業の量や必要時間が未確認という点です。業務受入の結果も未確認です。原因を発注側・開発側のどちらかへ決め付けず、承認を扱う担当には判断待ちの中身を、開発側には残作業と試験の見通しを尋ねます。

この記録から分かる遅れは、権限表の承認予定を過ぎても未承認であることです。利用開始まで何日遅れるか、11月20日に始められるかは、まだ判断できません。

変更が必要な仕事と、その先への影響を確かめる

基準を変える前に、権限表の承認待ちが、どの実装・試験・受入へつながるかを確かめます。影響がある仕事を特定するためで、未回答のまま日数を計算するためではありません。

図で確かめる問い：元の開始予定を残したまま、11月6日の事実と未承認の二案をどこへ分けて置き、どの判断の後で改訂版へ進むのでしょうか。

図を原寸で開く

図では、権限表の承認を待つ実装、権限の試験、業務受入のつながりを読みます。画面配置の検討を別に進められても、権限の実装や試験を省くことにはなりません。二案は未承認の候補で、元の計画から改訂版へ移った実績でもありません。

• 開発側へ聞くこと：承認が必要な権限設定、残る実装、権限別の試験、業務受入へ渡す条件を分けてもらいます。画面配置と権限処理の境界が、どの資料や版で説明できるかも確認します。
• 発注側へ聞くこと：権限表を誰が決め、どの判断が残り、いつ回答できる見込みかを確かめます。業務担当が受入確認を行える日も、開発側の都合とは別に確認します。
• 計画へ戻すこと：前提が変わる仕事と、その後へつながる仕事を対応させます。関係しない作業まで理由なく変えたり、必要な試験を消して短く見せたりしません。

待つ資料と先行できる部分、担当者の予定、やり直しの条件を詳しく整理する段階では、先に進める作業と待つ作業の分け方が参考になります。本稿では、その回答を材料にして、元の計画のどこを変更候補にし、何が決まったら改訂するかへ進みます。

同じ残作業と受入条件で、未承認の二案を比べる

二つの案は、同じ受注画面の権限確認から業務受入までを扱います。先行できる作業だけを数え、後の実装・試験・受入を比較から外すと、早くなったように見えるため注意が必要です。

比較するときに、同じ条件へ戻す

両案とも、権限を決めた後の実装、権限別の試験、発注側の業務受入を残します。開発側には、残作業の内訳、前提となる回答、担当の空き、試験と修正の見込みを示してもらいます。発注側は、受入確認に参加できる時点と、使い始めるために必要な条件を返します。

配置を先行する案では、先に検討したものがどの変更でやり直しになるか、誰がその差を確認するかを付けます。費用は、先行分だけでなく再作業や延長中の対応も含めて説明を求めます。未回答を0円・追加なしとして扱ったり、開始予定を守れると約束したりしません。

11月5日から11月8日までの日付の間隔を、そのまま実装に必要な作業日数へ変換することもできません。担当の稼働日、残作業、試験と受入の条件が、この例では分からないためです。

変更前後の差と、決めたい点を承認者へ渡す

案を選ぶ人が判断できるよう、変更前と変更候補を対応させます。今回の記録では、変更を承認する人は未確認です。開発側の担当者が案を説明したことと、案件の計画を変える権限を持つ人が判断したことを、同じ扱いにはしません。

1. 元の計画を示す。何について合意した版を基準にするか、対象の仕事と日付を確認します。この例なら、権限表・実装・業務受入・開始の予定を、変更前のまま示します。
2. 現在の事実と影響を示す。11月6日時点で権限表が未承認であること、承認済み権限による実装が未着手であることと、残る未回答を分けます。未確認の原因を断定した説明にはしません。
3. 二案の差と共通条件を示す。配置を先行するか、同じ範囲で待って組み直すかを比べます。必要な実装・権限試験・業務受入を両方へ残し、費用、担当の予定、再作業の条件を対応させます。
4. 決めたい点を明確にする。どの案を選ぶか、どの範囲と予定を変えるか、未回答を残して何を保留するかを示します。誰が判断し、誰へ何を確認すれば決められるかを、案件の変更手続と照らします。

相談では、例えば「元の開始予定は残しています。権限表の承認が予定を過ぎても未了で、二案の新しい開始日と費用はまだ未回答です。両案に残る実装・試験・受入の見通しをそろえ、どの範囲を変更するか判断したいです」と伝えられます。これは、この架空例を説明する相談文で、実際の承認や外部送信を行った記録ではありません。

判断を求める時点を決める際にも、根拠なく日付を補いません。承認を扱う窓口と、開発・業務側の回答予定を確かめ、開始予定へ影響する前に誰と相談するかを決めます。質問を送ったことだけで、未回答の条件を解消済みにはしません。

承認・却下・保留で、計画への反映を分ける

この例で選択された案は未決定で、基準計画の変更はまだ承認されていません。以下は今後判断を受けた場合の進め方で、この例の結論を作ったものではありません。

変更が承認された場合

決定した範囲、案、適用する時点と残る条件を記録します。承認された日程だけでなく、関係する担当、待ち条件、試験・受入の予定を改訂版へ対応させます。元の合意版と、その時点の見込みは保存し、どの変更を誰が決めたかをたどれるようにします。

承認が一部の範囲だけなら、その範囲と影響する仕事を更新します。まだ承認されていない別の変更や、未回答の費用まで、まとめて確定欄へ移さないようにします。

案が却下された場合

却下された案を実行予定として残さず、どの条件が合わなかったかを記録します。別案を検討するなら、元の計画との比較条件と残る仕事を保って再評価します。却下されたことだけで、元の日程を必ず守れるようになったと判断しません。

判断が保留になった場合

不足する回答、答える役割、判断を再開する条件を残します。新しい開始日を正式版へ上書きせず、どの作業まで進めてよいかも区別します。権限表の下書きや画面配置の検討があるだけで、正式権限の実装や業務受入を済ませた扱いにはできません。

PMIの2011年の実務標準も、保存した基準との比較、承認した変更の反映、影響する仕事の基準更新、周知と履歴保持を分けています。ここでは計画を追跡する考え方として参照し、特定の工程表ソフトや、すべての国内契約に共通する手続を指定していません。PMI・Practice Standard for Scheduling 第2版、3.3.3〜3.3.7節（冊子35頁・PDF46頁）

改訂後は、基準と実績を同じ時点で見直す

改訂版が決まった後も、予定を直しただけで作業が終わるわけではありません。この記録で実際の完了は未確認です。以後の報告では、どの版を基準に、いつ確認した実績と比べているかをそろえます。

• 変更前後を追えるようにする。元の合意版、判断前の見込み、採用された変更の内容、決定した人と時点、改訂版の適用範囲を対応させます。版番号や承認日時は、実際に得た記録を使い、例にない値を作りません。
• 実績は結果で更新する。権限表が承認されたか、承認された内容に沿った実装と試験がどうなったか、発注側の受入で何を確認できたかを区別します。修正したという連絡と、必要な条件を確かめた結果は別です。
• 残作業と見込みを見直す。新しい回答や実績で前提が変われば、残る仕事と担当の予定を更新します。改訂版へさらに変更が必要なら、今回と同じように変更候補と決定を区別します。

報告の進捗率を読む必要がある場合は、受入記録と予定を照らして進捗率を読む方法へ進めます。未発生のリスクと、発生した課題を一件ずつ追う場合は、リスク管理表を次の判断へつなぐ方法が参考になります。再計画の承認、個々の試験結果、リスクの解消を、一つの「完了」へまとめないようにします。

まとめ：元の計画を残し、案と決定を分ける

予定を引き直すときは、元の合意済み計画を保存し、現在の事実と未承認の変更案を分けます。権限表の承認予定を過ぎたことと、利用開始が何日ずれるかは別の問いです。残る実装・試験・受入、担当の予定と費用がそろわないまま、新しい開始日だけを確定しません。

判断を受けたら、承認・却下・保留に応じて扱いを変え、承認された内容と関係する仕事を改訂版へ反映します。その後も、適用する版と確認時点をそろえて実績を見直します。