Project VBAの深淵：タスク操作における「不可逆な破壊」を防ぐトランザクション設計
多くのVBAエンジニアは、`Task.OutlineIndent` や `Task.Predecessors` を叩く際、その背後にある「Undoスタックの肥大化」と「整合性の崩壊」という地雷に気づいていない。
Project VBAは、ExcelやWordのVBAとは一線を画す。一回のアクションが「プロジェクト全体のスケジューリング計算（再計算）」をトリガーし、その一挙手一投足がUndoスタックに積まれるからだ。大規模なWBSの自動生成や依存関係の再構築を行う際、コードが途中で落ちれば、手元には「中途半端なリンク関係を持つ壊れたプロジェクトファイル」だけが残る。
本稿では、レガシーかつ強力なProjectオブジェクトモデルを制御し、真のトランザクション管理を実現する極限の設計パターンを提示する。
—
1. なぜ「標準のUndo」を信じてはならないのか
ProjectのUndoスタックは、メモリ上の変更ログだ。大量のタスクをループで操作すると、スタックは即座にオーバーフローするか、あるいは巨大なメモリを占有してアプリケーションをフリーズさせる。
シニアエンジニアが採るべき戦略は、「Undoに頼らない」こと。すなわち、操作前に状態を退避させ、失敗時にリカバリする、あるいは論理的に「全成功か全失敗か」を保証するラップ処理の実装である。
2. トランザクション・パターン：ステートフル・ロールバック
トランザクションを実装する際、最も単純かつ強力なのは「XMLエクスポートによるスナップショット」だが、オーバーヘッドが大きすぎる。実務的なアプローチは、「操作対象のGUIDリストを保持し、例外発生時に再構築する」手法だ。
実装コード：安全なタスク依存関係設定
‘ 依存関係設定におけるトランザクション的アプローチ
Public Sub SafeUpdatePredecessors(ByRef targetTask As Task, ByVal predString As String)
Dim originalPred As String
‘ 現在の状態を退避（ロールバック用）
originalPred = targetTask.Predecessors
On Error GoTo RollbackHandler
‘ 操作を実行
targetTask.Predecessors = predString
‘ 再計算の強制実行とエラー検知
Application.CalculateProject
Exit Sub
RollbackHandler:
‘ 失敗時：元の状態へ復帰
targetTask.Predecessors = originalPred
Debug.Print “Critical Error: Transaction Failed. Rollback executed for Task ID ” & targetTask.ID
Err.Raise Err.Number, “SafeUpdatePredecessors”, “タスク更新に失敗しました。ロールバックを実行しました。”
End Sub
3. Windows APIによる「再計算の抑制」とメモリ解放
Project VBAの最大のボトルネックは、各操作ごとの「再計算」だ。これを制御しないとパフォーマンスは線形ではなく指数関数的に悪化する。
`ScreenUpdating` と再計算の分離
`Application.ScreenUpdating = False` は画面更新を止めるだけで、裏側の計算エンジンは止まらない。極限までパフォーマンスを求める場合、`Application.Calculation = pjManual` を一時的に活用すべきだが、これには強力な副作用が伴う。
‘ パフォーマンス最適化のための設計
Public Sub BatchTaskProcessing()
Dim calcMode As Long
calcMode = Application.Calculation
‘ 再計算を一時停止（計算エンジンをデタッチ）
Application.Calculation = pjManual
On Error GoTo Cleanup
‘ ここに重いタスク処理を記述
‘ …
Cleanup:
‘ 終了時に必ず手動で再計算をトリガーし、設定を戻す
Application.Calculation = calcMode
Application.CalculateProject
End Sub
4. 伝説的なエンジニアの戒め：オブジェクトの明示的解放
VBAのガーベジコレクションを信じてはいけない。特に`Application`や`Project`オブジェクトを多用する複雑なクラスモジュールでは、参照循環がメモリリークを引き起こす。
- 循環参照を避ける: `Task`オブジェクトをモジュールレベル変数で保持し続けるのは避け、操作が終わったら即座に `Set obj = Nothing` を実行すること。
- イベントの無効化: 自動計算イベントや`Project_Change`イベントがトランザクション中に発火しないよう、`Application.EnableEvents = False` を必ずトランザクションの開始と終了で制御せよ。
5. 結論：システム整合性を守るために
Project VBAにおいて「堅牢なコード」とは、エラーが発生しないコードではない。エラーが発生した瞬間に、プロジェクトファイルが「ゴミ」にならないよう設計されているコードのことだ。
1. 操作前に状態を保存する
2. 再計算のトリガーを完全に制御下に置く
3. 例外発生時は必ずクリーンアップパスを通す
この3原則を徹底するだけで、あなたの書くProject VBAは、他のエンジニアが触ることのできない、堅牢で高パフォーマンスなエンタープライズ級のツールへと昇華するはずだ。
技術は、細部に宿る。API仕様の隅々までを見通し、メモリの鼓動を感じながら設計せよ。それがアーキテクトの矜持である。
