こんにちは！プロジェクト管理の現場で、MS Projectのスケジュールに振り回されていませんか？
「前任者が作ったスケジュール、なぜか日付が固定されて動かない……」
「『できるだけ早く』に統一したいのに、何百件もあるタスクの制約条件を一つずつ手動で変えるなんてやってられない！」
そんな絶望的な状況に出会ったことはありませんか？
マクロの記録から一歩抜け出し、現場のインフラをコードで支配したいあなたへ。今回は、Project VBAの真髄である「タスクの制約条件（ConstraintType）の一括クリーンアップ」を、優しく、そして徹底的に解説していきます。
ここをクリアすれば、Project VBAの基本と「オブジェクトの機嫌の取り方」がバッチリ見えてきますよ。さあ、一緒にエンジニアとしてのステージを一つ上げましょう！
—
1. なぜMS Projectのスケジュールは狂うのか？（本質を知る）
MS Projectでは、タスクを作成するとデフォルトで「できるだけ早く（As Soon As Possible: 略して ASAP）」という制約が設定されます。これは、「先行タスクが終わったら、可能な限り最速で始める」という、いわゆる「流動的なスケジュール」の基本です。
しかし、現場の担当者が良かれと思って、あるいは操作ミスで、以下のような「頑固な制約」を設定してしまうことがあります。
- 指定日以降に開始（SNET / SNLT）
- M2（必須完了日）等の締め切り固定
- これ以上動かさない「完了日固定（FNLT）」
これらがジャングルэのように入り組むと、先行タスクを前倒ししても後続がビクともしない「硬直したスケジュール」が完成します。プロジェクトマネージャーにとって最大の敵です。
これをVBAで一網打尽にし、すべてのタスクを「できるだけ早く（pjConstraintASAP）」にリセットする自動化ツールを作ります。
—
2. Project VBAの基本と、知っておくべき「作法」
Excel VBAと違って、Project VBAには独特の「重み」とオブジェクト構造があります。まずは基本のキを押さえましょう。
頻出する3大オブジェクト
1. `ActiveProject`: 今開いているプロジェクトそのもの。
2. `ActiveProject.Tasks`: プロジェクト内の全タスクのコレクション（集合体）。
3. `Task`: 個々のタスク。ここから名前や期間、そして「制約条件」を操作します。
⚠️ Excelとは違う！Projectの「重み」と罠
Excelのように数万行のセルを `Range(“A1:A10000”).Value = …` のように一瞬で書き換える感覚でProjectを触ると、痛い目を見ます。
Projectは、1つのタスクの制約や日付を変えるたびに、プロジェクト全体のクリティカルパスや依存関係を裏で再計算します。そのため、何千件もあるタスクをループ処理するだけで、画面がフリーズしたかのように重くなることがあります。
これを回避するためのプロの技が、コードの前後に挟む「画面更新の停止（ScreenUpdating）」と「計算の手動化」です。この実務テクニックをコードに組み込んでいきましょう。
—
3. 実装コード：制約条件を一括クリアする「神マクロ」
それでは、開発環境（VBE：Alt + F11）を開き、標準モジュールに以下のコードを貼り付けてみてください。現場でそのままコピー＆ペーストして使える実用コードです。
Sub CleanUpTaskConstraints()
Dim t As Task
Dim targetCount As Long
Dim startTime As Double
startTime = Timer ‘ 処理時間計測用
‘ 【重要】パフォーマンス爆上げの作法：画面描画と自動再計算をストップ
Application.ScreenUpdating = False
targetCount = 0
On Error GoTo ErrorHandler
‘ プロジェクト内の全タスクを巡回するループ
For Each t In ActiveProject.Tasks
‘ 念のため、タスクが存在し、かつ「サマリータスク（要約）」や「削除済み」ではないか確認
If Not t Is Nothing Then
If t.Summary = False And t.Active = True Then
‘ すでに「できるだけ早く (ASAP)」以外になっているものだけをターゲットにする
If t.ConstraintType <> pjConstraintASAP Then
‘ 制約条件を「できるだけ早く」に変更
t.ConstraintType = pjConstraintASAP
‘ ついでに、過去に設定された無駄な「制約日付」もクリア（空欄にする）
‘ ※ASAPの場合、制約日付は通常不要ですが、念のためリセット
t.ConstraintDate = “1984/1/1” ‘ Projectの初期化日（実質クリア状態）
targetCount = targetCount + 1
End If
End If
End If
Next t
‘ 処理終了後に画面描画を復元
Application.ScreenUpdating = True
‘ 完了メッセージ
MsgBox “クリーンアップが完了しました！” & vbCrLf & _
“修正したタスク数: ” & targetCount & ” 件” & vbCrLf & _
“処理時間: ” & Format(Timer – startTime, “0.00”) & ” 秒”, _
vbInformation, “Project VBA 正常終了”
Exit Sub
ErrorHandler:
‘ エラー時の復元処理（画面が固まったままになるのを防ぐ）
Application.ScreenUpdating = True
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “エラー”
End Sub
—
4. コードの解説：ここがエンジニアのこだわりポイント
初心者のうちは「タスクをループして変えるだけでしょ？」と思いがちですが、上記のコードには現場を生き抜くための知恵が詰まっています。
1. `Application.ScreenUpdating = False` の魔法
先ほども触れましたが、これを挟むことで、VBAが裏で高速にタスクを書き換えている間、MS Projectが画面の再描画をサボってくれます。体感スピードが数倍〜十数倍変わるので、必ずセットで覚えましょう。
2. `t.Summary = False` のチェック
MS Projectには、複数の子タスクをまとめる「要約タスク（親タスク）」が存在します。親タスクの日付や制約は子タスクから自動算出されるため、親の制約を無理やりコードでいじろうとするとエラーになります。「子タスク（Summary = False）」だけを狙い撃つのが鉄則です。
3. エラーハンドリング（保険）の重要性
マクロ実行中に万が一エラーが起きたとき、`ScreenUpdating = False` のままプログラムが止まると、MS Projectの画面が操作不能なフリーズ状態のように見えてユーザーがパニックになります。必ず `ErrorHandler` を用意し、異常終了時でも画面を元に戻す配慮が、プロのエンジニアの証です。
—
5. 運用ルール策定：ツールをチームに導入するための極意
さて、素晴らしいマクロを作りましたが、これを現場にどう定着させるかが真の勝負です。ツールを作って終わり、にしてはいけません。
- 運用ルール1：スケジュールベースライン（基準計画）を引く前に必ず実行する
プロジェクト計画の初期段階、あるいは外部から受け取ったガントチャートをインポートした直後に、このマクロを強制実行する「ルーティン」に組み込みます。
- 運用ルール2：マクロ付きテンプレート（.mpt）の配布
このVBAコードを組み込んだプロジェクトテンプレートをチームに共有し、「スケジュールがおかしくなったら、まずこのボタンを押す」という共通言語を作ります。
—
まとめ：VBAはあなたの右腕になる
いかがでしたか？
今回は「タスクの制約条件の一括解除」というテーマを通じて、Project VBAの基本構造、重いアプリケーションを軽快に動かすテクニック、そして現場の運用ルールまでを解説しました。
最初は難しく見えたMS Projectのオブジェクトも、ルールと作法さえ分かってしまえば、あなたの思い通りに動く従順な右腕となります。
「手作業で何時間もかかっていたスケジュール整理が、ボタン一つで1秒で終わる」――この爽快感をぜひ、あなたの現場でも味わってみてください。ここをクリアしたあなたなら、もうProject VBAの初学者ではありません。自信を持って次の自動化へ進みましょう！
