Microsoft Accessでシステム開発

Aceessでのシステム開発に関するコラム集です。

Access開発でVBAが必須と言われる理由はどこにあるのか

Accessを使ってシステムを作ろうとすると、早い段階で「VBAが必要」と言われます。
これを聞いて、Accessは難しい、プログラミングが前提だと感じる人も少なくありません。

しかし、VBAが必須とされる理由は、単に処理を書きたいからではありません。
Access開発、Accessシステム開発の設計思想に、その必然性があります。

Accessは「操作されるアプリケーション」である

Accessは、ユーザーが操作することを前提にしたアプリケーションです。
データの抽出や更新は、常に「何かの操作」をきっかけに発生します。

ボタンを押す、画面を開く、入力を終えるといった動作に対して、どの処理を走らせるかを定義する必要があります。
この「操作と処理を結びつける役割」を担っているのがVBAです。

マクロだけでは足りない理由

Accessにはマクロという仕組みもあります。
簡単な処理であれば、マクロだけで完結する場合もあります。

しかし、Accessシステム開発では、
・条件によって処理を分けたい
・複数の処理を組み合わせたい
・エラー時の挙動を制御したい
といった要求が必ず出てきます。

これらは、業務ロジックそのものです。
VBAは、その業務ロジックを表現するための手段として必要になります。

フォームとVBAは切り離せない

Accessでは、フォームが処理の起点になります。
フォームが開かれたとき、入力されたとき、閉じられたとき、それぞれにイベントが発生します。

VBAは、このイベントに対して処理を記述する仕組みです。
そのため、フォーム設計とVBA設計は表裏一体の関係になります。

Access開発では、画面だけを作って終わることはありません。
画面がどのように振る舞うかを定義するために、VBAが必要になります。

クエリだけでは表現できない処理がある

Accessにはクエリという強力な仕組みがあります。
多くのデータ処理はクエリで完結します。

それでも、
・処理の順序を制御する
・ユーザーの入力内容に応じて動作を変える
・複数のクエリを連動させる
といった処理は、クエリだけでは表現できません。

VBAは、これらの処理を統合するための「接着剤」のような役割を果たします。

VBAはAccessの設計思想そのもの

VBAは後付けの機能ではありません。
Accessは最初から、VBAによる制御を前提に設計されています。

テーブル、クエリ、フォーム、レポートという部品を、どの順番で、どの条件で動かすか。
それを記述するための言語がVBAです。

この点を理解すると、VBAは「難しいから必要」なのではなく、「設計を成立させるために必要」だということが見えてきます。

VBAを避けたAccess開発が抱える問題

VBAを使わずにAccess開発を進めようとすると、
・処理が分散する
・動作が把握しにくくなる
・仕様変更に弱くなる
といった問題が起きやすくなります。

結果として、Accessが「壊れやすい」「ブラックボックスになる」と感じられてしまいます。

VBAをどう位置づけるかでAccessの印象が変わる

VBAを「プログラミング」と捉えると、Accessは敷居が高く感じられます。
しかし、VBAを「アプリケーションの振る舞いを定義する設計言語」と捉えると、役割は明確になります。

Access開発において、VBAは主役ではありません。
テーブルやクエリ、フォームをつなぎ、業務を成立させるための要となる存在です。

VBAが必須と言われる理由は、Accessが単なるデータ管理ツールではなく、業務アプリケーションを作るための環境だからです。