【実務・中級編】初心者向け：Task.ConstraintTypeの基本操作とEnum定数の正しい使い分け – Project VBA解析バイブル

【Project VBAを掌握する極限の知見】Task.ConstraintTypeの深層と型不一致の完全克服

開発プロジェクトの現場において、スケジュール計算エンジンの挙動をプログラムから直接制御できるか否かは、ツール全体の価値を決定づける分水嶺となる。特に、Microsoft ProjectのVBAを用いたタスク制御において、`Task.ConstraintType`（制約の種類）の扱いは避けて通れない最重要テーマだ。

多くの初学者が「とりあえず動いたからいいか」と安易なコードを書き、のちのち致命的なスケジュールの崩壊や、得体の知れない「型不一致エラー」に悶絶する。

今回は、プロジェクトマネジメントの数理モデルの裏側にあるオブジェクトの振る舞いを紐解きながら、実務の現場で絶対に破綻しない堅牢な制約条件制御の極意を伝授する。

—

なぜ `ConstraintType` の理解がプロポーザル（提案）の成否を分けるのか

Projectのタスクには、デフォルトで「なるべく早く（ASAP）」などの制約が自動付与される。しかし、外部のExcelやデータベース（DB）から一括でWBS（Work Breakdown Structure）をインポートする自動化ツールを構築する場合、この制約条件を明示的にコードからコントロールしなければ、前後のリンク関係（先行・後続タスク）が無視され、スケジュールエンジンが狂い始める。

ここで多くのエンジニアが躓くのが、「VBAのEnum（列挙体）の型」と「Projectの内部プロパティが要求する型」のミスマッチである。

—

主要な ConstraintType と Enum 定数の正しい使い分け

`Task.ConstraintType` プロパティに代入する値は、Microsoft Projectが提供する `PjConstraint` 列挙体（Enum）を使用する。実務で頻繁に登場するのは以下の4つだ。

| Enum定数 | 値 | 意味 | 実務での利用シーン |
| :— | :—: | :— | :— |
| `pjAsSoonAsPossible` | 0 | なるべく早く (ASAP) | デフォルト。特別な理由がない限りこれを選択すべき。 |
| `pjAsLateAsPossible` | 1 | なるべく遅く (ALAP) | 予算やリソースの都合上、ギリギリまで着手したくない場合。 |
| `pjMustStartOn` | 2 | 指定日開始 (MSO) | 外部の確定的マイルストーンや法令上の期限がある場合。 |
| `pjMustFinishOn` | 3 | 指定日終了 (MFO) | 納期の厳守が絶対条件である場合。 |

> 【アーキテクトの警告】
> `pjMustStartOn` や `pjMustFinishOn` などの「ハード制約」を安易に多用してはならない。これらはプロジェクトの柔軟性を殺し、スケジュール計算エンジンを硬直させ、リスケジュールのたびに致命的なガントチャートの歪みを生む元凶となる。

—

陥りがちな罠：なぜ「型不一致エラー（Run-time error ’13’）」が発生するのか？

実務のコードで最も多いバグが、以下のような記述だ。

‘ 【アンチパターン】これでは型不一致エラーを引き起こす可能性がある
Dim t As Task
Set t = ActiveProject.Tasks(1)
t.ConstraintType = “0” ‘ 文字列を代入している（言語仕様による暗黙の型変換への依存）

あるいは、バリアント型（Variant）や不適切なデータ型でAPIを叩いた際、ProjectのCOMコンポーネントが型の厳密性を要求するため、容赦なく 「実行時エラー ’13’: 型が一致しません」 を吐き出す。

堅牢な設計の鉄則

1. 明示的な型宣言: 変数を定義する際は、必ず `PjConstraint` または適切な整数型（`Long`）を使用する。
2. ConstraintDateとの同時制御: `MustStartOn` などの制約を設定する場合、制約日（`ConstraintDate`）の指定がセットで必須となる。片方だけを設定すると、エンジンがエラーまたは不正なデフォルト日付（1984年や2049年など）を補正し、データが破損する。

