VBAで構成されたEXCELファイルは、異動などで次の担当者に引き継ぐ際に困難をきたしてしまい、結局メンテを前任者がやる羽目になってしまいがちかと思いますが、これを解消する良い方法はないでしょうか？ VBAは、大規模になると制御やチームでのメンテナンスに向いていないので、個人が自宅で他人にメンテナンスさせない前提なので、企業ではRUBY同様絶対に使用しない事をお勧め致します。PythonとFastAPIフレームワークとWundergraphとTypeScriptとSnowflakeならGo言語のGinフレームワーク並に高速で、Pyhonなのでチームで他人のソースコードでも読み書きしやすいのでチームメンテナンスしやすいです。近い将来、Pythonの他人のソースコードでも読み書きのしやすさ、RustのハイセキュリティとC言語並みの高速なMojoと言う夢の様なプログラム言語が登場してきますので、ご期待下さいませ。Appleが研究中で御座います。業務DATAの可視化には更に、AWS上のKintoneと連携してTableauを追加したり、楽々精算、楽々請求、楽々販売とmoneyforwardは連携だけならプログラムしなくても連携出来ます。 ㈱エーオン 代表取締役社長 石 塚 正 浩 090−7555−5011 https://aon.co.jp https://aon.tokyo

https://jp.quora.com/VBA%E3%81%A7%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9FEXCEL%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AF-%E7%95%B0%E5%8B%95%E3%81%AA%E3%81%A9%E3%81%A7%E6%AC%A1%E3%81%AE%E6%8B%85%E5%BD%93%E8%80%85%E3%81%AB

豊 知也

 · 

フォロー

元最高技術責任者

 · 3年前

ありますよ。

・

そもそも、VBAなんてものを使わなければならないような「業務のやり方」に問題があるんですよ。

だから、VBAをちょっと使えばできそうだな、ぐらいの作業が「発生した時に」、その業務内容自体をシンプルに変えるんです。

・

そもそも、仕事はすべて、「入力」「処理」「出力」の3つしかないのですよね。

で、Excelなどを使いたくなるシーンは、このいずれかが「煩雑」な時であり、

で、VBAを使いたくなるシーンは、この「煩雑」なものに対して、さらに「煩雑」な「入力か処理か出力」をしようとする時なんですよね。

なぜなら、「煩雑」に「煩雑」を繋げると、恐ろしく膨大な「手間」がかかってしまうため、なんとかこの「手間」をパソコンにやらせてやろうなんて考えた時に選択肢で出てくるのがVBAなんです。

・

でも、パソコンがやってるから「人の手間」は減るかもしれないけど、「パソコンの手間」は増えているし、その分だけVBAの中に「煩雑×煩雑」が入るので、当然コードが「複雑」になりメンテナンスも出来なくなる。

そしてVBAを書こうなんて考えるのは、専門の人間では無いから、コードのメンテナンス性は低く書き方がこれまた「煩雑」になる。

ここでVBAを使うというのは、仕事の中に「煩雑」を取り入れて「固定」するような行為なわけです。

だから、「担当者」も一緒に「固定」されてしまうわけです。

・

でもね、そもそも考えてみてください。

で

Toyokawa Issei

 · 

フォロー

元料理人高卒プログラマもどき

 · 3年前

他の質問の回答でも書いたのですが、VBAツールの開発やメンテナンスは、「ひとり」の人にやらせてはだめです。「二人以上」のチームで行うべきなんです。

複数人で行えば、情報共有のためのコーディング規約、仕様書の作成、上司への報告、引き継ぎのフローなどもきちんとルール化され、コード自体の質も向上すると思います。

VBAを理解してるしてないにかかわらず、そもそもその部署の管理者が管理できていないツールがあること自体が問題なんです。

なぜ管理できていないのかと言うと、「チームリーダー」がいないからです。チームリーダーと管理者の連携がないんです。

チームリーダーを置くためには、何はともあれ「チームを作る」ことが先決です。

チームができれば、お金をかけないRPAも可能になると思います。

Sone Masayuki

 · 

フォロー

3年前

そもそも、残った人は全員VBAを理解していない…ってことでは、どうしようもありません。そうなったら、マクロを含むシートのメンテは原作者がやるしかないですよね。これが結構ありがちなパターンだと思います。

幸い、VBAを理解できる人がいる場合は、マクロを徹底的にわかりやすく書くことでしょうかね。私はその一環として、普段なら気持ち悪いので絶対やらない、漢字かな交じり日本語の変数名を使うこともしました。引き継がれた人が理解しやすいようにすると言う大義名分の下、まあ許してもらおうと。

SORIMACHI Yuji

 · 

フォロー

COBOLプログラマ

 · 3年前

そうした引き継ぎ問題の主因は、引き継ぎ相手のVBAスキルが低く、書いてあるコードが理解できないというところにあるので、いっそ引き継がないという選択肢も考慮すべきです。属人的なVBAに頼ってる作業などそれほどクリティカルではないだろうと割り切ってしまいましょう。

Sugawara Katsunori

 · 

フォロー

システムエンジニア時々傭兵プログラマ

 · 3年前

VBAを使わない事です。

そもそも、ガチのプログラム言語をマトモに要員管理、資産管理もしない職場で軽々しく使って良いものではなかったのです。

しかし、今更というものあるでしょうから、プログラマを動員(無理なら教育)するのが最も良いかと思います。

