プロジェクト開始日変更の「再計算地獄」を断つ：Project VBA 高速化の極意
プロジェクト管理の現場で、開始日の変更に伴う全タスクの再計算は、いわば「静かなる時限爆弾」です。タスク数が数千を超えた瞬間、VBAがApplication.Calculationを制御し損ねれば、画面はフリーズし、ユーザーは強制終了の誘惑に駆られるでしょう。
今日は、Project VBAの心臓部である「スケジュールエンジン」を支配し、再計算のオーバーヘッドを極限まで排除するアーキテクチャを伝授します。
—
1. なぜ「標準の再計算」は遅いのか
Projectのスケジュールエンジンは、依存関係（プレデセッサ）をグラフ構造として保持しています。開始日を1日動かすだけで、エンジンは連鎖的な再計算を試みる。この際、UIの更新（画面描画）と計算イベントが密結合していることが、パフォーマンス低下の主犯です。
我々が目指すべきは、「エンジンを意図的に停止させ、バルク更新後に一括再計算を実行する」というアプローチです。
—
2. 堅牢な設計：Calculation制御のベストプラクティス
単に `Application.Calculation = pjManual` を置くだけでは不十分です。例外発生時に再計算がOFFのまま放置されると、データ整合性が崩壊します。必ず「エラーハンドリングによる保護」を実装してください。
高速化のためのプロダクションコード
以下のコードは、大規模プロジェクトでも安全に開始日を更新するためのテンプレートです。
Public Sub UpdateProjectStartDate(ByVal newStartDate As Date)
Dim originalCalculation As Long
Dim proj As Project
Set proj = ActiveProject
‘ 1. 現在の計算モードを保存
originalCalculation = Application.Calculation
On Error GoTo ErrorHandler
‘ 2. エンジンを停止（ここが最重要：再計算の連鎖を遮断する）
Application.Calculation = pjManual
‘ 3. 業務ロジックの実行
‘ 開始日を変更し、各タスクの制約条件を再定義する
proj.ProjectSummaryTask.Start = newStartDate
‘ 例：全タスクの制約を「開始日以降」に強制適用する場合の処理
Dim t As Task
For Each t In proj.Tasks
If Not t Is Nothing Then
‘ 制約タイプをASAP等に固定、あるいは特定条件で変更
t.ConstraintType = pjConstraintASAP
End If
Next t
‘ 4. 最後に一括計算を実行し、モードを戻す
Application.Calculation = pjAutomatic
Exit Sub
ErrorHandler:
‘ 異常終了時も必ず計算モードを復旧させる
Application.Calculation = originalCalculation
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
End Sub
—
3. 実務で差がつく3つのテクニック
① データベース・外部ファイル連携の注意点
外部（ExcelやSQL Server）から開始日を流し込む際、「タスクのGUIDをキーにすること」を鉄則としてください。行番号（ID）は移動により変化するため、IDベースのロジックを組むと、データがずれてプロジェクトが崩壊します。
② `Application.ScreenUpdating` の併用
`Application.Calculation` とセットで考えるべきは画面描画です。再計算中に画面を更新させる必要はありません。
Application.ScreenUpdating = False
‘ … 処理 …
Application.ScreenUpdating = True
これを加えるだけで、特にネットワークドライブ上のファイル操作において劇的な体感速度の向上が見込めます。
③ 依存関係の「静止」と「再構築」
複雑な依存関係を持つプロジェクトの場合、開始日変更後に `CalculateAll` メソッドを呼ぶタイミングを制御してください。ループ内で何度も計算を走らせるのではなく、すべてのデータ更新が終わった「最後の一回」のみ計算を実行するのが、プロのエンジニアの流儀です。
—
4. 最後に：アーキテクトからの助言
VBAでProjectを制御するということは、単にプロパティを書き換えることではありません。「スケジュールエンジンの挙動を予測し、その負荷を管理すること」です。
今回紹介したコードは、あくまで「最低限のガードレール」です。大規模な開発であれば、さらに「変更分のみを更新する」ための差分検知ロジックや、ログ出力によるデバッグ機能を追加してください。
ツールは、使われることで初めて価値を持ちます。しかし、そのツールがシステムを壊すことがあってはなりません。堅牢なエラーハンドリングと計算モードの制御。この二つを徹底することで、あなたのツールは「信頼されるエンジニアの証」となるはずです。
さあ、コードを書き、プロジェクトを自在に操ってください。
