Access開発の「泥沼」から脱却せよ：OpenArgsをJSONで掌握するアーキテクチャ設計
Access開発において、画面間でのパラメータ受け渡しに頭を悩ませたことはないだろうか。
「フォームを開くたびにグローバル変数が増殖する」「OpenArgsにカンマ区切りの文字列を詰め込み、`Split`関数で解析してインデックス指定する」……。
断言する。その設計は、技術的負債の温床だ。
インデックスのズレによる実行時エラー、仕様変更時の修正漏れ、引数順序の属人化。これらはすべて、VBAが本来持つべき「堅牢性」を著しく損なっている。本稿では、`OpenArgs`にJSONという構造を持たせることで、この混沌を制御下に置く「極限の設計手法」を伝授する。
—
1. なぜ「カンマ区切り」は死に至るのか
多くのエンジニアが陥る過ちが、`OpenArgs`に「値1,値2,値3」といった文字列を詰め込む手法だ。
この手法は以下の理由で即刻排除すべきだ。
- 構造の硬直化: 引数を1つ追加するだけで、既存のすべての呼び出し元コードを修正しなければならない。
- 型の喪失: すべてが文字列として扱われるため、型変換のオーバーヘッドと、変換ミスによるエラーリスクが常に付きまとう。
- 可読性の欠如: `Args(2)`が何を指すのか、コードを見ただけでは判別不能である。
プロフェッショナルな設計において、データは「構造」を持つべきだ。そこで登場するのがJSONである。
—
2. 実装の設計指針：JSONの力でパラメータを「オブジェクト化」する
Access VBAでJSONを扱うために、車輪の再発明をする必要はない。世界中で使われている「[VBA-JSON](https://github.com/VBA-tools/VBA-JSON)」ライブラリを標準採用する。これを導入することで、複雑なパラメータをたった一行でシリアライズ・デシリアライズできる。
実装手順
1. [VBA-JSON](https://github.com/VBA-tools/VBA-JSON)から `JsonConverter.bas` をダウンロードし、プロジェクトにインポートする。
2. 参照設定で `Microsoft Scripting Runtime` を有効化する。
【プロダクションコード】呼び出し元：JSONを生成して渡す
呼び出し側は、構造化されたDictionaryをJSON文字列に変換して渡すだけだ。これにより、引数の順序を気にする必要はなくなる。
‘ 呼び出し元フォームのボタンイベント等
Public Sub OpenDetailForm()
Dim params As Object
Set params = CreateObject(“Scripting.Dictionary”)
‘ パラメータをキーと値で管理
params.Add “ID”, 1024
params.Add “Mode”, “Edit”
params.Add “IsReadOnly”, False
params.Add “TargetDate”, Format(Date, “yyyy-mm-dd”)
‘ JSON文字列に変換してOpenArgsへ
DoCmd.OpenForm “frmDetail”, , , , , , JsonConverter.ConvertToJson(params)
End Sub
【プロダクションコード】呼び出し先：初期化の堅牢性を担保する
受け取り側は、JSONをパースして`Dictionary`として扱う。これにより、キー指定による安全なアクセスが可能になる。
‘ 呼び出し先フォームのLoadイベント
Private Sub Form_Load()
If IsNull(Me.OpenArgs) Then Exit Sub
Dim params As Object
Set params = JsonConverter.ParseJson(Me.OpenArgs)
‘ 存在チェックを挟むことで堅牢性を確保
If params.Exists(“ID”) Then Me.txtID = params(“ID”)
If params.Exists(“Mode”) Then Me.lblMode.Caption = params(“Mode”)
‘ 型の安全性を意識した実装
If params(“IsReadOnly”) Then
Me.AllowEdits = False
End If
End Sub
—
3. この設計がもたらす圧倒的な「保守性」
このアプローチの真価は、「後方互換性の維持」にある。
例えば、後から「ユーザー権限」というパラメータを追加したとする。
従来の`Split`方式であれば、すべての`Split`関数のインデックスを数え直すという苦行が必要だった。しかし、JSON方式であれば、既存のコードはそのままで、新機能側で新しいキーを参照するだけでいい。
運用上の注意点
- 巨大なデータの受け渡し: `OpenArgs`は文字列としてメモリに保持される。数MB単位の巨大なJSONを渡すのはAccessの設計思想に反する。その場合は、`CurrentDb`を利用した一時テーブルや、グローバルなデータ保持クラスを検討すべきだ。
- バリデーション: `ParseJson`した後は、必ずキーが存在するか`params.Exists(“Key”)`を確認すること。これを怠ると、実行時エラーがユーザーの画面を埋め尽くすことになる。
—
結論：コードに「意図」を刻め
Access開発は、しばしば「場当たり的な修正の積み重ね」になりがちだ。しかし、OpenArgsをJSONというインターフェースで抽象化することで、画面間の結合度は劇的に低下し、開発効率は飛躍的に向上する。
君たちが書くコードは、単なる命令の羅列であってはならない。未来の自分、あるいは次にこのコードを保守する仲間が、一目見ただけで意図を汲み取れるような「設計の美学」を持たせること。
さあ、古いやり方は捨てよう。JSONでスマートなアーキテクチャを実装するんだ。それが、真の業務自動化エンジニアへの第一歩だ。
