プロジェクトマネジメントを「暗黙知」から「資産」へ：依存関係の論理的根拠をコードで刻む
プロジェクトが炎上する最大の要因は、進捗の遅れそのものではない。「なぜこのタスクが遅れると、あのタスクに影響が出るのか？」という依存関係の論理的根拠がブラックボックス化していることだ。
Project VBAを扱うエンジニアとして、私は断言する。依存関係（Predecessors）を単なる「リンク」として放置するのは、時限爆弾を抱えるのと同義だ。本稿では、タスクの依存関係に「理由」というメタデータを付与し、変更履歴を自動追跡するための堅牢な設計手法を伝授する。
—
1. なぜ「依存関係の論理的根拠」が自動化されるべきか
多くの現場で、依存関係は「とりあえず繋ぐ」ものになっている。しかし、プロジェクトの規模が拡大すれば、担当者の交代や仕様変更により「この先行タスク、なんで今のタスクの前提になってるんだっけ？」という疑念が必ず生まれる。
この混乱を防ぐには、カスタムフィールド（Text1等）を「論理的根拠の保持場所」として強制的に運用する必要がある。手動運用は間違いなく破綻する。だからこそ、VBAでUIを制御し、妥当性を担保するのだ。
2. 堅牢な設計：データ整合性を守るアーキテクチャ
設計の肝は、「依存関係の変更時に、必ず理由の入力を求める」という強制力だ。
設計上の注意点
- イベントドリブンの活用: `Project_BeforeTaskChange` イベントをフックせよ。ただし、無限ループには細心の注意を払うこと。
- データの永続化: 外部DBへの書き出しは非同期か、あるいは「プロジェクト保存時」のバッチ処理に限定する。Projectのインメモリ操作と外部I/Oを混ぜると、パフォーマンスは劇的に低下する。
- 型定義: カスタムフィールドは「文字列」として扱うが、実態は「変更ログのインデックス」であると定義せよ。
—
3. 実装：依存関係変更時の「理由」記録自動化コード
以下のコードは、Projectのイベントを活用した「論理的根拠強制入力システム」のプロトタイプだ。
‘ プロジェクトのイベントモジュール (ThisProject) に記述
Private Sub Project_BeforeTaskChange(ByVal tsk As Task, ByVal Field As PjField, _
ByVal NewVal As Variant, Cancel As Boolean)
‘ 依存関係(Predecessors)が変更された時のみ反応する
If Field = pjTaskPredecessors Then
Dim reason As String
reason = InputBox(“このタスク依存関係の変更理由を入力してください。” & vbCrLf & _
“例：設計変更によりA作業の完了が必須となったため”, “依存関係の論理根拠”)
‘ キャンセルされた、あるいは空入力の場合は変更を無効化
If reason = “” Then
MsgBox “理由なき依存関係の変更は認められません。”, vbCritical
Cancel = True
Exit Sub
End If
‘ Text1フィールドに根拠を記録
‘ Text1を「依存関係の論理的根拠」という名称でカスタムフィールド設定しておくこと
tsk.Text1 = Format(Now, “yyyy/mm/dd hh:nn”) & ” : ” & reason
‘ 変更履歴を即座に保持するため、プロジェクト全体の更新フラグを立てる
Application.FileSave
End If
End Sub
コードの解説
- `Cancel = True` の重要性: ユーザーが理由を入力しなかった場合、変更を即座に破棄する。これにより、データ品質を担保する「ガードレール」として機能する。
- `tsk.Text1` の活用: カスタムフィールドをログとして活用することで、後から「誰が、いつ、なぜ」この依存関係を繋いだかを追跡可能にする。
—
4. 運用上の極意：パフォーマンスと保守性
この仕組みをプロダクション環境で動かす際、以下の3点に注意せよ。
1. カスタムフィールドの命名:
GUI上で「Text1」という名前のまま運用するのは素人だ。必ずプロジェクト設定から「論理根拠」という名称に変更し、ユーザーが迷わないUIを提供せよ。
2. パフォーマンスの罠:
`FileSave`を多用しすぎると、大規模プロジェクトではフリーズを引き起こす。上記コードはシンプルにしているが、本番運用では「変更ログを配列に溜め込み、一定のタイミングで一括書き込みする」設計へ昇華させるべきだ。
3. データベース連携の作法:
もし外部SQL Server等と連携するなら、VBAから直接クエリを投げるな。一度CSVやJSONにエクスポートし、別プロセスのETLツールで取り込むのが、Projectという巨大なオブジェクトモデルを壊さないための唯一の正解だ。
結び：エンジニアとしての誇り
プロジェクトの管理ツールを自動化することは、単なる「作業の効率化」ではない。「プロジェクトという名の複雑な事象を、論理というコードで記述する行為」である。
依存関係の背後にある「なぜ」をコードで管理し始めた瞬間、君のプロジェクトは「追跡可能な資産」へと変貌する。明日から、君のプロジェクトから「なぜこうなっているのか分からない」という言葉を抹殺してほしい。
それが、我々エンジニアが手にする真の自動化の成果だ。
