【テクニカル・上級編】【中級者向け】タスクの「インデントレベル」を判定して、WBS番号を自動採番する汎用パーサー – Project VBA解析バイブル

スポンサーリンク

Project VBA: WBS番号自動採番パーサー – 伝説的アーキテクトが語る階層構造の解剖学

長年、Project VBAの深淵に挑み続けてきた者として、語らせていただこう。我々が日々格闘する「タスク」という名の構造物。その真の姿は、単なるリストの羅列ではない。そこには、人間の思考プロセスが凝縮された、洗練された階層構造、すなわちWBS（Work Breakdown Structure）が息づいている。

しかし、この構造を人力で管理することの非効率性、そしてそれに伴うエラーの頻発は、開発現場の隠された病巣であった。ましてや、カスタムフィールドへのWBS番号の自動書き出しなど、かつては夢物語の領域であったと言っても過言ではない。

本稿では、その「夢物語」を現実のものとするための、実践的なアプローチを、伝説的アーキテクトの視点から、魂を込めて深掘りしていく。我々が到達すべきは、単なる「動くコード」ではない。それは、メモリの鼓動を理解し、APIの囁きを聞き分け、レガシーの呪縛すら解き放つ、極限の知見である。

WBS番号自動採番の核心：インデントレベルの解析

WBS番号、例えば「1.1.1」といった形式で表現されるそれは、タスクの階層構造を直接的に反映している。この番号を自動生成するためには、まず各タスクの「インデントレベル」を正確に判定する必要がある。Project VBAにおいて、タスクのインデントレベルは、そのタスクが親タスクに対してどれだけ深くネストされているかを示す指標だ。

このインデントレベルをプログラムで取得し、それを基にWBS番号を生成するロジックこそが、本ツールの肝となる。

1.1 Project VBA オブジェクトモデルの活用

Project VBAのオブジェクトモデルは、我々がタスク情報を取得するための強力な武器となる。特に `Task` オブジェクトが持つ `OutlineLevel` プロパティは、まさに我々が求めている「インデントレベル」を直接提供してくれる。

‘ 仮のコード断片
Dim tsk As Task
Dim outlineLevel As Integer

‘ Taskオブジェクトが取得できたとして
outlineLevel = tsk.OutlineLevel

しかし、ここで伝説的アーキテクトとして、単なるプロパティの参照で終わらせるわけにはいかない。`Task` オブジェクトは、メモリ上に構築される。そのライフサイクルを理解し、不要になったオブジェクトは明示的に解放する。これが、大規模なプロジェクトや、繰り返し処理を行う際に、メモリリークやパフォーマンス低下を防ぐための鉄則である。

1.2 メモリ最適化の極意：オブジェクトの明示的解放

VBAにおいては、オブジェクト変数を `Nothing` に代入することで、そのオブジェクトが参照していたメモリを解放することができる。特に `Task` オブジェクトのような、メモリ上に存在しうる多数のインスタンスを扱う場合、この明示的な解放は極めて重要になる。

Sub ProcessTasks()
Dim t As Task
Dim tasks As Tasks
Dim i As Integer

‘ Projectオブジェクトの取得 (省略)
Set tasks = ActiveProject.Tasks

‘ 繰り返し処理
For i = 1 To tasks.Count
Set t = tasks.Item(i)

‘ ここで t.OutlineLevel を使用してWBS番号を生成するロジックを実装
‘ …

‘ オブジェクト参照をクリア (メモリ解放)
Set t = Nothing
Next i

‘ Tasksコレクションも解放
Set tasks = Nothing
End Sub

この `Set t = Nothing` は、一見些細な行に思えるかもしれない。しかし、数千、数万というタスクを処理する際に、この積み重ねがシステム全体の安定性と応答速度に決定的な影響を与える。レガシー環境では、メモリリソースが限られていることも少なくない。我々は、常に「最小限のメモリで最大限のパフォーマンスを発揮する」という思想を貫く必要がある。

1.3 Windows APIとの連携（高度な領域）

さらに踏み込むならば、Project VBAのオブジェクトモデルだけでは到達できない領域が存在する。例えば、タスクの表示状態や、特定のカスタムフィールドの操作において、より低レベルでの制御が必要になる場合がある。その際に、Windows APIの呼び出しが有効となる。

