プロジェクトの「闇」を可視化せよ：Project VBAで構築する依存関係監査ログの極意
プロジェクトが炎上する最大の原因は、タスクの「依存関係」がブラックボックス化することだ。
「なぜこのタスクは先行タスクの完了を待たなければならないのか？」
この問いに答えられないプロジェクトは、意思決定の遅延を招き、最終的には誰も責任を取れない「ゾンビ・タスク」を生み出す。
今日は、Project VBA（Microsoft ProjectのVBA）を駆使し、タスクの依存関係に「理由（根拠）」を自動的に紐付ける、堅牢な監査ログシステムの設計論を伝授する。
—
1. なぜ「カスタムフィールド」なのか？
Projectには標準で「先行タスク」や「後続タスク」の情報を保持するフィールドがある。しかし、これらは「何と繋がっているか」を示すだけであり、「なぜ繋がっているか（論理的根拠）」を保持する場所はない。
ここに「テキスト型カスタムフィールド（例: `Text1`）」を投入する。これを単なるメモ欄として使うのは素人のやり方だ。我々はこれを「意思決定の証跡（Audit Trail）」として定義する。
—
2. 堅牢な設計のための3つの鉄則
本番環境で「動けばいい」というコードは、数ヶ月後に必ず爆弾となる。以下の設計思想を死守せよ。
1. 非破壊的書き込み: 既存の理由を消去せず、タイムスタンプと共に追記する（履歴の保持）。
2. 型安全とバリデーション: 依存関係が存在しないタスクへの書き込みを物理的に遮断する。
3. イベント駆動の分離: UI操作とビジネスロジックを分離し、循環参照や予期せぬイベント連鎖を防止する。
—
3. 実装：依存関係監査ログ・プロシージャ
以下は、選択中のタスクに対して「依存関係の理由」を追記し、カスタムフィールドに書き込むためのプロダクション・コードだ。
‘ =============================================================
‘ 依存関係監査ログ・プロシージャ
‘ 対象: Microsoft Project VBA
‘ 役割: 依存タスクの理由をText1にタイムスタンプ付きで追記
‘ =============================================================
Public Sub AppendDependencyReason()
Dim tsk As Task
Dim reason As String
Dim currentLog As String
‘ ユーザーから理由を入力（簡易的な入力インターフェース）
reason = InputBox(“この依存関係の論理的根拠を入力してください:”, “監査ログの記録”)
If Trim(reason) = “” Then Exit Sub
‘ プロジェクト内の選択中タスクをループ
For Each tsk In ActiveSelection.Tasks
‘ 依存関係（先行タスク）がない場合はスキップする堅牢性
If tsk.PredecessorTasks.Count = 0 Then
MsgBox “タスク ID: ” & tsk.ID & ” には先行タスクが存在しません。”, vbExclamation
GoTo NextTask
End If
‘ 既存のログを取得し、新しいエントリを追加
currentLog = tsk.Text1
tsk.Text1 = Format(Now, “yyyy/mm/dd HH:nn”) & ” – ” & reason & vbCrLf & currentLog
NextTask:
Next tsk
MsgBox “監査ログの更新が完了しました。”, vbInformation
End Sub
—
4. 運用上の注意点：データベースと外部連携
このデータを外部システム（ExcelやSQL Server等）にエクスポートして分析したい場合、以下の点に注意せよ。
- 改行コードの罠: VBAの`vbCrLf`は、CSV出力時にセルの崩壊を招く。外部連携を行う際は、改行を「|」などの特殊文字に置換してから出力するラッパー関数を必ず用意すること。
- パフォーマンスの重み: タスク数が数千を超えるプロジェクトで、頻繁にカスタムフィールドを書き換えると、描画負荷が無視できなくなる。`Application.ScreenUpdating = False` を活用し、描画を抑制するエンジニアリングを怠るな。
—
5. 伝説のエンジニアからの提言
このシステムの本質は「ログを取ること」そのものではない。「記録される」という事実が、担当者に論理的なタスク設計を強いることにある。
「理由」を書かされるタスク担当者は、自然と「なぜこのタスクが必要か」を考えるようになる。ツールがチームの思考の質を変える。これこそが、業務自動化エンジニアが目指すべき真の自動化の姿だ。
コードをコピペして終わりにするな。この仕組みをチームに導入し、プロジェクトの「意思決定の解像度」を極限まで高めてみせろ。それが、君がこのプロジェクトを支配する第一歩になるはずだ。
