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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

資産でもなんでもない

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

素人でも何とか保守できるのがいいところ。プロに頼んだら、その日からブラックボックス化。

結局>>1はVBAいじりたくないだけだろ。
リプレースメリットがないと変えられないよ。

リプレイスさせても、素人作に負けるような物しか作れない。

手書きの文字からの完璧なインプットができればなぁ・・・。
相当な数の仕事を楽にできる。

なんでVBAがダメなんだ？
VBAのおかげでどれだけ業務効率化できたかわからないよ。
通信ログの解析とか、人月単位で工数削減できたぞ。

そうやって無秩序に作られたプログラムが人月単位で工数増やしてるから。

>>15
人月単位で増えた工数の原因は、ツールではなく
ツールがなければログ解析もできない後任の阿呆だろ？
そもそも必要なツールなら工数割り振ってちゃんと作らせてやれ
文句はそれからだな

VBAでつくったものの方が使いやすいことが多い。金かけて、使いにくい物がくるのでは。

>>16
ドキュメントも作らずに自己満足なプログラムだけ作って仕事した気分になってる奴が原因だろ。

>>18
その自己満足なツールが業務効率を上げていれば問題なし
その製作者がいなくなれば、後任は手作業で仕事することになり、
前任者よりも効率は落ちるだろうが、それもただ元の効率に戻っただけのこと
そもそも無理して前任者が作ったツールを使おうとする必要はない
社内の標準ツールにしたければ、ちゃんと工数を割り当ててやれ

大部分のツールは、数人しか使わない単純な手作業を自動化したもの。プロが出る必要もない。

プロってなんだ

そういう物をシステムにするのが仕事だろw

一般企業のVBA資産はシステム化の提案に向かう好機だな。
自前のVBA資産は…なんというか触りたくない。
Excelでテーブル定義書いたらSQLもボタン一つで〜とか、入社当時先輩が自慢気に話してたけど。
ご丁寧にパスワード保護とかされてると、なんというか失笑もの。

>>22
使えない先輩を駆逐する方法を考える方が先じゃないか？

システム化されるとメンテする度に予算を確保せねばならなくなる。そもそも、 VBA版より使いにくい。

エンドユーザコンピューティング（死語）

とは言え、古いものを使わされてるペーペーには、
置き換えさせるほどの発言力もない。

EUCって初めて聞いたときは、「なんで今の議題に漢字コードが関係するんだ？」と思ったものです。

研究で、今度初めてエクセルマクロ（VBA）を使った者ですが、
これ便利ですね。

同様の研究で、他のプログラム言語を使ったのがあるんですけど、
正直、入り口と出口は分かっても、
それ以外は作った本人にしか分かりません。
ほんと、ブラックボックスです。

エクセルマクロ（VBA）なら、説明書きをちゃんと作れば、
本人以外でも、「理解して」使えます。

甘過ぎ

キーボードマクロで雛型作って、適当に改造というお手軽さは手放せない。

XAMLおよびVBA 7の仕様リリース
http://www.infoq.com/jp/news/2012/03/Xaml-VBA-Specs

ＶＢＡだけで就職先はあるのでしょうか？
Ｊａｖａなどは募集をよく見ますが…

あとＶＢＡとＪａｖａは皆さんどのくらいでできるようになりましたか？
専門学校で学んだのですか？

なんというスルー検定

群馬県高崎市に住む４１歳ＡＢ型、製造業界で派遣プログラマーの仕事をしているhekenekoこと、黒飛健と申します。
新日本テクトスという会社を追われ、その後どうしてよいかわからなくなりました。
だけど私の大好きな尾崎豊の歌に励まされ、夢であるプロのクリエイターを目指すことにしました。
何度も挫けそうになりましたが、尾崎豊の歌を聞きながら自分を励ましています。
今も尾崎豊の歌のおかげで、夢を諦めずにＣＧアニメの製作を続けられています。
とりあえず、以下の動画を見てください。一生懸命作ったもので、自分では既にプロレベルの傑作だと思ってます。
できればみなさんのご意見、ご感想を聞きたいです。
新しいラダニアムの翼(new wing of radaniam part �T) .mp4
http://www.youtube.com/watch?v=PRPJ69rVgbE

題名”ラダニアムの翼その１(A wing of radaniam_part�T).mp4”
http://www.youtube.com/watch?v=WTde4RdA5LU
私の世界観の全てを凝縮した力作です。hekenekoワールドをご堪能あれ。

>>32

Officeファイル一つで完結していて、
そのうえソース丸出しで転がっていることが多いのに、
負の資産としてしか感じられない人を駆逐すればいい