しかし、Windows APIの利用は諸刃の剣だ。その強力さは、誤った使い方をすればシステム全体を不安定にさせる。API呼び出しは、その関数の仕様、引数、戻り値、そして何よりもメモリ管理を徹底的に理解した上で行う必要がある。

例えば、あるAPIが文字列を返す場合、その文字列のバッファ管理は呼び出し元が行う必要がある。VBAからこれらのAPIを呼び出す際には、`Declare` ステートメントを用いてAPI関数を宣言し、適切なデータ型（`ByVal`, `ByRef` など）を指定して呼び出す。

‘ 例：Windows APIの宣言 (実際にはWBS番号生成とは直接関係ないが、API連携の概念を示す)
If VBA7 Then ‘ 64-bit VBA
Declare PtrSafe Function GetComputerName Lib “kernel32” Alias “GetComputerNameA” (ByVal lpBuffer As String, nSize As Long) As Long
Else ‘ 32-bit VBA
Declare Function GetComputerName Lib “kernel32” Alias “GetComputerNameA” (ByVal lpBuffer As String, nSize As Long) As Long
End If

Sub GetSystemNameExample()
Dim buffer As String
Dim size As Long
Dim retVal As Long

‘ バッファサイズを初期化 (APIに任せる場合も、ある程度のサイズは確保)
size = 256
buffer = String$(size, Chr$(0)) ‘ Null終端文字列を想定

‘ API呼び出し
retVal = GetComputerName(buffer, size)

If retVal > 0 Then
‘ 戻り値は実際に書き込まれた文字数。Null終端文字は含まれない。
‘ Null終端文字までを考慮して、文字列を切り出す
buffer = Left$(buffer, InStr(buffer, Chr$(0)) – 1)
MsgBox “Computer Name: ” & buffer
Else
MsgBox “Failed to get computer name.”
End If

‘ オブジェクト変数ではないが、文字列変数も不要になったらクリアすることが望ましい
buffer = vbNullString
End Sub

このAPI連携は、Project VBAの標準機能だけでは実現できない、システム間連携の極限を追求する際に必要となる。しかし、その利用は「必要最小限」に留めるべきである。APIへの依存度を高めすぎると、OSのバージョンアップやパッチ適用によって予期せぬ不具合を引き起こすリスクが増大する。

2. WBS番号自動採番パーサーの実装

ここからは、上記の知見を踏まえ、具体的なVBAコードとして実装していく。このパーサーは、Project VBAのタスクリストを走査し、各タスクのインデントレベルを解析して、カスタムフィールドにWBS番号を自動書き出しすることを目的とする。

2.1 汎用パーサーの設計思想

  • 汎用性: 特定のプロジェクト構造に依存せず、どのようなProject VBAファイルでも動作すること。
  • 拡張性: 将来的に、WBS番号のフォーマット変更や、他のカスタムフィールドへの書き出しに対応できること。
  • パフォーマンス: 大量のタスクに対しても、迅速に処理を完了すること。
  • 保守性: コードが理解しやすく、バグ修正や機能追加が容易であること。

2.2 VBAコード例：WBS番号自動採番パーサー

このコードは、`WBS_Number` という名前のカスタムフィールドにWBS番号を書き出すことを想定しています。もし、このカスタムフィールドが存在しない場合は、事前に作成しておく必要があります。

Option Explicit

‘—————————————————————————————-
‘ Module: WBS_Numbering_Module
‘ Purpose: Project VBAタスクのWBS番号を自動採番し、カスタムフィールドに書き出す
‘ Author: 伝説的アーキテクト
‘ Version: 1.0
‘ Notes:
‘ – ‘WBS_Number’ という名前のカスタムフィールドが事前に作成されている必要があります。
‘ – 処理対象のタスクは、プロジェクト内の全タスクとします。
‘ – 実行前に、プロジェクトのバックアップを取得することを強く推奨します。
‘—————————————————————————————-

Sub AutoNumberWBS()

