Project VBAを掌握する極限の知見：計算エンジンの挙動を支配する「Options」制御術
多くの開発者が、Microsoft ProjectのVBA（MS Project Object Model）を扱う際、致命的なミスを犯している。それは、「タスクのプロパティを書き換えること」に終始し、「計算エンジンそのものの制御」を軽視している点だ。
数千、数万のタスクを持つ大規模プロジェクトにおいて、タスクの開始日や期間をループ処理で書き換えるコードを書いてみろ。画面はフリーズし、計算が走り続けるたびにCPU負荷は跳ね上がり、ユーザーは「ツールが重い」と不満を漏らすだろう。あるいは、計算が終わる前に次のデータが流し込まれ、スケジュールが矛盾した状態で確定するという、最悪のデータ整合性エラーを引き起こす。
プロフェッショナルは、タスクを操作する前に、まずエンジンのギアを切り替える。
本稿では、MS Projectの計算エンジンを完全に制御下に置き、パフォーマンスと堅牢性を極限まで高めるための`Application.Options`および計算モードの制御術について、アーキテクトの視点から解説する。
1. なぜ「Options」の制御が必要なのか
MS Projectは、単なるリスト形式のソフトウェアではない。依存関係、制約条件、リソース制約を複雑に絡め合わせ、動的にスケジュールを再計算する「制約充足エンジン」である。
デフォルトの設定（Automatic Calculation）では、VBAから一つのプロパティを変更するたびに、エンジンはプロジェクト全体の整合性を保とうと再計算を開始する。これは、1つの値を書き換えるたびに、巨大な数式を解き直しているようなものだ。
制御すべき主要なパラメーター
VBAから操作すべき核心的な要素は以下の2点である。
1. Calculation Mode (`Application.Calculation`):
計算を「自動（Automatic）」で行うか、「手動（Manual）」で止めるか。大量のデータ更新時には、これを `pjCalculationManual` に設定することが鉄則である。
2. Scheduling Options (`Application.Options`):
タスクのデフォルトの計算ロジック（ASAP/ALAPの挙動）や、計算の精度に影響を与える設定。
2. 堅牢な設計思想：State Management（状態管理）
業務ツールを設計する際、最も避けるべきは「エラー発生時にアプリケーションの状態が壊れたまま残ること」である。
例えば、計算モードを `Manual` に切り替えた後、コードの途中でエラーが発生して終了してしまったらどうなるか？ ユーザーが次にプロジェクトを開いたとき、スケジュールが全く更新されない「死んだプロジェクト」を渡すことになる。これは、ツール開発者としての敗北を意味する。
プロフェッショナルは、「元の状態を退避させ、処理完了後（あるいはエラー発生後）に必ず元の状態へ復元する」という、トランザクションのような設計を行う。
3. プロダクション・クオリティのコード実装
以下に、大量のタスクデータを更新するための、実戦投入可能なテンプレートコードを示す。単なるコピペではなく、なぜこのように書くのか、その設計意図を読み取ってほしい。
Option Explicit
''' <summary>
''' プロジェクトの計算モードを制御しながら、安全にタスクを更新する
''' </summary>
Public Sub BulkUpdateTasks(ByVal targetTaskID As Long, ByVal newDuration As Double)
Dim originalCalculation As MSProject.Calculation
Dim app As MSProject.Application
Set app = MSProject.Application
' 1. 現在の計算モードを退避 (State Preservation)
originalCalculation = app.Calculation
On Error GoTo ErrorHandler
' 2. 計算モードを「手動」に切り替え、エンジンを停止させる
' これにより、ループ中の不要な再計算を徹底的に排除する
app.Calculation = pjCalculationManual
' 画面更新の停止（パフォーマンス向上）
app.ScreenUpdating = False
' --- メインロジック開始 ---
Debug.Print "Processing Task ID: " & targetTaskID
Dim t As MSProject.Task
Set t = app.ActiveProject.Tasks(targetTaskID)
If Not t Is Nothing Then
' タスクの更新
t.Duration = newDuration
' ここで複雑な制約条件の変更などを想定
' 例: ASAP (As Soon As Possible) を明示的に設定
t.StartType = pjStartAsSoonAsPossible
Else
Err.Raise vbObjectError + 513, "BulkUpdateTasks", "Task not found."
End If
' --- メインロジック終了 ---
CleanUp:
' 3. 正常終了時もエラー時も、必ず元の状態に戻す (Restoration)
On Error Resume Next ' 復元処理自体のエラーによる二次災害を防ぐ
app.Calculation = originalCalculation
app.ScreenUpdating = True
Debug.Print "Calculation mode restored to: " & originalCalculation
Exit Sub
ErrorHandler:
' 4. エラーログの記録（実務ではDBやログファイルへ出力すべき）
MsgBox "Critical Error in BulkUpdateTasks: " & Err.Description, vbCritical
Resume CleanUp
End Subコードの設計ポイント
- `On Error GoTo ErrorHandler` + `CleanUp`: これが「プロの型」である。エラーが起きても、必ず `CleanUp` ラベルへジャンプさせ、計算モードを `Automatic` に戻す。
- `app.ScreenUpdating = False`: 計算エンジンだけでなく、UIの描画負荷も削る。これは大規模データ操作時の基本である。
- `pjCalculationManual`: データの書き込みが全て終わるまで、エンジンを眠らせておく。
4. 外部データ（DB/Excel）連携時の注意点：チャンク処理の概念
データベース（SQL Server等）やExcelから大量のデータを読み込み、Projectへ流し込む場合、さらに高度な戦略が必要になる。
すべてのレコードを一つずつ `Task.Start = …` と書き換えるのは、非効率の極みだ。もし、データが数万件規模になるのであれば、以下の設計を検討せよ。
1. バッチ（チャンク）更新:
1,000件ごとに計算モードを `Automatic` に戻して一度計算を実行し、再度 `Manual` に戻す。これにより、メモリ消費を抑えつつ、データの整合性を定期的にチェックできる。
2. I/Oと計算の分離:
「データの読み込み（I/O）」と「Projectへの書き込み（Calculation）」を明確に分けること。読み込み中に計算が走るのは、リソースの無駄遣いである。
5. まとめ：エンジニアとしての矜持
MS ProjectのVBA開発において、`Options` や `Calculation` プロパティを制御することは、単なるテクニックではない。それは、「アプリケーションのライフサイクルを完全に把握し、ユーザーに予測可能な挙動を提供するための責任」である。
「動けばいい」というコードは、現場ではバグの温床となる。
「計算エンジンの挙動を支配し、エラー時でも状態を保証する」コードを書く。
それこそが、伝説的なアーキテクトへの第一歩である。
君の書くコードが、プロジェクトの運命を左右することを忘れるな。
