MS Project VBAの深淵：ConstraintType一括操作でスケジュールを「制御」せよ
現場でMS Projectを扱っていると、誰もが一度は直面する壁がある。「すべて『できるだけ早く（ASAP）』に設定されたタスク群に対し、特定のフェーズだけ制約をかけて遅延リスクをシミュレーションしたい」という要求だ。
GUIで一つひとつポチポチと設定を変える？ それはエンジニアの仕事ではない。今回は、Project VBAのオブジェクトモデルを掌握し、堅牢かつ高速にタスク制約を一括変更する「プロフェッショナルな設計術」を伝授する。
—
1. なぜ「単純なループ」で事故が起きるのか
多くの初心者は、`ActiveProject.Tasks`を単純にFor Eachで回し、`Task.ConstraintType = pjMustStartOn` と書く。これが地獄の始まりだ。
MS Projectのスケジュールエンジンは、タスクの属性変更を検知するたびに再計算を試みる。数千行のタスクに対して一括でプロパティを叩けば、計算負荷でCPUは悲鳴を上げ、最悪の場合、予期せぬ依存関係の連鎖でスケジュールが崩壊する。
堅牢な設計のための3つの鉄則
1. CalculationModeの制御: 処理中は手動計算モードへ切り替え、最後に一度だけ再計算させる。
2. エラーハンドリングの徹底: プロセス中に「読み取り専用」や「サマリータスク」への誤操作を防ぐ。
3. オブジェクトのキャッシュ: `ActiveProject`への頻繁なアクセスを避け、ローカル変数に保持してオーバーヘッドを減らす。
—
2. プロダクションコード：ConstraintBulkUpdater
このコードは、単なるスクリプトではない。実務の現場で「事故を未然に防ぐ」ために設計されたテンプレートだ。
Option Explicit
‘ ———————————————————
‘ 目的: 指定したタスク群の制約を一括変更し、スケジュールを再計算する
‘ 注意: 実務投入前に必ずバックアップを取ること
‘ ———————————————————
Public Sub UpdateTaskConstraints()
Dim proj As Project
Dim tsk As Task
Dim calcMode As Long
Set proj = ActiveProject
‘ 1. 計算モードを一時的に手動へ切り替え（パフォーマンス最適化）
calcMode = Application.Calculation
Application.Calculation = pjManual
On Error GoTo ErrorHandler
‘ 2. タスクを走査して制約を更新
For Each tsk In proj.Tasks
‘ サマリータスクや空行を除外するフィルタリング
If Not tsk Is Nothing Then
If Not tsk.Summary Then
‘ 例：特定のカスタムフラグが立っているタスクのみ対象にする等の条件分岐を推奨
‘ ここでは全タスクを「指定日開始(MSO)」に変更する例
tsk.ConstraintType = pjMustStartOn
tsk.ConstraintDate = Date ‘ 現在日を強制制約日とする
End If
End If
Next tsk
‘ 3. 処理完了後に再計算を実行
Application.Calculation = calcMode
proj.Calculate
MsgBox “制約変更とスケジュール再計算が完了しました。”, vbInformation
Exit Sub
ErrorHandler:
Application.Calculation = calcMode
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
End Sub
—
3. 実務で「データベース連携」を行う際の極意
このツールを外部システム（Excelの進捗管理表やSQL Server）と連携させる場合、以下の点に注意せよ。
- データ型の一致: Projectの`ConstraintDate`は`Variant`型だが、内部的には日付型を期待している。外部から読み込む際は、必ず`CDate()`で明示的に変換すること。
- タスクIDの脆さ: 「ID」は行の挿入で変わる。データ連携のキーとしては決して使ってはならない。代わりに`UniqueID`を使用する設計にせよ。
- トランザクション思考: データベース連携時にエラーが起きた際、Project側の変更をどこまでロールバックさせるか。`Application.Undo`機能の限界を理解し、可能であれば「処理前のプロジェクトファイル保存」を強制する運用を組むのが賢明だ。
—
4. 最後に：エンジニアとしての矜持
VBAはレガシーと言われることもあるが、MS Projectのオブジェクトモデルを直接操作できるのは、今のところVBA（またはCOM経由のインターフェース）だけだ。
「ボタンを押せば何かが変わる」ツールを作るのは誰でもできる。しかし、「計算負荷を考慮し、予期せぬ依存関係による崩壊を防ぎ、かつ保守可能なコードを書く」ことが、我々アーキテクトに求められる責任だ。
このコードをベースに、君のプロジェクトの要件に合わせてロジックを磨き上げてほしい。理論とコードが噛み合ったとき、プロジェクトマネジメントは「管理」から「制御」へと進化するはずだ。
