制約条件の可視化：スケジュールエンジンの「沈黙の不整合」を制御する
プロジェクトマネジメントの現場において、最も恐ろしいのは「計算されたスケジュール」ではなく、「制約によって歪められたスケジュール」である。
MS Projectのエンジンは強力だ。しかし、ユーザーが「開始日固定（Must Start On）」や「終了日制約（Must Finish On）」といった制約（Constraints）を乱用したとき、クリティカルパスは形骸化し、ガントチャートは嘘をつき始める。この「制約」は、タスクの論理的なつながり（Predecessors/Successors）よりも優先されるという、スケジュールエンジンの絶対的なルールに基づいている。
本稿では、これらの「隠れた制約」をVBAによって抽出し、カスタムフィールドを用いてガントチャート上に視覚的なフラグを立てる手法を解説する。単なるコードの紹介ではない。COMオブジェクトのライフサイクル、計算エンジンのオーバーヘッド、そして大規模プロジェクトにおけるメモリ管理の観点から、プロフェッショナルが実装すべき「堅牢な自動化」の真髄を論じる。
1. 課題の核心：制約の「不可視性」
MS Projectの標準インターフェースでは、制約が設定されていても、ガントチャート上にその性質が明示的に表示されることは少ない。エンジニアが目にするのは、結果としての「日付」だけだ。
なぜ制約が問題なのか。それは、制約が設定されたタスクは、先行タスクの遅延を吸収できず、スケジュール全体を「硬直」させるからだ。大規模なプロジェクトにおいて、制約の散布図を把握することは、プロジェクトのリスク管理そのものである。
我々が実装すべきは、以下のロジックである。
1. 全タスクを走査し、`ConstraintType` を判定する。
2. 特定の制約（`pjMustStartOn` など）を持つタスクを特定する。
3. カスタムフィールド（`Text1`等）に識別文字列を書き込み、ガントチャートの列として表示させる。
2. アーキテクチャ設計：計算エンジンの制御とパフォーマンス
初心者が書くコードは、ループの中でタスクのプロパティを書き換えるたびに、MS Projectの計算エンジンをトリガーしてしまう。これは致命的なパフォーマンス低下を招く。
計算モードの制御
タスクのプロパティ（特にカスタムフィールド）を更新する際、MS Projectはデフォルトで再計算（Recalculation）を試みる。数千タスクあるプロジェクトでこれを繰り返すと、計算コストは指数関数的に増大する。
我々は、処理を開始する前に `Calculation = pjManual` を設定し、すべての処理が完了した後に一括で `Calculation = pjAutomatic` に戻す。これが鉄則だ。
COMオブジェクトの解放
VBAはガベージコレクション（GC）に頼り切ることはできない。特に大規模な自動化を長時間実行する場合、`Set task = Nothing` による明示的な参照解除を怠ると、メモリリークを引き起こし、MS Projectのプロセスが不安定になる。
3. 実装：高信頼性制約抽出エンジン
以下に、エンタープライズ環境での利用に耐えうる、最適化された実装例を示す。
Option Explicit
' Windows API: プロセスのメモリ使用量を監視するための準備（高度なデバッグ用）
' 大規模プロジェクトの自動化では、メモリの枯渇を検知する必要がある
If VBA7 Then
Private Declare PtrSafe Function GetProcessMemoryInfo Lib "psapi.dll" ( _
ByVal hProcess As LongPtr, _
ByRef lpWorkingSetXfer As PROCESS_MEMORY_COUNTERS, _
ByVal cb As Long) As Long
Private Type PROCESS_MEMORY_COUNTERS
cb As Long
PageFaultCount As Long
PeakWorkingSetSize As LongPtr
WorkingSetSize As LongPtr
QuotaPeakPagedPoolUsage As LongPtr
QuotaPagedPoolUsage As LongPtr
QuotaPeakNonPagedPoolUsage As LongPtr
QuotaNonPagedPoolUsage As LongPtr
PagefileUsage As LongPtr
PeakPagefileUsage As LongPtr
End Type
Else
Private Declare Function GetProcessMemoryInfo Lib "psapi.dll" ( _
ByVal hProcess As Long, _
ByRef lpWorkingSetXfer As PROCESS_MEMORY_COUNTERS, _
ByVal cb As Long) As Long
Private Type PROCESS_MEMORY_COUNTERS
cb As Long
PageFaultCount As Long
PeakWorkingSetSize As Long
WorkingSetSize As Long
QuotaPeakPagedPoolUsage As Long
QuotaPagedPoolUsage As Long
QuotaPeakNonPagedPoolUsage As Long
QuotaNonPagedPoolUsage As Long
PagefileUsage As Long
PeakPagefileUsage As Long
End Type
End If
''' <summary>
''' プロジェクト内の制約タスクを抽出し、カスタムフィールドにフラグを立てる
''' </summary>
Public Sub FlagConstraintTasks()
Dim t As Task
Dim proj As Project
Set proj = ActiveProject
' 1. パフォーマンス最適化: 計算モードをマニュアルに、画面更新を停止
On Error GoTo ErrorHandler
Application.ScreenUpdating = False
proj.Calculation = pjManual
Debug.Print "--- Processing Started: " & proj.Name & " ---"
' 2. タスクの走査
' Taskオブジェクトのライフサイクルを制御するため、ループ内で明示的に解放する
For Each t In proj.Tasks
' ヌルタスク（空行）のスキップ
If Not t Is Nothing Then
' 制約の判定
' ConstraintTypeは列挙型(Enum)として定義されている
Select Case t.ConstraintType
Case pjMustStartOn, pjMustFinishOn, pjStartNoEarlierThan, pjStartNoLaterThan
' カスタムフィールド Text1 に制約の種類を書き込む
' 文字列結合によるオーバーヘッドを最小限にする
t.Text1 = "⚠️ CONSTRAINT: " & GetConstraintName(t.ConstraintType)
Case pjAsSoonAsPossible, pjAsLateAsPossible
' ASAP/ALAPは通常、制約なしと同様の扱いだが、
' 意図的な設定として記録したい場合はここで処理する
t.Text1 = "ℹ️ ASAP/ALAP"
Case Else
' 制約なし
t.Text1 = ""
End Select
' 3. メモリ管理: オブジェクト参照の明示的解除
' ループ内でのメモリ圧迫を防ぐ
' Set t = Nothing はループの最後で行う必要はないが、
' 複雑な階層構造を持つ場合は重要となる
End If
Next t
' 4. 後処理: 計算モードを自動に戻し、画面更新を再開
proj.Calculation = pjAutomatic
Application.ScreenUpdating = True
MsgBox "制約タスクのフラグ立てが完了しました。", vbInformation
CleanUp:
Set t = Nothing
Set proj = Nothing
Exit Sub
ErrorHandler:
Application.ScreenUpdating = True
If Not proj Is Nothing Then proj.Calculation = pjAutomatic
MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical
Resume CleanUp
End Sub
''' <summary>
''' ConstraintType Enum を文字列に変換するヘルパー関数
''' </summary>
Private Function GetConstraintName(ByVal cType As Long) As String
Select Case cType
Case pjMustStartOn: GetConstraintName = "Must Start On"
Case pjMustFinishOn: GetConstraintName = "Must Finish On"
Case pjStartNoEarlierThan: GetConstraintName = "Start No Earlier Than"
Case pjStartNoLaterThan: GetConstraintName = "Start No Later Than"
Case pjFinishNoEarlierThan: GetConstraintName = "Finish No Earlier Than"
Case pjFinishNoLaterThan: GetConstraintName = "Finish No Later Than"
Case Else: GetConstraintName = "Other"
End Select
End Function4. 深掘り：レガシー環境とシステム間連携における知見
レガシー環境の保守
MS Projectのバージョンが古い環境（例：Project 2010/2013等）では、新しい列の追加や特定のプロパティへのアクセスにおいて、挙動が微妙に異なる場合がある。本コードでは、`ConstraintType` という標準的な列挙型を使用しているため、高い互換性を確保している。
システム間連携への拡張
このVBAロジックは、単体で完結させるべきではない。
真のアーキテクトは、このフラグ（`Text1`）をトリガーとして、外部のBIツール（Power BIやTableau）や、社内のダッシュボードシステムへ「リスクのあるタスク」としてデータを流し込む設計を考える。
例えば、`ActiveProject.SaveAs` を利用して、このフラグが立ったタスクのみを抽出した中間ファイル（XMLやCSV）を生成し、ETLプロセスに回すといった連携が、エンタープライズにおける自動化の完成形である。
メモリ監視の重要性
大規模プロジェクト（タスク数 10,000超）を扱う場合、VBAの実行中にMS Projectのメモリ使用量が急増することがある。上記のコードに示唆した `GetProcessMemoryInfo` (Windows API) を用いて、ループの一定回数ごとにワーキングセットサイズを監視し、閾値を超えた場合にプロセスを安全に終了させる、あるいはログを出力するといった「防衛的プログラミング」が、運用フェーズでの信頼性を決定づける。
結論
ガントチャートの視認性を高めることは、単なる「見た目の改善」ではない。それは、プロジェクトの論理的整合性を担保するための「監査プロセス」の自動化である。
制約を可視化し、エンジンの挙動をコントロール下に置くこと。それこそが、複雑怪奇なプロジェクトスケジュールという荒波を乗りこなすための、エンジニアに求められる真の技術である。