Dim tsk As Task ‘ 各タスクオブジェクトを格納
Dim tasks As Tasks ‘ プロジェクト内の全タスクコレクション
Dim wbsCounter() As Integer ‘ 各階層レベルのカウンターを格納する動的配列
Dim currentLevel As Integer ‘ 現在処理中のタスクのインデントレベル
Dim wbsNumber As String ‘ 生成されるWBS番号文字列
Dim maxLevel As Integer ‘ プロジェクト内の最大インデントレベル (動的に決定)
Dim i As Integer ‘ ループカウンタ

‘ — 初期化処理 —
On Error GoTo ErrorHandler

‘ Projectオブジェクトの取得
If ActiveProject Is Nothing Then
MsgBox “アクティブなプロジェクトがありません。”, vbCritical
Exit Sub
End If

‘ カスタムフィールド ‘WBS_Number’ が存在するか確認 (省略: 必要に応じて実装)
‘ …

‘ 全タスクコレクションを取得
Set tasks = ActiveProject.Tasks

‘ 最大インデントレベルを特定 (動的配列のサイズ決定のため)
maxLevel = 0
For Each tsk In tasks
If tsk.OutlineLevel > maxLevel Then
maxLevel = tsk.OutlineLevel
End If
Next tsk

‘ WBSカウンター配列を初期化 (最大レベル + 1 のサイズ)
‘ 例: maxLevel = 3 なら、wbsCounter(1) から wbsCounter(4) まで使用
ReDim wbsCounter(1 To maxLevel + 1)
‘ 全てのカウンターを0で初期化
For i = 1 To maxLevel + 1
wbsCounter(i) = 0
Next i

‘ — WBS番号生成と書き出し —
Application.ScreenUpdating = False ‘ 画面更新を停止 (パフォーマンス向上)
Application.Calculation = xlCalculationManual ‘ 計算モードをマニュアルに変更

For Each tsk In tasks
currentLevel = tsk.OutlineLevel

‘ 現在のレベルのカウンターをインクリメント
wbsCounter(currentLevel) = wbsCounter(currentLevel) + 1

‘ より上位のレベルのカウンターをリセット
‘ 例: レベル2からレベル1になったら、レベル2以降のカウンターはリセット
For i = currentLevel + 1 To maxLevel + 1
wbsCounter(i) = 0
Next i

‘ WBS番号文字列を構築
wbsNumber = “”
For i = 1 To currentLevel
wbsNumber = wbsNumber & wbsCounter(i) & “.”
Next i
‘ 末尾の “.” を削除
wbsNumber = Left(wbsNumber, Len(wbsNumber) – 1)

‘ カスタムフィールド ‘WBS_Number’ に書き出し
‘ ‘WBS_Number’ が存在しない場合のエラーハンドリングは別途必要
On Error Resume Next ‘ 一時的にエラーを無視 (カスタムフィールドがない場合のため)
tsk.Text11 = wbsNumber ‘ Text11 を ‘WBS_Number’ とする例 (FieldID 285)
‘ 実際には File > Options > Advanced > Custom Fields で確認
If Err.Number <> 0 Then
‘ カスタムフィールドが存在しない、またはアクセスできない場合のエラー処理
Debug.Print “Error writing to WBS_Number field for task: ” & tsk.Name & ” (Error: ” & Err.Description & “)”
‘ 必要であれば、ここでカスタムフィールド作成処理などを実装
End If
On Error GoTo ErrorHandler ‘ エラーハンドリングを元に戻す

‘ オブジェクト参照をクリア (メモリ解放)
Set tsk = Nothing

Next tsk

‘ — 後処理 —
Application.ScreenUpdating = True ‘ 画面更新を再開
Application.Calculation = xlCalculationAutomatic ‘ 計算モードを自動に戻す

MsgBox “WBS番号の自動採番が完了しました。”, vbInformation
Exit Sub

ErrorHandler:
‘ エラー発生時の処理
MsgBox “エラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical

‘ 画面更新と計算モードを元に戻す (エラー発生時も確実に実行)
If Not Application.ScreenUpdating Then Application.ScreenUpdating = True
If Application.Calculation = xlCalculationManual Then Application.Calculation = xlCalculationAutomatic

‘ オブジェクトの解放
Set tsk = Nothing
Set tasks = Nothing

End Sub

