【実務・中級編】【上級者向け】カスタムフィールドの数式内にVBAのユーザー定義関数（UDF）を擬似的に組み込む – Project VBA解析バイブル

MS Projectの計算限界を突破せよ：イベント駆動型「擬似UDF」によるカスタムフィールド制御の極意

MS Projectを利用して高度なプロジェクト管理を試みるエンジニアが、必ずと言っていいほど突き当たる「壁」がある。それは、カスタムフィールドの数式（Formula）の貧弱さだ。

「ExcelならVLOOKUPが使える」「SQLなら複雑なJOINができる」「VBAなら外部APIを叩ける」――。それに対し、MS Projectの数式エンジンは、極めて限定的な関数しか提供していない。複雑なビジネスロジック、外部データベースとの照合、あるいは特定の条件に基づいた動的な文字列操作を行おうとした瞬間、あなたは「数式では不可能」という絶望に直面するだろう。

しかし、諦めるのは早い。我々アーキテクトに与えられた武器は、数式エンジンではなくVBA（Visual Basic for Applications）だ。

本稿では、MS Projectの数式制限を完全に無効化し、VBAのロジックをカスタムフィールドに注入する、「イベント駆動型・擬似UDF（User Defined Function）」の実装術を伝授する。これは単なるプログラミングではない。プロジェクトの整合性を守り抜くための「設計思想」である。

1. なぜ「手動マクロ」ではいけないのか

初心者がやりがちな失敗がある。それは、「計算が必要な時に、ボタンを押してマクロを実行し、カスタムフィールドの値を書き換える」という手法だ。

これは一見、動いているように見える。しかし、実務レベルのツールとしては「設計の敗北」である。

• データの不整合: ユーザーがタスク期間を変更した直後、マクロを実行し忘れたら？ その瞬間に、表示されている計算結果は「嘘」になる。
• ユーザー体験の欠如: 常に「計算ボタン」を意識させるツールは、ユーザーの思考を分断し、入力ミスを誘発する。
• 信頼性の喪失: プロジェクト管理ツールにおいて、最も致命的なのは「数値が信用できないこと」だ。

我々が目指すべきは、「ユーザーが気づかないうちに、裏側で常に最新の計算結果が反映されている状態」。つまり、数式（Formula）と同じ感覚でVBAのロジックを動作させる「擬似UDF」の構築である。

2. アーキテクチャ設計：イベント駆動のメカニズム

MS Projectには、オブジェクトの状態変化を検知する「イベント」が存在する。これを利用し、特定のプロパティ（期間、リソース、コストなど）が変更された瞬間に、VBAのロジックを走らせる。

採用すべきイベント

• `Project_Change`: プロジェクト内のオブジェクト（Task, Resource等）に変更があった際に発生する。

設計の鉄則：計算コストの最小化

ここが腕の見せ所だ。`Project_Change`は非常に頻繁に発生する。すべてのタスクに対して、すべてのカスタムフィールドを毎回再計算するような愚かな実装（$O(N)$のループ）を書けば、プロジェクトが巨大化した瞬間にMS Projectはフリーズする。

「変更されたオブジェクトを特定し、その周辺のみを計算する」。この局所化こそが、プロフェッショナルな設計の絶対条件だ。

3. プロダクション・コード：堅牢な擬似UDFの実装例

以下に、タスクの「期間」と「リソース負荷」に基づいて、カスタムフィールド（`Text1`）に「リスクレベル」を自動的に書き込む、実戦的なコード例を示す。

このコードは、`ThisProject`モジュールに記述することを想定している。

Option Explicit

' ==============================================================================
' 擬似UDFエンジン：カスタムフィールド自動計算モジュール
' 目的: タスク変更時に特定のロジックに基づきText1(リスク判定)を更新する
' ==============================================================================

Private Sub Project_Change(ByVal Name As String, ByVal Arg As Long)
    On Error GoTo ErrorHandler

    Dim t As Task
    Dim targetTask As Task
    
    ' 1. 変更対象の特定
    ' Nameには変更されたオブジェクトの名前が入るが、
    ' Project VBAのChangeイベントは、どのタスクが変わったかを直接返さない場合がある。
    ' そのため、Selection（選択範囲）または、変更のコンテキストを利用して対象を絞り込む。
    
    ' 効率化のため、現在選択されているタスク、または変更が起きたタスクを特定
    ' ※実務では、変更されたプロパティ(Arg)を判定して、計算が必要な時のみ実行する。
    
    ' 簡易的な実装として、選択中のタスクを対象とする（パフォーマンス重視）
    If ActiveProject.Tasks.Count = 0 Then Exit Sub
    
    ' 変更が発生したタスクを特定するロジック（SelectedTasksを利用）
    ' ユーザーが編集中のタスクに対してのみロジックを適用することで、計算負荷を最小化する
    For Each t In ActiveProject.SelectedTasks
        Set targetTask = t
        
        ' 2. 計算ロジックの実行 (ここが擬似UDFの本体)
        UpdateRiskLevel targetTask
    Next t

