GASとノーコード

業務内でも業務外でもGASを使いたくて、勉強用の書籍や資料を揃えているところです。その内容も記事に書く予定ですが、昔を思い出してみると、こんな風に自分がGASを勉強する姿勢になっていること自体に驚いているというのが正直なところ。

わたしは新卒で入社してからプログラミングを開始した人間で、しばらくは逆に昔のGASにあたるVBAに興味津々でした。VB6（！）で業務システムを扱う仕事だったというのもあり、むしろ親近感を覚えていたぐらいで、古臭さや嫌悪感みたいなものは全然ありませんでした（ただし、その当時でもVB6は古い技術になりつつありましたが）。

それから数年して、業務上でも.NETが採用され始め、「オブジェクト指向」を理解し始める頃には、Office製品に付属するVBAやVB Scriptに対する印象も一緒に古くなっていきました。そういったいわゆる簡易プログラミングにあたるものは、素人が使うもの、不完全な言語、と思い込んでましたね…振り返れば、VB系の不完全さを業務で散々味わったが故の嫌悪感だった気もしますが…

現在でもVBA自体は存在しているものの、MS Officeのシェアも含め、昔より影響力が減っているのは間違いないはずです（とはいえMS Officeは充分に現役でしょう）。そのシェアを奪っている一番手はおそらくGoogle Workspaceで使える各Officeスイート製品で、実際に個人でも業務でも大変お世話になっています。

転職後、以前よりもソースコードを書く機会が減り、スプレッドシートと向き合う機会が増えました。その中で自分の作業を自動化したいという気持ちが強くなり、前向きにGASを勉強する意思が湧いてきたという次第です。昔、やたらExcelで凝った関数やマクロ使いまくりのブックを自慢しているマネージャがいましたが、ちょっとその気持ちわかるもんな…自分なりにプログラミングをしたいんだよな…

昔話はともかく、GASの仕様を見るにつけ、現役のプログラミング言語（ECMAScript）を使えるということは素晴らしいと感じる。VBAもVBが盛んだった時期には現役だったはずですが、ちょっと生き延びすぎたということなんですかね。Pythonに変更されるという噂も一時期飛び交いましたが、どうなったんでしたっけ。個人的には、もう一段の進化を期待していて、もっとたくさんの言語でこういうスクリプティングができるようになればいいな、と思っています。ベースになっているのがECMAScriptならば、現時点でもいろいろトランスパイラが使えるのかもしれないですけど。

現時点でわたしはシステムプログラミング言語としてはRustを推しているわけですが、その他にもこういった業務自動化に使えるような簡易プログラミング言語と、さらにテキストベースではないプログラミング言語環境（最近ノーコードと呼ばれているやつ）の3つが必要なんじゃないかなと今のところ考えています。それらがレイヤーのようにそれぞれ支え合って連携できるようになったりすれば、技術レベルや求められるパフォーマンスに応じて使い分けが可能になるでしょうし。と書きつつ、たぶんこういった考えはもう何十年も多くの人間が挑んできて一部実現しては世代が入れ替わったきたんでしょう。わたしもその中で、せいぜい頑張るとしましょう。