VBScriptを掌握せよ：業務自動化の「聖域」たる日付演算の極意
業務自動化の現場において、VBScriptは「レガシー」などという安っぽい言葉で片付けられるべき存在ではない。Windowsの深層で静かに、かつ確実にタスクを完遂する、極めて軽量で強力なアーキテクチャだ。
しかし、多くのエンジニアが「日付計算」の罠に落ちる。`DateAdd`や`DateDiff`を単なる関数として使っているうちはアマチュアだ。業務バッチの要となる「営業日計算」や「月末算出」において、なぜバグが混入するのか。その本質を突き、保守性の高いプロダクションコードの書き方を伝授する。
1. なぜ「力技の日付演算」は死を招くのか
多くの初心者は、`DateAdd(“d”, 1, d)` のような単純な加算を繰り返し、ループで土日を判定しようとする。だが、これはアルゴリズムとして最悪だ。
- パフォーマンスの欠如: 処理対象期間が長い場合、無駄なループが実行時間を食いつぶす。
- メンテナンス性の欠如: 祝日リストがハードコーディングされ、翌年の法改正で即座に沈没する。
真のプロフェッショナルは、「日付を計算可能なシリアル値として扱い、ロジックを関数単位でカプセル化する」。これが堅牢なシステムを作る鉄則だ。
2. 月末最終日を「数学的」に求める
月末を求めるために、毎月「28日か、30日か、31日か」を判定するようなif文を書いているなら、今すぐ破棄してほしい。VBScript（というかCOMのDate型）は、「翌月の0日目」は「当月の最終日」であるという性質を持っている。
‘ 指定した日付の月末日を取得する関数
Function GetEndOfMonth(dTarget)
‘ 翌月の1日を求め、そこから1日引くことで、確実に当月の最終日を導き出す
Dim dNextMonth
dNextMonth = DateAdd(“m”, 1, dTarget)
GetEndOfMonth = DateSerial(Year(dNextMonth), Month(dNextMonth), 0)
End Function
この簡潔さ。これが`DateSerial`関数の真価だ。引数に0を渡せば前月末を返す。この仕様を熟知しているだけで、コードの行数は劇的に減る。
3. 実践：営業日計算と祝日判定の設計
業務自動化で最も重要なのは「土日祝を除いた処理日」の算出だ。これを実現するためには、祝日リストを外部ファイル（CSV等）から読み込み、`Dictionary`オブジェクトに格納するのが最適解だ。
祝日を考慮した営業日判定コード
‘ 必須：Scripting.Dictionaryで祝日を高速参照する
Function IsBusinessDay(dDate, dictHolidays)
Dim nWeekDay
nWeekDay = Weekday(dDate)
‘ 土日判定
If nWeekDay = vbSaturday Or nWeekDay = vbSunday Then
IsBusinessDay = False
Exit Function
End If
‘ 祝日判定（辞書オブジェクトにキーが存在すれば休日）
If dictHolidays.Exists(dDate) Then
IsBusinessDay = False
Exit Function
End If
IsBusinessDay = True
End Function
なぜこの設計が「最強」なのか
1. 分離の原則: 祝日リストをCSVで管理することで、コードを一切触らずに年次更新が可能になる。
2. Dictionaryの活用: `Array`で祝日を回すのは愚策だ。`Dictionary`を使えば、祝日の検索はO(1)の計算量で完了する。数千件のデータ処理でも瞬きする間に終わる。
4. 現場で生き残るための「実装の作法」
最後に、プロダクション環境でバグをゼロにするための「守護神」的テクニックを3つ共有する。
- Date型とString型の混同を避ける: VBScriptは型に寛容すぎる。`CDate()`関数を明示的に使い、常に型を強制せよ。曖昧な比較は、月初のバグの温床だ。
- エラーハンドリングの徹底: `On Error Resume Next`を乱用するな。特定の演算（ファイル読み込みなど）のみを囲い込み、即座に`Err.Clear`する。
- ログ出力の標準化: 日付演算は「いつ計算したか」が不明だとデバッグが不可能になる。演算の入力値と出力値を必ずログに吐き出せ。
結びに：エンジニアの誇りとして
VBScriptは古い言語かもしれない。しかし、その上で動くロジックが論理的に美しければ、それは時を超えて価値を発揮する。
あなたが今書こうとしているそのコードは、数年後のあなたを助ける資産になるか？ それとも、修正するたびに胃を痛める負債になるか。「美しいコードは、正しい設計からしか生まれない」。この言葉を胸に、明日からの自動化タスクに挑んでほしい。
何か不明点があれば、常に原点である「日付演算のロジック」に立ち返れ。そこに全ての答えがある。
