ExcelとAccessのマクロとVBAの違いについての所感

ExcelとAccessのマクロとVBAの違いについての所感

私はExcelVBAをゴリゴリ使い倒してからAccessVBAに入った人間なんですが、同じVBAでもなんというかニュアンスが違うというか、思ってたよりスッと入れなくてぐぬぬ…、となったものでした。誰得だよとは思いつつ、そのへんの「なんとなく違うポイント」をまとめてみました!


「VBA」と「マクロ」の違い

これがExcelとAccessでだいぶ解釈が違うので混乱ポイントなのかなと。そもそもこの2つは

  • VBA … Visual Basic for Application というプログラム言語のこと
  • マクロ … 操作を自動化して制御する機能のこと

というもので、Excel/Accessともにこの根本的な部分は同じです。VBAでプログラミングを行うときはVBE(Visual Basic Editor/Alt+F11キーで開くやつ)というVBA専用の編集画面を開いてコードを打ち込む、というところも共通です。

↑VBE画面の例(Excel)

ただ、VBAはもはや「言語名」にとどまらず「VBAで実装した機能」のことも「VBA」と呼んでしまうことも多く、すごーく広義な意味合いになっちゃってるんですよね。このへんもわかりにくくなっちゃう原因だと思います。

ExcelだとVBA≒マクロ

こちらの記事がとってもわかりやすいです! 私個人の解釈では、Excelにおいてはほぼ同義なんじゃないかなと。よく勘違いされがちな「マクロの自動記録」も、その記録先はVBEです。開いてみると記録された操作がVBA言語で記述されているのがわかります。

↑マクロの記録は「これでもか」というくらい記述してくれるので、実は必要なのはちょっとだけだったりします。(上記はセル範囲に格子状の罫線をつけるという同じ動作をしています。)

Excelにおいては、自動記録もしくは直接入力にてVBA言語で「こういう操作をしなさい」という命令文を作って、それが「マクロ」と呼ばれる機能となる、という感じでしょうか。

AccessだとVBA≠マクロ

Accessでの「マクロ」という概念はもっと固有に独立していて、VBAの編集ツールはVBE、マクロの編集ツールはマクロツールと、全く別物の専用ツールが存在します。

  • (Accessにおける)VBA … VBE画面にVBA言語を使ってコードを直接打ち込んで機能を作る
  • (Accessにおける)マクロ … マクロツール上でクリック、ドラッグ、選択などをしながら機能を作る

なんとなく、VBAのほうが カタカタ! ターン!! プログラミング!! って感じがするかもしれませんが、どちらもプログラミングです。そもそもプログラミングって、「作業を行わせるための指示文を作成すること」ですからね。

AccessVBAに比べて、Accessマクロは、選択肢があらかじめ用意されていて、選ぶ、クリック、ドラッグ、という直感的な操作でプログラミングができるので、とても初学者にやさしいです。最初の一歩が踏み出しやすいというか。

AccessVBAとAccessマクロは作れるものに違いがあるの?

私の経験では、(Accessというソフトウェアの枠を超えない範囲では)VBAでできることは、大抵はマクロでも再現できるのではないかと思っています。

最初、「マクロはかんたんな反面、VBAに比べてできることが少ないんじゃないか」と勘違いしてしまったのですが、マクロツールはVBAを元に作られているので、VBAで書けることは大抵マクロでも書けます。

ただし、細かな部分で「VBAではできるけどマクロでは無理」ということにも遭遇したことはあって(ある命令でVBAなら別フォーム指定できるけどマクロだとアクティブフォーム以外指定できないなど)、同じ結果を得るためにVBAよりマクロのほうが多くの記述が必要だったり、VBAとは違う方法になることもあります。

ただ、VBAはフォルダ・ファイル操作のようなアプリ外の操作ができるのと、ADOなどを使って別のアプリケーションと連携することができるので、1つのAccessファイルを超えて色々動かしたい場合はVBAに分があります。

Accessマクロで複雑な記述をするにはAccessVBAの知識が必要

さて、「マクロでも結構できるよ!」と言ったものの、「かんたん」かどうかは別問題で。

Accessマクロのメリットは、やりたいことを選択、ドラッグ、みたいな操作でプログラミングできちゃう! というところだと思うんですよね。「フォームを開く/閉じる」くらいのものならマクロはとっても便利です。初学者が入りやすいのは間違いないです。

