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
ありますよ。
・
そもそも、VBAなんてものを使わなければならないような「業務のやり方」に問題があるんですよ。
だから、VBAをちょっと使えばできそうだな、ぐらいの作業が「発生した時に」、その業務内容自体をシンプルに変えるんです。
・
そもそも、仕事はすべて、「入力」「処理」「出力」の3つしかないのですよね。
で、Excelなどを使いたくなるシーンは、このいずれかが「煩雑」な時であり、
で、VBAを使いたくなるシーンは、この「煩雑」なものに対して、さらに「煩雑」な「入力か処理か出力」をしようとする時なんですよね。
なぜなら、「煩雑」に「煩雑」を繋げると、恐ろしく膨大な「手間」がかかってしまうため、なんとかこの「手間」をパソコンにやらせてやろうなんて考えた時に選択肢で出てくるのがVBAなんです。
・
でも、パソコンがやってるから「人の手間」は減るかもしれないけど、「パソコンの手間」は増えているし、その分だけVBAの中に「煩雑×煩雑」が入るので、当然コードが「複雑」になりメンテナンスも出来なくなる。
そしてVBAを書こうなんて考えるのは、専門の人間では無いから、コードのメンテナンス性は低く書き方がこれまた「煩雑」になる。
ここでVBAを使うというのは、仕事の中に「煩雑」を取り入れて「固定」するような行為なわけです。
だから、「担当者」も一緒に「固定」されてしまうわけです。
・
でもね、そもそも考えてみてください。
で
他の質問の回答でも書いたのですが、VBAツールの開発やメンテナンスは、「ひとり」の人にやらせてはだめです。「二人以上」のチームで行うべきなんです。
複数人で行えば、情報共有のためのコーディング規約、仕様書の作成、上司への報告、引き継ぎのフローなどもきちんとルール化され、コード自体の質も向上すると思います。
VBAを理解してるしてないにかかわらず、そもそもその部署の管理者が管理できていないツールがあること自体が問題なんです。
なぜ管理できていないのかと言うと、「チームリーダー」がいないからです。チームリーダーと管理者の連携がないんです。
チームリーダーを置くためには、何はともあれ「チームを作る」ことが先決です。
チームができれば、お金をかけないRPAも可能になると思います。
そもそも、残った人は全員VBAを理解していない…ってことでは、どうしようもありません。そうなったら、マクロを含むシートのメンテは原作者がやるしかないですよね。これが結構ありがちなパターンだと思います。
幸い、VBAを理解できる人がいる場合は、マクロを徹底的にわかりやすく書くことでしょうかね。私はその一環として、普段なら気持ち悪いので絶対やらない、漢字かな交じり日本語の変数名を使うこともしました。引き継がれた人が理解しやすいようにすると言う大義名分の下、まあ許してもらおうと。
そうした引き継ぎ問題の主因は、引き継ぎ相手のVBAスキルが低く、書いてあるコードが理解できないというところにあるので、いっそ引き継がないという選択肢も考慮すべきです。属人的なVBAに頼ってる作業などそれほどクリティカルではないだろうと割り切ってしまいましょう。
VBAを使わない事です。
そもそも、ガチのプログラム言語をマトモに要員管理、資産管理もしない職場で軽々しく使って良いものではなかったのです。
しかし、今更というものあるでしょうから、プログラマを動員(無理なら教育)するのが最も良いかと思います。
そして、VBAのExcelブックも部署内資産として、キチンと管理して、その先のVBAの無断開発を禁止する事です。
Excel-VBAをのメンテナンス性を高めるには「仕様書をきちんと書いておく」となりますが、コーディングより仕様書の方が長くなる上に、VBAが判らない人にはあっても宝の持ち腐れとなります。
私もExcel-VBAで業務効率化をしていた経験がありますが、次のことを実践してました。
VBA内で定数を定義しないでエクセルのセル上で定義する。
VBA内の変数、処理ロジックにコメントをやたら多く入れておく。
サブを多用し、処理ループ・流れを一覧できるようにしておく。
などですが、処理ロジックが大きく変わるとやはりVBAが判る人が必要になりますので、定数変更で対応できない場合には、ＶＢＡの分かるプロに見てもらうこととしていました。それが無理なら捨ててとも言ってました。
ないです。
それが可能なのだったら、VBA出現以降30年、様々なプログラミング言語が出てきたのは無駄だったということになってしまう。
30年間積み上げてきた工夫を、全部取り入れることを拒否しているのがVBA。だから評判が悪い。たぶん互換性が理由。
エクセルマクロの良い点：手軽に開発できる
悪い点:ブックの複製で同じようなものが沢山できて収拾がつかなくなる。
アドインを書けばいいのでは？
アドインでファイル名を命名させると出所もわかるので、やった方がいいと思います。
勤務表_PCログイン名_日付.xlsx
とか。
悪い点は工夫すれば、どうにかなりますよ。
- 情報システム部門を設置する
- アウトソーシングする
- VBAでごまかさずに専用ソフトを導入する
- 自動化しないで手作業でやる
VBAでつくったツールが大量にあり、レガシーとして問題になりつつあります。どうやって解決するのがいいのでしょうか？ 野良VBAを使っている組織は、その内容に応じて個別に良さげな手段を模索する以外にありません。大抵は、基幹システムで対応できない雑多な業務をVBAでどうこうしているので、統一した手法でとかは無理です。
また、VBAで実装されている業務の多くは、トラブルと業務が止まる基幹系とちがって、大抵は人力でなんとかなります。
事前にトラブルを予見してだと予算承認してもらえることは稀なので、痛い目を見てから慌てて対処するのが基本パターンだと思います。
汎用的な対策としては、VBA職人のいる小さなソフトウェア会社に委託して、少人数常駐してもらうのが良いと思います。
理由は、自社で人材を雇用し育成するより低コストだからです。なので、多重下請けの元請けに委託することも避け、実際に技術者が在籍している企業に発注する必要があります。
委託なのは、VBAで作られたツールの保守には導入現場特有の業務知識が必要なため、短期間で人が入れ替わる派遣契約では必要な情報が失われる可能性があるからです。
業務は、現在のVBA資産の棚卸しと保守と新規開発の委託になります。棚卸ししたVBA資産の中から緊急性の高いものはモダンな環境に移すなり、基幹系の機能にします。VBAの寿命が尽きるまで放置しても大丈夫そうなものは問題を先送りします。
RPAについては、VBA資産の棚卸し(内容の分析とドキュメント作成を含む）後に、移行しやすいRPAの選定を
VBAでつくったツールが大量にあり、レガシーとして問題になりつつあります。どうやって解決するのがいいのでしょうか？ VBAツールは、大抵の場合「ひとりの」人によって作られている場合がほとんどです。これがVBAの最大の問題点だと思います。
VBAツールの開発もリファクタリングも「ひとりの」人が行うのではなく、二人以上の「チームで」行うべきです。
つまり、VBAツールを使う必要のある部署には必ず二人以上のVBAプログラマないしは「VBA開発チーム」を配置するべきなのです。
といっても、外部からプログラマを調達する必要はありません。社内教育によってすべての部署にVBAプログラマを配置できるよう育成すればよいのです。こういうとき、VBAの特徴である「敷居の低さ」が利点になります。なんせ、PC に Excel さえインストールされていれば誰でもすぐに学習できますから。
VBA開発チームができてしまえば、新人VBAプログラマのメンターも社内で賄えますし、各部署のVBA開発チーム同士で情報交換を行い、部署の垣根を超えた全社レベルでの業務効率化を推進することも可能になります。
レガシーツールのリファクタリングもチームで行えばナレッジマネジメントを共有することができますし、プログラミング言語を1つでもマスターした人は他のプログラミング言語をマスターするための学習コストを大幅に節約できるので、それぞれのスキルによって社内全体で人材を流動的に活用することもでき、会社自体の競争力も向上します。
VBA開発はチームで行う
これに尽きる
0 件のコメント:
コメントを投稿