【テクニカル・上級編】【初心者向け】「制約なし」タスクのデフォルト挙動を理解する：プロジェクト開始日との連動ロジック – Project VBA解析バイブル

【極限の知見】Project VBAにおける「制約なし」の正体：プロジェクト開始日とASAPロジックの連動を掌握する

エンジニアが「制約（Constraint）を設定していない」と口にする時、そこには重大な誤解が潜んでいる。

Microsoft Projectにおける「制約なし」とは、エンジンの制御を放棄した状態ではない。それは、`pjTaskConstraintAsSoonAsPossible` (ASAP: As Soon As Possible) という、プロジェクト開始日および先行タスクとの依存関係に強く拘束された、極めて動的なデフォルト挙動を指しているのだ。

本記事では、初心者が陥りがちな「意図しない日付のズレ」という事象を、計算エンジンの低レイヤーな挙動から解き明かす。シニアエンジニアが、大規模なスケジュール管理システムを構築・保守する際に不可欠となる、エンジンの挙動制御とメモリ管理の真髄を伝授しよう。

1. 「制約なし」という名の、暗黙の制約

多くの開発者は、タスクの `ConstraintType` プロパティを意識せずにコードを書く。しかし、Projectの計算エンジン（Scheduling Engine）は、常に以下の数式を解き続けている。

$$Task_{Start} \ge \max(Project_{Start}, \text{Predecessor}_{Finish} + \text{Lag})$$

ここで重要なのは、制約を設定していないタスクは、プロジェクト開始日（`Project.Start`）という絶対的な基準点に、論理的な鎖で繋がれているという事実だ。

プロジェクト開始日を変更した瞬間、すべての「制約なし」タスクは、連鎖的に再計算（Recalculate）の波に飲み込まれる。これが、大規模プロジェクトにおいて、一箇所の変更がシステム全体の整合性を揺るがす「日付ドリフト」の正体である。

2. 計算エンジンの挙動をシミュレートする

単に日付を変えるだけでは、エンジニアの仕事ではない。エンジンの挙動を定量的に把握するために、VBAを用いて「プロジェクト開始日の変更が、制約なしタスクに与える影響」をシミュレートするコードを記述する。

ここでは、パフォーマンスを最大化し、計算エンジンのオーバーヘッドを最小限に抑えるための作法（`Calculation` モードの制御）を組み込んでいる。

Option Explicit

' ======================================================================================
' Module: SchedulingEngineSimulator
' Description: プロジェクト開始日の変更に伴う、ASAPタスクの挙動をシミュレートする
' Author: Legendary Chief Architect
' ======================================================================================

Sub SimulateDateDrift()
    Dim pj As MSProject.Application
    Set pj = MSProject.Application
    
    ' 高速化のための定石：計算モードをマニュアルに切り替え、再計算の暴走を防ぐ
    ' エンジンへの負荷を制御することは、大規模システムにおける鉄則である
    Dim originalCalc As MSProject.Calculation
    originalCalc = pj.Calculation
    pj.Calculation = pjCalculationManual
    
    ' 画面更新の停止（UIスレッドの負荷軽減）
    pj.ScreenUpdating = False

    On Error GoTo ErrorHandler

    ' 1. テストデータの構築
    ' ここでは、制約なしタスクの連鎖を構築する
    Dim t As MSProject.Task
    Dim i As Integer
    Const TaskCount As Integer = 100
    
    ' 既存タスクのクリア（クリーンな環境でのシミュレーション）
    pj.SelectAll
    pj.DeleteSelected
    
    ' タスクの生成
    For i = 1 To TaskCount
        Set t = pj.Tasks.Add("Task " & i)
        t.Duration = "1d"
        If i > 1 Then
            ' 先行タスクを設定（連鎖的な依存関係の構築）
            t.Predecessors.Add pj.Tasks(i - 1).ID
        End If
    Next i

    ' 2. 初期状態の記録
    Dim initialStart As Date
    initialStart = pj.ProjectStart
    Debug.Print "--- Initial State ---"
    Debug.Print "Project Start: " & initialStart
    Debug.Print "Task 1 Start: " & pj.Tasks(1).Start
    Debug.Print "Task " & TaskCount & " Start: " & pj.Tasks(TaskCount).Start

    ' 3. プロジェクト開始日の変更（これがトリガーとなる）
    Dim newStart As Date
    newStart = DateAdd("d", 10, initialStart)
    pj.ProjectStart = newStart
    
    ' ここでエンジンの再計算を明示的に指示する
    ' 計算モードがManualの場合、この呼び出しがなければ日付は更新されない
    pj.Calculate

    ' 4. 結果の検証
    Debug.Print "--- Post Drift State ---"
    Debug.Print "Project Start: " & pj.ProjectStart
    Debug.Print "Task 1 Start: " & pj.Tasks(1).Start
    Debug.Print "Task " & TaskCount & " Start: " & pj.Tasks(TaskCount).Start

    ' 検証ロジック：ASAPタスクはプロジェクト開始日に同期しているか？
    If pj.Tasks(1).Start = pj.ProjectStart Then
        Debug.Print "SUCCESS: Task 1 is correctly anchored to Project Start."
    Else
        Debug.Print "FAILURE: Task 1 drifted unexpectedly."
    End If