—

【コピペOK】実務で使える堅牢なプロダクションコード

以下のコードは、外部のデータベースやExcelから読み込んだタスク情報を想定し、エラーハンドリングを網羅した安全な制約条件設定プロシージャである。

Option Explicit

”’

”’ 対象のTaskオブジェクト ”’ PjConstraint 列挙体 ”’ 制約日（ハード制約の場合は必須） Public Sub SetTaskConstraintSafely(ByVal targetTask As Task, _
ByVal constraintType As PjConstraint, _
Optional ByVal constraintDate As Date = 0)

‘ 1. オブジェクトの存在確認（Null参照バグの防止）
If targetTask Is Nothing Then
MsgBox “指定されたタスクオブジェクトが無効です。”, vbCritical, “設計エラー”
Exit Sub
End If

On Error GoTo ErrorHandler

‘ 2. トランザクション的な処理（エラー発生時のロールバックはできないが、ログ等で追跡可能に）
With targetTask
‘ 制約の種類を設定
.ConstraintType = constraintType

‘ ハード制約（指定日開始・終了など）の場合は必ずConstraintDateを設定する
Select Case constraintType
Case pjMustStartOn, pjMustFinishOn, pjStartNoEarlierThan, pjStartNoLaterThan, pjFinishNoEarlierThan, pjFinishNoLaterThan
If constraintDate = 0 Then
Err.Raise 9999, “ConstraintEngine”, “この制約タイプには有効な制約日の指定が必須です。”
End If
.ConstraintDate = constraintDate

Case Else
‘ ASAP / ALAP の場合は制約日は不要（Project側で自動管理）
End Select
End With

Exit Sub

ErrorHandler:
‘ 3. 実務レベルのエラーハンドリング
MsgBox “タスク ID: ” & targetTask.ID & ” (” & targetTask.Name & “) の制約設定に失敗しました。” & vbCrLf & _
“エラー内容: ” & Err.Description, vbExclamation, “スケジュールエンジン制御エラー”

‘ 必要に応じてエラーログ出力ロジックをここに挿入
End Sub

このコードの優れている点

• Optional引数の活用: ASAP/ALAPであれば日付を指定せずとも安全に処理できる。
• ビジネスロジックのバリデーション: 「ハード制約なのに日付が空」という矛盾を、Project本体がエラーを吐く前にVBA側（`Err.Raise`）で検知・トラップしている。

—

ファイル連携・データベース連携における実務上の注意点

ExcelやSQL Server等の外部データソースからWBSを同期するツールを作る際、以下の罠に注意してほしい。

1. 計算モードの制御（Manual Calculation）
大量のタスクに対して一括で `ConstraintType` を変更する場合、Projectの自動計算機能が働くと、1行変更するたびにスケジュール全体が再計算され、パフォーマンスが劇的に低下する（数千行あると数分単位で固まる）。

• 対策: 処理の最初に `Application.Calculation = pjManual` にし、全処理完了後に `pjAutomatic` に戻すこと。

2. サマリータスク（親タスク）への介入
サマリータスクに対して無理やり制約条件を書き込もうとすると、Projectのスケジュールエンジンと衝突して予期せぬ日付のズレを引き起こす。制約条件は基本的に「末端のタスク（Leaf Task）」に対してのみ操作する設計にすべきである。

—

総括

`Task.ConstraintType` の制御は、単なるプロパティへの代入作業ではない。Microsoft Projectという巨大な数理モデルの挙動を意のままに操るための「ドライバー」である。

型とライフサイクル、そしてエンジンへの負荷を意識したコードを書くことで、あなたの開発する自動化ツールは「偶発的に動くもの」から「ビクともしないインフラストラクチャ」へと昇華する。現場の信頼を勝ち取る堅牢なコードを、ぜひあなたのプロジェクトにも実装してほしい。