プロジェクトマネジメントをコードで制す：VBAクラスモジュールによる「タスク操作」の極意
多くの現場で、`ThisProject.Tasks` を直接叩くスパゲッティコードが散見される。標準モジュールに数千行のロジックを詰め込み、バグを追うのに半日を費やす――それは「開発」ではなく「苦行」だ。
Project VBAを掌握するということは、「Projectオブジェクトをどう制御するか」ではなく「タスクという概念をどう抽象化するか」を定義することに他ならない。本稿では、上級者への登竜門である「クラスモジュールを活用したタスク操作のカプセル化」について、実戦的な知見を共有する。
—
1. なぜ「直接操作」は滅びるのか
`ActiveProject.Tasks(i).Name = “…”` といったコードが散乱すると、以下の「負の遺産」が積み上がる。
- 変更への脆弱性: 仕様変更でタスクの属性をいじると、プロジェクト全体を検索置換する羽目になる。
- 検証の欠如: タスクの開始日やコストに異常値が入っても、コードのあちこちでバリデーションを繰り返すことになる。
- メモリ管理の不透明性: 大規模プロジェクトでオブジェクトを無造作に走査すれば、GC（ガベージコレクション）が追いつかないほどではないにせよ、内部的なオーバーヘッドは確実に蓄積する。
これらを解決するのが「タスクのオブジェクト指向設計」だ。
—
2. 実装：TaskWrapperクラスの構築
まずは、タスクを単なる「行」としてではなく「操作可能なオブジェクト」として定義する。クラスモジュール `clsTask` を作成し、以下を記述してほしい。
‘ クラスモジュール: clsTask
Option Explicit
Private pTask As MSProject.Task
‘ コンストラクタ代わりの初期化メソッド
Public Sub Initialize(targetTask As MSProject.Task)
Set pTask = targetTask
End Sub
‘ プロパティの抽象化（バリデーションをここに集約）
Public Property Let Deadline(value As Date)
If value < pTask.Project.Start Then
Err.Raise 1001, "clsTask", "期限はプロジェクト開始日より前には設定できません。"
End If
pTask.Deadline = value
End Property
' ビジネスロジックのカプセル化
Public Sub MarkAsHighPriority()
pTask.Priority = 800
pTask.Text1 = "要緊急確認"
End Sub
重要な設計思想
- バリデーションの集中: `Deadline` プロパティのセッターで、不正な値を弾くロジックを1箇所に封じ込めている。
- インターフェースの分離: 呼び出し元は「どうやってタスクを更新するか」を知る必要はない。「期限を設定する」という命令を送るだけでいい。
—
3. 実践：標準モジュールでの活用
呼び出し側は驚くほどシンプルになる。
Sub UpdateTaskWorkflow()
Dim t As MSProject.Task
Dim taskObj As clsTask
‘ プロジェクト内のタスクを走査
For Each t In ActiveProject.Tasks
If Not t Is Nothing Then
Set taskObj = New clsTask
taskObj.Initialize t
‘ 直感的な操作が可能に
taskObj.MarkAsHighPriority
taskObj.Deadline = Date + 7
End If
Next t
End Sub
—
4. データベース連携と「堅牢性」の注意点
Project VBAで外部ファイル（ExcelやSQL Server）と連携する際、最も多いミスが「Projectオブジェクトを長時間保持しすぎること」だ。
1. 参照の解放: クラス内で保持している `MSProject.Task` は、処理が終わるごとに `Set pTask = Nothing` で明示的にメモリを解放する癖をつけよ。
2. トランザクション管理: データベースへの書き込みは、必ず「一度メモリ上に展開したオブジェクトの検証」を経てから行うこと。プロジェクトのデータと外部DBの不整合は、致命的な報告ミスに繋がる。
3. エラーハンドリング: クラス内で発生したエラーは、必ず呼び出し元へ `Err.Raise` で再送出する設計にすること。クラス内でログを吐いて握りつぶすと、何が起きているかブラックボックス化する。
—
5. 最後に：エンジニアとしての矜持
VBAは「簡易的なツール」として軽視されがちだが、設計次第で大規模なPMO支援ツールにもなり得る。
「動くコード」を書くのは新人の仕事だ。
「壊れにくく、修正が容易で、誰が読んでも意図が伝わるコード」を書くのが、真のエンジニアの仕事である。
このクラス化の手法を武器に、あなたのプロジェクト・管理業務を、手作業の泥沼から自動化の洗練された領域へと引き上げてほしい。次回の記事では、この設計を拡張し、タスクの親子関係を再帰的に走査するアーキテクチャについて掘り下げる。
君のコードが、プロジェクトを成功へと導く礎になることを期待している。
