【Project VBA】「制約条件」と「依存関係」の崩壊を許すな。WBS品質チェック・エンジンの設計思想
プロジェクト管理において、VBAでWBS（作業分解構成図）を制御している諸君。君たちの管理しているタスクリストは、本当に「生きている」か？
多くの現場で、WBSは単なる「絵に描いた餅」と化している。原因は明白だ。「開始日固定」という人為的な制約条件が、動的に変化する「依存関係（先行タスク）」の論理を破壊しているからだ。
今日は、この「論理の矛盾」を検知し、プロジェクトの崩壊を未然に防ぐための「品質チェック・エンジン」の設計論を授ける。
—
1. なぜ「制約」と「依存関係」が競合するのか
Project VBAにおいて、タスクは常に2つの圧力に晒されている。
1. 依存関係（ロジック）: 先行タスクが終わらなければ、後続タスクは開始できない。
2. 制約条件（エゴ）: 「この日は絶対に開始しなければならない」という管理者の強い意志。
この2つが矛盾したとき、Projectのスケジューラは「制約条件」を優先し、依存関係を無視してタスクを配置する。その結果、ガントチャート上では「先行タスクが完了していないのに、後続が開始している」という論理的デッドロックが発生する。
これを自動的に検知するのが、真の自動化エンジニアの責務だ。
—
2. 堅牢な設計：チェックロジックの要諦
闇雲にループを回すな。計算量を最適化し、メモリを浪費しない設計が求められる。
- 単一責任の原則: チェック機能は、修正機能とは分離せよ。まずは「ログを吐く」ことに特化させる。
- 早期リターン: 無効なタスクや制約のないタスクは、即座に評価対象から除外せよ。
- 構造化データへの変換: オブジェクト指向的なアプローチをVBAで模倣し、`Task`クラスを設計するか、あるいは辞書オブジェクト（`Scripting.Dictionary`）を使ってインメモリで高速に参照せよ。
—
3. 実践：競合検知エンジンのプロダクションコード
このコードは、Projectの`Tasks`コレクションを走査し、依存関係の論理に反する「制約付きタスク」を抽出する。
Option Explicit
‘ 依存関係と制約の矛盾を検知し、イミディエイトウィンドウにログを出力する
‘ 読者の環境に合わせて、ログをテキストファイルや別シートへ出力するよう拡張せよ
Public Sub AuditTaskConstraints()
Dim tsk As Task
Dim pred As TaskDependency
Dim isError As Boolean
Debug.Print “— 監査開始: ” & Now & ” —”
For Each tsk In ActiveProject.Tasks
If Not tsk Is Nothing Then
‘ 制約タイプが「開始日固定」等の場合のみチェック対象とする
If tsk.ConstraintType <> pjConstraintNone And tsk.ConstraintType <> pjConstraintAsSoonAsPossible Then
‘ すべての先行タスクを検証
For Each pred In tsk.TaskDependencies
‘ 先行タスクの終了日と、自タスクの制約日付を比較
‘ もし「先行タスク終了日 > 自タスクの開始制約日」なら矛盾
If pred.From.Finish > tsk.ConstraintDate Then
LogConflict tsk, pred
isError = True
End If
Next pred
End If
End If
Next tsk
If Not isError Then Debug.Print “論理矛盾は見つかりませんでした。”
Debug.Print “— 監査終了 —”
End Sub
Private Sub LogConflict(tsk As Task, pred As TaskDependency)
‘ 保守性を考慮し、エラー情報は詳細に出力する
Debug.Print “【矛盾検知】ID:” & tsk.ID & ” | Name:” & tsk.Name
Debug.Print ” -> 理由: 先行タスク[” & pred.From.Name & “]の終了(” & pred.From.Finish & “)”
Debug.Print ” -> 衝突: 制約日(” & tsk.ConstraintDate & “)”
End Sub
—
4. プロダクション環境における注意点
このコードを実務で運用する際、以下の3点に注意せよ。
1. カレンダーの罠: `Finish`の日付比較において、休日や労働時間を無視して単純比較すると誤検知を生む。`Application.DateAdd`等のメソッドを活用し、プロジェクトカレンダーの労働時間を考慮した比較を行うのがプロの所業だ。
2. 再帰構造の回避: 大規模なWBSでは、依存関係が数千に及ぶことがある。`TaskDependencies`の全走査は重い。特定の階層のみ、あるいは「現在進行中のフェーズ」に絞るフィルター機能を必ず実装せよ。
3. データベース連携: もしWBSをSQL Server等で管理しているなら、VBAで直接DBを叩くな。一旦中間テーブルにタスク状態をインポートし、矛盾検知はSQL（集合演算）で行え。 VBAはあくまで「UIと実行の仲介役」に徹するのが、高負荷に耐えうるアーキテクチャである。
—
最後に：エンジニアとしての矜持
自動化とは、単なる「作業の省略」ではない。「人間が気づけない論理の綻びを、コードによって先制的に可視化すること」だ。
このツールを導入することで、君のチームは「なぜスケジュールが守られないのか？」という不毛な議論から解放されるだろう。事実（データ）が語る論理矛盾を突きつければ、修正の優先順位は自ずと決まるはずだ。
さあ、コードを書き換えろ。君のプロジェクトが、もっと論理的で、美しいものになることを期待している。
