プロジェクトの「真実」をコードに刻め：Project VBAで実現する依存関係の自動監査ログ
プロジェクトマネジメントにおいて、最も忌むべきは「なぜこのタスクが先行しているのか、誰も説明できない」というブラックボックス化だ。特にProject VBAを駆使してWBSや依存関係を動的に制御している場合、コードがブラックボックス化すればプロジェクトそのものが霧の中に消える。
今日は、タスクの「メモ（Notes）」フィールドを監査ログのストレージとして活用し、依存関係の生成・変更を追跡可能な「真実の記録」に変えるアーキテクチャを伝授する。
—
1. なぜ「メモ」フィールドなのか？
多くのエンジニアがカスタムフィールドにログを逃がそうとするが、これは罠だ。カスタムフィールドは型定義やビューの制約を受けやすく、保守性が低い。
一方で、標準の「メモ（Notes）」フィールドは以下の利点がある。
- 永続性: プロジェクトファイル自体に深く埋め込まれ、外部DBの同期エラーに左右されない。
- 可視性: 現場のPMがタスク詳細を開いた瞬間に、その依存関係の「出自」を確認できる。
- 非破壊的: 既存のスケジューリングロジックを一切汚染しない。
—
2. 堅牢な設計指針：Write-Onlyの哲学
ログを追記する際、既存の情報を消去してはならない。常に「追記（Append）」し、最新のステータスが常にトップに来るように設計する。
必須のデータ構造
1. タイムスタンプ: `Now()`
2. 実行者: `Environ(“Username”)`
3. アクション: 「何がどう変わったか（Predecessor IDの付与など）」
4. 論理的根拠: なぜその制約が必要か
—
3. 実践コード：依存関係設定と監査ログの自動同期
以下のコードは、単に依存関係を貼るだけでなく、その事実をメモに書き込むプロシージャだ。これを直接操作せず、必ずこの関数を経由させることで、監査の「抜け道」を塞ぐ。
‘ 依存関係を付与し、同時にメモフィールドへ監査ログを自動追記するコア関数
‘ @param targetTask 依存関係を受けるタスクオブジェクト
‘ @param predTaskID 先行タスクのID
‘ @param reason 依存関係を設定する論理的根拠
Public Sub SetPredecessorWithAudit(ByRef targetTask As Task, ByVal predTaskID As Long, ByVal reason As String)
On Error GoTo ErrorHandler
Dim logEntry As String
Dim userName As String
userName = Environ(“Username”)
‘ 監査ログのフォーマット定義
logEntry = “[” & Format(Now, “yyyy-mm-dd hh:nn”) & “] User: ” & userName & vbCrLf & _
“Action: Predecessor ” & predTaskID & ” Added.” & vbCrLf & _
“Reason: ” & reason & vbCrLf & _
“—————————————-” & vbCrLf
‘ 1. メモ欄に新しいログを追記（既存のメモを保持しつつ先頭に挿入）
targetTask.Notes = logEntry & targetTask.Notes
‘ 2. 依存関係の付与（Projectオブジェクトの仕様に従う）
targetTask.Predecessors = targetTask.Predecessors & “,” & predTaskID
Exit Sub
ErrorHandler:
MsgBox “依存関係の更新中にエラーが発生しました: ” & Err.Description, vbCritical
End Sub
—
4. プロダクション環境における注意点
ファイル・DB連携の罠
もしあなたが外部データベース（SQL Server等）とProjectファイルを同期させている場合、この「メモ」フィールドの書き込みが競合の原因になることがある。
- 対策: 外部同期が走るタイミングと、このVBA実行タイミングを必ず分離すること。可能であれば、外部DB側にも同じ「理由」フィールドを設け、VBA側で双方向に更新をかけるアーキテクチャが理想だが、まずは「Projectファイル内の自己完結」から始めるべきだ。
パフォーマンスの重み
タスク数が数千件を超える大規模プロジェクトでは、`targetTask.Notes`への頻繁な読み書きはオーバーヘッドになる。ループ処理の中でこの関数を呼ぶ場合は、「更新が必要な場合のみ書き込む」というガード句を必ず実装せよ。
—
5. チーフアーキテクトからの助言
「自動化」の目的は、楽をすることではない。「人間が手作業でミスをする余地を排除し、プロジェクトの意思決定を透明化すること」だ。
この仕組みを導入すれば、プロジェクトの終わりには各タスクの「メモ」欄が、意思決定の歴史を語るドキュメントへと昇華しているはずだ。これこそが、単なる「作業員」と「真のエンジニア」を分かつ視座である。
さあ、コードを書き換えろ。そして、君のプロジェクトに「説明責任」という魂を吹き込むのだ。
