Project VBAの深淵：依存関係を一括制御し、プロジェクトの「硬直」を解き放て
現場のプロジェクトマネジメントにおいて、MS Projectの「依存関係」は諸刃の剣だ。計画変更のたびに数百のリンクをポチポチと手作業で修正しているようでは、エンジニアとしての価値を放棄しているに等しい。
「FS（終了-開始）をSS（開始-開始）に一括変換したい」。このシンプルな要求の裏には、タスクの階層構造（WBS）と計算エンジンの挙動を制御する深い洞察が必要だ。今日は、小手先のテクニックではなく、「壊れない」「再利用可能である」「計算負荷を最小化する」という3つの観点から、Project VBAの極限の知見を授けよう。
—
なぜ、単純なループ処理では失敗するのか？
多くの初学者が陥る罠は、`Task.TaskDependencies`コレクションを闇雲にループさせ、その場でリンクを書き換えることだ。
しかし、Projectのオブジェクトモデルにおいて、依存関係の書き換えは計算エンジンを再走させるトリガーとなる。ループの途中でリンクを削除・再生成すれば、インデックスがずれるだけでなく、計算負荷が蓄積し、大規模プロジェクトではVBAがフリーズ（あるいは応答なし）を引き起こす。
堅牢な設計のための鉄則
1. オブジェクトのキャッシュ: 頻繁にアクセスするプロパティは変数に退避せよ。
2. 計算の抑制: `Application.Calculation = pjManual` を活用し、処理中の自動計算を一時停止せよ。
3. リンクの全削除は厳禁: 部分的な変更を行う際は、既存のリンクを「更新」するのではなく、「削除して再生成」というアトミックなトランザクションとして扱うべきだ。
—
実装：依存関係一括変換ツール（Production Code）
このコードは、現在選択中のタスク配下にある、特定の依存関係タイプを別タイプに置換するツールだ。実務での保守性を考慮し、エラーハンドリングと計算負荷の制御を組み込んでいる。
‘ 依存関係の一括変換エンジン
Public Sub BulkUpdateLinkType()
Dim proj As Project
Dim selTasks As Selection
Dim t As Task
Dim dep As TaskDependency
Dim oldType As Long, newType As Long
‘ 設定: 変更前後のリンクタイプ (例: FS(0) → SS(2))
oldType = pjFinishToStart
newType = pjStartToStart
Set proj = ActiveProject
Set selTasks = ActiveSelection.Tasks
If selTasks Is Nothing Then Exit Sub
‘ 1. 計算エンジンを停止し、パフォーマンスを最大化する
Application.Calculation = pjManual
On Error GoTo ErrorHandler
For Each t In selTasks
‘ 依存関係を逆順から処理（コレクション操作の鉄則）
Dim i As Long
For i = t.TaskDependencies.Count To 1 Step -1
Set dep = t.TaskDependencies(i)
‘ 特定のリンクタイプのみを対象に置換
If dep.Type = oldType Then
‘ プロパティの更新
dep.Type = newType
End If
Next i
Next t
CleanExit:
‘ 2. 計算を再開し、一気に結果を反映させる
Application.Calculation = pjAutomatic
MsgBox “依存関係の変換が完了しました。”, vbInformation
Exit Sub
ErrorHandler:
MsgBox “Error ” & Err.Number & “: ” & Err.Description, vbCritical
Resume CleanExit
End Sub
—
プロフェッショナルとしての注意点
1. 外部プロジェクトへの依存（リンク）
このコードは同一プロジェクト内を想定している。もし、`ExternalTask`が絡む依存関係を含んでいる場合、`dep.FromTask.Project`の参照で例外が発生する可能性がある。大規模なプログラムを組む際は、必ず `If Not dep.FromTask Is Nothing Then` のような null チェックを挟む癖をつけよ。
2. 計算エンジンの再開タイミング
`pjAutomatic`に戻す瞬間、MS Projectは全タスクのクリティカルパスを再計算する。タスク数が数万件規模の場合、この瞬間にCPU負荷が跳ね上がる。非常に巨大なスケジュールの場合は、一度ファイル保存を挟むか、計算処理をあえて手動のままにする運用設計も検討すべきだ。
3. 「なぜ」SSなのか？
自動化する前に自問せよ。FSからSSへの変更は、単なる進捗管理の都合か、それとも「並行作業の可視化」という本質的な要件か。ツールはあくまで「正しく設計された計画」を補助するためにある。ゴミのような計画をどれだけ速く変更しても、ゴミが出るだけだ。
最後に：エンジニアの誇り
VBAは古い言語かもしれない。だが、Project VBAを使いこなすということは、組織の時間を買い戻すことに他ならない。このコードをベースに、君自身のプロジェクト固有の要件を付け加え、誰にも文句を言わせないレベルの「管理自動化」を成し遂げてほしい。
次に会うときは、手作業で調整している姿など見たくない。健闘を祈る。
