Excel VBA 質問スレ Part54

**デフォルトの名無しさん** · 2018/05/26(土) 20:37:37.74

ExcelのVBAに関する質問スレです
コード書き込みや作成依頼もOK

最近プロによる書き込みが多々見うけられますが
彼らに絡むと話がこじれるので質問したい方は適当にスルーしてください

※前スレ
Excel VBA 質問スレ Part53
http://mevius.5ch.net/test/read.cgi/tech/1524823358/

**デフォルトの名無しさん** · 2018/07/21(土) 22:41:02.84

>>952
それ全部PowerShellの首を絞める言葉なの分かってますか?
適材適所分かっていますか?

PowerShellに向くものが有るとは思いますがあなたが言ってるのは向かない用途ばかりです。

**デフォルトの名無しさん** · 2018/07/21(土) 22:44:41.80

>>942
VBAを使う利点と理由かー

①進捗管理表
利点:休日の判定や予実績の線を更新する作業が楽にできる点
予定と実績の工数を入力するだけで、誰がどの案件をどれほどやってるか一覧で管理できる。

理由:関数でももちろんできるけど、あまり関数セル多いと重くなるじゃん？グラフ操作もVBAならではだし

②申請書
利点:記入欄を自動で埋めてくれるのはもちろんのことだけど、一番便利なのは必要な書類の洗い出し機能。うちの職場では申請内容によって用意しなければいけない資料が色々あるんだけど、
所定のマクロに申請内容を入力するだけで、
他フォルダの中から必要なドキュメントだけ、記入を終えた状態で持ってきてくれる。

理由:前述した所定のマクロファイルそのものが、申請書でもあるのよ。せっかくExcel内のデータを使用するならVBAを使った方が良いと思っている

以上。
ほぼドキュメントの利点を言っちゃってるけど、
そんな便利なものを作れる = VBAの利点だよね

**デフォルトの名無しさん** · 2018/07/21(土) 22:50:31.76

追記すると、
VBAそのものの強みは、やはり普及率が高いOfficeにくっついているという点と
プログラミング初心者でも取っ付きやすい点だと思う。
環境設定なぞ必要ないし、実行するのも簡単。
とにかくお手軽だよね。社会人のほとんどが実行できる環境を手に入れているプログラミング言語なんてVBAくらいだと思う

**デフォルトの名無しさん** · 2018/07/21(土) 22:56:17.09

>>954
噛み合わないとはどういうことでしょうか?
具体的におねがいします

PowerShellの主な用途は日常作業の自動化やシステム管理ですが、
ちゃんとしたアプリケーションも作れます
GithubでのPowerShellプロジェクトは5万ほど、VBは3万程度です
すべてがちゃんとしたライブラリやアプリというわけではないでしょうが傾向はわかりますね
ちなみにVBA単体はgithubに検索候補としてリストアップされていませんでした(つまりVB.NETやVB6なども件数に含まれます)
PowerShellはCOMも.NETも使えるのでもちろんExcelに関する仕事もできます

C#がVBAを批判する理由は、
貧弱な文法やベーシックライブラリ、低機能なIDE、賢くないインテリセンス、
ソースやパッケージの管理しにくさ、セントラルパッケージの不在
などです(他にも多々あるでしょうが)
これらはPowerShellが備えているものばかりです
VBAを批判する理由は全く当てはまりませんね

**デフォルトの名無しさん** · 2018/07/21(土) 23:00:45.68

>>955
VBAは業務処理をちゃちゃっと自動化するにはやや面倒すぎるプラットフォームです
その用途ならPowerShell、python、rubyがおすすめです
特にPowerShellはインストール制限が非常にゆるい(現在サポートされてるWindowsにはほぼ完備)のでどこででも安定して力を発揮してくれます

**デフォルトの名無しさん** · 2018/07/21(土) 23:04:20.93

>>956
全く首をしめてませんね
PowerShellはテキストファイルですしファイルの分割が容易です
ユニットごとに管理するのはお手の物です
当然ソース管理ツールとの相性は抜群です

