【テクニカル・上級編】Project VBAによる「リソース平準化」の自動実行と結果の検証レポート作成 – Project VBA解析バイブル

MS Project VBAの深淵：リソース平準化の自動化と「真の検証」を実装する

プロジェクト管理の現場において、MS Projectの「リソース平準化（Leveling）」はブラックボックスに近い。UI上のボタン一つで済ませる運用は、小規模なプロジェクトでは許容されるが、数百のタスクと複雑な依存関係を持つエンタープライズ環境では、「平準化の定義」そのものをコードで制御し、実行結果を論理的に検証するプロセスが不可欠だ。

今日は、Project VBAの最深部を叩き、平準化オプションの精緻な制御と、その結果を判定するメカニズムについて、アーキテクトの視点から解説する。

—

1. Project オブジェクトモデルの「歪み」を理解する

多くのエンジニアが陥る罠は、`Application.LevelResources`を単純に呼び出すことだ。しかし、このメソッドはプロジェクトのメモリ状況やキューの状態に強く依存する。

我々が制御すべきは、`Project.LevelingOptions`オブジェクトだ。ここには、平準化の制約条件が全て詰まっている。これを無視して実行することは、目隠しで重機を操縦するようなものだ。

LevelingOptions の最適化戦略

Sub ConfigureLevelingEngine(proj As Project)
With proj.LevelingOptions
‘ 優先順位付けの基準（重要：デフォルトは手動設定に依存しすぎるため明示的に指定）
.LevelingOrder = pjLevelingOrderPriorityStandard

‘ 期間の制限（重要：制約を緩めすぎるとスケジュールが崩壊する）
.LevelWithinAvailableSlack = True

‘ 自動計算の抑制（大規模プロジェクトではループ処理前に計算を止める）
.AutoLevel = False
End With
End Sub

—

2. 実装：平準化実行と検証レポートの生成

平準化は、単にメソッドを叩いて終わりではない。「どのリソースが、どの程度過負荷（Overallocated）であったか」をスナップショットとして保持し、実行前後の差分を検証する必要がある。

以下は、平準化後の過負荷を検知する検証ロジックを含むプロトタイプコードだ。

Public Sub ExecuteAndValidateLeveling()
Dim proj As Project
Set proj = ActiveProject

‘ 1. 事前検証：過負荷リソースの列挙
Dim overAllocatedResources As Collection
Set overAllocatedResources = GetOverAllocatedResources(proj)

‘ 2. 平準化実行
On Error Resume Next
proj.LevelResources
If Err.Number <> 0 Then
Debug.Print “Critical Error: Leveling failed – ” & Err.Description
Exit Sub
End If
On Error GoTo 0

‘ 3. 事後検証とレポート出力
Dim remainingOverload As Collection
Set remainingOverload = GetOverAllocatedResources(proj)

Call GenerateVerificationReport(overAllocatedResources, remainingOverload)

‘ オブジェクトの明示的解放（VBAのGCを過信しない）
Set overAllocatedResources = Nothing
Set remainingOverload = Nothing
End Sub

Private Function GetOverAllocatedResources(proj As Project) As Collection
Dim res As Resource
Dim result As New Collection
For Each res In proj.Resources
‘ Overallocatedプロパティは計算コストが高いため注意が必要
If Not res Is Nothing Then
If res.Overallocated Then
result.Add res.Name
End If
End If
Next res
Set GetOverAllocatedResources = result
End Function

—

3. シニアエンジニアのための「極限の知見」

メモリとパフォーマンスの境界線

MS Projectのオブジェクトモデルは、COM経由のアクセスであるため、ループ内でのプロパティ参照は致命的な低速化を招く。`ActiveProject.Resources`を逐次参照するのではなく、配列またはコレクションに一度ロードしてから処理を回すのが定石だ。

Windows APIによる「強制終了」検知

大規模なプロジェクトでは、平準化中にProjectが「応答なし」になることが珍しくない。この際、`DoEvents`を挟むだけでは不十分だ。必要に応じて`FindWindow`や`PostMessage`等のWin32 APIを駆使し、アプリケーションのハンドル状態を監視する必要がある。

ログ出力の重要性

結果をイミディエイトウィンドウに出すだけで満足してはいけない。本番環境であれば、以下の情報をCSVまたはDBに書き出すアーキテクチャを組むべきだ。

• Timestamp: 実行時刻
• Target Project Name: 実行対象ファイル
• Pre-Leveling Count: 実行前の過負荷リソース数
• Post-Leveling Count: 実行後の過負荷リソース数
• Leveling Status: 成功/失敗および実行時間

—

4. 結び：エンジニアリングの美学

リソース平準化の自動化は、単なる定型業務の効率化ではない。「プロジェクトの健全性をプログラムで定義し、監視する」という高度なガバナンスの実装だ。

多くの者が「ツールがやってくれる」と信じて疑わないブラックボックスの中身を、一行のコードで制御し、その結果を数値で証明する。それが、我々エンジニアが手にするべき「真のコントロール」である。

次回の記事では、`Task`オブジェクトと`Assignment`オブジェクトを用いた、より粒度の細かい「個別タスクレベルの平準化制御」について、より踏み込んだ話をしようと思う。

レガシーであれ、最新環境であれ、本質は変わらない。コードを書き、システムを掌握せよ。