ただし、ちょっと複雑なことをしようと思うと、VBAの文法に基づいた「仮説」が立てられないと、組み立てるのが難しくなってきます。「VBAでこういうメソッド(命令)があるからそれをマクロでやるには」とか「このプロパティ(属性)はマクロではどうやって書くんだ」とか。

↑エラートラップなんかもちゃんとできる

主観ですが、VBAで書く構文を日本語で組み立てる、みたいな感覚になってきます。VBA脳→マクロで再現、という感じになってくると、最初からVBAで組んでしまったほうが早い、というのはあるかもしれませんね。

AccessVBAとAccessマクロはどう使い分ければいいの?

どちらを使っても良いと思うので、プログラミングを設定する規模と、その後のメンテナンスは誰がどの頻度で行うのかということを踏まえて、マクロかVBAかを選択するのが良いんじゃないかな、というのが私見です。

かんたんな動作ならマクロを使ったほうが楽だしメンテナンスへの敷居がVBAよりも低くなります。ある程度以上の難易度をマクロで頑張りすぎると長くなって全体像をつかみにくくもなるので、VBAのほうが後々メンテはしやすいかも。

ただ、同じファイル内でこっちはマクロ、こっちはVBA、と混在しているとそれはそれで全体像の把握は難しくなるので、チームで使いやすい形を相談して、そのルールや設計図をちゃんと記録しておくのがベストですね。

初学者の「プロシージャ」の違い

ExcelVBAもAccessVBA(マクロ)も、まずは小さなまとまりから始めると思います。VBAでは、プログラミングの1つのまとまりを「プロシージャ」と呼びますよね。この「はじめてのプロシージャ」の種類が、ExcelとAccessでは違うんじゃないのかなー、と思いました。

Excelは「独立型」から入る場合が多い

私もそうだったのですが、ExcelVBAの初めてって、「標準モジュール」を作るところからスタートしませんか? これは、Excelは「手作業をコードに置き換えて自動化してみよう」みたいなところから始めるのが効率的だからなのかなと。

Excelにもユーザーフォームはあるのですが、それよりも「シート」というインターフェースがすでにガッツリあるので、とりあえずフォームを作る必要がないんですよね。まず目の前のこのシートに対して「なんかやってみよう!」みたいな。

だから、標準モジュールから始めて、独立型プロシージャ(ジェネラルプロシージャ)を作ってそれを起動するきっかけも自分で作って、という流れになるんですよね、きっと。

独立型プロシージャ(ジェネラルプロシージャ)とは、起動のきっかけを与えてやらないと実行できない形のプロシージャで、自由なプロシージャ名をつけることができます。

対称に、イベント駆動型プロシージャ(イベントプロシージャ)というものがあり、シートやフォームに対してユーザーが行った動作をきっかけに自動的に実行されます。こちらは対象のモジュールに「オブジェクト名_動作名(例:Worksheet_Click)」という名称で書かれていないと、イベントプロシージャとして認識されません。

参考↓

そうすると、フォーム、コントロール、イベント、ということを知らなくても進められるんですよね。シートにもモジュールがあってシートイベントがあるということも、知らなくてもとりあえず何かはできるようになる。なので、ExcelVBAの初学者はもしかしたら「イベント駆動型プロシージャ(イベントプロシージャ)」という存在を、知らない人が多いのでは…?(私がそうだった!)

ExcelVBAの学び方セオリーみたいなものとして、初学者は「標準モジュール+ジェネラルプロシージャ」から始めて、それができるようになってから新しい扉「シートモジュール、フォームモジュール、イベントプロシージャ」の世界へ飛び込もう! 可能性が広がるよ! みたいな流れが存在する気がする…!!

Accessは「イベント駆動型」から入る場合が多い

比較してみるとAccessはまったく逆で。

テーブル、クエリ、レポート、などの主要オブジェクト群に「フォーム」があって、初学者はここに対してVBA(マクロ)でプログラミングをすると思うんです。まずフォーム上のボタンをクリックするなどのイベントプロシージャから入るはず。

