Project VBAの深淵：ConstraintDateが引き起こす「日付の呪い」と回避の鉄則
Project VBA（Microsoft Project Object Model）を操る際、`Task.ConstraintDate` プロパティほど、シニアエンジニアを疲弊させるプロパティはない。
「なぜか開発環境では動くのに、クライアントのPC（OS設定が異なる環境）ではエラーを吐く」
「特定のタスクだけ計算エンジンが想定外の挙動を示す」
これらは単なるコードミスではない。VBAが抱えるレガシーな日付処理と、Projectのスケジュールエンジンが持つ厳格な制約条件との間で発生する、「ロケール依存の同期不全」だ。今日は、この落とし穴を物理レベルで封じ込めるための極限の知見を授ける。
—
1. なぜ `DateValue` だけでは不十分なのか
多くの初級エンジニアは、日付を文字列から変換する際に `DateValue(“2023/12/31”)` を使う。しかし、これは危険な賭けだ。
Windowsのコントロールパネルで「地域」設定が変更されていれば、`DateValue` は文字列を解釈できず、ランタイムエラーを投げる。また、Projectのスケジュールエンジンは、内部的に `Variant` 型の値を `Double`（シリアル値）として受け取ることを好む。文字列として日付を渡すと、暗黙的なキャストが発生し、そこにロケールの解釈が入り込む余地が生まれるのだ。
2. 極限の回避策：シリアル値による直接注入
最も安全な方法は、日付を文字列として扱わず、最初から数値（シリアル値）として制御することだ。これにより、OSのロケール設定から完全に独立できる。
‘ プロジェクトの制約日付を安全に設定するためのアーキテクチャ
Public Sub SetTaskConstraintSecure(ByRef tsk As Task, ByVal targetDate As Date)
‘ 1. 引数のDate型をDouble（シリアル値）に変換し、文字列解釈の余地を排除
‘ 2. 制約タイプを固定し、エンジンを再計算モードに持ち込む前にメモリをクリーンに保つ
Dim dblDate As Double
dblDate = CDbl(targetDate)
‘ プロパティへの直接代入は型の不一致を招くリスクがあるため、
‘ エンジンに直接シリアル値を渡すアプローチをとる
On Error Resume Next
tsk.ConstraintDate = dblDate
If Err.Number <> 0 Then
‘ ここにログ出力処理を実装：システム保守におけるトレースの要
Debug.Print “Error setting constraint on Task ID: ” & tsk.ID
End If
On Error GoTo 0
End Sub
3. メモリ管理とパフォーマンスの最適化
Project VBAで大規模なスケジュールを操作する場合、オブジェクトの参照を放置することは「メモリリークの温床」となる。特に `Task` オブジェクトをループで回す際は、参照カウンタを意識しなければならない。
- 明示的なNothing代入: `Set tsk = Nothing` をループの終端で必ず実行せよ。
- イベントの抑止: `Application.ScreenUpdating = False` は基本だが、`Application.Calculation = pjManual` に設定することで、制約日付変更ごとのエンジン再計算を抑制し、処理速度を劇的に向上させること。
‘ パフォーマンスを極限まで高めるための定型
Public Sub OptimizeConstraintBatch(ByVal proj As Project)
‘ エンジンを停止させ、更新効率を最大化する
Dim calcMode As Long
calcMode = Application.Calculation
Application.Calculation = pjManual
‘ … ここでTask操作を実行 …
‘ 最後に戻す
Application.Calculation = calcMode
End Sub
4. システム間連携における「境界線」の設計
もし外部DBやWeb APIから日付データを受け取る場合、「ISO 8601形式（YYYY-MM-DD）」で取得し、それを `DateSerial(年, 月, 日)` でVBAの内部表現に変換するというパイプラインを構築すること。
これにより、クライアントPCの「YMD」か「MDY」かという、古臭いOS設定の呪縛から完全に解放される。
最後に：シニアエンジニアの矜持
Project VBAは古い技術だが、その背後にあるスケジュールエンジンは今なお現役の極めて強力な計算機だ。APIが要求しているのは「解釈」ではなく「厳密な数値」である。
「動けばいい」という考えを捨て、OSの地域設定という不確実な変数からシステムを切り離すこと。それが、真に堅牢なエンタープライズシステムを構築する唯一の道だ。
コードを記述する際、常に「この行は、10年後の保守担当者と、全く異なるロケールのPC上で何を引き起こすか」を自問自答せよ。その思考の積み重ねこそが、アーキテクトの魂である。