CleanUp:
    ' オブジェクトの明示的な解放（メモリリーク防止の極意）
    ' 大規模なループや頻繁なAPI呼び出しを行う場合、この作法を怠るとメモリが枯渇する
    Set t = Nothing
    Set pj = Nothing
    
    ' 設定の復元
    pj.Calculation = originalCalc
    pj.ScreenUpdating = True
    Exit Sub

ErrorHandler:
    MsgBox "Critical Error in Simulation: " & Err.Description, vbCritical
    Resume CleanUp
End Sub

3. アーキテクトの視点：メモリ管理とパフォーマンスの極限

上記のコードには、単なる「書き方」を超えた、システム管理者が知るべき設計思想が組み込まれている。

3.1 `Calculation` モードの制御

Project VBAにおいて、最も重い処理は `Calculate` である。ループ内でタスクのプロパティ（`Start`, `Finish`, `Duration` 等）を書き換えるたびに、エンジンが再計算を試みる設定（`pjCalculationAutomatic`）になっていると、計算量は指数関数的に増大する。
「書き込みはManualで行い、最後に一括でCalculateする」。これは、VBAを組み込んだエンタープライズ・スケジューリング・システムにおける黄金律である。

3.2 オブジェクトのライフサイクル

`Set t = Nothing` という記述を軽視してはならない。ProjectはCOM（Component Object Model）アーキテクチャに基づいている。VBAの変数がスコープを抜けても、参照カウントが残っている限り、背後のメモリ領域は解放されない。特に、外部アプリケーション（Excelや独自開発のC++モジュール）からProjectを操作する場合、この「参照の残留」が原因で、プロセスがゾンビ化し、メモリを食いつぶす事態を招く。

3.3 Windows APIによる高精度な計測（応用）

もし、あなたがこのシミュレーションの実行時間をナノ秒単位で計測し、エンジンのスループットを分析したいのであれば、`QueryPerformanceCounter` を用いるべきだ。

' Windows APIの宣言
If VBA7 Then
    Declare PtrSafe Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
    Declare PtrSafe Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Else
    Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
    Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
End If

' 計測の概念（概念コード）
' 1. QueryPerformanceFrequencyで周波数を取得
' 2. 処理前後にQueryPerformanceCounterを呼び出し
' 3. 差分を周波数で除して、真の実行時間を算出する

これを用いることで、コードの変更（例えば制約条件の追加）が、計算エンジンにどれほどのオーバーヘッドを与えるかを、数学的に証明することが可能になる。

4. 結論：制御不能な日付を排除せよ

「制約なし」は、自由を意味しない。それは「プロジェクト開始日と依存関係に従う」という、エンジンのアルゴリズムへの完全な委譲である。

システム開発者は、以下の3点を肝に銘じておくべきだ。
1. デフォルトの挙動（ASAP）を、仕様として定義せよ。
2. 大量のデータ操作を行う際は、必ず `Calculation = Manual` でエンジンを封じ込めよ。
3. オブジェクトの解放と、計算負荷の計測を、設計の初期段階から組み込め。

これらを掌握して初めて、あなたは「Projectを動かす使い手」から、「Projectを制御するアーキテクト」へと昇華することができる。