Accessから入った人は、逆に「標準モジュール」とか「ジェネラルプロシージャ」を知らない人のほうが多いのでは…? プロシージャを共通化して使いまわしたいとか、そういうときにはじめて使うんじゃないかな。初学者ではそこまでいかない人が多いんじゃないかなー??

それに、Excelと比べると、AccessではVBA(マクロ)を使うためにはAccess自体の総合的な知識が必要だと思うので、VBA(マクロ)を始める前の段階で覚えることが多くて、最初の一歩の敷居は高い印象。

具体的には、テーブル、クエリ、レポート、フォームという主要オブジェクト、各種セクション、コントロールなどの特徴、レコードソースやコントロールソース、このあたりのことをまずは理解しないといけなくて。

実際私は、VBA(マクロ)を組むときも、そういったオブジェクトとかコントロール群の特徴をよく理解していないと書けないなー、という感想を持っています。

全体設計の重要度

ExcelVBAは全体の設計が命

とにかく、ExcelVBAは自由度が高い。高すぎる。マクロの記録的なちょこっとしたレベルから、フォームを駆使したガッツリなアプリケーションまで組めてしまうので、全体像を把握できる設計図を残しておかないと本当につらい…。

とにかく、自由度が高すぎるがゆえにとっちらかりやすい

モジュールやプロシージャといったことが分かってなくてもなんか動くものが作れちゃうから、個人のレベルの範囲がものすごく広いし、Excel自体を使ってるユーザーもものすごく多いし、ものすごくカオスなんだろうな。

ExcelVBAは他言語のプログラマから嫌われがちというお話も聞くのですが、おそらく他の言語に比べてコーディングルールというものが徹底されていない(そもそもコーディングルールという概念を知らないユーザーが多い)というのも一因なんじゃないのかなぁ。

AccessVBA(マクロ)は補助的役割

Accessは、データベースソフトという目的から、全体の大きな流れは、テーブル、クエリ、フォーム、レポートなどの主要オブジェクトがやってくれるし、その間の連携はあらかじめできるようになっているので、VBAやマクロは補助的な役割。小さな部分で完結する便利な小技っていう印象。

ただし、VBA自体が小技扱いだとしても、データベースソフトとしての主要オブジェクトの設計はきっちりやっとかなきゃいけないので、そっちは別の話。

あらかじめデータベースソフトとして、そこそこちゃんと設計された形になってるのが前提なので、VBA(マクロ)を組み込んでもExcelVBAほどぐっちゃぐちゃにはなりにくいのでは。

そのぶん最初の一歩の敷居が高いので、Excelユーザーよりも人口も少ないし、オブジェクト、モジュール、プロシージャというあたりは理解していないと難しいので、たぶん個人のレベルの範囲もそこそこ以上の方が多いはず。

ちなみにAccessは他の主要オブジェクトがたくさん機能持ってるので、VBAに依存しなくても結構いける感じがします。VBA使わなくてもプロパティシートからできるんじゃん! と思うことが結構ありました。

総括

_人人人人人人人人人人_
> どっちもたのしい <
 ̄Y^Y^Y^Y^Y^Y^Y^Y ̄

両方やってみたことで、モジュール、プロシージャ、オブジェクトまわりの総合的な理解が深まった気がします。

長いことExcelVBAばかりやってきていて、もちろんフォームもコントロールもイベントプロシージャも使っていたんですが、「なんとなく」だった部分が多かったんだなと。Accessのマクロ/VBAをさわってみることで、曖昧でふわっとしていたものが「なるほどー!」という気持ちになりました。アレはこういうことだったのか、ということがボロボロと出てくる出てくる。

とにかく、いろんなものがきれいに連携して組み合わさっていて、ああ、プログラミングって、VBAという言語って、こういうことなんだなっていうか。

この記事に需要があるかわからないんですが、自分としてはまとめてみたいと思っていたので書きました! 以上です!!

公開日:2018/04/13

1件のピンバック

  1. […] ExcelとAccessのマクロとVBAの違いについての所感 […]


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

コメントは承認制ですので、反映までしばらくお待ち下さい。(稀にスパムの誤判定にて届かないこともあるようですので、必要な際はお問い合わせからお願い致します。)

YouTubeでQ&Aコンテンツを企画しています

運営しているYouTubeチャンネルで、ご相談やご質問を募集しています。動画のコメントやお問い合わせページからお気軽にご相談をお寄せください。