2.3 コード解説と実践的アドバイス

  • `Option Explicit`: 変数の宣言を強制し、タイポによるバグを防ぐための基本中の基本。
  • `wbsCounter()` 配列: 各階層レベルの「現在の番号」を保持します。例えば、`wbsCounter(1)` は最上位レベルのタスク番号、`wbsCounter(2)` はそのサブタスクの番号、といった具合です。タスクのインデントレベルが下がると、そのレベルのカウンターをインクリメントし、それより下位のレベルのカウンターはリセットします。
  • `maxLevel` の特定: プロジェクト内のタスクの最大インデントレベルを事前に把握することで、`wbsCounter` 配列のサイズを動的に決定します。これにより、不要なメモリ消費を抑えつつ、あらゆる階層構造に対応できます。
  • `Application.ScreenUpdating = False`: 画面描画処理は、VBAの実行速度に大きな影響を与えます。これを無効にすることで、処理速度が劇的に向上します。処理完了後に `True` に戻すのを忘れないように。
  • `Application.Calculation = xlCalculationManual`: 大量のデータ更新は、Excelの自動計算を頻繁にトリガーし、パフォーマンスを低下させます。計算モードをマニュアルにし、処理完了後に自動に戻すことで、このオーバーヘッドを回避します。
  • カスタムフィールドの指定: コード例では `tsk.Text11 = wbsNumber` としていますが、これは「WBS_Number」という名前のテキスト型カスタムフィールドが `FieldID` 285（`pjText11`）に割り当てられているという前提です。実際には、`File > Options > Advanced > Custom Fields` で、使用するカスタムフィールドのタイプ（Text, Number, Dateなど）とIDを確認し、コードを適宜修正してください。`tsk.CustomFieldValue(“WBS_Number”) = wbsNumber` のような、フィールド名で直接アクセスできる方法もありますが、FieldIDによるアクセスの方が、より低レベルで確実な場合があります。
  • エラーハンドリング: `On Error GoTo ErrorHandler` は、予期せぬエラーが発生した場合に、プログラムがクラッシュするのを防ぎ、後処理（画面更新の再開、計算モードの戻しなど）を実行するために重要です。特に、カスタムフィールドが存在しない場合のエラーは、`On Error Resume Next` で一時的に無視し、後でログ出力やユーザーへの通知を行うのが賢明です。
  • オブジェクトの明示的解放: `Set tsk = Nothing` は、ループの各イテレーションの終わりに実行されます。これにより、タスクオブジェクトが参照していたメモリが解放され、メモリリークを防ぎます。これは、数千、数万のタスクを処理するような大規模プロジェクトでは、パフォーマンスと安定性に不可欠なプラクティスです。

2.4 レガシー環境への配慮

長年運用されているシステムには、しばしばレガシーな部分が残ります。例えば、古いバージョンのProject VBAやOffice Suite、あるいはWindows OSなどがそれに該当します。

  • API互換性: Windows APIを利用する場合、OSのバージョンによって関数の挙動や利用可能なAPIが異なる場合があります。`#If Win64 Then` のようなプリプロセッサディレクティブを用いて、64bit版と32bit版のVBAで異なるAPI宣言を行うなどの配慮が必要です。
  • オブジェクトモデルの差異: Project VBAのバージョン間でも、オブジェクトモデルの挙動に微妙な違いが生じることがあります。可能な限り、新しいバージョンで開発・テストを行い、古いバージョンでの動作確認は慎重に行う必要があります。
  • リソース制約: レガシー環境では、CPUパワーやメモリ容量が限られていることが多いため、前述のメモリ最適化やパフォーマンスチューニングは、単なる「ベストプラクティス」ではなく、「必須要件」となります。

3. システム間連携の極限：Project VBAと外部システム

本稿のテーマはWBS番号の自動採番ですが、伝説的アーキテクトとして、さらにその先を見据えておく必要があります。それは、Project VBAで管理されるタスク情報を、他のシステムと連携させることです。

例えば、

  • ERPシステムとの連携: プロジェクトの進捗状況やリソース配分を、企業の基幹システムと同期させる。
  • BIツールとの連携: プロジェクトデータを抽出し、経営層向けのダッシュボードを自動生成する。
  • バージョン管理システムとの連携: プロジェクト計画の変更履歴を自動的に記録・管理する。