察するにあなたはPowerShellを使ったことがないようなので
とりあえずPowerShellを試して見てはどうでしょうか

**デフォルトの名無しさん** · 2018/07/21(土) 23:04:45.25

>>944
こいつには何を言っても無駄かもな…

現状で有利/不利とかのレベルの低い話じゃなくて面倒かどうかの話

**デフォルトの名無しさん** · 2018/07/21(土) 23:06:58.79

自分がVBAを避ける理由は単純でMS Officeのロードマップに位置付けが無いから

MSのリソースも限りがあるんだし、
VBA好きならPythonやjavaScriptの話が出る時点で大反対すべきだと思うんだけど

**デフォルトの名無しさん** · 2018/07/21(土) 23:18:54.92

>>957
悪くないユースケースですね
自分は進捗管理にはRedmineなど他の管理ツールを使いますが
エクセルしか無い場合はVBAのほうが手っ取り早そうですね

申請書に関してはメリットには感じませんでした
入力と出力書類は分離したほうが管理しやすいと思いますよ

**デフォルトの名無しさん** · 2018/07/21(土) 23:22:22.82

>>958
普及率と難易度でいったら該当する言語はPowerShellではないでしょうか
コンソール恐怖症の人が多いのはわかってますがpowershell_iseもあるのでチャレンジして欲しいですね
VBAだとあんなに面倒だった処理がこんなに簡単に、と驚くはずです

**デフォルトの名無しさん** · 2018/07/21(土) 23:23:18.32

>>964
文面からしてお前のスキルが低いだけじゃね？
ほんとにプログラム組める？

**デフォルトの名無しさん** · 2018/07/21(土) 23:27:39.44

VBAはいらないって本当なら VBA自体が無くなるんだけどね、MSもまだ無くさないみたいだし。
本当に必要無いなら次スレもないでしょう。
ってだけなんだけどねw
VBAスレ来て必要無いって騒いでる奴は何がしたいんだか、わからんよねw

**デフォルトの名無しさん** · 2018/07/21(土) 23:30:08.86

>>964
分離は簡単にできるんだけどねw

**デフォルトの名無しさん** · 2018/07/21(土) 23:38:04.68

>>964
うちの職場はソフトウェアのインストールについてかなり厳しくて…
あるもので対処せざるを得ないところがありますね。
それを踏まえると、ツールはExcelで作るのがベターなのです。職場によって正解は様々でしょうね。

申請書について厳密にいうと、表紙となっているExcelが、申請内容を記載するマクロとなっていて、そのマクロに申請内容をチェックするのです（①新規・②廃止…等）。マクロ内のチェック箇所がデータ
としてのインプットと言えますね。
該当する項目の申請書を指定したフォルダにコピーし、必要欄の記入をしてくれるというのが一連の流れです。

申請書についてはもっと良い方法があるのかもしれませんね。
こういった改善方法を探すのも、SEの醍醐味です。

**デフォルトの名無しさん** · 2018/07/21(土) 23:40:40.67

>>958
> 社会人のほとんどが実行できる環境を手に入れているプログラミング言語なんてVBAくらいだと思う
お手軽かどうかを別にすれば>>965が言ってるPowerShellに加えてC#とVB.NETもあるよ

**デフォルトの名無しさん** · 2018/07/21(土) 23:46:10.80

>>965
主張は分かるけど、VBAが性質上事務系の職場でよく使われていて、他の開発環境を入れたりOSの付属物であってもアップデートが難しいことは考慮してほしいわ
・OSはWindows7
・PowerShell(ISE)は2.0
・VBA以外の開発環境は導入できない
が、ここにいる人たちの環境のほとんどだと思う

**デフォルトの名無しさん** · 2018/07/21(土) 23:46:21.44

>>959
自分で書いてて分からないんだから...
要するにPowerShellはバッチ処理向きということ。
VBAはそういう用途も出来るけど、目的が違う。
Excel上で動かすのが基本になる。
データベースに接続してデータ集計するのはどの言語でもできる。
今日の集計じゃ無くて昨日の集計を見せてくれと言われて太字で囲まれたC3セルに昨日の日付を入れて隣のボタンを押して下さい言うのがVBAの用途でしょ。