そして、VBAのExcelブックも部署内資産として、キチンと管理して、その先のVBAの無断開発を禁止する事です。

Aoki Kazumi

 · 

フォロー

元 人事部の理事 (1990–2020)

 · 3年前

Excel-VBAをのメンテナンス性を高めるには「仕様書をきちんと書いておく」となりますが、コーディングより仕様書の方が長くなる上に、VBAが判らない人にはあっても宝の持ち腐れとなります。

私もExcel-VBAで業務効率化をしていた経験がありますが、次のことを実践してました。

VBA内で定数を定義しないでエクセルのセル上で定義する。

VBA内の変数、処理ロジックにコメントをやたら多く入れておく。

サブを多用し、処理ループ・流れを一覧できるようにしておく。

などですが、処理ロジックが大きく変わるとやはりVBAが判る人が必要になりますので、定数変更で対応できない場合には、ＶＢＡの分かるプロに見てもらうこととしていました。それが無理なら捨ててとも言ってました。

新田 光宏

 · 

フォロー

プログラマー (2003–現在)

 · 3年前

ないです。

それが可能なのだったら、VBA出現以降30年、様々なプログラミング言語が出てきたのは無駄だったということになってしまう。

30年間積み上げてきた工夫を、全部取り入れることを拒否しているのがVBA。だから評判が悪い。たぶん互換性が理由。

釜田 豊樹

 · 

フォロー

元ITコンサルタント、現某海外パッケージベンダーの技術系管理職

 · 3年前

エクセルマクロの良い点：手軽に開発できる

悪い点:ブックの複製で同じようなものが沢山できて収拾がつかなくなる。

アドインを書けばいいのでは？

アドインでファイル名を命名させると出所もわかるので、やった方がいいと思います。

勤務表_PCログイン名_日付.xlsx

とか。

悪い点は工夫すれば、どうにかなりますよ。

伊勢山 剛

 · 

フォロー

SE、社内SE、広報、映像制作、イベント運営、コールセンター管理など

 · 3年前

• 情報システム部門を設置する
• アウトソーシングする
• VBAでごまかさずに専用ソフトを導入する
• 自動化しないで手作業でやる

黒岩 雅彦

 · 

フォロー

大阪在住

 · 3年前

関連

VBAでつくったツールが大量にあり、レガシーとして問題になりつつあります。どうやって解決するのがいいのでしょうか？

野良VBAを使っている組織は、その内容に応じて個別に良さげな手段を模索する以外にありません。大抵は、基幹システムで対応できない雑多な業務をVBAでどうこうしているので、統一した手法でとかは無理です。

また、VBAで実装されている業務の多くは、トラブルと業務が止まる基幹系とちがって、大抵は人力でなんとかなります。

事前にトラブルを予見してだと予算承認してもらえることは稀なので、痛い目を見てから慌てて対処するのが基本パターンだと思います。

汎用的な対策としては、VBA職人のいる小さなソフトウェア会社に委託して、少人数常駐してもらうのが良いと思います。

理由は、自社で人材を雇用し育成するより低コストだからです。なので、多重下請けの元請けに委託することも避け、実際に技術者が在籍している企業に発注する必要があります。

委託なのは、VBAで作られたツールの保守には導入現場特有の業務知識が必要なため、短期間で人が入れ替わる派遣契約では必要な情報が失われる可能性があるからです。

業務は、現在のVBA資産の棚卸しと保守と新規開発の委託になります。棚卸ししたVBA資産の中から緊急性の高いものはモダンな環境に移すなり、基幹系の機能にします。VBAの寿命が尽きるまで放置しても大丈夫そうなものは問題を先送りします。

RPAについては、VBA資産の棚卸し(内容の分析とドキュメント作成を含む）後に、移行しやすいRPAの選定を

Toyokawa Issei

 · 

フォロー

元料理人高卒プログラマもどき

 · 3年前

関連

VBAでつくったツールが大量にあり、レガシーとして問題になりつつあります。どうやって解決するのがいいのでしょうか？

VBAツールは、大抵の場合「ひとりの」人によって作られている場合がほとんどです。これがVBAの最大の問題点だと思います。

VBAツールの開発もリファクタリングも「ひとりの」人が行うのではなく、二人以上の「チームで」行うべきです。

つまり、VBAツールを使う必要のある部署には必ず二人以上のVBAプログラマないしは「VBA開発チーム」を配置するべきなのです。

といっても、外部からプログラマを調達する必要はありません。社内教育によってすべての部署にVBAプログラマを配置できるよう育成すればよいのです。こういうとき、VBAの特徴である「敷居の低さ」が利点になります。なんせ、PC に Excel さえインストールされていれば誰でもすぐに学習できますから。

VBA開発チームができてしまえば、新人VBAプログラマのメンターも社内で賄えますし、各部署のVBA開発チーム同士で情報交換を行い、部署の垣根を超えた全社レベルでの業務効率化を推進することも可能になります。

レガシーツールのリファクタリングもチームで行えばナレッジマネジメントを共有することができますし、プログラミング言語を1つでもマスターした人は他のプログラミング言語をマスターするための学習コストを大幅に節約できるので、それぞれのスキルによって社内全体で人材を流動的に活用することもでき、会社自体の競争力も向上します。

VBA開発はチームで行う

これに尽きる