MS Projectの深淵：制約条件と依存関係の「静かなる衝突」をコードで制圧する
多くのVBAエンジニアは、MS Projectのタスクを「ただの行データ」と見なしている。だが、真のアーキテクトは知っている。Projectは、タスクが互いに干渉し合う「複雑系」そのものであることを。
特に「制約条件（Constraint）」と「依存関係（Link）」の競合は、大規模プロジェクトのスケジュールを崩壊させる癌だ。MS Projectは警告を発するが、数百のタスクを抱えるWBSでいちいちダイアログを閉じて回るのは、エンジニアの仕事ではない。
今回は、この競合を検知し、強引に「ASAP（できるだけ早く）」へ強制補正する、堅牢なオートメーション・ルーチンを共有する。
—
1. 競合の本質：なぜ「警告」は無視してはならないのか
MS Projectの制約条件は、依存関係（先行タスク）よりも強い優先権を持つことがある。
- 開始日固定（Must Start On）などを設定したタスクに先行タスクを追加すると、Projectは計算ロジック内で「論理的矛盾」を起こす。
- ユーザーの手動変更による「制約の固定」は、プロジェクトの柔軟性を殺す。
- 放置すれば、クリティカルパスの計算は無意味となり、ガントチャートは嘘をつき始める。
これをプログラムで解決するには、`Task.ConstraintType` プロパティを走査し、不適切な定数を動的に書き換える必要がある。
—
2. 実装：Constraint Cleaner (VBA)
このコードは、全タスクを走査し、依存関係があるにもかかわらず「制約が固定されている」タスクを抽出し、安全にASAPへリセットする。
Option Explicit
‘ プロジェクトの安定性を担保するための制約補正エンジン
Public Sub SanitizeTaskConstraints()
Dim proj As Project
Dim tsk As Task
Dim count As Long
Set proj = ActiveProject
‘ オブジェクトの明示的な解放とエラーハンドリングの徹底
On Error GoTo ErrorHandler
‘ 処理の高速化（描画の一時停止）
Application.ScreenUpdating = False
For Each tsk In proj.Tasks
If Not tsk Is Nothing Then
‘ サマリータスクはスキップ（手動調整が必須のため）
If Not tsk.Summary Then
‘ 先行タスクが存在し、かつ制約がASAPではない場合
If tsk.PredecessorTasks.Count > 0 Then
If tsk.ConstraintType <> pjAsSoonAsPossible Then
Debug.Print “Fixing Task: ” & tsk.Name
‘ 制約をASAPに強制変更
tsk.ConstraintType = pjAsSoonAsPossible
tsk.ConstraintDate = “NA” ‘ 日付リセット
count = count + 1
End If
End If
End If
End If
Next tsk
CleanUp:
Application.ScreenUpdating = True
MsgBox count & ” 件の制約競合を解消しました。”, vbInformation
Exit Sub
ErrorHandler:
Debug.Print “Error ” & Err.Number & “: ” & Err.Description
Resume CleanUp
End Sub
—
3. チーフアーキテクトの視点：パフォーマンスと安定性
メモリ管理の極意
VBAにおける`For Each`ループは、Project Object Modelの巨大なコレクションを走査する。数千行のタスクに対しては、`ScreenUpdating`をオフにするのは基本中の基本だ。さらにメモリのリークを防ぐため、ループ内のオブジェクト変数は必ず`Nothing`に倒す習慣をつけてほしい。
なぜ「手動修正」を許容しないのか
システム管理者が手動で修正を行えば、必ずヒューマンエラーが発生する。このコードの真の価値は「一貫性の担保」にある。制約条件をASAPで統一することで、クリティカルパスが「依存関係のみ」に依存するように純化される。これにより、スケジュール予測の精度が飛躍的に向上する。
レガシー環境への配慮
もしMS Projectが古いバージョン（2010以前など）であれば、オブジェクトモデルの挙動が不安定になることがある。その際は、Windows APIの`SendMessage`を使って、Projectのウィンドウハンドルを操作し、ダイアログを強制的に閉じる等の「黒魔術」が必要になるが、それはまた別の機会に話そう。
—
結論：ツールは「思想」を運ぶ
ただコードを書くのではない。プロジェクト管理者が無意識に抱えている「複雑なWBSへの恐怖」を、システムで解消するのだ。制約と依存の矛盾を放置することは、未来のバグを確定させることと同義である。
このツールを貴方の環境に組み込み、スケジュールの歪みを根絶せよ。真の自動化とは、システムを「あるべき姿」に保ち続ける、静かなるエンジニアリングである。
何かあれば、現場の最前線からまた深淵を覗いて見せよう。現場からは以上だ。