それにちゃんとしたアプリケーションも作れますなどと言うから驚き。
あなたがVBAを批判する内容を見ればそんなことは言えないでしょ。
C#に比べてどんだけ面倒なんだよ。
そんな言い訳が通るならあなたのVBA批判にもまったく同じ言い訳が出来る。

**デフォルトの名無しさん** · 2018/07/21(土) 23:52:36.61

>>971
その環境は2020年に消えるし、遅くとも2023年にはOSバージョン分離は解決するよ
Officeのバージョンは知らんけど

**デフォルトの名無しさん** · 2018/07/21(土) 23:55:21.06

別にVBAが無くなったら代わりのものを使うでしょ。
VBAだってその場の環境に合っていただけ。

**デフォルトの名無しさん** · 2018/07/22(日) 00:06:19.91

>>971
適当にググったらこんな記事がありました
ttps://news.mynavi.jp/article/20180104-566132/
2017年12月で月1%差が減ってるのでこれだと逆転ももうじき…かもしれませんね

**デフォルトの名無しさん** · 2018/07/22(日) 00:07:10.80

リストビューなんだけども、タブ区切りテキストファイルを読んでリストビューに追加をwinxpでやったやつを、win10で書き換えたら、一段ずれるんだけど正解の書き方ってなに？

listitems.add.SubItems(1) = ○○

**デフォルトの名無しさん** · 2018/07/22(日) 00:17:15.29

>>974
>別にVBAが無くなったら代わりのものを使うでしょ。

じゃ、代わりのもの出してくれよ

**デフォルトの名無しさん** · 2018/07/22(日) 00:26:39.50

>>972
>データベースに接続してデータ集計するのはどの言語でもできる。
何度も言われてますがそれはみんなわかってます
以下に手軽に安全にできるかというところが焦点です
VBAでは型安全なORMフレームワークもないでしょう?

>今日の集計じゃ無くて昨日の集計を見せてくれと言われて太字で囲まれたC3セルに昨日の日付を入れて隣のボタンを押して下さい言うのがVBAの用途でしょ。
これがVBAの使い方だとしたらガッカリですね
PowerShellならオプションで日付を指定すればいいですし
なんなら日付選択とボタンを配置したフォームを起動してもいいでしょう
たったコレだけのためにアプリケーションレイヤ以下を面倒なVBAで書くのはあまりにも非効率的です

>それにちゃんとしたアプリケーションも作れますなどと言うから驚き。
PowerShellはバッチが最も得意分野ですがFormsもWPFも使えますし単体でWebサーバーにもなりますのでリッチなアプリを開発できますよ
VBAと違って自作パッケージ管理もよく整備されてますし、セントラルパッケージも充実しています
特に大きな違いはユニットテストがサポートされていることでしょうかね
ちゃんとしたアプリケーションでは迅速かつ正確なテストは不可欠です
Pesterと言うパッケージなのですが実はコレPowerShell V5から(つまりWindows 10から)はMicrosoftのお墨付きでデフォルトで入ってます

**デフォルトの名無しさん** · 2018/07/22(日) 00:30:23.35

>>977
それこそPowerShellでいいだろ

**デフォルトの名無しさん** · 2018/07/22(日) 00:39:59.15

>>973
いや～そりゃ希望的観測すぎるんじゃ
XPのように7はかなりの期間残るよたぶん
ただまぁ確かにWin10が標準になればPS5.0(.NET4.5)が使えるようになるから、Excel以外の処理はそっちで…って事例は今より増えてくるだろうけど

肝心のExcel操作はどうだろう
理想を言えばMSがImport-Excelで欠けてる機能全部作り込んでPowerShell標準のコマンドレットとして提供してほしいけど、無理かなぁ
Python搭載よりよっぽど現実的だと思うんだけどなぁ

**デフォルトの名無しさん** · 2018/07/22(日) 00:42:43.30

こうやってみてるとPowerShellって凄いんだな
そんな事まで出来るんだ
知らんかったわ