CleanUp:
    Exit Sub

ErrorHandler:
    ' 業務ツールにおいて、エラーでプロジェクトを落とすことは許されない。
    ' ログ出力、あるいはステータスバーへの通知に留める。
    Debug.Print "Error in Project_Change: " & Err.Description
    Resume CleanUp
End Sub

''' <summary>
''' タスクのリスクレベルを計算し、Text1フィールドに書き込む
''' </summary>
''' <param name="t">対象のTaskオブジェクト</param>
Private Sub UpdateRiskLevel(ByVal t As Task)
    If t Is Nothing Then Exit Sub
    
    Dim riskScore As Double
    Dim riskLabel As String
    
    ' --- 複雑なロジックの例 (本来は外部DBや複雑な数式で行う内容) ---
    ' 例: (期間が長い) AND (リソースが不足している) = 高リスク
    
    ' 期間(Days)と、割り当てられたリソースのコストを組み合わせた独自のスコア計算
    riskScore = t.Duration / 480 ' 8時間単位での重み付け
    
    ' リソース負荷の判定（ここでは簡易的にコストで代用）
    If t.Cost > 100000 Then
        riskScore = riskScore * 1.5
    End If
    
    ' スコアに基づいたラベル付け
    Select Case riskScore
        Case Is >= 10
            riskLabel = "🔴 CRITICAL"
        Case Is >= 5
            riskLabel = "🟡 WARNING"
        Case Else
            riskLabel = "🟢 STABLE"
    End Select
    ' ---------------------------------------------------------

    ' 3. 値の反映
    ' 無限ループを防ぐため、値が変わる場合のみ書き込む
    If t.Text1 <> riskLabel Then
        t.Text1 = riskLabel
    End If
End Sub

コードの解説：なぜこれが「プロの書き方」なのか

1. `On Error GoTo ErrorHandler` の徹底:
ユーザーの予期せぬ操作（タスクを削除した瞬間に変更イベントが走る等）でマクロがクラッシュすると、プロジェクトファイル全体が破損するリスクがある。エラーを握り潰すのではなく、適切にトラップして「静かに」処理を終了させるのが鉄則だ。
2. `If t.Text1 <> riskLabel Then` による再帰防止:
値を書き換えると、再び`Change`イベントが発生する可能性がある。値が既に一致している場合は書き込みをスキップすることで、無限ループ（スタックオーバーフロー）を回避している。これはイベント駆動設計における絶対的な規律だ。
3. 計算範囲の局所化 (`SelectedTasks`):
全タスクをループさせるのではなく、`SelectedTasks`（ユーザーが操作している範囲）に絞ることで、数千タスクあるプロジェクトでも遅延を感じさせないレスポンスを実現している。

4. さらなる高みへ：外部データ（SQL/CSV）との連携

この「擬似UDF」の真の価値は、VBAの全機能を使える点にある。例えば、`UpdateRiskLevel`の中で、`ADODB.Connection`を用いて社内のSQL Serverから最新の「プロジェクト予算」や「リソース単価」を取得し、それを計算に組み込むことが可能だ。

' 実装イメージ：SQL Serverから単価を取得して計算に使う
Dim conn As Object
Set conn = CreateObject("ADODB.Connection")
conn.Open "Provider=SQLOLEDB;Data Source=SERVER_NAME;Initial Catalog=DB_NAME;Integrated Security=SSPI;"

Dim rs As Object
Set rs = conn.Execute("SELECT UnitCost FROM ResourceMaster WHERE ResName = '" & t.ResourceName & "'")

If Not rs.EOF Then
    ' SQLから取得した単価を用いて計算...
End If

このように、「MS Projectの外にある真実」を、カスタムフィールドの中に持ち込む。これが、単なるツール作成者と、システムアーキテクトを分かつ境界線である。

結論：設計思想がツールを定義する

MS Projectのカスタムフィールドを、単なる「表示用の箱」として使うのは今日限りでやめなさい。

VBAによるイベント駆動型の実装を選択することで、カスタムフィールドは「動的なビジネスロジックの実行エンジン」へと昇華する。ただし、その代償として、パフォーマンス管理とエラーハンドリングに対する極めて高い責任が伴うことを忘れてはならない。

「動けばいい」という考えを捨て、「いかに効率的に、いかに堅牢に、いかに透明に」を追求せよ。その先にのみ、真にプロフェッショナルな業務自動化の世界が待っている。