保守という名の先延ばしだよね

自分は事務の社内SEなのでプログラム作業と言ったらVBAを書くことですね。
だいたいがDBからデータを取ってきてExcelリストにしたり、Excelリストから書類を作るといったVBAプログラムです。
そのVBAのプログラムが大きくなってくると外注さんにシステム発注してシステム改修してもらってます。
僕はシステムのプロトタイプを作るのにVBAは一番の材料だと思います。

うちは中年や年寄りの多い保守的な会社なので、いきなり新システム導入と言い出すと現場は絶対に嫌がります。
でもExcelで便利なシートとかは、いつも作ってと頼まれます。
そういうのできっかけを作って試行錯誤して本システムを導入すれば現場もシステム改修に協力的になってくれます。
VBAはとても良いツールだと思います。
おそらく事務の人にとってMS OfficeのVBAは技術者がEmacsで使うLISPのようなものですね。

仕事とは全く無関係で趣味でVBAいじれる人間が、社の電算室経由で頼まれたパターン。
「データを取り出してこういう帳票を作るようソフトウェアベンダに依頼したところ『有償でカスタマイズが必要』と言われた。
　しかしウチにそんなに金はない、幸いデータを取り出す部分はカスタマイズ不要で行えるらしいから、
　帳票に整形する部分をマクロとかいうのでやってくれんか」
社員が趣味の範疇で作ったVBAマクロなんざ危なっかしくて敵わんと思うのは俺だけなんだろうか。
その分報酬が貰えるわけでも給料が上がるわけでもないし、何かあった時責任取れないだろ。
ちゃんと然るべき金を払ってベンダに作らせろよ。俺だっていつまでこの会社にいるかわからんし。
ていうか見る人が見れば初心者丸出しのコードだろうから恥ずかしくてコードとか見せられんわ。

VBAソース修正しかできなくて、
いざ、まっさらな状態からプログラミングさせると出来ないとかいうやつが多いらしい

コボラーの行き先がVBAだったとは

適当なソースコード見られるのが
恥ずかしく苦しいし駄目出しの声が聞こえてくるようだ
しっかり綺麗なの作りたい

最近プログラマーになったんだけど、
任されたExcelツールがスパゲティどころかゲロで草映えるｗ

Excelのセル上で使う関数とか最大限使って
参照、参照、参照

UserFormとかVBAベースで作れば簡単だと思うのに、
チェックとか条件によってある項目は消すとか
そういう仕様書だけ５０枚ぐらいある。

それをいちいちセルの条件付書式とかで設定してて
すげー感心した

>>1
現場の人間が作ったVBAプログラムこそ、現場ニーズの塊じゃねーか！
ぶぅわぁぁぁぁぁか！
どんなものが、社内の公式システムに足りてないのか、調べるのに一番いいだろがっ！！！

つかＶＢＡしか出来ない奴らが自分の雇用を守るのが必死なうちは
会社の固定費も削減できないしボーナスも増えない。
アイツらこそ会社の害虫だろ。

>>44
本質的な所を絞れていればそうかもな。
でも、そんなケース殆ど見たこと無い。
適当な増改築 & UI周りのものすごい作りこみ & ModelとViewの密結合の破壊力はマジぱねぇっす。

>>44
でもその自慢のＶＢＡも遠く離れた営業所などでは使い物にならない。
固定費削減だからVPNとか広げるどころかクラウドでファイル共有出切るようになって廃止基調だし。

職場でもWebに切り替えようとする動きがあると必死に反対して根回しまでしているVBAオンリーな人達が・・・・

現場がプロトタイプとして作る → 専門PGがリファクタリング
みたいな流れがあれば良かったんだよな。

VBA自体の問題点は
Access用VBAの言語仕様が他と違う事が互換性なんかの面でひどいと思うのと、
Explicitは最初からON状態にしておくべきだったと思うんだ。
(Offにしたい人だけ明示的にOffに出来るようにとか。)

あとは関係ないけどVBEditorの検索ダイアログのバグはいつまで放置なんだろう・・・

VBAで作られた社内システムの多くは資産というより不良債権化してるし、
MSも廃止したい気配(OfficeRTでは動かないとか)だし今更感あるけど、
使い続けるならきちんとコストかけてリファクタリングする方が良いと思う。

>>48
専門PGが引き取るなら、そのままWeb化案件になることが多いよね。
専門PG連れて来る予算が付いた時点で、現場の担当者レベルを超えてるケースが殆どだろうし。