**デフォルトの名無しさん** · 2018/07/22(日) 00:46:55.56

>>978
検討に値しない。
C3セルに入力と隣のボタンが最重要なのに。
そういう話すら理解出来ないんじゃ。

コード変更しちゃダメでしょ。
そういう用途じゃ無いって言ってるのに。

**デフォルトの名無しさん** · 2018/07/22(日) 00:49:30.97

>>977
???
無くなったらExcelPythonなりExcelVB.Netなりが出てくるでしょ。
そういう話想像も出来ないの?

**デフォルトの名無しさん** · 2018/07/22(日) 00:51:53.07

>>978
リッチなアプリをPowerShellで作るのは面倒という批判に耐えられないだろ。
君の批判そのものなんだから。

**デフォルトの名無しさん** · 2018/07/22(日) 00:59:08.18

まずC#の方が全てにおいて上だよ。
PowerShellに比べれば。

そしてそれに反論しようとすれば基本的にVBAと同じ論理展開になる。
用途が違うというね。

つまりPowerShellは全てにおいて中途半端とも言える。
VBAを批判する者の論理を進めていくとそういうことになる。

だからPowerShellユーザーのVBA批判は検討に値しない。

**デフォルトの名無しさん** · 2018/07/22(日) 01:26:51.64

>>985
> まずC#の方が全てにおいて上だよ。
なら、C#で作ればいいだけ

**デフォルトの名無しさん** · 2018/07/22(日) 09:07:18.88

事務システムの委託開発業務なんてよく成り立つよなあ、って驚く。
そんなのアウトソースするまでもなく社員がちょちょっと自分で作って完結させればいいんだし、
逆に言うとそんなふうにならなけりゃ米中に競争力で勝てない。
VBAでもPowershellでもなんでもいいよ。
プロの開発者はそんな委託仕事じゃなくて国際市場で勝負できるプロダクト作ってほしいものだ。
と常日頃思ってる自分にとって、ここでの議論は気に食わない部分が多少ある。
だから「プロがこんなとこに来るんじゃねーよ」と言いたくもなる。

**デフォルトの名無しさん** · 2018/07/22(日) 09:23:44.04

>>985
まずPowerShellはC#コードをコンパイルして実行できるためC#の機能の大半を包括しています
その上でPowerShellはC#にない高級なコマンドレット、カジュアルな文法などを持っています
また、もともとシェル系言語ということもありサブプロセスとの連携やリモート処理はC#よりもだいぶ得意です

C#は強力な型システム、業界でも屈指の高い生産性を誇る非同期処理、
Visual Studioとの高い親和性などPowerShellにはない強みも持っています
そしてPowerShell実行環境はマネージドライブラリとして提供されているため、当然ですがC#からPowerShellを実行することも可能です

一方でVBAにはこれといって目を引くような強みはありません

互いに非常に強力な機能を持ちつつ、相手より得意な分野があり、相互に連携可能なC#とPowerShell
これらとVBAを同じ目線で語ることは不可能でしょう

**デフォルトの名無しさん** · 2018/07/22(日) 09:58:22.12

>>988
まず、PowerShellはC#コードをコンパイルして実行出来ません。

あなたがVBAを批判する時に良く出てくる面倒だとかいうフレーズはVBAでも「～すれば出来る」というこちらの回答に対してでした。
ならばPowerShellに対しても「～すれば」という場合は出来ないと判断すべきでしょ。

PowerShellではPowerShell ISE以外で開発することは出来ません。
VisualStudioとの親和性?
そんなものは全く有りません。

あなたのVBA批判を元にすればそういうことになります。
VBAに対しては全ての条件を厳しく、PowerShellに対しては全ての条件を優しくでは困りますね。

VBAでも制約がある中で工夫でそれを乗りきっているわけです。
そういう工夫を否定するならPowerShellにおける工夫も否定して発言してもらわないと困りますね。

**デフォルトの名無しさん** · 2018/07/22(日) 10:02:18.60

>>986
私はPowerShellの適材適所を認めています。
しかしVBE批判者の論理に則ればそういうことになるということです。

