「全部GASでいいじゃないか！VBAが必要な場所なんてある？」というツイートをみたので、いくつかVBAでないとだめなケースを考えてみた。
そもそも同じ機能を作り直す必要がない
「それGoogleSpreadsheet+GASでできるよ」とはいうものの、全く同じものを作り直す必要はない。作り直しの機会があればって話だけど、そんなに「寿命の短いソフトウェア」を作ってる時点で、その現場でのソフトウェアの価値は薄い。「同じものを何年も繰り返し使われてこそ」のソフトウェア。
オフラインで動かしたい
GASでの致命的な点はオフラインで動かないというところ。「デジタル化」と「クラウド化」って似て非なるもので、「デジタル＋オフライン」ってのはありえる。ソフトウェアは「道具」であって「コミュニケーション」はその一部でしかない。さらにセキュリティ観点で「絶対オフラインで動かしたい」ってニーズはある。「設定さえきちんとしておけばセキュア」なのが今どきのクラウドサービスだが、それができてないケースは山程ある。「アクセルの隣にある自爆ボタンを押さなければこの車は安全なのです！！！」という言い訳は聞き飽きた。
「ネットワークを敷く」というお仕事も存在する。その場合はオフラインだ。常にクラウドに繋がってる環境にいると、うっかり「みんなクラウドに繋がってて当然」という気がするが、どこかの誰かがオフラインでオンラインにしている。誰かにとってのクラウドは誰かにとってのオンプレで成り立ってる。繋がってないPCでちょっとした処理を動かすならVBAはまだまだ有用。
逆にネットワークを使いまくりたい
GASのFetchAPIに相当するのが、VBAではMSXML2だ。もはやVBAではないんだけど、WindowがOSレイヤーで提供しているAPIに直アクセスできるところがVBAのいいところ。
そして、GASのFetchAPIはアクセスできる数に制限がある。あたり前だが、VBAでは無制限に通信できる。証券取引委員会から大量のXBRLをダウンロードしてパースするなんてことも、MSXML2使ってやってる人もいる。
FetchAPIでは、一日のアクセス数に上限がある。さらに一日の全体データ転送量にも制限がある。しかもトリガー経由でのスクリプトの実行には実行時間に制限がある。制約が多すぎていざ使おうと思ったら使えないとかかなりきつい。
GASをいざ使い始めると何かしらの制限に引っかかって苦しんでる人が検索すると出てくる。
さらに恐ろしいのは、Googleが規約を途中で変えてくるというところ。制約がゆるくなる規約変更ならまだしも厳しくなるケースだってある。業務の生殺与奪の権奪われまくり。
ファイルサーバーにアクセスしたい
GASを使うならファイルサーバーじゃなくてGoogleDrive上でのファイルのやり取りでしょうというのが「常識」かもしれないけど、残念なことにこの世のファイル管理はそうはなってない。Google様がGoogleDriveを出してきたときにはこれでファイルサーバが要らなくなると思ったけど、そうはならなかった。何なら企業向けにはBOXがシェアを伸ばしてる。
さらにクラウドベースでもマイクロソフトがAzureでSMBプロトコルでサーバーを提供している。さらにアーカイブ用途のクラウドストレージではS3が圧倒的シェア。
つまり
- ビジネスユーザ向けクラウドストレージではBOX
- ファイルサーバーのクラウドサービスはAzure
- アーカイブ向けクラウドストレージではS3
と、どこでもGoogleが存在感を出せてない。「GAS使うためにBOXもAzureもAWSも辞めましょう」という理屈は通用しない。結局いずれともつながるという観点では「PC上で処理が動く」ってことはとても大事。別にVBAというプログラミング言語を使いたいわけではなくて「PCをハブにして手軽にデータを変換したい」ってだけなの。
アナログからデジタルに変換したい
オシロスコープからのデータをエクセルVBAで加工するなんてことも、GASで代替できるもんじゃない。世の中にはアナログデータをデジタル化してくれている人たちがいる。「今どきPCでVBA？時代遅れねww」とバカにするのは勝手だがあなたのデジタルデータは誰かがアナログから変換しているのだ。
PaaSのバージョンアップに左右されたくない
あえてGASをPaaSと表現したが、PaaSのバージョンアップでこれまでのコードが動かなくなることはある。「何もしてないのに動かなくなりました」なんてセリフはPaaSが出る前はなかったけど、PaaSで運用していると平気で「あなたのコードはこれこれの古い機能を使ってるから動かなくなります」と警告してくる。
もちろん食らいついて修正するというのが、PaaSと付き合う上での「常識」ではある。が「3年コードを一切弄らずに動く道具」はそれはそれで尊い。「常にコードはブラッシュアップするのが常識っしょ！」って現場ばかりではない。あなたが契約した年金の運用ルールが毎月変わってよいわけがない。
VBAはめちゃくちゃ「古臭い」仕組みなのだが、「長い間使われている」というだけで価値がある上に「その仕組をまた再利用できる」という点でこれも健全なITと言える。
終わりに
とはいえ私個人はVBAをお仕事にはしてない。前職ではVBAを使って社内業務改善もしていたが、いまではクラウドサーバー（IaaS）上でRubyやMySQLを使ってSaaS型の事業形態でお仕事をしている。VBAを仕事にしていない理由は「あまりに低コストで作れて提供価値も高い」からビジネス上の差がつかない。例えば図書館や小学校というサービスはとても価値が高いけど、ビジネスとして始めるにはかなりしんどい。VBAはそういう存在。価値の有無と金の稼ぎやすさは別もの。