リソースの「最大単位（MaxUnits）」を科学する ― VBAで実現するプロジェクト稼働率の自動最適化
多くのPMが陥る罠がある。「リソースの最大単位（MaxUnits）を、なんとなく100%で設定する」という怠慢だ。
実務において、人間は機械ではない。会議、事務処理、突発的なトラブル。それらを考慮せず、計画値と実績の乖離を放置すれば、スケジュールは必ず崩壊する。今回は、過去のプロジェクト実績から「そのリソースが真に発揮できる最大稼働率」を算出し、ProjectのMaxUnitsを動的に最適化するアーキテクチャを伝授する。
なぜ「100%」という設定が破綻を招くのか
Project VBAにおいて、`Resource.MaxUnits`はリソースの供給能力を定義する。これを安易に100%（あるいはそれ以上）に固定すると、Projectの平準化エンジンはリソースを「常に全力で働ける神」として扱う。結果、オーバーアロケーション（過負荷）の検知が甘くなり、現場の疲弊とスケジュールの遅延が連鎖する。
真のエンジニアは、「過去3ヶ月の稼働実績（Actual Work / Planned Work）」から、そのリソースの現実的な最大稼働許容量（実効効率）を算出する。
システム設計の極意：疎結合と堅牢性
VBAで外部アプリケーション（Project）を制御する際、最も避けなければならないのは「不完全なオブジェクト参照によるメモリリーク」と「データ整合性の欠如」だ。
1. Late Bindingの採用: 参照設定に依存せず、環境変化に強い設計にする。
2. トランザクションの意識: Projectの操作は時間がかかる。`Application.ScreenUpdating` を制御し、イベントを一時停止させるのは定石中の定石だ。
3. データソースの分離: 過去の稼働実績はExcelのテーブルとして保持し、それを読み込んで計算する「計算エンジン」と「書き込みエンジン」を明確に分ける。
—
【プロダクションコード】稼働率最適化エンジン
このコードは、Excelのテーブルから実績データを読み込み、指定したProjectファイルの該当リソースのMaxUnitsを更新する。
Option Explicit
‘ 伝説的なエンジニアの設計：エラー処理とリソース解放を徹底する
Public Sub OptimizeResourceMaxUnits(ByVal projectPath As String)
Dim projApp As Object ‘ MS Project Application
Dim proj As Object
Dim res As Object
Dim targetEfficiency As Double
On Error GoTo ErrorHandler
‘ 1. Applicationの初期化（Late Binding）
Set projApp = CreateObject(“MSProject.Application”)
projApp.FileOpen projectPath
Set proj = projApp.ActiveProject
‘ 2. 稼働率計算（ここでは簡略化のため定数だが、実際はExcelテーブルから算出）
‘ 実績値から計算した「実効係数」を算出するロジックをここに挿入
targetEfficiency = 0.85 ‘ 例：過去の実績から導き出した最大許容稼働率（85%）
‘ 3. 全リソースのMaxUnitsを更新
projApp.ScreenUpdating = False
For Each res In proj.Resources
If Not res Is Nothing Then
‘ 稼働率を小数からパーセントへ変換して反映
res.MaxUnits = targetEfficiency
Debug.Print “Resource: ” & res.Name & ” Updated to ” & (targetEfficiency 100) & “%”
End If
Next res
projApp.FileSave
projApp.Quit
MsgBox “リソース最適化が完了しました。”, vbInformation
ExitPoint:
Set res = Nothing
Set proj = Nothing
Set projApp = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラー: ” & Err.Description, vbCritical
Resume ExitPoint
End Sub
実務で突き当たる壁と解決策
1. データ整合性の担保
Excel側で「誰がどのプロジェクトで何時間働いたか」を管理するテーブルを用意すること。`Work / (Total Duration 8h)` で算出される実効稼働率を移動平均で取ると、非常に精度の高い「最大単位」が導き出せる。
2. パフォーマンスの罠
プロジェクトファイルが大規模（数千行）の場合、`For Each` ループは遅延の原因になる。その場合は、一度データを配列（Variant Array）に取り込み、メモリ上で計算してから一括設定する手法（`Application.Batch`的な考え方）へ拡張すべきだ。
3. 保守性への投資
このマクロを「ただのツール」にしてはならない。
- ログ出力: どのリソースが、どの計算ロジックに基づいて何％に変更されたか、必ずログファイルに記録を残せ。
- ロールバック機能: 万が一、自動算出が極端な値（例えば0%など）になった場合に備え、前回の設定値をバックアップする処理を組み込むのが一流の仕事だ。
結びに代えて
ツールを作ることは、業務の型を作ることだ。リソースの最大単位を自動化するということは、現場の「無理」を数値で可視化し、組織を「持続可能なプロジェクト管理」へと導くことと同義である。
コードは嘘をつかない。君が設計したロジックが、プロジェクトの命運を左右するのだ。さあ、今すぐ自身の管理するプロジェクトのリソースデータを開き、このスクリプトを走らせてみてほしい。数値の向こう側に、本来あるべき健全な開発現場が見えてくるはずだ。