**デフォルトの名無しさん** · 2018/07/22(日) 10:35:19.44

VBA は、Excel とか、人間が見て、表に書き込む用途には良い

でも、ボタンを押して、DB・ファイルI/O・テキスト処理などをする場合、
PowerShell, Ruby が適している

これらを、VBA で書くのは地獄だろ。
数行のコードが、数百行になる。
百倍！

Excel エンジニアは、プログラマーじゃないけど、
これらの処理は、プログラマーが求められている業務だから

仕様書・テスト・保守とか、ソフトウェア開発の領域だから、
Excel の領域をはるかに超えている

普通は、目標からツールを選択するけど、
先にツールを決めた場合は、やれる事を限定しないといけない

どこかに、そのツールを使っていくと、非常に不利になってくる分岐点がある。
そこがそのツール・技術・技術者の限界で、
新技術へ以降しなければならないというサイン！

**デフォルトの名無しさん** · 2018/07/22(日) 10:55:23.83

>>991
>DB・ファイルI/O・テキスト処理

ユーザーが手元で作ってきた経緯が長い（下手すると１０年以上）から、そういうのはオレオレ便利ツールが揃っているんだよ。
オレオレであったとしても大抵のことがPowerShellやRubyより少ない行数で書けて、品質が問題なければ十分。
十分てのは「わざわざプロに委託するまでもない」ていう意味。

大企業で異動が頻繁ではないユーザー部門だったら多くはその程度のレベルには行ってる。
もちろんExcel、VBAオンリーじゃないけどね。
逆にIT部門の方が全然ダメだったりする。

**デフォルトの名無しさん** · 2018/07/22(日) 11:00:30.12

>>991
スクリプト言語と汎用言語の違いがわからない痛い人なのかね？

**デフォルトの名無しさん** · 2018/07/22(日) 11:02:15.87

いい加減うぜーからどっかいけよクソアスペ
VBAに文句言ってる人がどこに文句つけてるのかまったく理解できてないから話も通じないしかみ合わない

**デフォルトの名無しさん** · 2018/07/22(日) 11:07:52.11

一見マウント取ってボコボコに叩いているように見えるも彼が何と戦っているかは誰も知らない

**デフォルトの名無しさん** · 2018/07/22(日) 11:08:06.32

やっぱりrubyキチガイのしわざだったか

**デフォルトの名無しさん** · 2018/07/22(日) 11:25:39.83

>>989
PowerShellはC#コードをコンパイルして実行出来ます。
あなたの知っているPowerShell?と本物のPowerShellは別もののようです。
あなたは違う製品をPowerShellと誤認識している可能性があるので、まずは確認をおねがいします。

ただの言葉遊びですね
「〜すれば出来る」という抽象的な文にしてしまえば、まるでVBAもPowerShellも同じであるかのように錯覚させることができます
実際には「〜」のボリュームにて果てしないほどに差がつきます

PowerShellはISEのほかVisualStudioCodeでの開発がMicrosoftによってサポートされてます
VisualStudioにもPowerShell MVPの方が作成したPowerShell Tools for Visual Studioという拡張があります

結果的にVBAに厳しくPowerShellに優しく見えてしまったのかも知れません
ですが評価とは本来そういうものです
成績が悪いのはいじわるされているからだ、などと大人気ないことを言われては困ります

欠陥を補うための工夫と、より良い結果を導き出すための工夫を混同してはいけません
PowerShellはVBAのように足りないものを補うために頭を悩ませることはそう多くはありません
頭を使うなら、どんなものを作ればより高い価値を提供できるのか、について考えるべきです
人間の脳は有限なので、開発基盤由来の困難解決に脳のリソースを使うほど、品質向上のための脳のリソースが減っていきます

**デフォルトの名無しさん** · 2018/07/22(日) 11:31:45.12

1000ぱんてぃ

**デフォルトの名無しさん** · 2018/07/22(日) 11:32:24.57

1000ぱんてぃ

**デフォルトの名無しさん** · 2018/07/22(日) 11:32:57.67

1000ぱんてぃ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 56日 14時間 55分 20秒