【Project VBA極意】ベースライン自動化の深淵：単なるメソッド呼び出しを超越せよ
現場で「ベースラインを保存するだけ」のマクロを書けと言われたとき、多くの者は `ActiveProject.BaselineSave` を一行叩いて満足する。だが、それでシステムが止まらないと断言できるか？
我々のようなレガシーアーキテクチャの守護者にとって、VBAは単なるスクリプトではない。Projectのオブジェクトモデルは、メモリリークとCOMの墓場だ。今日は、単なる自動化を超え、堅牢なシステム運用に耐えうる「ベースライン自動化」の神髄を伝授する。
—
1. 勘違いされた `BaselineSave` の正体
`BaselineSave` は、単純なメソッドではない。内部では、プロジェクトの全タスク・リソースの現在のスナップショットをメモリ上に展開し、それを `Baseline` 構造体へ書き出すという、極めて重いI/O操作を伴う。
特に、数千行を超えるWBSを抱える大規模プロジェクトにおいて、これをイベント駆動やタイマー実行で不用意に呼び出せば、Projectのインスタンスは一瞬でフリーズし、最悪の場合、プロジェクトファイルそのものが破損する。
2. 現場で生き残るための実装：防御的プログラミング
初心者は「動けばいい」コードを書くが、エンジニアは「落ちない」コードを書く。以下は、エラーハンドリングとオブジェクトのライフサイクルを制御した、現場で即戦力となる実装例だ。
‘ —————————————————————————
‘ @Title: 極限のベースライン保存ルーチン
‘ @Description: メモリ最適化と排他制御を考慮したベースライン保存処理
‘ —————————————————————————
Public Sub SaveBaselineRobustly()
Dim prj As Project
Set prj = ActiveProject
‘ 1. プロジェクトが開かれているか、かつ書き込み権限があるかの確認
If prj Is Nothing Then Exit Sub
On Error GoTo ErrorHandler
‘ 2. 処理前のメモリ最適化（DoEventsを挟むことでOSへの制御権譲渡）
DoEvents
‘ 3. ベースライン保存の実行
‘ All:=True : 全タスクを対象
‘ Copy:=pjCopyNormal : 標準のコピーモード
‘ SetToBaseline:=pjBaseline1 : ベースライン1に保存
prj.BaselineSave All:=True, Copy:=pjCopyNormal, SetToBaseline:=pjBaseline1
‘ 4. 完了通知（必要に応じてログ出力へ変更せよ）
Debug.Print “Baseline Saved at: ” & Now
CleanExit:
Set prj = Nothing ‘ オブジェクトの明示的解放（VBAのガーベジコレクションを待つな）
Exit Sub
ErrorHandler:
MsgBox “システムエラー: ” & Err.Description, vbCritical
Resume CleanExit
End Sub
3. なぜ「明示的解放」が不可欠なのか
VBAはCOM（Component Object Model）ラッパーだ。`ActiveProject` を変数に代入した時点で、裏側では参照カウントがインクリメントされている。これを解放せずに関数を抜ければ、プロジェクトが閉じられるまでメモリ空間にゴミが残り続ける。
小規模なツールなら無視できるが、長期稼働するシステムや、API連携を行うアドイン環境では、この「小さなゴミ」が数日後のクラッシュを引き起こす。`Set prj = Nothing` は、我々にとっての「死刑執行」ではなく「礼儀」なのだ。
4. 上級者への問い：システム間連携の更なる先へ
この先、君たちが直面するのは「サーバー側のベースライン保存」だ。もしプロジェクトがProject ServerやPWA（Project Web App）上にある場合、クライアント側のVBA単体で完結させようとするのは愚策である。
- APIの活用: PWA環境であれば、VBAから直接 `BaselineSave` を呼ぶのではなく、REST APIやCSOMを通じてサーバー側でタスクをキューイングさせるアーキテクチャへの移行を検討せよ。
- Windows API: プロジェクトの保存待ちに `WaitForSingleObject` を組み合わせ、Projectのプロセス状態を監視するラッパーを構築すれば、UIのハングアップを回避しつつバックグラウンド処理が可能になる。
—
最後に：コードを書く意味を問い直せ
「自動化」は手段であって目的ではない。君たちが書くコードは、誰かの業務を救うためのものだ。たかがベースライン保存だが、それが確実に行われるという「信頼」こそが、システム管理者にとって最も高価な資産となる。
このコードをただコピペして使うのではない。なぜこの順序なのか、なぜエラーハンドリングが必要なのかを咀嚼してほしい。それができる者だけが、真の自動化エンジニアとして評価される。
次の記事では、「MS Projectの計算エンジンを強制的に再帰させるための低レイヤーAPI操作」について掘り下げるとしよう。準備はいいか？
