プロジェクト開始日変更におけるWBS制約の破壊と再構築：VBAによるタスク群の強制再配置ロジック
プロジェクトマネジメントにおいて、上位計画の変更に伴うスケジュールの一括スライドは日常茶飯事である。しかし、Microsoft Project（以下、Project）をVBAで制御する現場において、この要件はしばしばエンジニアを絶望の淵に追い込む。
原因は「制約（Constraint）」だ。個々のタスクに `.ConstraintType` が明示的あるいは暗黙的に設定されている状態で、プロジェクトの開始日（`ProjectStart`）を強引に書き換えると、Projectのスケジューリングエンジンは矛盾を検知し、タスクが宙ぶらりんになるか、意図しないガントチャートの歪みを生む。
今回は、Project VBAのオブジェクトモデルの深層に踏み込み、数千件規模のWBSを持つ巨大プロジェクトファイルにおいて、制約の呪縛を断ち切り、全タスクを整合性を保ったまま完璧に再配置する極限のアルゴリズムを解説する。
—
1. Project VBAにおける「制約」の罠とライフサイクル
Projectのタスク（`Task`オブジェクト）は、スケジュール計算において独自のライフサイクルを持つ。GUI上で操作している分には直感的だが、VBAから一括操作する場合、以下の仕様がパフォーマンスと整合性の足枷となる。
- 制約タイプの既定値: 新規タスクは通常 `pjConstraintAsSoonAsPossible`（できる限り早く）で初期化されるが、一度でもユーザーや過去のロジックで日付が固定されると、`pjConstraintStartNoEarlierThan` や `pjConstraintMustStartOn` に変貌する。
- スケジューリングエンジンの計算コスト: プロジェクト全体で `.ConstraintType = pjConstraintAsSoonAsPossible` を代入するたびに、裏で依存関係（Predecessors/Successors）を考慮した再計算走査が発生する。これを数千回繰り返せば、VBAは容易に応答停止（フリーズ）する。
ゆえに、一括変更ロジックにおいては、「計算エンジンの一時停止」「一括プロパティ書き換え」「依存関係を考慮した一括再計算」の3ステップを厳密に踏む必要がある。
—
2. 実装アーキテクチャ：高速全タスク再配置エンジン
以下のコードは、プロジェクトの開始日を安全に変更し、全タスクの固定制約を解除した上で、新たな開始日に向けてタスク群を再配置するプロダクションコードである。
メモリリークを防ぐため、オブジェクト変数のスコープと解放、およびCOMオブジェクトの適切な参照管理を徹底している。
Option Explicit
‘ ==============================================================================
‘ 処理名: 基準日変更に伴う全タスク制約解除・再配置エンジン
‘ 概要: プロジェクト開始日を強制変更し、全タスクの固定制約を「できる限り早く」に
‘ 統一した上で、依存関係を維持したスケジュール再計算を実行する。
‘ ==============================================================================
Public Sub RealignProjectSchedule(ByVal targetNewStart As Date)
Dim prj As Project
Set prj = ActiveProject
‘ パフォーマンス最大化のためのUI・計算エンジン制御
‘ 描画と自動再計算を抑制し、メモリとCPUの無駄なコンテキストスイッチを防ぐ
Application.ScreenUpdating = False
Application.Calculation = pjManual
Dim originalHandling As Boolean
originalHandling = Application.DisplayAlerts
Application.DisplayAlerts = False
On Error GoTo ErrorHandler
Dim startTime As Double
startTime = Timer
Debug.Print “=== スケジュール再配置処理 開始: ” & Format(Now, “yyyy/mm/dd hh:nn:ss”) & ” ===”
‘ 1. プロジェクト全体の開始日を更新
‘ ※ProjectStartを変更すると、プロジェクト全体の基準がシフトする
prj.ProjectStart = targetNewStart
Dim tsk As Task
Dim totalTasks As Long
totalTasks = prj.Tasks.Count
Debug.Print “対象タスク総数: ” & totalTasks & ” 件”
‘ 2. 全タスクの走査と制約の強制解除
‘ 巨大なWBSにおけるループ処理は、オブジェクト参照のオーバーヘッドを最小化する
Dim i As Long
For i = 1 to totalTasks
Set tsk = prj.Tasks(i)
‘ ヌルタスク（削除済み行など）の安全なスキップ
If Not tsk Is Nothing Then
‘ サマリタスク（親タスク）は自動計算されるため、通常は直接制約をいじる必要はないが、
‘ 強制リセットの場合は対象に含めるか判定を入れる。ここでは全通常タスクを対象とする。
If Not tsk.Summary Then
‘ 固定制約を「できる限り早く (ASAP)」に強制変更
‘ これにより、先行タスクの終了日に依存する状態を作る
If tsk.ConstraintType <> pjConstraintAsSoonAsPossible Then
tsk.ConstraintType = pjConstraintAsSoonAsPossible
End If
‘ 明示的な日付制約値が残っている場合のクリア
‘ ASAPに変更すれば日付は自動計算されるが、念のためConstraintDateをリセット
‘ ※Projectの仕様により、ASAP時はConstraintDateは無視されるが整合性のために記述
End If
End If
‘ ループごとのメモリ解放（極限環境対策）
Set tsk = Nothing
Next i
‘ 3. 計算エンジンを有効化し、依存関係に基づき一括再計算を実行
Application.Calculation = pjAutomatic
‘ 強制的にプロジェクト全体を再計算（CalculateAll）
Application.CalculateAll
Debug.Print “=== スケジュール再配置処理 完了 (所要時間: ” & Format(Timer – startTime, “0.00”) & “秒) ===”
CleanUp:
‘ 状態の復元
Application.ScreenUpdating = True
Application.DisplayAlerts = originalHandling
Set prj = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error No: ” & Err.Number & vbCrLf & _
“Description: ” & Err.Description, vbCritical, “Project VBA 致命的エラー”
‘ エラー時も確実に環境を復元
Application.Calculation = pjAutomatic
Resume CleanUp
End Sub
—
3. チーフアーキテクトが解説する極限の最適化ポイント
① `Application.Calculation = pjManual` の絶対性
Project VBAにおいて、タスクを1つ変更するたびにスケジュールエンジンが走り、後続の数千件のタスクの早期・遅延日（ES/EF/LS/LF）を再計算する。これが`.ConstraintType`や`.Start`の変更ループ内で発生すると、O(N^2)に近いオーダーで処理が重くなり、完了までに数十分を要する。
手動計算（`pjManual`）に切り替え、ループ脱出後に `Application.CalculateAll` を1度だけ叩くことで、処理時間を数秒単位まで劇的に短縮している。
② メモリ管理とオブジェクトの明示的破棄
`For Each` ループは記述がスマートだが、VBAのCOMラッパーにおいては、ループ変数に代入されるたびに内部で参照カウンタがインクリメントされるケースがある。数万件のループを回す場合、インデックスアクセス（`prj.Tasks(i)`）を使用し、処理の最後に `Set tsk = Nothing` を明示的に行うことで、ガベージコレクションの負荷を軽減し、メモリリークを根絶している。
③ サマリタスク（Summary Task）の挙動への配慮
コード内でも触れている通り、プロジェクトのサマリタスクや要約タスクは、子タスク（Subtasks）の日付から自動的に算出される（Read-only的な振る舞いをする）。これらに対して無理な日付や制約を書き込もうとするとエラーを引き起こすため、`If Not tsk.Summary Then` によるフィルタリングが実務では必須となる。
—
4. システム間連携（外部DB/Excel連携）への応用
このロジックは、基幹システム（SAPや独自ERP）から夜間バッチ等で出力された「最新のWBS・工数データ（CSV/Excel）」をProjectにインポートする際の、前処理としても極めて有効である。
外部からインポートされたデータは、どうしても過去の固定制約（「前工程が遅れてもこの日は動かさない」といったローカルルール）を内包したまま取り込まれがちだ。インポート直後に本マクロのロジックを走らせることにより、プロジェクトのマスター日程変更に対する「完全な追従性」を担保した、クリーンなWBSを自動生成することが可能となる。
レガシーなVBA環境であっても、オブジェクトのライフサイクルとProjectの内部エンジン（PDS: Project Determination System）の挙動を完全に把握していれば、数千規模のタスク群を意のままにコントロールできる。限界を疑わず、コードでインフラを制圧せよ。
