VBAに頼ると時代から取り残される
また煽っていきます。
Excelというのはプログラミングと相性が悪いです。見た目を整える機能も、計算する機能も中途半端です。関数ベースの処理では、配列処理やAnd、Orの条件分けがでくると破綻します。関数を無理やり組み合わせれば実現できますが、そもそもそういう機能が実装されていません。用途としては、別のシステムで出したリストデータをレポートに加工する程度のものでしょう。ただ、VBAを使うことで、そういうコンセプトを大きく飛び越えることができてしまいます。
よく聞くのが、ExcelでDBにつなげてフロントエンドとして活用するという事例です。個人的には「やめとけ」としか言葉が出てきません。そういう用途であれば、Accessでやった方が楽にできます。今時、Office365ならAccessの導入コストが問題になることもありません。わざわざExcelを駆使していばらの道を進む意味がありません。もともとDBじゃないソフトでDBみたいな処理をさせようとすると、逆に苦労が増えます。また、Powershellなら一発で済むような処理を、わざわざExcelとVBAで実装して「難しい」とメンテナンスを放棄している事例も見たことがあります。
PCが一般の企業に普及してから、ソフトウェアは大きく変わり続けています。ただ、PCが普及しだしたころと同じような感覚でソフトを使っている人が多いような気がします。PCが普及しだしたころは、Excelだけでも結構な値段がしました。そのうえAccessを導入するとなると、それなりの出費がかさみました。クラウドでいろいろなサービスも充実しています。とれる手段は大きく広がりましたが、未だに十何年前の手法に固執する人が多いように思います。
経験則ですが、ExceでVBAを書いている人と十何年前の手法に固執する人と重なります。昔はVBAは強力な武器でした。しかし、今では道具の一つに過ぎません。プログラムをするにしても敷居は大きく下がっています。書籍の質も上がっているので、MS Officeの自動処理をPythonでやるという選択肢も、やる気があれば実現できます。むしろ、VBAは手法として古いです。情報はたくさんありますが、元になっているExcelの機能が貧弱です。
昔書いたツールがクラウドサービスでやすやすと乗り越えられると、実のところ残念な気持ちになります。新しいツールが出てきたときもそうです。残念ではあるけれど、今までのツールを捨てて乗り換えてみると、意外に便利だったりします。今では、コードを書かなくてもシステムを組めるくらいのサービスはいろいろあります。そろそろ、ExcelとVBAの窮屈な縛りから解放されたらどうでしょう。でないと、ソフトウェアの進化による恩恵が受けられません。
コメント
白栁隆司＠エンジニアカウンセラー
今回のタイトル、「VBAに頼ると～」ではなくて「VBAに固執すると～」の方が、内容としては適切な印象を受けますね。
どの様な技術であれ、それに固執することは適切な判断の機会を逃してしまうでしょう。
「頼ること」が【悪】なのではなく、思考停止し前例踏襲の上にあぐらをかき、続けることこそが【悪】なのだと考えます。
もし、我々技術者であればともかく、一般的な事務作業の傍らで、自作のExcelVBAに頼る人達まで、同じ様に切り捨てるのであれば、やりすぎだと感じます。
まるで、最新の医療知識に即してないからと、家庭で行われる民間療法を貶す医師のような、行儀の悪さだと、写ります。
ちゃとらん
「また煽っていきます。」と宣言されてますから、一般的な事務作業の人達も含めているのでしょう。
そもそも、技術者が顧客要望やメンテナンス以外で、VBAやEXCELマクロ、Accessなどでシステムを組む事はないでしょう。（チョンプロを除く）
一般人が業務作業を軽減するのも含めての脱VBAという『煽り』なら、私も賛成です。
makoto
正解はほどほどにVBAとうまく付き合うこと。
とかでしょうか。
- Horus -
当たりです！
Ika
先にコメントした方が書いていらっしゃるとおりだと思います。VBAなんて、というのは簡単なのですが。
今日、久しぶりにVBAを使ったら、まぁー大変。今時の言語じゃないし、もう、忘れてるし、昔やってたはずのことがサラサラと出来ないし。c#なら一発なのを自分でメソッド実装して、とか。使いたくもないけれとも、とにかく標準環境で動くのことがなによりも大切なこと。
でも実際の事務系の仕事ではexcelが主で、VBAが主でないわけだから。プログラマ目線で書いているように一見されるのですが、VBAが話に出てくることから推し量るに、プログラマの仕事自体が「従」な状況。それなら誰しも今ある環境で最大限のパフォーマンスを探るでしょう。pythonを例に挙げてますが、それを追加して確実に動く状況にするのは誰？誰も保証しないのが普通ですよね。excelだけは入っている、ならVBA使う。それもエンジニアの仕事でしょう。
あ、いや、VBAに頼るのは、と言ってることから見ると、特定のインスタンス的な、つまり、誰かに対する愚痴なのかな？それなら、上から目線で説教されても興醒めですよね。失礼しました。
- Horus -
少々強めの内容を書こうかと思い「VBAに頼るのは」とタイトルを付けました。あんまり蔑ろにして単なるVBA叩きじゃしょうがないなと、書いている内に「頼る」から「依存」になっていたようです。白栁隆司 さんの指摘通りですね。流石、コラムニストさんだけあってよく読んでいると思いました。
エセエンジニア
だったら、何を使えばいいの？
担当が変わって前任者の作った関数やマクロに閉口しています。
マクロ記録使ったことない人
過去のコラムも含めてExcelとVBAに一番憑りつかれているのはコラム主ではないかと思いますがね
プログラミング言語としてはVBAは貧弱なのは間違いないが、Excelさえ入ってればどこでも使える都合のよさは強力
質を求めない小さな処理、個人あるいは小グループで使うようなものなら"高尚な"プログラミング言語で組まずともVBA、それこそマクロ記録で済むようなものも多いわけで
一定以上の規模のシステム/ツールをVBAで作成するのは確かにアホなこと
でもそれは設計時点で間違っているわけで、コラム主が批判すべきはそんな設計をする人間やそれを止められないコラム主自身だと思いますよ
- Horus -
ご指摘のとおり、VBAに憑りついていますよ。ネタとしてこれほど扱いやすい事例はないですので。
VBAは簡単に手を出せるのとGUIが簡単に操作できるという特性上、使う人の考え方が出やすいです。なので、VBAを起点に書くとコラムが書きやすいです。本当のところ、その程度の見解です。
一般的な事務作業者
2020/12/02 16:46白栁隆司＠エンジニアカウンセラーさんに賛同！！
すべすべかっぱ
8ビットマシン語時代からの時代錯誤中年エンジニアです。なので、古臭いやり方使います。(笑)
Excelはとても良くできたツールですけど、どうしても二次元のデータ構造に縛られてしまいますよね。
データモデルをうまくExcelが処理しやすい様に落とし込んでやるのがコツです。まぁ、それが簡単にできれば苦労しないですけど。(笑)
Excel VBAはAccess VBAより安定していて好きです。Access VBAは変な動作（仕様？）でドツボにハマる事があって萎えます。
Excelか、Accessか、選ぶのは処理するデータによります。そして、コードがシンプルになるツールを選びます。
- Horus -
なるほど。ちょっと目を引いたのでコメントしておきますと、私はAccessでVBAを書いた方がシンプルになるんですよ。
侘助
リーベルGさんの高慢と偏見、人形つかいを読み返した方がいいと思う。
結局どういうポジションの人が何を改善したいのか、ということが伝わらないと
不毛な論議にしかならないのでは？
- Horus -
単なるツールの話です。改善とかそういうものではなく、ツールの向き合い方の一つの見解を提示です。論点が違っています。
議論を語るのであれば、指摘ではなく論点の確認をしましょう。いきなり「しかならないのでは？」と強気にでるのはいいですが、外していては恰好がつきません。
なお、個人的な趣向により「議論」というキーワードを使用する人には厳しめに対応いたしますのでご了承を。
Horus
最近忙しいので、レスポンスを付けやすい人にだけインラインにて返答させて頂いております。肯定的なご意見に対しては、どうも返答が冗長になりがちになってしまいます。
気の利いた返答が苦手なので、沈黙をもって納得とさせて頂きます。
匿名
安定して動いているならば、VBAでも企業はいいだけなんだけれどもな
この人、もしかしてクラウド関連の技術者でそっちのサービスへ誘導しようとしているのかな？とか思ってしまう
社内のシステム（VBA）を、専用ソフトやクラウドサービスなんかへ移行しようとしたかかってしまうコストを度外視してモノを言っているのが気にかかる
安定して稼働しているならば、触らない、でいいと思う
無意味なシステム更新で法人税を減らさなきゃいけない企業は全体の3％程度
- Horus -
アイディアというのは、まず現実を度返しして考えるものではないでしょうか。アホみたいに効率の悪い状態で安定してるから、問題提起としてこういうコラムを書いてみました。
俊
Excelで完結するところがVBAの良いところだと思います。
PythonやそのライブラリをローカルPCにインストールするのって一般ユーザには敷居が高いですし、情シスに許可をもらえるかどうかもわかりませんし。
自由な職場ならDBにストアドプロシージャを登録して、レポーティングツールで表示させたりとかすると幸せになりそうですが。
通りすがり
まず見事な煽り芸と言っておきます。
コメント欄をみると「Excelがあれば動くのがいい」という意見がありますが、この理屈であれば、Hoursさんの言うようにPowershellならExcelなんてインストールされていなくても動くし、JavaScriptに至ってはどのOSでもだいたいブラウザがあるのですから、VBAなどよりよほど場所を選びません。ですので、この論点で主張するのは、視野が狭いかと思います。
また、「今動いているからいい」というのは、DXの崖に落ちると言われる企業によくある現状最適に陥った思考です。あるべき姿を考えられていないと思います。だからAccessにすべきとまでは言いませんが。
しかし、それよりも大事なことは、ここで反論する方々がいかにVBAに魂をとらわれているか、変なプライドを持ち合わせているかということではないかと思います。
Hoursさんの主張はタイトルから「時代から取り残される」という主張なのですから、反論すべき点は「取り残されないと考える論拠」です。
それは「Excelは滅びぬ。何度でも蘇るさ」でもいいですし、「VBAというのはポータビリティがあり、クロスプラットフォームで動作する」でもいいですし、「VBAのコーディングができると他の言語やAPIとの連携がこんなに便利」でもいいです。
そういった反論抜きでは、ただ自分達の既得権益とプライドを守るために感情的に反発しているだけに見えてしまいます。
- Horus -
申し訳ないですが、何が言いたのかさっぱり分かりません。
> そういった反論抜きでは、ただ自分達の既得権益とプライドを守るために感情的に反発しているだけに見えてしまいます。
自分は意見を言うだけであって、それが人にどう見えてもいいと思っています。そのくらい肝が据わっていないと、エンジニアライフで意見なんて発信し続けられません。
俊
Powershellのバッチは、デフォルトから設定変更しないと実行できないため、それこそ企業によって実行可能かどうか変わりますし、影響範囲が大きいです。
# これは私がサーバOSばかり触っているため、クライアントOSだと違うのかもしれません
ブラウザによるサービス提供は賛成ですが、コンテンツの責任を持つ部署をどこにするか、という問題もありますし、別にWWWサーバを用意しないといけないため、このレベルで問題の発生している企業では実現が難しいと思います。
Accessはランタイム版があるため、利用側はAccessを購入する必要はありません。
ただ、Accessは、先日のOSバージョンアップで、コーディングスタイルによって一部の半角カタカナのカラム名を認識しなくなってエラーになったりしたため、結構バージョン依存していてそんなにお手軽ではないと思います。
DBリンク先のSQLServerでは全角カタカナなのにAccess側で半角カタカナとか使うなとか、コーディングした前任者に言いたいことは多々ありますが。
クラウドサービスで実現する件についても、情報漏洩についてのリスク分析を適切に実施する必要があり、導入可否については情シス部門を巻き込む必要があり、それ程お手軽ではないと思います。
- Horus -
Powershellについては発想が逆ですね。.batのように不用意にダブルクリックで実行されないからむしろ安全です。
ご指摘の通り、現状を変えるという視点でこの話をすれば、また話は違ってくると思います。ただ、VBAで安直に対応し続けるという選択肢を取っても、同様にリスクは存在します。