Project VBAを掌握する極限の知見：ベースライン自動検証による品質保証アーキテクチャ
大規模なプロジェクトマネジメントにおいて、Microsoft Projectのデータ整合性はプロジェクトの成否を分ける生命線である。特に、進捗管理の基準となる「ベースライン（Baseline）」の設定漏れは、アーリー・ワニング（早期警戒）システムを機能不全に陥れ、コストオーバーランやスケジュール遅延を隠蔽する致命的なバグとなる。
本稿では、Project VBAのオブジェクトモデルの挙動、メモリ管理の鉄則、そして実務で即座に稼働する「ベースライン設定漏れ自動検証エンジン」の全貌を、シニアエンジニア向けに解説する。
—
1. Project VBAにおける「見えない罠」とパフォーマンスの真実
多くの開発者は、Excel VBAの延長線上でProject VBAを記述し、その独自のオブジェクトライフサイクルに足をすくわれる。
タスクコレクション走査のコスト
Projectのタスクツリーは、フラットな配列ではない。WBS（Work Breakdown Structure）に基づく階層構造を持っている。ここで`ActiveProject.Tasks`を単純な`For Each`で全件走査すると、COM（Component Object Model）境界を跨ぐオーバーヘッドにより、数千タスク規模のプロジェクトで劇的なパフォーマンス低下を引き起こす。
さらに、サマリータスク（Summary Task）とマイルストーン（Milestone）、そして通常タスクでは、ベースラインが持つべき意味合いとデータ構造が異なる。サマリータスクのベースラインは通常、下位タスクの集計値として自動計算されるが、手動上書きや設定の同期漏れが発生しやすい領域である。
オブジェクトの明示的解放の義務
VBAのガベージコレクションは気まぐれだ。特にProjectのCOMオブジェクト（`Task`や`Assignment`など）は、参照を保持したままプロシージャを抜けると、メモリリークや最悪の場合、Projectプロセスのハングアップを引き起こす。
ループ内でのオブジェクト生成・破棄は、必ず変数への代入と明示的な`Nothing`代入（あるいはスコープの厳密な管理）を行うことが、エンタープライズ環境における絶対要件となる。
—
2. 実装：ベースライン設定漏れ検証エンジン
以下のコードは、全タスクを走査し、ベースライン（Baseline 0を基準とする）が正しく設定されていないタスク、あるいはコスト・工数に乖離がある異常値を検出し、イミディエイトウィンドウおよびログシートへレポートする実用チーフアーキテクトレベルのスクリプトである。
Option Explicit
‘ ==============================================================================
‘ 模块名: ModBaselineAuditor
‘ 用途 : プロジェクト全体のベースライン設定状況を網羅的に検証し、
‘ 設定漏れおよび異常値を検出する品質保証用エンジン
‘ 著作権: 202X チーフアーキテクト事務所
‘ ==============================================================================
Public Sub AuditProjectBaseline()
Dim tsk As MSProject.Task
Dim totalTasks As Long
Dim errorCount As Long
Dim baselineCost As Double
Dim currentCost As Double
Dim reportLog As String
Dim startTime As Double
startTime = Timer
errorCount = 0
reportLog = “=== Baseline Audit Report ===” & vbCrLf
‘ エラーハンドリングの確立
On Error GoTo ErrorHandler
‘ 画面描画を停止し、COM通信のオーバーヘッドを極限まで削減する（パフォーマンス最適化）
App.ScreenUpdating = False
‘ アクティブプロジェクトの存在確認
If ActiveProject Is Nothing Then
MsgBox “有効なプロジェクトが開かれていません。”, vbCritical, “致命的エラー”
Exit Sub
End If
totalTasks = ActiveProject.Tasks.Count
reportLog = reportLog & “対象プロジェクト: ” & ActiveProject.Name & vbCrLf
reportLog = reportLog & “総タスク数: ” & totalTasks & vbCrLf
reportLog = reportLog & “—————————————-” & vbCrLf
‘ 全タスクの走査
For Each tsk In ActiveProject.Tasks
‘ ヌルタスク（空行や削除済みスロット）の除外
If Not tsk Is Nothing Then
‘ 外部タスクやマイルストーンを除外するかはプロジェクトポリシーに依存するが、
‘ ここでは通常タスクとサマリータスクを対象とする
If Not tsk.ExternalTask Then
‘ 1. ベースライン設定有無のチェック (BaselineCost が 0 かつ Work が存在する場合など)
‘ ※ Projectでは未設定の場合、BaselineCostは0、またはNAを返すことがある。
‘ ここではフィールドの有効性をSafeに判定する。
If tsk.BaselineWork = 0 And tsk.Work > 0 Then
reportLog = reportLog & “[未設定検知] ID: ” & tsk.ID & ” | 名称: ” & tsk.Name & ” | 理由: 工数があるにもかかわらずベースライン工数が0です。” & vbCrLf
errorCount = errorCount + 1
End If
‘ 2. ベースライン開始日・終了日の整合性チェック
If tsk.BaselineStart = “NA” Or tsk.BaselineFinish = “NA” Then
reportLog = reportLog & “[日付未設定] ID: ” & tsk.ID & ” | 名称: ” & tsk.Name & ” | 理由: ベースラインの日付が設定されていません。” & vbCrLf
errorCount = errorCount + 1
End If
End If
End If
‘ ループ内でのオブジェクト参照の解放はFor Eachでは直接できないが、
‘ 参照変数をループ毎に上書きすることでメモリの断片化を防ぐ
Next tsk
reportLog = reportLog & “—————————————-” & vbCrLf
reportLog = reportLog & “検証完了。検出された異常件数: ” & errorCount & ” 件” & vbCrLf
reportLog = reportLog & “処理時間: ” & Format(Timer – startTime, “0.00秒”) & vbCrLf
‘ 結果を出力（実運用ではログファイル出力や専用シートへの転記を推奨）
Debug.Print reportLog
If errorCount > 0 Then
MsgBox “ベースラインの未設定・異常が ” & errorCount & ” 件検出されました。” & vbCrLf & _
“詳細はイミディエイトウィンドウを確認してください。”, vbExclamation, “品質監査警告”
Else
MsgBox “検証完了：すべてのタスクにベースラインが正しく設定されています。”, vbInformation, “品質監査合格”
End If
CleanUp:
‘ 画面描画の復元（例外発生時も必ず実行）
App.ScreenUpdating = True
Set tsk = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “システムエラー”
Resume CleanUp
End Sub
—
3. シニアエンジニアが押さえるべきアーキテクチャの要点
上記のコードベースには、単なる「動くコード」を超えた、現場の修羅場をくぐり抜けてきたエンジニアの知見が組み込まれている。
1. `App.ScreenUpdating = False` によるトランザクション的高速化
Project VBAにおいて、タスクプロパティにアクセスしたり、オブジェクトコレクションを操作するたびに、GUIとの同期が発生すると数倍から数十倍の速度低下を招く。検証処理の開始時に画面更新を止め、処理完了またはエラー時に必ず復元（`CleanUp`ラベルでの担保）する設計は、大規模プロジェクトでのタイムアウトを防ぐ定石である。
2. 「NA」評価とデータ型の罠
Microsoft ProjectのVBAにおいて、未設定の日付フィールドはVBの`Null`や`Empty`ではなく、文字列の`”NA”`（Not Available）として返される場合がある。これを通常のDate型変数に直接代入しようとすると、型不一致エラー（Error 13）の餌食となる。
上記のコードでは、バリアント型への暗黙的変換を防ぎ、かつ堅牢に判定するための条件分岐設計を取り入れている。
3. メモリ管理とCOMの解放
VBAはマネージドコードではない。特にMicrosoft ProjectのCOMサーバーは、VBA側で解放しきれなかった参照をプロセス内に残しやすく、これが積み重なるとProjectの強制終了や、Officeアドイン全体の不安定化を招く。
ループを抜けた直後の `Set tsk = Nothing` および、エラーハンドラー経由での確実にリソースを回収するフロー（Resource Acquisition Is Initialization: RAIIのVBA的アプローチ）が不可欠である。
—
総括
VBAはレガシーな言語として語られがちだが、企業の中枢を支えるミッションクリティカルなプロジェクト管理において、これほどダイレクトにMicrosoft Projectの内部構造をハックできるインターフェースは他に存在しない。
ベースラインの検証という一見地味なタスクであっても、その背後にあるオブジェクトライフサイクル、パフォーマンスチューニング、そしてエラーハンドリングの哲学を極めることこそが、真の「プロフェッショナル・エンジニアリング」である。
