Project VBAの深淵：WBS階層構造をJSONへ昇華させるアーキテクチャ設計
多くの開発者が「Project VBA」に触れ、挫折する理由は一つだ。彼らは「階層構造（WBS）の再帰的性質」を、単なる行のループとして捉えてしまうからだ。
Projectのタスクデータはフラットなリストに見えて、その実態は「木構造（Tree Structure）」である。この本質を無視して書かれたコードは、タスクが増えるたびにバグを量産し、いずれメンテナンス不能なゴミの山と化す。
今日は、Projectのタスク階層をJSONへシリアライズし、Webダッシュボードと完璧に同期させるための「極限の設計思想」を伝授する。
—
1. なぜ「力技のループ」が地雷なのか
初心者が書くコードは、タスクを上から順に読み込み、インデントレベルを判定して親を探そうとする。これは愚策だ。
`OutlineLevel` プロパティを頼りに動的に親を探索すると、計算量は増大し、条件分岐の嵐でデバッグが困難になる。
真のアーキテクトは「再帰処理」を用いる。
タスクツリーを再帰的に走査（DFS: 深さ優先探索）することで、コードの複雑性を最小化し、階層がどれだけ深くても破綻しない構造を作るのだ。
—
2. JSON生成：VBAにおける堅牢なアーキテクチャ
JSONを文字列結合で作るな。それは脆弱性（エスケープ漏れ）の温床だ。
VBAからJSONを扱う際は、`ScriptControl`は廃止し、可能であれば`VBA-JSON`ライブラリ等を利用するか、最小限の構成でオブジェクトを生成する設計を推奨する。
以下は、Project VBAでタスクツリーを再帰的に抽出し、JSON構造体へ変換するための本質的なコードだ。
実装コード：Task Tree Serializer
‘ プロジェクトタスクを再帰的にJSON階層へ変換する
‘ 依存関係や制約条件もこのノード内に含めることが可能
Public Function SerializeTasks(ByVal t As MSProject.Task) As Object
Dim dict As Object
Set dict = CreateObject(“Scripting.Dictionary”)
‘ 基本情報の抽出
dict.Add “id”, t.ID
dict.Add “name”, t.Name
dict.Add “outlineLevel”, t.OutlineLevel
dict.Add “start”, Format(t.Start, “yyyy-mm-dd”)
dict.Add “finish”, Format(t.Finish, “yyyy-mm-dd”)
‘ 子階層の再帰的探索
Dim children As Object
Set children = CreateObject(“System.Collections.ArrayList”)
Dim subTask As MSProject.Task
For Each subTask In t.OutlineChildren
children.Add SerializeTasks(subTask)
Next subTask
dict.Add “children”, children
Set SerializeTasks = dict
End Function
—
3. 現場で生き残るための「設計の鉄則」
① 「前提条件（Predecessors）」の扱い
タスクの依存関係は、文字列として取得すると解析コストが高い。`Task.PredecessorTasks` プロパティを使用して、IDのリストを配列としてJSONに含めるべきだ。BIツール側でガントチャートを再描画する際、このIDリストがライフラインとなる。
② パフォーマンスの重み
`Application.ScreenUpdating = False` は必須だが、それ以上に重要なのは「プロパティへのアクセス回数」だ。ProjectのCOMオブジェクトは、アクセスするたびに内部的にオーバーヘッドが発生する。
頻繁にアクセスするプロパティは、一度ローカル変数に格納してから処理するだけで、大規模プロジェクトにおける実行時間は劇的に改善する。
③ 外部API連携の注意点
VBAから直接Web APIを叩く場合、`WinHttp.WinHttpRequest.5.1` を使用する。
- 非同期処理は諦めろ: VBAで非同期を追いかけるのはコストが見合わない。同期通信でタイムアウト設定を適切に行う方が、堅牢性は格段に上がる。
- JSONの文字コード: 必ずUTF-8で送信すること。VBAの文字列は内部でUnicodeだが、送信時にSJISへ変換される罠がある。
—
4. 伝説のエンジニアからの提言
あなたが作ろうとしているのは、単なる「データ変換ツール」ではない。「組織の意思決定プロセスを可視化するパイプライン」である。
- エラーハンドリング: JSONシリアライズ中に `Nothing` が混入するケースを考慮せよ。
- 拡張性: 将来、リソース（担当者）の情報が必要になった時に、今の階層構造を壊さずに追加できるか？
「とりあえず動く」コードを書くのは学生の仕事だ。
我々プロフェッショナルは、「次にこのコードを触る誰かが、呪いをかけたくならないコード」を書く。
この設計をベースに、君のプロジェクトを「見える化」の先にある「最適化」の領域へと押し上げろ。健闘を祈る。
