こんにちは！プロジェクト管理の現場で、日々スケジュールやリソースの調整に頭を悩ませていませんか？
「マクロの記録」から一歩抜け出して、本格的な自動化や高度な分析に挑戦したい方へ。今回は、Microsoft Projectの裏側でうごめく「スケジュール計算エンジン」の深層へ皆さんをご案内します。
テーマは「『開始日固定』制約が引き起こすクリティカルパスの歪みをVBAで解析する」です。
なんだか難しそうな名前が並びましたが、大丈夫。一歩ずつ、優しく、そして本質的な部分までしっかりと噛み砕いて解説していきますね。ここをクリアすれば、あなたもProject VBAの基本と「エンジニアとしての視点」をぐっと掴めますよ。それでは、さっそく始めましょう！
—
1. なぜ「開始日固定」はスケジュールを歪ませるのか？
Microsoft Projectは、デフォルトでは「できるだけ早く（ASAP：As Soon As Possible）」タスクを片付けようと自動でスケジュールを計算します。全体の納期を決める「クリティカルパス」も、この自然な流れの中で計算されるからこそ意味を持っています。
しかし、現場の担当者が良かれと思って、あるいは外部の都合によって、タスクに「開始日固定（Start No Earlier Than や Must Start On など）」という制約をガチっとかけてしまうことがあります。
これがどういう現象を引き起こすかというと……。
本来なら前のタスクが終わればすぐに始められるはずの作業が、人為的な制約によって「足止め」を食らうのです。その結果、プロジェクト全体のクリティカルパスがねじ曲げられ、隠れリスク（本当は危ないのに、見かけ上は余裕があるように見える現象）が生まれます。
この「歪み」を人の目で見抜くのは至難の業。だからこそ、VBA（Visual Basic for Applications）の力を借りて、プログラムにシミュレーションさせ、定量的なレポートを自動作成してもらうのです。
—
2. Project VBAの基本：オブジェクトのライフサイクルを掴む
Excel VBAと違って、Project VBAの主役は「Task（タスク）」であり、その背後にある「ConstraintType（制約の種類）」や「TotalSlack（トータルフリーのスラッグ／余裕時間）」です。
まずは、Projectのオブジェクトモデルの基本をサクッと押さえましょう。
- `ActiveProject`：今開いているプロジェクトそのもの
- `ActiveProject.Tasks`：プロジェクト内にあるすべてのタスクの集合体
- `Task.ConstraintType`：タスクにかけられている制約の種類（ASAPなのか、日付固定なのか）
- `Task.TotalSlack`：スケジュールが何日遅れても全体の納期に影響しないか（余裕時間）
これらをVBAから操作・取得することで、制約がクリティカルパスにどんな悪影響を与えているかを丸裸にできます。
—
3. 実践！制約の歪みを解析するレポート生成ツール
お待たせしました。ここからは、開発現場でそのままコピペして使える実践的なVBAコードをご紹介します。
このマクロを実行すると、プロジェクト内のすべてのタスクを走査し、「開始日系の制約」がかけられているタスクをピックアップ。さらに、本来のクリティカルパスにどのような影響を与えているかをイミディエイトウィンドウ（またはExcel等への出力の基礎）にレポートしてくれます。
解析用VBAコード
Sub AnalyzeConstraintDistortion()
‘ =====================================================================
‘ 目的: 「開始日固定」等の制約がクリティカルパスに与える歪みを解析する
‘ 対象: Microsoft Project のアクティブプロジェクト
‘ =====================================================================
Dim tsk As Task
Dim constraintName As String
Dim affectedCount As Long
‘ 画面描画を停止してマクロの実行速度を爆発的に上げる（プロの常道テクニック！）
App.ScreenUpdating = False
Debug.Print “==================================================”
Debug.Print ” 【制約条件によるクリティカルパス歪み解析レポート】”
Debug.Print “==================================================”
affectedCount = 0
‘ プロジェクト内の全タスクをループ処理
For Each tsk In ActiveProject.Tasks
‘ 削除されたタスクやサマリータスク（見出し行）を除外
If Not tsk Is Nothing Then
If Not tsk.Summary Then
‘ 制約の種類を判定（ここでは「できるだけ遅く」や「指定日以降に開始」などをキャッチ）
Select Case tsk.ConstraintType
Case pjConstraintStartNoEarlierThan, pjConstraintStartNoLaterThan, pjConstraintMustStartOn
affectedCount = affectedCount + 1
‘ 制約名の文字列変換
Select Case tsk.ConstraintType
Case pjConstraintStartNoEarlierThan: constraintName = “指定日以降に開始”
Case pjConstraintStartNoLaterThan: constraintName = “指定日以前に開始”
Case pjConstraintMustStartOn: constraintName = “開始日固定”
End Select
‘ ログ出力（ここで歪みの兆候をキャッチ！）
Debug.Print “■ 歪み検知タスク ID: ” & tsk.ID & ” | 名称: ” & tsk.Name
Debug.Print ” – 設定された制約: ” & constraintName & ” (” & tsk.ConstraintDate & “)”
Debug.Print ” – 現在の開始日: ” & tsk.Start
Debug.Print ” – トータルフリー: ” & (tsk.TotalSlack / 480) & ” 日” ‘ Projectの内部単位(分)を日(480分=8時間)に変換
Debug.Print “————————————————–”
End Select
End If
End If
Next tsk
‘ 画面描画を復元
App.ScreenUpdating = True
‘ 総合結果の出力
Debug.Print “解析完了。 歪みリスクのあるタスク数: ” & affectedCount & ” 件”
Debug.Print “==================================================”
MsgBox “解析が完了しました！イミディエイトウィンドウを確認してください。”, vbInformation, “分析完了”
End Sub
—
4. コードのポイントと「陥りやすいエラー」の回避術
上記のコードには、現場でベテランエンジニアたちが口を酸っぱくして伝える重要なテクニックが詰まっています。いくつかポイントを解説しますね。
① `App.ScreenUpdating = False` による高速化
Projectは、VBAからタスクのプロパティに触れるたびに画面を再描画しようとします。タスクが数千件あるプロジェクトでこれをやると、完了までに数分かかることも。最初に画面描画を止め、最後に復元するだけで、体感スピードが何十倍も変わります。これは必ずセットで覚えましょう。
② `Not tsk Is Nothing` のガード
Project VBAでは、タスクを削除した直後のインデックスのズレや、メモリ上の特殊な状態によって、`For Each` の中で「空っぽのタスク（Nothing）」が出現することがあります。これを見落としてプロパティにアクセスすると、お馴染みの「実行時エラー ’91’: オブジェクト変数が設定されていません」が爆誕します。このガード条件は必須の作法です。
③ 時間単位（分）のトラップ
`TotalSlack` などのプロパティが返す数値の単位は、Excelの「日」とは異なり「分（Minutes）」です。標準的な1日8時間労働であれば、`480` で割って「日」に換算してあげないと、人間が読めない数字になってしまいます。ここも初心者がハマりやすいポイントですよ！
—
5. おわりに：ここをクリアすれば、あなたはもう中級者！
いかがでしたでしょうか？
「単にスケジュールを入力するツール」として見ていたMicrosoft Projectが、VBAを通して見ると「複雑な数理モデルと制約を持つ計算エンジン」に変わって見えたのではないでしょうか。
「開始日固定」という何気ない操作が、いかにプロジェクト全体のクリティカルパスを歪め、リスクを隠してしまうか。それをプログラムで自ら検知できるようになれば、現場でのあなたの評価は間違いなく一段階上がります。
ここをクリアしたあなたなら、もうマクロの記録の卒業生ではありません立派な「自動化エンジニア」の仲間入りです。ぜひ、ご自身のプロジェクトデータでも試してみてくださいね。それでは、次回の知見でお会いしましょう！
