  |
はてなキーワード: VbAとは
そもそも本格的なデータ加工や解析、統計だったらAccessなりOracle DBなりを使うべきであって、エクセルVBAはしょせんエクセルVBAなのよ。
エクセルVBAが上記DBソフトウェアの下位だって言ってるんじゃなくて、適材適所だってことね。
だから、エクセルVBAで大切なことは、見読性だと思うのよね。
処理速度にこだわって配列上ですべての処理を終えても良いし、確かにそのほうが早いしかっこいいんだけど、
処理がコケたときにどこで何が起きてるかわかりづらくなるくらいだったら、
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
エクセルVBAってさ、「そんなに頭良くない奴でも1週間勉強すれば”何か動く”ものが作れる」ってとこが最大の功罪なんだよね。
ウチの職場にポンコツすぎて干されたじぃさんとおばさんがいて、仕方ないからエクセルVBA覚えさせたら、”何か動く”ものをつくり作り始めた。
でもその内容が恐ろしい。
例えば10万件くらいあるレコードの検索を平気で線形探索させる。
二分探索とか、当然知らない。
ゆえにとてつもない時間がかかる。
これで「私VBAできるようになりました（ﾄﾞﾔｯ）」ってなもんだもんね。
配列？
そんなのに理解が及ぶのなんて、転生後だよ。
是正を求めるほうがどうかしてる。
これ自分もやる
相手が手作業でやる前提の見積もりしてるなら、わざわざそれを減らす必要ない
VBAは便利だけど実際の業務に組み込むとなると賛否あるし面倒も多い
他人のことは放っておけ
手作業頑張った感が出る中間ファイル生成させるとかやって、空いた時間で勉強するんやぞ
ExcelVBAの後にどうせだから他のVBAもやっとくかと遊んでたら、OutlookVBAで名前空間と出会って衝撃的だった
会社から365移行するとか言われたんでOfficeScript触って連想配列とかいう素晴らしいものと出会った
GraphAPI使って、メールも含めて仕事してるフリが出来るようになってだいぶ満足感出てきた
さぁ次は何しようかなー
昔はVBAで処理したり関数作ってたようなものも、Excel側で用意されるようになった
VBA嫌いのExcel師(営業事務)なんだけど、その程度のことをVBAでやろうとするヤツを駆逐したい。
お前は営業や他のユーザーの理解度を自分レベルだと勘違いするのをやめるべき。
うちの会社はVLOOKUP(最近はINDEXとMATCH)組めるのが「Excelできる」と名乗っていい最低限のラインで、営業と営業事務では名乗れないやつはほとんどいない。でもVBAは使える人は稀。
基本はその「難しくてもVLOOKUPの知識を駆使すればなんとかなるレベル」でExcelを組まないと破綻する。
うちの会社の一事業部は複数の会社に発注をしていて、そうすると会社ごとにデータを比較して見たいのに項目や項目順が違って簡単に比較できない、ということがよくある。
その場合マッピングと呼ばれるデータ項目の統一化が必要なんだけど、会社によって合算したいデータがそれぞれ別の方法でしか取れないとか、合算値に余計なデータが入ってるからrawデータ取ってきて件数はレコード数でカウントしないといけないとか、まぁ色々出てくる。
全取引に対してのデフォルト対応としての統一マッピングはしてるけど、そういうのはVBAでやらずにSaaS使ってるし、ものによって重視する値が変わるので例外が2割くらいある。うちの会社はその辺りの裁量が営業に認められているので例外も多め(なおオンリーワンになりたいためだけに特殊対応した奴は一人を除いて矯正or自滅済)
そういう融通をきかせるのにExcelの計算シートでマッピングするのは絶対。
あとVBAだと営業側が「どういう計算をしてるのか」とか「正しい数値が出てるのか」が確認できない。
っていうのは例えば100円3件と150円2件の仕入れにうちの取り分2割乗せて720円として見せたかったのに、『=100*3+150*2*1.2』って数式書いたせいで660円になっとるやんみたいな。こんなんよくある眠い時のヒューマンエラーで、VBA書く人ならやらかさない、なんてことは絶対ない。
しかも営業がこういうのの修正とか提案用にちょいちょいと列増やして数式入れようとしても「マクロ壊れるからやめて」とか言われる。営業が自分で調整可能なら1時間以内でできるものでも、VBA書いた人に依頼しなきゃいけないんだと、書いた人の通常業務との兼ね合いで1週間待たされたりする。
営業に金稼がせるためには営業の利便性と裁量は必須で、Excel利用者に裁量権が認められてないVBAのツールなんか全体最適化されてないクソ。
※なお裁量大きいからってあんまり好き勝手するとやらかした時に他の助けも得られず(やれることに限界がある)自滅ルート
自分も軽くVBA習得してるんだけど、フォルダ内のデータ一括読み込みとシートの分割統合の関数代わりにしか使ってない。しかもただの効率化なのでVBAが死んだところで手作業に戻せる範囲。
他人が保守できるように作るのならVBAなんか入れるべきではないし、VBA入れないなら計算シートは必須。あと計算周りを大掛かりにやるならSaaS入れてDX検討すべき。
多少デグレしても問題ないシステムなら適宜コード直せばいいけど元増田見たら社外とデータやり取りするシステムっぽいし
こういう『明らかにゴミだけど直した副作用で問題起きたら100%いじったやつの責任になるから手出しできない』系のものはそこらじゅうの会社にあるよ
俺は社外に出ない資料作る仕事してるから1回数時間かかるゴミVBAをPythonに移植して数秒で終わらすみたいなこと気軽にしてるけど移植とかコード書き直して一発で綺麗に決まることあんまないから俺が元増田の立場なら多分システム直すより転職考える
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
今仕事でよくExcel VBA使ったツール作ってるんだけど、これがまためちゃくちゃ楽しくて、もっと出来ることを増やしたい
でもVBAは属人性高いからあんまり良くないよね、という話も聞く（たしかに、今のところ全部自分用のツールとして作っているから上手くいっているけど、他人に渡したときに想定していない動きをするのがかなり怖い）
このレベルの人間が次に勉強すべきところってどのへんなんだろう？そして、どんな仕事ができるんだろう？
やっぱりPythonとかなのかな……学ぼうとして一度挫折しているから重く感じてしまうんだよな……どう勉強したらいいのかもわからないし……
PowerQuery？とかPower BI？とかもよく聞くし気になるけど、仕事で使える場面あるだろうか……
結局仕事でやらなきゃいけないことがある→楽に処理したい→楽するためにツール作る、みたいな流れが一番楽しいし身になるんだよな……
↓追記
すごく今更だけどトラバがいくつかついてた。
AIで書けるとか言ってるけど仕様打合せしてプロンプト書いて出てきたコードの動作確認してんのプログラマじゃねえか
いやまだそっちは実用になりませんとか言ったって
ノーコードとかローコードとかまたわーわー言ってるけど書ける奴の間口がちょっと変わっただけで作業してるやつ結局はプログラマじゃねえか
いっつもそうだ
juliaもpythonもそんな触れ込みだった瞬間があったぞperlより直観的ですって
EJBもnode.jsもエンジニアが不要になる～とか言ってた奴を産んだ時があった
あのときの用語は何だっけかそうだエンドユーザーコンピューティングだ
VBもそうだ
言葉で書いた通り動くって話だったぞ
英語の国の人はそうなのかなーって思いながら書いてた
Σプロジェクトもプログラマが不足するから大変だ―プログラマが不要で仕事できるようにしようーみたいな話だったと聞いている
メインフレームのシステム開発に欠かせず数多のシステム開発に使われた言語であるCOBOLだって英語を話すように書くとあっという間にシステムが出来上がるという触れ込みだった
でも、本気で悩んでいるようでいて、実際はべつにそうでもなくて、正直言って自分でよくわからない
よくわからないことが、なんか空しい、それだけはわかる、とりあえずそういう状態
たとえば資格
世間一般に難関資格とされるものを必死こいて取得したはいいけれど、
一応必要とされる業界に身を置いてはいるものの、だからといって転職して給料アップまでは気力が保たない
確実に今よりは待遇もよくなることは、理性的に考えれば分かるんだけど、
資格勉強していたときの、目標に向かって突き進む集中力の爆発がなくて、ただただやる気が出てこない
資格は持っていないが、とりあえず意味もなくPython、PHP、JavaScriptは一通り使えて、
WEBアプリの開発もいくつか個人で適当に作ってみては、ドメインの有効期限が切れたらそのまま消え去るを繰り返している
流行りに乗ってAI関連も少しいじってはみていて、ローカルで特化した文書生成用ぐらいは用意できる
Excelはとりあえず関数、ピボットテーブル、VBAぐらいは使えて、仕事はそれだけでほぼほぼ自動化してしまっている状態
Photoshop、Illustrator、Jw_cad、AutoCADなら、なんか使えます
たとえば英語
気付いたときには、英検一級からTOEIC満点、TOEFL満点まで取ってしまった
最近はスピーキングの練習として、ChatGPTに大変お世話になっている
意味もないのに、主にビジネス向けのシチュエーションを想定して、スピーキングの練習を無心で繰り返している状態
でも、外資系にいけば、他の資格や実務の経験等を合わせても、客観的に見てもおそらくまあまあの希少人材ではあるんだと思う
だけど、いくら待てど暮らせど、その気には一切なってくれない
長々と書いてしまったけれど、たぶん上を目指すべきなのに、その気になれないのが自分でもよくわからない
結局、すべてなにか明確な目的があって始めたことではないので、それを駆使してのし上がってやるぜ的な情熱がない
どうすればそれを得ることができるのか、それがわからない
自分は、なにか強力な推進力がないと前に進めない人間で、それがどうやって生まれるのか自分でもよくわからないまま、この歳まで生きてきてしまった
まだ転職が難しい年齢とまではいえないけど、何のために転職するのか、明確な理由が欲しい
転職転職言っているけど、べつに転職したいわけではなくて、ただ世間一般的に考えて、収入を上げて社会的なステータスを向上させることが正しい方向だとは思うので、そう言ってるだけではある
他になにか、それぞれのスキルの意義ある使い道があって、それに自分の気がちゃんと向いてくれるのならば、べつになんだっていいのだ
もうよくわかんない
どうすればいいですか
なにがしたいのが自分でもわかりません
人員補充で人事に新しい人入れてって頼んだら集まらなかったのか派遣のおっさん（47）を連れてきた
小太りで覇気のない顔で
課長（43）は「47で派遣？w使えないだろw」って早く別の派遣と交換してほしがってた
俺は「いやいや何か理由があって派遣なのかもしれないし」試してみましょうと言って仕事をさせた
派遣のおっさんはエクセルにデータを入力して必要な数値を算出する仕事だったんだが
まず入力が遅かった
そもそもエクセルの仕組みも理解しておらず必要な数式を消してしまったり、VBAをいじらせたら変なことして動かなくしてしましった
（結局俺が直した）
若い子なら仕事が終わってから勉強してくるんだろうがそんなそぶりもなかった
また電話も取らないし、
お昼休みの雑談にも入らず自分の席でスマホゲーム（ウマ娘ってやつ？）をやってる
上司も「俺の予想通りだっただろw」って言われて反論できなかった
やっぱり亀の甲より年の功なんだなあって思ったわ
結局初回契約期間の1ヶ月で別の派遣社員の女の子と交換してもらった
保存できなくなる。
「(ファイル名).xlsmの保存中にエラーが検出されました。いくつかの機能を削除または修復することにより、ファイルを保存できる場合があります。新しいファイルで修復を実行するには[続行]をクリックしてください。ファイルの保存を中止するには、[キャンセル]をクリックしてください。」
ググれば修復する手順が出てくるし、修復することで保存できるようにはなる。
疑問なのがここ1か月くらいで頻発するようになったところ。
去年まではこんな問い合わせは一度も受けたことが無い。
一応VBAマクロ使ってるとか、利用者のITリテラシーが低いとか自業自得な点は多々あるのだが
見る限り、そんなに変な機能を使っているわけでもなさそう。作成者もういないけど。
