かなり煽り要素の強いタイトルですが、巷で言われる表題の件についてググった内容と併せて私の意見をまとめてみました。
なぜExcelマクロは嫌われるのか
その半面、一部有識の経験で作られているがゆえに、その担当者が退職・異動の後、第三者がマクロが組まれているExcelを理解できず、修正ができないといった問題が生まれました。
Excelを利用していればおそらくどの職場でも発生している問題かと思います。
実際、私の職場でもExcelマクロのみならず、batにACCESSにスケジューラと絡んで壮大なピタゴラスイッチができあがっており、トータルでメンテナンスできる人材はかなり希少です。
BIツールを使うんだ！
これ実際に私の職場でExcelマクロ属人化問題に対して提唱された案です。
意図として
「excelマクロは属人化するからノーコード系ツールに載せ替えたい」
とのことでしたが。本当に載せ替えたらこのExcelマクロ属人化問題は解決するのか？
ノーコードツールになってエンドユーザーに優しくなったら属人化問題は解決するのでしょうか？
私は懐疑的に見ています。
おそらくBIツールを導入してから数年後には
「BIツールは属人化するから使うな！」
が提唱されはじめるのではないかと思います。
きっとExcelマクロも当初は(今も？)エンドユーザーが使うことを想定したうえでリリースされていたはずで、時代が繰り返されるだけになるのではと思っています。
とはいえ、BIツールがエンドユーザーに優しく、そのカバー領域では機能的にも優れているのは事実で一部を置き換えていくはありかと思います。
システムやサービスに置き換えろ！
これだけ世の中に業務用システムやサービスが出回ってる以上、よっぽど特殊な業務をしてない限りは必ず世の中にでているサービスのカバー領域に入っているはず。
現在Excelマクロが担っている部分を置き換えることで、
従来の「属人化」部分をサービス、システムが担ってくれることになります。
とはいえ、だいたいExcelマクロで組んでいる領域はシステム化する際にカバーしきれなかった領域を自前でこさえた結果だったりするので、置き換えるとなるとその周辺領域を巻き込んでごっそりということになる。
骨折り損のくたびれもうけ
牛刀をもって鶏を割く
になりかねないのであまり現実的ではない。
(どのみち新たに生まれるカバーしきれない領域を自前でこさえる新たな属人化の再生産が起こる)
そもそも、
既存のシステムでカバーできない を疑うが一番現実的でローコストかもしれません。
誰も触ってない機能、使われてない機能が実はExcelマクロでカバーしてることそのものだったなんてことも往々にしてあるかもしれません。
(特にパッケージシステムや完全自社開発でのシステムなどではどんな機能があるのか、その機能に対してどの機能をどう活用してるのかが明示的になっておらず、車輪の再開発のような似たことが起こってるのでは)
Excelマクロが悪ではない
Excelマクロが というよりはそのExcelマクロの周辺に「属人化」の要因があるのではと思います。
・仕様書がない
・目的がわからない
・コードが複雑で解読できない
これらが満たされていれば、ある程度の属人化は回避できるのではと思います。
また以下の要素も大きいのではないかなと思いますが、
Excelマクロへの過剰な業務押し付け
マクロに限らずRPAでも同じことがいえますが、柔軟性が高く何でもできるがゆえ不必要にExcelマクロ化してしまってるケースもあります。
具体的には役割分担が適切にされずすべてExcelに押し付けられてる状態のことです
Excelマクロの話とはずれますが、巷で言われている神Excelなどが上記に当てはまると思います。
https://www.itmedia.co.jp/news/articles/2203/31/news064.html
他の例だとどう考えてもExcelマクロで組んだほうが簡単な操作を無理やりRPA上で実装しようとしたりだとか
(これ実際に見た例で行・列コピーして別シートに貼り付けて、フィルタをかけて、csvに保存してまた別のフィルタをかけて～をRPA上で壮大な工数をかけて実現しようとしていました。後日、Excel上でVBAで組み直してRPAからマクロをキックする形に修正)
まとめ
役割分担と仕様書作成をしっかりやろう
ということなのだと思います。
いくつか記事を読みましたが、役割分担がまず第一 と記載されてるものが多い印象で私もその派です。
BIツールのカバー領域はBIツールへ、システムのカバー領域はシステムへ、Excelマクロのカバー領域はExcelマクロで。
各々のシステムに分割する場合はそれらのつながりを網羅できる設計書・仕様書を作成
機能ごとに分割せず何か一つのツールで業務を自動化するにしても、大大前提として目的を記載した仕様書は忘れずに。
(22/11/01)
コメントをいただいた内容を基に自戒を込めて追記します。
「仕様書を作る」これはおそらく誰もが作ったほうがいいだろうと思いながらも仕様書自体は即効性をもった工数削減効果が見出しづらいため、優先度低めにしがちと思います。
リリースした後に時間があるときに作っておこうと思いながら結局つくらない。
〇対策
後々組織への大きな負債としてのしかかることを前提に設計段階から目的を記した仕様書を作っておくべきです。
WBSの頭に「仕様書作成」を用意してもいいかもしれません。
ツールと仕様書はセットであるべきものとして、仕様書なくしてリリースさせずというルールを課すことが後世の平和への第一歩かもしれません。。。
参考
以下を参考にさせていただきました