これらの連携を実現するには、Project VBAのVBAコードから、Web APIを呼び出したり、データベースにアクセスしたり、あるいはCOMコンポーネントを介して他のアプリケーションと通信したりする必要があります。

3.1 Web API連携の基本（VB.NET/C#との連携）

VBAから直接HTTPリクエストを送信してWeb APIを呼び出すのは、やや煩雑です。より高度で安定した連携を実現するためには、VB.NETやC#で開発されたDLL（クラスライブラリ）を作成し、それをVBAからCOM経由で呼び出す、というアプローチが推奨されます。

VB.NETでWeb APIクライアントを作成する場合、`HttpClient` クラスを使用するのが現代的です。

// VB.NET コード例 (クラスライブラリとしてビルド)
using System;
using System.Net.Http;
using System.Threading.Tasks;
using System.Runtime.InteropServices; // COM連携用

namespace ProjectVBA_API_Client
{
[ComVisible(true)] // VBAから参照可能にする
[Guid(“YOUR-UNIQUE-GUID-HERE”)] // GUIDを生成して設定
public interface IApiClient
{
[DispId(1)] // DISPIDを割り当てる
string CallApi(string url, string method, string body);
}

[ComVisible(true)]
[Guid(“ANOTHER-UNIQUE-GUID-HERE”)]
public class ApiClient : IApiClient
{
public string CallApi(string url, string method, string body)
{
using (var client = new HttpClient())
{
var request = new HttpRequestMessage
{
RequestUri = new Uri(url),
Method = new HttpMethod(method)
};

if (!string.IsNullOrEmpty(body))
{
request.Content = new StringContent(body, System.Text.Encoding.UTF8, “application/json”);
}

try
{
// 非同期処理を同期的に実行
HttpResponseMessage response = client.SendAsync(request).GetAwaiter().GetResult();
response.EnsureSuccessStatusCode(); // エラーコードの場合は例外をスロー
return response.Content.ReadAsStringAsync().GetAwaiter().GetResult();
}
catch (HttpRequestException e)
{
// エラーログや例外処理
return $”Error: {e.Message}”;
}
}
}
}
}

このVB.NETクラスライブラリをVBAから参照するには、COM登録が必要になります。

‘ VBA コード例
Sub CallExternalAPI()
Dim apiClient As Object ‘ または、インターフェースを定義してキャスト
Dim result As String

On Error Resume Next
‘ COMコンポーネントのインスタンスを作成
‘ CLSIDはregasm.exeで登録した際のGUIDを指定
Set apiClient = CreateObject(“ProjectVBA_API_Client.ApiClient”)
On Error GoTo 0

If apiClient Is Nothing Then
MsgBox “APIクライアントコンポーネントが登録されていません。”, vbCritical
Exit Sub
End If

‘ API呼び出し
result = apiClient.CallApi(“http://example.com/api/data”, “GET”, “”)

MsgBox “API Response: ” & result

‘ オブジェクト参照をクリア
Set apiClient = Nothing
End Sub

このような連携は、VBA単体では実現困難な、システム間連携の極限を可能にします。しかし、DLLのビルド、COM登録、GUID管理など、開発・運用の手間は増大します。

4. 結び：未来への架け橋

Project VBAにおけるWBS番号の自動採番は、単なる生産性向上ツールに留まりません。それは、我々が「タスク」という概念を、より深く、より構造的に理解するための、一つの「鏡」なのです。

本稿で示した、オブジェクトのライフサイクル管理、API連携、レガシー環境への配慮といった知見は、Project VBAの現場で長年培われてきた、いわば「職人技」です。これらの技術を習得し、実践することで、あなたは単なるVBAプログラマーから、システムアーキテクトへと進化するでしょう。

我々が目指すべきは、単に「動くコード」を書くことではない。それは、未来のシステムが、より堅牢に、より効率的に、そしてより賢く進化していくための、確かな礎を築くことである。

この魂を込めた知見が、あなたの開発現場に、新たな光をもたらすことを願ってやまない。

スポンサーリンク
タイトルとURLをコピーしました