VBA資産を駆逐するにはどうすればいいか

**仕様書無しさん** · 2011/12/25(日) 14:16:01.14

社内に数多あるVBA資産。
老害がひとりよがりな発想と貧困な技術で作った負の遺産だ。

ところが、これを置き換える手段というのは中々存在していない。
なぜならWebにしろ何にしろ、まずサーバーありきで考えられているのに対し、
Accessなんかは(あたかも)クライアント単体で動く。ランタイムもたいていの場合不要だ。
この利便性は認めざるを得ない。

JettyとSQLite？結構。
で、どの端末がホストするんだ？
ポートがコンフリクトしないか？その保守は誰が？
SQLServerCEとC#？結構。
で、ソースは誰が保守するんだ？
アドホックな対応にも毎回cloneしてコンパイルってか？
HTA？結構…じゃねぇな。

ということで、VBA資産をいかにして駆逐するかを議論するスレです。
Excel詳細設計書に仕込まれたアホなマクロを自慢げに語る先輩、上司にガックリした者よ、集い、ともに戦おうではないか。
VBA資産さえなくなれば、我々はOfficeに依存しなくてもよくなる。

**仕様書無しさん** · 2011/12/25(日) 16:11:04.70

>>1
WSHはLLで置き換えたりすることがあるかも
サーバを置きたくないというのならこの話にそれ以上の発展なくね？
C#のソース誰が保守するんだ？って話をしてるが、じゃあVBAは誰が保守するんだ？
管理したいと思ったやつがやりたいようにすればいいじゃん

**仕様書無しさん** · 2011/12/25(日) 16:24:31.37

VBAが資産と考えられるほど使われてて、スタンドアロンで便利！とか思われてるうちはムリ。
だって仕事のやり方変える気がないんだろ？
といいつつ、Filemakerを勧めてみる。アレはなかなか便利だ。
スクリプト作るとこはマには地獄のようだが、慣れると快感になるぞｗ

**仕様書無しさん** · 2011/12/25(日) 16:56:51.08

>>1
お前は根本的な所がわかってない。

VBA資産を駆逐したところで、同じ発想で作られた
言語が違うだけのものができるだけなんだが。

同じ人間が作れば、言語を変えた所で
できあがるのは何も変わらない。

たとえば最近はちゃんとオブジェクト指向なJavaScriptのコードを見かけるが
作る人がヘボだと昔ながらのHTMLに直接グローバルな関数が埋め込まれる
そんなコードになるんだよ。

**仕様書無しさん** · 2011/12/26(月) 13:20:58.16

>>2
発展がないから問題なんだよ。
解決してたらこんなスレいらないじゃないか。
ソース管理の話は、何かひとつあげつらいたかっただけなので、気にしないでくれ。

>>3
そーなんだよ、変えるつもりがないんだよ、やつらは。
>>1で俺が問題っぽく挙げてるあれやこれやは、俺が「機能性、保守性の観点から変えましょう」と提案した時に
色んな人から言われた言葉なんだよ。
で、「それが解決できないんじゃあねぇwってか今動いてるんだしいいじゃんw」と。
確かにそれは事実だが、Excelのシート数百枚を集計とかやってるアホさに目をつむるのは如何なものか、だよちくしょう。

>>4
ああ、まぁそれは真理だな…。俺は第二の負の遺産を作ろうとしているのかもしれない。

**仕様書無しさん** · 2011/12/26(月) 18:31:24.17

だったら保守性うんぬん言ったってしょーがない。
システムのリプレイスには、圧倒的に便利になる仕掛けを示すしかないよな。
VBAを捨てずにSkydriveで共有とか、Office365導入とか考えたら早いんでない？

**仕様書無しさん** · 2011/12/27(火) 00:03:59.63

別に駆逐する必要はない
アウトプットを手作業で作るか自動化して作るか、ただそれだけの違い
重要なのは、業務内容を文書等で明確化しておくこと
自分がいなくなったら、後任は手作業でやればいい
ただそれだけ

**仕様書無しさん** · 2011/12/27(火) 07:44:03.52

資産でもなんでもない

**仕様書無しさん** · 2011/12/27(火) 19:33:21.73

>>1の馬鹿を駆逐すべきだ