自動記録(マクロの記録)でできないことがいろいろ見えてくる。

「マクロの記録」でしかマクロを作ったことがない方に向けた説明です。 まず、VBA基本」VBA初心者の方に合わせて順を追って構成しておりますので、 「マクロの記録(自動記録)」も初めてで解らないという本当の初心者の方はVBA入門」の先頭からお読み下さい。





「業務ロジック」というのは単純な作業を「判断・分岐、繰り返し」を持って行なうという仕掛けだと思います。 「業務ロジック」などという言葉をいきなり持ち出しましたが、一連の「仕事」について細かく手順を細分化させたひとつひとつの「作業」を上から箇条書きのように説明した文書と考えて下さい。
もちろん、イベントなどこの説明に該当しにくいものもありますが、いつも皆さんが手作業で時間を掛けて行なっている作業をマクロで自動化できないだろうか、などと考える種類の処理はこの説明で良いはずです。




但し、細分化の工程でどうしても「③で結果が○○だったら⑤に進む」とか、「④を入力シートの行数分繰り返して行なう」などという説明が必要になるはずです。 こういったことをこの章では「判断・分岐、繰り返し」と呼んでおり、「マクロの記録(自動記録)」で作成されるコードには含まれないものです。
つまり「判断・分岐、繰り返し」については自分でVBAのコードを作成・記述しなければなりません。




この章でここから数ページで説明している内容は、この「判断・分岐、繰り返し」と、それを含めてのプログラム作成の取りかかりに関する説明です。

「判断・分岐、繰り返し」とは...
何かの業務をコンピュータ上の「仕組み」に置き換える場合に「判断・分岐、繰り返し」は重要なファクターです。
「判断・分岐、繰り返し」というのは「何の条件の時に行なう」とか「どの条件になるまで繰り返す」という部分のことです。 その条件で「何」を行なうかについては、もしかしたら「マクロの記録」に出てくるようなことかも知れませんから、逆に考えて「マクロの記録」で作成されたコードに対して「判断・分岐、繰り返し」のコード記述を追加することで実現できる場合もあると思います。



また、複雑な場合は「判断・分岐、繰り返し」による1工程の中でさらに「判断・分岐、繰り返し」が行なわれることもあります。 それらを総合して「業務ロジック」に関する説明や、場合によってはプログラムコードが成立していきます。

どのコンピュータ言語でも同様です。
この「判断・分岐、繰り返し」という部分のコード記述はどのコンピュータ言語にもあります。
Basic(VB・VBA)のみならず、CJavaでもこの基本は同じです。 「書き方」が違うだけで、ある程度経験されれば違う言語でも「英語」による構文なので判読はできるようになります。
しかも、コンピュータ言語のバージョンが変わってもほとんど影響を受けない不変的な部分でもあります。



「マクロの記録」でこの「判断・分岐、繰り返し」が出てこないのは、操作の記録という行為の中ではできないからだけです。 結果的に「○○を3回繰り返す」だったとしても記録という手段では「○○」「○○」「○○」が繰り返し記述されることにしかならないということです。
つまり、「マクロの記録」はBasic(VB・VBA)言語の「言語」たる部分は全く使っていないということでもあります。

EUP(End User Programing)」なのか?
別の側面の話になります。



Microsoftは一時期「EUP(End User Programming)」を推奨していて、そのための資格を設立してアナウンスしていました。 「一時期」と書きましたが、資格自体は現在も存続しています。
ですが、スマートフォン時代になってマイクロソフト主導に利用者が乗ってこなかったのか、 あるいは現場が勝手にプログラムを作成することについて企業側が抵抗したのか判りませんが、実際問題「死語」になってしまったようです。



しかし、業務をコンピュータ上の「仕組み」にできれば業務が合理化できるだろうということはその業務の担当者なら簡単に判ることです。
「楽になる」かどうかは別として、「システム化によりチェック精度が上がる」「個々のデータの所在が明確になる」「作業者が替わっても同じ品質の結果が得られる」などの歴然としたメリットがあります。
さらに、ネットワークが完備している中での「業務システム化」であれば、現場部門と本社などの管理部門、さらには監査部門などが同じデータをタイムリーに見られるので、 システムが掛からない項目についても牽制機能を働かせるというメリットがあります。



企業側が「現場作成のシステム化を規制したい」反面として、企業の規模・体制にもよりますが、情報システム部門が各現場の「システム化」要請の全てには答えられないことはあると思います。 細かい業務の「システム化」については「現場でできるなら現場で用意してほしい」という現実論は避けられないのでしょう。



ExcelVBAだけで大がかりな「業務システム」を構築するようなことはできませんが、 ここでコンピュータ言語の基礎に触れて学んでいこうということは、他のコンピュータ言語にも応用ができることだということです。

一方、どこの企業でも見受けられることですが、部署で行なっている業務の個々の「作業」は、その「作業」の名前程度は部署の責任者が掌握はしているものの、 実際の「作業」の内容となると実務担当者でないと解らないということが結構あります。
異動・退職による業務引継ぎも実務担当者ベースなので部署の責任者は「蚊帳の外」のままだったりします。 よくあるのは引き継いだ新しい実務担当者が引継ぐ内容を100%は理解しておらず、必要な業務作業の一部が「欠落」してしまうことです。 その「欠落」にしばらくの間誰も気づかず、ある時に顧客に影響するような大きな「欠陥」に発展することも考えられます。
そこまで行かなくても業務の「システム化」の推進の有無すらもその実務担当者の裁量になってしまって、業務の品質も「人」に依存してしまいます。



EUP(End User Programing)」という言葉が出回った時、私も最初は「現場が勝手にシステム化する手段」と受け取りました。
会社が必要とする基幹システムに載らない細かい業務でも、システム化して合理化あるいは精度向上できるものはたくさんあると思いますが、 先にも書いた通りでシステム化の要不要や詳細な内容を実務担当者が握ってしまっていることが多いので、 「EUP(End User Programing)」は結局その実務担当者が「やるかやらないか」になってしまいます。



ここから先は「べき論」や「規制論」ではなく、自分で取り組むとなった時に何を学ばなければならないかの説明になります。