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(土) 21:08:16.07

>>925
言って良いよ
俺は凡人って自覚あるからね

本当に技術力があるなら、どうぞ自然と敬意を持ってしまうような発言をしてみてください
さあどうぞ遠慮しなくていいですよ

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

>>926
つまりExcelの環境が与えられているのですよ。
その場合に本当にExcelがダメなら他言語でも良いでしょう。
私も他を勧めます。

でもここにいる他言語の人はそうでは無いわけです。
←これに反論したいかもしれませんがこのスレで何度何度もなされているのは、最初にどんな場合でもExcelなダメという他言語者からの批判に対して適材適所だというVBA側からの反論なのですよ。

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

>>927
あなたが凡人なら私に技術があるかどうかは分からないでしょう。
技術があるかないかについては相手の発言の中に出てきた具体的な文言から判断できることがあります。
そういうことを指摘もせずに何ら具体的なことも無しに発言しても意味が無いでしょう。

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

>>928
最初から全否定してる人はいないよ
本当にVBAを使うべき理由があるならくろうしてでもVBAを使うしそうでなければ他の楽な言語を使う
ただVBAを使うべき理由がそう簡単には見つからないというだけ

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

>>930
いや、違う。
最初から全否定している人ばかりだ。
こちらは何度も適材適所だと言っている。
VBAに合わない場合は勧めないとさえ言っている。

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

>>929
本当に凄い人ってのはですね
凡人から見てもわかるものなんですよ

凡人から見ても高い技術力が伺えるような発言をいつまでもお待ちしております

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

実際の所で言うと今の時代にVBAって必要ないよね

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

>>930
>VBAを使うべき理由があるならくろうしてでもVBAを使うしそうでなければ他の楽な言語を使う

私は同じことを同度も言っている。
それに反論してくるのはいつも他言語者達だ。

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

VBAオンリーになるはあくまで結果であってexcel自体が適材適所の範疇を超えて使われ過ぎなのが問題
帳票出力ツールでもDBでも無ければメモ帳ですら無いのに

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

>>932
既にそういう発言には意味が無いと言って納得して貰っている筈ですが...

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

>>931
なんども適材適所って具体的になんなんですかって聞いてるんですけどね
無視されるか具体性のない要領をえない答えばかりでした

ここは技術力の高い方がビシッと
「こういうときはこういう理由でVBAがベストだ。
そして過去の具体的な事例はこうだ。
サンプルツールを作ったのでよかったらみんなも試してくれ。」
ぐらいの事を言ってくれませんかねえ
誰か技術力の高い人いないかなあ

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

本当はVBAを使ってエクセルで何してるの？
必要ないんじゃないの？

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

こういう時にすっと具体的な事例と論理的な解説をしてくれる人からは経験に裏打ちされた確かなスキルを感じる
あれこれ言い訳して発言を避けようとする人からは技術力を全く感じない

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

>>928
> 最初にどんな場合でもExcelなダメという他言語者からの批判
そういう低レベルの奴らと話したいなら>>904とか俺にアンカーつけんな

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

VBAはすごく便利なツールだと思うけどなあ
進捗管理表や申請書の自動作成等、VBAで助けられているドキュメントは多岐にわたるよ。
ちょっとした処理なら手続き型で事足りるし、プログラミングに慣れていない人でも書きやすいはず

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

>>941
進捗管理票や申請書作成においてVBAを使う利点は何でそれは何故と考える？

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

>>941
それは良い使い方だと思うよ

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

>>940
ここはExcelVBAのスレでしょう。
Excelと付いている時点でVBAが有利になるわけです。
制約された有利です。

もう何度もされている議論です。
1つのブックだけで済むというのも大きな有利点です。
使う人自身でメンテナンス出来るというのもメリットになります。
Excelという制約の中が前提に有るわけだから他言語はその時点で大きなデメリットになるわけです。

そういうのが大前提になっているスレですよ。
寧ろ私が言わなくても分かっているべきだと思います。
普通の、Excelとは関係ない実行ファイルを作る点においてはVBAは検討の余地すら無いでしょう。
そんなことは当たり前の話です。
であるなら当然Excelの話になった時はVBAが有利になるというのも当然頭に入っているべきでしょう。

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

社のセキュリティ規則で、自作の実行ファイルなんて簡単に審査通らないつーの
そういう環境すら想像できないってどんだけアフォなのよってね

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

>>939
具体的なことを何も言えないのはあなたでしょう。
それをご自身も認めたでしょう。

それにVBAがベストな例など何度挙げられているでしょう。
根拠なき中傷しか出来ないのは哀れだと思います。

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

>>944
1つのbookになってしまうのでソース管理などで不利になります
ソースがあればどの言語でもメンテナンスできます
現実の業務はこのスレの中では行われないのでこのスレでの優位性には価値がありません

もう少しスキルが高そうな意見はだせませんか?

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

>>945
それは結構有るんですよね。
バイナリエディタ入れられないからVBAで作るとか。
簡易なもので済む場合は直ぐ作れるから良いけど。
エディタとか場合によっちゃメモ帳で我慢したり。

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

>>947
プログラム組んだこと無い人は黙っててくれませんか?

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

>>947
1つのbookであってもソース管理が出来るのはあなたを除いてみんな分かっていると思いますよ。
ソース管理ツールを入れられる環境であればですが。

入けられない環境なら他が有利とは言えないですし、入れられる環境なら1つのbookでもソース管理できるのはみんな分かっています。

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

>>945
自作の実行可能ファイルがダメでもPowershellという選択肢はありますね
そもそもセキュリティ都合で自作ツールすらNGな場合VBAマクロも制限することが多いですね
VBAでもデータベースや共有フォルダにアクセスして破壊してしまうことは可能です
そういった厳しい現場ではツールメンテナンス担当がいてその人が発行したツールをチームで使います
逆にexeだけ禁止してVBAは素通りという審査体制は非常に低レベルな現場と言えるでしょう

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

>>950
可能か不可能かで言ったらそれは可能でしょう
不利になるとは意味が違ってきますよね

仮にソース管理ツールが無い場合でも単一のファイルでのソース管理は面倒です
特定のクラスやモジュールだけ差し替えたり再利用したい場合など日常茶飯事です
あくまでプログラムはユニットを単位として製造するものなのでユニットごとに扱いやすい形態で管理出来たほうが便利ですよね

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

>>951
うんやっぱりアフォだな
一般的な大企業すら想像できないらしい

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

VBAに比較するとPowerShellはゴミです。
噛み合わないからです。

ちゃんとしたプログラムならCやC++、C#などにすべきでしょう。
Excelに関するならVBAの方が良い。

PowerShellはC#使いがVBAを批判する内容が同じように当てはまるし、Excel向きでもない。
PowerShellが使えない言語とは思いませんがあなたはPowerShellの用途を理解していないと思います。

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

VBAなんて煩雑な業務をちゃちゃと自動化可能だから利用すんのになんで再利用だのなんだの永続的なこと言ってんの？
無駄な仕事してる無能？

**デフォルトの名無しさん** · 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秒