Project VBAを掌握する：タスク日付操作の「聖域」に踏み込むな
Project VBAを扱うエンジニアの多くが、最初の壁にぶつかる。`Task.Start = DateAdd(“d”, 7, Task.Start)`。このコードを書いて満足しているようでは、まだ「Projectの深淵」を覗いていないと言わざるを得ない。
Projectは単なる日付管理ツールではない。プロジェクトの心臓部は「カレンダー（稼働日設定）」であり、そこにVBAで安易に手を突っ込むことは、システムの整合性を自ら破壊する行為に等しい。今日は、この泥沼に足を取られないための、極限の知見を授ける。
—
1. なぜ `DateAdd` では死ぬのか
VBAの標準関数 `DateAdd` は、カレンダーという概念を知らない。これをProjectの日付型フィールドに叩き込むと何が起きるか。
- 稼働日無視: 土日や祝日、さらには「特定のエンジニアが休暇中」というカレンダー上の非稼働日を無視して日付を強制変更する。
- カレンダーの矛盾: 変更された日付が「非稼働日」に配置されると、Projectは自動的に「制約」を付与し、スケジュールの歪み（スケジュール・スリップ）を引き起こす。
- 計算の不整合: `Start` と `Finish` の間に存在する「稼働時間」の計算が崩れ、工数（Work）が狂う。
これらは、プロジェクト管理における致命的なエラーだ。我々アーキテクトは、Projectの「スケジュールエンジン」を信じ、それを正しく操作しなければならない。
—
2. 正解は「Projectのメソッド」に委ねる
日付を直接操作するのではなく、Projectのオブジェクトモデルが持つ「スケジュール機能」を呼び出すのが鉄則だ。
推奨される実装パターン
タスクの日付を操作する際は、`DateAdd`ではなく、`Application.ActiveProject.Calendar` を介した検証を行うか、あるいはProjectが提供する`Task.SetField`メソッドを用いて、エンジンの計算をトリガーさせる必要がある。
‘ 【極限の最適化】Taskの日付を安全に操作するための設計
Public Sub SafeTaskDateUpdate(ByRef tsk As MSProject.Task, ByVal targetDate As Date)
‘ 1. カレンダーに基づいた検証（簡易的な例）
‘ 実際にはProjectのCalendarオブジェクトからWorkingDayを判定する
If Not ActiveProject.Calendar.Period(targetDate).Working Then
Debug.Print “警告: 非稼働日への設定を検知しました。”
End If
‘ 2. 直接代入ではなく、フィールド指定で更新を試みる
‘ これにより、計算エンジンが再計算プロセスを開始する
On Error Resume Next
tsk.SetField FieldNameToFieldConstant(“開始日”), Format(targetDate, “yyyy/mm/dd”)
‘ 3. エラーハンドリングとメモリ最適化
If Err.Number <> 0 Then
Err.Clear
End If
End Sub
—
3. シニアエンジニアが意識すべき「メモリとAPI」
大規模プロジェクトのVBA環境では、`ActiveProject` を安易に連発すると、COMポインタの解放漏れやメモリリークを誘発する。特に、数千行のタスクをループ処理する際は注意が必要だ。
オブジェクトの明示的解放と最適化の鉄則
1. Late Bindingの回避: `Dim tsk As MSProject.Task` と型を明示せよ。
2. ループ内の処理回数を最小化: `ScreenUpdating` をオフにし、`Calculation` を `Manual` に切り替えてから一括処理を行え。
3. 明示的なNothing: オブジェクト変数は必ず `Set obj = Nothing` で解放し、ガベージコレクションの負荷を軽減せよ。
‘ パフォーマンスを極限まで高めるための定石
Public Sub OptimizeBulkUpdate()
Application.ScreenUpdating = False
Application.Calculation = pjManual ‘ 計算エンジンを一時停止
Dim tsk As MSProject.Task
For Each tsk In ActiveProject.Tasks
If Not tsk Is Nothing Then
‘ ここにロジックを記述
End If
Next tsk
Application.Calculation = pjAutomatic ‘ 一括再計算
Application.ScreenUpdating = True
End Sub
—
4. レガシーシステム連携の極致：Windows APIの活用
外部システム（例えばSQL Server上の工数管理DB）とProjectを連携させる際、Projectのオブジェクトモデルだけでは不足する場合がある。その際は、Windows API（`User32.dll`）を用いてウィンドウハンドルを制御し、バックグラウンドでの同期を確実に行う必要がある。
もし君が、巨大なエンタープライズ環境でProjectをハックしようとしているなら、`Task`オブジェクトの`UniqueID`を常にキーとせよ。`ID`は行の移動で変化するが、`UniqueID`は不変だ。これはProject開発における「最大の戒律」である。
結びに：エンジニアとしての矜持
Project VBAを触ることは、単なるコーディングではない。それは、組織が走らせている「プロジェクトそのものの時空」を操作することと同義だ。
安易な日付計算は、未来の工数計算を歪ませ、プロジェクトマネージャーの信頼を失墜させる。君が書くその一行が、明日誰かの残業時間を左右するかもしれない。だからこそ、Projectのロジックに敬意を払い、エンジンの挙動をマスターした上で、コードを紡いでほしい。
「正しく計算できる」ことは最低条件だ。「最も効率的かつ安全に計算させる」ことこそが、我々アーキテクトの存在意義である。
