MS Project VBA：制約なき混沌を葬る。ASAP強制適用による計算エンジン正常化の処方箋
Project管理において、スケジューリングの「不確定性」は癌である。特に、レガシーなプロジェクトファイルには、制約条件（Constraint）が意図せず空欄のまま放置されたタスクが散見される。
MS Projectの計算エンジンは、制約が設定されていないタスクに対して「プロジェクト開始日」を起点とした計算を行うが、依存関係の変更や予期せぬクリティカルパスの断絶を引き起こす原因となりやすい。
今日は、無秩序なプロジェクトデータを「ASAP（できるだけ早く）」という鉄の規律で統制し、計算エンジンの挙動を100%予測可能にするためのVBA戦略を伝授する。
—
1. なぜ「制約なし」が危険なのか？
MS Projectにおいて、制約条件を明示的に設定しないことは、「エンジンの挙動をプロジェクトのデフォルト設定に委ねる」という怠慢に等しい。
- クリティカルパスの隠蔽: 制約が曖昧なタスクは、ネットワーク図上で計算上の「遊び（スラック）」を誤認させる。
- 計算負荷の増大: 複雑な依存関係の中でデフォルト挙動が衝突すると、再計算のオーバーヘッドが増大し、大規模ファイルでは保存時や更新時にフリーズを誘発する。
- データクレンジングの欠如: 誰かが「とりあえず入れた」タスクが、数ヶ月後のスケジュール再計算で予期せぬ日付に跳ね上がる。
プロのエンジニアは、「制約条件は、明示的に設定する」のが鉄則だ。
—
2. 堅牢な設計思想：無差別な適用は「死」を招く
コードを書く前に設計の指針を共有する。全てのタスクにASAPを適用すれば良いわけではない。
1. 「マイルストーン」と「手動タスク」の除外: これらに不用意にASAPを適用すると、手動で調整した日付が破壊される。
2. エラーハンドリング: COMオブジェクトの操作は、MS Projectの計算エンジンとの同期ズレが起きやすい。`Calculate`メソッドの適切なタイミングでの呼び出しが肝となる。
3. Undo（元に戻す）のコスト: 大量変更を行う場合は、`Application.UndoClear`を検討すべきだが、基本はユーザーが意図を理解できるようにプロセスを切り出す。
—
3. 実践コード：Project制約クレンジング・エンジン
以下のコードは、制約が未設定（`pjConstraintNone`）のタスクを検出し、ASAP（`pjASAP`）に変換する堅牢な実装だ。
Option Explicit
‘ @brief プロジェクト内の制約なしタスクをASAPに変換する
‘ @author Project Automation Architect
Public Sub NormalizeTaskConstraints()
Dim tsk As Task
Dim count As Long
‘ 画面更新を停止してパフォーマンスを向上
Application.ScreenUpdating = False
On Error GoTo ErrorHandler
For Each tsk In ActiveProject.Tasks
‘ ヌルタスク（空行）とサマリータスクを除外する判断も必要だが、
‘ 今回は実タスクのみを対象とする
If Not tsk Is Nothing Then
If Not tsk.Summary Then
‘ 制約が未設定（pjConstraintNone）のタスクのみをASAPへ
If tsk.ConstraintType = pjConstraintNone Then
tsk.ConstraintType = pjConstraintASAP
count = count + 1
End If
End If
End If
Next tsk
‘ 最後に再計算を実行し、エンジンの状態を確定させる
Calculate
MsgBox count & ” 件のタスクをASAP制約に更新しました。”, vbInformation
ExitPoint:
Application.ScreenUpdating = True
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
Resume ExitPoint
End Sub
このコードのポイント
- `tsk.Summary`のチェック: サマリータスクに対して制約を強いると、サブタスクの構成次第で思わぬ日付固定が発生する。サマリーは子タスクの計算結果をロールアップさせるべきであり、直接いじらないのが定石だ。
- `Calculate`の明示: VBAで値を変更した直後は、MS Projectの表示上の日付とメモリ上の計算値が乖離することがある。明示的な`Calculate`は必須の儀式である。
—
4. プロダクション環境への導入アドバイス
もしあなたが大規模なプロジェクトファイルを扱っているなら、以下の点に注意してほしい。
- バックアップ: 本番適用前に、必ずファイルコピーを作成すること。制約の変更は、一度行うとクリティカルパスを一気に書き換える破壊的な操作になり得る。
- ログ出力: どのタスクがいつ変更されたか、`Debug.Print`ではなく、別シートにログを出力する仕組みを組み込むことを推奨する。
- VBAプロジェクトの保護: このようなツールをチームに配布する場合、コードの改竄を防ぐためにVBAプロジェクトパスワードを設定し、かつモジュール構成をクリーンに保て。
終わりに：ツールは「規律」の代弁者である
制約なしタスクを放置することは、プロジェクトの「曖昧さ」を放置することと同義だ。VBAは単なる自動化ツールではない。あなたが定義した「正しいプロジェクト管理の姿」を、システム全体に強制するための最強の手段だ。
さあ、このコードを武器に、君のプロジェクトファイルを「計算可能な真理」へと浄化してほしい。技術は、誰が設計したかでその価値が決まる。
