【Project VBA極限知見】タスク名からWBS階層を自動判定・インデントする堅牢な構造化パーサーの設計
大規模なプロジェクト管理において、Microsoft Project（以下、MS Project）のWBS（Work Breakdown Structure）のメンテナンスほど不毛な作業はない。Excelやテキストベースで起票されたタスクリストをProjectにインポートした際、フラットに並んだタスク群を一つひとつ手動でインデントし、階層構造を構築していく……。この作業はプロジェクトマネージャーの貴重な時間を奪うだけでなく、ヒューマンエラーによる構造崩壊の温床となる。
今回は、タスク名に含まれるプレフィックス（「1.」「1.1.」「1.1.1」など）を正規表現で解析し、ミリ秒単位でアウトラインレベル（Outline Level）を自動構築する「WBS階層自動パーサー」のプロダクションコードを伝授する。
ただ動くだけのコードではない。Project VBA特有の「オブジェクトのライフサイクル」と「再計算の罠」を完全に統御した、実務投入可能な最高峰のアーキテクチャを解説しよう。
—
1. なぜ「力技のインデント操作」は破綻するのか？
多くのVBAエンジニアが犯す最大の過ちは、タスクループの中で無造作に `.OutlineIndent` や `.OutlineOutdent` メソッドを呼び出すことだ。
‘ 【アンチパターン】絶対にやってはいけない実装
Dim t As Task
For Each t In ActiveProject.Tasks
If t.Name Like “1.” Then t.OutlineIndent
Next t
このアプローチが実務で必ず破綻する理由は2つある。
1. 再計算のオーバーヘッド（パフォーマンスの崩壊）
MS Projectは、タスクの階層を変更するたびにプロジェクト全体のスケジュール再計算とサマリータスクの再構築を走らせる。数千件のタスクに対し、ループ内でインデント操作を行うと、画面がフリーズしたかのような重さに陥る。
2. 操作の相対性によるロジックの破綻
`.OutlineIndent` は「現在の位置から見て右に下げる」という相対的な操作である。そのため、処理の順番が狂ったり、二度打ちが発生したりすると、意図せぬ階層へ迷い込んでしまう。
【極限の解法】絶対レベル指定と一括更新
Project VBAでは、相対メソッドに頼るのではなく、タスクの `OutlineLevel` プロパティに直接数値を代入し、さらに処理中は計算モードをマニュアルに切り替えてパフォーマンスを極限まで引き上げるのが定石である。
—
2. バグを生まない堅牢なアーキテクチャ設計
今回のパーサーは、以下の要件を満たす設計とする。
- 正規表現（RegEx）による厳密な階層判定: 命名規則の揺らぎ（全角半角、ドットの数）を吸収する。
- トランザクション制御: 処理開始時に計算を手動（Calculation Manual）にし、エラー時も確実に自動へ復旧させる。
- 安全なオブジェクト参照: 削除や移動を考慮し、タスクのID（ユニークIDではなくタスクID）ベースで安全にシーケンシャル制御する。
—
3. 【コピペ即実戦投入】WBS階層自動パーサー・プロダクションコード
以下のコードをMS Projectの標準モジュールに貼り付けて実行してほしい。
Option Explicit
‘================================================================================
次元を超えるWBS階層自動パーサー (Project VBA Architecture)
概要: タスク名のドット区切りプレフィックスを解析し、アウトラインレベルを自動構築
================================================================================
Public Sub AutoIndentWBSHierarchy()
Dim prj As Project
Set prj = ActiveProject
‘ パフォーマンスと整合性のためのトランザクション開始
Dim originalCalc As Long
originalCalc = Application.Calculation
Application.Calculation = pjCalculationManual ‘ 自動計算を停止し爆速化
On Error GoTo ErrorHandler
Dim t As Task
Dim regEx As Object
Set regEx = CreateObject(“VBScript.RegExp”)
‘ プレフィックスパターン (例: “1”, “1.1”, “1.2.3.4” が行頭にあるもの)
‘ ※末尾のスペースやタブも考慮
regEx.Pattern = “^\s([0-9]+(\.[0-9]+))\s+”
regEx.Global = False
regEx.IgnoreCase = True
Dim matches As Object
Dim targetLevel As Integer
Dim processedCount As Long
processedCount = 0
‘ プロジェクト内の全タスクを走査
For Each t In prj.Tasks
If Not t Is Nothing Then
If regEx.Test(t.Name) Then
Set matches = regEx.Execute(t.Name)
‘ ドットの数からアウトラインレベルを算出
‘ 例: “1” -> レベル1, “1.1” -> レベル2, “1.1.1” -> レベル3
targetLevel = CalculateOutlineLevel(matches(0).SubMatches(0))
‘ 安全性の担保: レベルの境界チェック (MS Projectは通常1〜9)
If targetLevel >= 1 And targetLevel <= 9 Then
' OutlineLevelに直接代入（絶対指定による破綻防止）
t.OutlineLevel = targetLevel
processedCount = processedCount & 1 ' 処理カウンター
End If
End If
End If
Next t
' トランザクション終了・変更の適用
Application.Calculation = originalCalc
MsgBox "WBS構造の自動整形が完了しました。" & vbCrLf & _
"処理対象タスク数: " & processedCount, vbInformation, "Architectural Parser"
Exit Sub
ErrorHandler:
' 異常終了時も必ず計算モードを復元する（これがないとファイルが破損するリスクがある）
Application.Calculation = originalCalc
MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical, "System Error"
End Sub
'--------------------------------------------------------------------------------
' 補助関数: ドットのカウントからアウトラインレベルを算出
'--------------------------------------------------------------------------------
Private Function CalculateOutlineLevel(ByVal prefix As String) As Integer
Dim segments() As String
segments = Split(prefix, ".")
' セグメントの数がそのままアウトラインレベルになる ("1.2.3" なら 3個 -> レベル3)
CalculateOutlineLevel = UBound(segments) + 1
End Function
—
4. コードの急所：プロが仕込んだ設計思想の解説
1. `Application.Calculation = pjCalculationManual` の徹底
この記述を忘れたツールは「おもちゃ」に過ぎない。数千行のタスクに対して `t.OutlineLevel = x` を実行する際、MS Projectが毎回スケジュールを再計算すると数分を要する。手動モードにすることで、処理時間を数秒へと圧縮する。
2. `On Error GoTo` によるトランザクションの死守
VBAで最も恐ろしいのは、処理途中でエラーが発生して `Application.Calculation` が手動のままファイルが保存されることだ。これが発生すると、ユーザーが手動でタスクを追加・変更してもスケジュールが一切動かなくなる致命的な状態（ファイル破損に近い状態）に陥る。エラーハンドラで確実に元の状態へ戻す設計が、プロとアマの決定的な差である。
3. 正規表現によるノイズ耐性
単に `Left` 関数などで切り出すのではなく、`^\s([0-9]+(\.[0-9]+))\s+` という正規表現を用いることで、タスク名に全角スペースが混ざっていたり、前後に余計な空白があっても誤作動を起こさない堅牢性を担保している。
—
5. データベース・外部ファイル連携時の実務上の注意点
このツールを、Excelインポートや外部データベース（SQL Server / PostgreSQL等）からのデータ連携パイプラインの一部として組み込む場合の重要知見を共有する。
- 一意制約（UID）とタスクIDの混同に注意
外部DBと連携する際、タスクの「ID（行番号としてのID）」と「UniqueID（一意のシステムID）」を混同してはならない。タスクが挿入・削除されるたびに「ID」は変動するが、「UniqueID」は不変である。もし外部DB側でタスクの親子関係を管理している場合は、`t.UniqueID` をキーとして紐付けるアーキテクチャに拡張すべきである。
- 文字コードと改行コードの罠
外部テキストやCSVからタスク名を読み込む際、不可視文字（BOMやCRLF）がタスク名に混入すると、正規表現のアンカー（`^` や `$`）が意図通りにマッチせず、パース漏れを引き起こす。外部データを取り込む際は、必ず文字列のトリミング（`Trim` 関数や制御文字の除去）を前処理として挟むこと。
総括
今回提供したパーサーは、単なる「インデントを自動化する便利マクロ」ではない。MS Projectという重厚なプラットフォームの挙動を熟知し、パフォーマンス、エラー耐性、保守性のすべてを高次元でバランスさせた工業製品レベルのコードである。
現場の非効率を嘆く時間は終わりだ。このアーキテクチャを武器に、あなたのプロジェクト管理プロセスを極限までコード化し、完全自動化を達成してほしい。