仮にそういう流れが出来たとして、リファクタリングしたコードを現場の人が読めるかが疑問。
コードの綺麗汚いの感覚すら無い方が多数派だろうからな。
だからといって、VBAマクロが現場の手を離れちゃうなら本末転倒だし。


VBAはリファクタリング自体難しいのも不良債権化に一役買ってるよな。
言語自体のOOP周りの構文が弱すぎる上、APIは副作用てんこもりだし。
他の言語では当たり前なボイラープレートコードの集約やインタフェースの切り出しも、VBAだと職人芸になる。

まだまだVBAが元気だった頃なら、
サブルーチン分けやライブラリ化、コメント付けを専門PGがやるだけで、
現場にこんなに不良債権が溜まらないで済んだんだろうと思うよ。

素人がソースいじるとコピペ→部分改変とかでどんどん肥大化する傾向だし、
的を射ないコメントがそこらじゅうにあったりで、ひどい事になってるから
早めに対策しないとどんどんメンテナンス困難になる。(そして不良債権化。)

ライブラリのリファレンスをVBAの関数リファレンスと同じ書式で書いて、
VBAのリファレンスとマージしておけば、素人でも使えるだろうし、
内部がOOPでコーディングされてても、素人が使う部分は旧来の関数・手続きIFにして、
OOP自体を隠蔽化していれば現場レベルでもマクロを再改造出来たと思う。

マクロ入りのファイルは1年に1度とか点検・リファクタリングしてれば
良かったんだろうけど、今となっては手遅れ気味だよね。

Modern UIでは実行環境を実装させない方針っぽいから、
今後OfficeがModern UI化したらVBAもなくなるのかもしれないし、
今更コストをかけてリファクタリングする意味はナサゲ。
(そうなったら、MS-Officeユーザーが減るとは思うけど。)

すごく目が滑る長文
まるで出来損ないのVBAコードのようだ

VBAがドツボでＤＱＮなのはＬＡＮ環境で無いと動かない点。

VPN契約してない２人しかいない営業所や現地常駐の営業が全国に数十拠点あったりしたらVBAアプリとか涙目。

どうすればいいか、って
基幹システムにExcel+VBA以上の使い勝手を持たせればいいだけだろ
具体的機能も画面設計もロジックも全て出来てるんだからコピーするだけじゃん
それすら出来ないならシステム屋の仕事を履き違えてるか能力が低い

>>53
VBA以上の使い勝手を実装するのはとても簡単だが
Excel以上の使い勝手はExcelを使う以外実現できない。

じゃあ駆逐するの無理じゃねーの
最優先すべきは現場の生産性(≒使い勝手）なんだから

ExcelVBAの登場は、ありがたいのか、迷惑なのか微妙だよな

昔は全部、システム作成依頼で来ていた。
　メリット：会社内で動いているプログラムを管理できる
　デメリット：システム作成しなきゃならない

今は、個人が勝手に作る
　メリット：要求をもっとも理解しているユーザーが作成するから、現場でほしいものが確実に作られる
　デメリット：作った本人がいなくなると管理不能になる

重くて遅くて自由度が低いWebアプリを盲目的に推進する一方で
Excel/AccessVBAをレガシーだの何だのと言い掛かりを付けて放逐しようとするのって何か違うと思うんだよな
どいつもこいつも製作側の都合ばかり考えて、システムの本質を間違えているよ

http://officetanaka.net/seminar/seminar1.htm
http://officetanaka.net/seminar/seminar2.htm

VBAセミナーは今後も開かれて受講者も着実に増えていき、
VBAは決して駆逐できないのである。

というか教える側も受講者を増やして飯の種にしたいから必死だろ

社内システムとしてはいいんじゃないか？
社内で作れば。
VBAを外注で作ってもらうというのは.......

>>60
社内システムとして作って、担当者が居なくなった、
ちゃぐちゃのVBAの改修が外注に回って来る現実がある

最近VBAシステムをWeb化したけど、どう考えてもVBA版のほうが使い勝手は上だったと思ってる
ただVBAをそのまま焼きなおすだけだったら、最低でもクライアントアプリにしないと大金出して劣化するだけだわ

>>62
そんなことは無いだろ
今はWebでExcelが動く時代だぞ
ブラウザ上のJavaScriptで頑張れば何でも出来る。頑張ればだが。

>>62
前時代的なweb化じゃあ駄目だよ。
ajaxバリバリ使ってSPAにしないと。

まあ時間と金と人が潤沢にあればなんとでもなるだろうけど
VBAリプレースにそんなもんがあるわけもなく…