【実務・中級編】初心者向け：VBAによる制約条件の一括削除と、プロジェクトの完全ASAP化 – Project VBA解析バイブル

Project VBA

2026.11.01

スケジュール計算エンジンの「呪縛」を解け：Project VBAによる制約条件の完全無力化とASAP化の極意

スケジュール計算エンジンの「呪縛」を解け：Project VBAによる制約条件の完全無力化とASAP化の極意

プロジェクト管理の世界において、Microsoft Projectは単なる「表計算ソフト」ではない。それは、複雑な依存関係とリソース制約を解くための「高度な計算エンジン」である。

しかし、現場の人間が手動で「○月○日開始」といった制約条件（Constraints）をタスクに刻み込むたび、このエンジンの純粋な計算ロジックは汚染され、スケジュールは「硬直」する。依存関係（Predecessors）に基づいた動的な動きが失われ、無理やり固定された日付が、後続のタスクを次々と不整合へと引きずり込んでいくのだ。

本記事では、プロジェクトを一度「白紙（ASAP状態）」に戻し、計算エンジンが本来の力を発揮できるフラットな状態へとリセットするための、堅牢なVBA実装手法を伝授する。単なるコードの書き方ではない。「エンジンのライフサイクルをどう制御するか」という設計思想の話だ。

1. なぜ、あなたの「制約解除スクリプト」は失敗するのか

初心者が書くコードは、大抵の場合、以下のような単純なループ処理に終始する。

' 典型的な「動かない」あるいは「遅い」コードの例
For Each t In ActiveProject.Tasks
    t.ConstraintType = pjTaskConstraintNone
Next t

一見、これで正解に見える。しかし、プロフェッショナルの視点で見れば、これには3つの致命的な欠陥がある。

① オブジェクトの生存確認（Nothingチェック）の欠如

Projectの`Tasks`コレクションには、削除されたタスクや、構造上「空」の状態の要素が含まれることがある。`Nothing`であるオブジェクトに対してプロパティを操作しようとした瞬間、ランタイムエラーでプロセスは死ぬ。

② 計算エンジンの過負荷（Recalculation Overhead）

Projectは、プロパティが変更されるたびにスケジュールを再計算しようとする。1,000個のタスクに対してループを回し、一つずつ制約を解除すれば、内部では1,000回の再計算が走る可能性がある。これは、大規模プロジェクトにおいて致命的なパフォーマンス低下を招く。

③ 制約（Constraint）と日付（Date）の混同

制約の種類を`pjTaskConstraintNone`（ASAP）に変えても、内部的な`ConstraintDate`プロパティに古い日付が残存している場合がある。エンジンの挙動を完全に制御するには、プロパティの「状態」を意識しなければならない。

2. プロダクション級の設計思想：Robust Reset Architecture

堅牢なツールを作るためには、以下の3層構造で設計を行うべきである。

1. State Management (状態管理): 計算モードを「手動」に切り替え、処理中の不要な再計算を封殺する。
2. Safe Iteration (安全な反復): `Nothing`チェックとエラーハンドリングを組み込み、例外が発生してもプロセスを破綻させない。
3. Final Synchronization (最終同期): 全ての操作が終わった後に、一度だけ強制的に再計算を実行し、プロジェクト全体を整合状態にする。

3. 実装例：Project完全ASAP化モジュール

以下に、実務の現場でそのまま投入できるレベルの、保守性と堅牢性を備えたコードを示す。

Option Explicit

''' <summary>
''' プロジェクト内の全タスクの制約条件を解除し、
''' ASAP（可能な限り早く）状態へ一括リセットする。
''' </summary>
Public Sub ResetProjectToASAP()
    Dim t As Task
    Dim taskCount As Long
    Dim resetCount As Long
    Dim startTime As Double
    
    ' 1. 前処理: パフォーマンス最適化
    ' 計算モードを手動に切り替え、プロパティ変更ごとの再計算を抑制する
    Application.Calculation = pjCalculationManual
    startTime = Timer

    On Error GoTo ErrorHandler

    ' 2. メインループ: 安全なオブジェクト走査
    For Each t In ActiveProject.Tasks
        ' オブジェクトの存在確認（Nothingチェックは必須）
        If Not t Is Nothing Then
            ' サマリータスクやマイルストーンを除外する必要があるかは要件次第だが、
            ' 通常、プロジェクト全体をフラットにする場合は全タスクを対象とする
            
            ' 制約の種類を「制約なし(ASAP)」に変更
            ' これにより、依存関係(Predecessors)による自動計算が優先されるようになる
            If t.ConstraintType <> pjTaskConstraintNone Then
                t.ConstraintType = pjTaskConstraintNone
                resetCount = resetCount + 1
            End If
            
            ' 念のため、制約日付が残存して悪影響を与えないようクリア（必要に応じて）
            ' ※ConstraintTypeをNoneにすれば通常は無視されるが、整合性のために念押し
            ' t.ConstraintDate = t.Start 
        End If
    Next t

    ' 3. 後処理: 状態の復元と再計算
    ' 計算モードを自動に戻し、一度だけ全体を再計算させる
    Application.Calculation = pjCalculationAutomatic
    ActiveProject.Calculate
    
    taskCount = ActiveProject.Tasks.Count
    
    ' 結果の通知
    MsgBox "リセット完了" & vbCrLf & _
           "対象タスク数: " & taskCount & vbCrLf & _
           "変更タスク数: " & resetCount & vbCrLf & _
           "実行時間: " & Format(Timer - startTime, "0.00") & " 秒", _
           vbInformation, "Success"

    Exit Sub

ErrorHandler:
    ' エラー発生時は計算モードを必ず自動に戻してから終了させる（重要）
    Application.Calculation = pjCalculationAutomatic
    MsgBox "致命的なエラーが発生しました。" & vbCrLf & _
           "Error No: " & Err.Number & vbCrLf & _
           "Description: " & Err.Description, vbCritical, "Fatal Error"
End Sub

4. 実務における「一歩先」の注意点

このスクリプトをデータベース連携や外部ツールの一部として組み込む場合、以下の設計的配慮を忘れてはならない。

データベース/ファイル連携時のトランザクション思考

もし、このVBAをExcelから呼び出したり、SQL Serverのデータに基づいてスケジュールを生成するワークフローの一部として使うなら、「失敗した時にプロジェクトをどう戻すか」を考えておく必要がある。
制約解除は「破壊的変更」である。実行前に必ずプロジェクトのバックアップ（`FileSaveAs`）を自動生成するロジックを組み込むのが、チーフアーキテクトとしての流儀だ。

ログの重要性

大規模な自動化ツールでは、`MsgBox`で結果を出すだけでは不十分だ。どのタスクに対して操作を行ったか、あるいはどのタスクでエラーが出たのかを、テキストファイルやログ用テーブルに書き出す仕組みを持たせよ。それが、運用フェーズでの「デバッグコスト」を劇的に下げる。

パフォーマンスの限界点

数万タスク規模のプロジェクトでは、`For Each`によるループ自体がボトルネックになる。その場合は、タスクのIDを配列に格納して一括処理する、あるいは特定の条件に合致するタスクのみを抽出するフィルタリングロジックを検討せよ。

結論

Project VBAにおける制約条件の制御は、単なるプロパティの書き換えではない。それは、プロジェクトの「意志」を、人間の強引な入力から、エンジンの論理的な計算へと解放する作業である。

「動けばいい」コードを書くのは今日で終わりにしろ。エンジンの挙動を理解し、例外を予測し、計算コストを管理する。それこそが、真の業務自動化エンジニアが備えるべき資質である。