2022-02-08 DX エクセルVBAの属人を防ぐには

ほえほえ＠スプシマン @hoehoe1234

エクセルVABの属人化を防ぐには２つしか方法がない。 ①コードレビューを行い、分かる人を複数人にする ②仕様書を書いて今は分かる人はいないがその気になればわかるようにしておく もちろん、保守性のよいコードにしておくことは前提条件。全部お金がかかる。なので属人化の排除≒お金。

ほえほえ＠スプシマン @hoehoe1234

使わないかもしれないものにお金を書けるのが属人化の排除。しかし、程度というものが有り、エントロピーの法則が働く。属人化の排除を高いレベルで維持しようとするとお金がかかりすぎる。これは部屋を常にきれいに保つのはとても大変だということと同じ原理。

ほえほえ＠スプシマン @hoehoe1234

かといって何もしないと部屋は汚部屋となり部屋として機能しなくなる。用途、費用、目的に応じた「きれいさ」がある。ペアプロなどは効果は高いが費用がかかりすぎる。コードレビュー程度が現実的だろう。設計書はどうだろうか？そもそもまともに設計書が「かけない」という事実がある。

ほえほえ＠スプシマン @hoehoe1234

設計書を書くには訓練が必要なのでノンプロが文書だけでアプリの仕様を説明することはとてもむずかしい。アプリを作ること以上に時間と頭を使うだろう。一応当塾では①全体概要②機能一覧③業務フロー程度を推奨しています。

ほえほえ＠スプシマン @hoehoe1234

テストしようなんかは当然ないですし、もし作るとすれば「運用マニュアル」を業務フローと兼用でつくるのがいいかな？なんて思います。「どこになにがあるか？どうデータがながれるか？」だけでも助かりますからね。これとは別に「よいコードを書けるように」というのがあります。

ほえほえ＠スプシマン @hoehoe1234

きちんと関数分割し、関数コメントもちゃんと入っているアプリは当然ですが読みやすいです。全てがコピペ、直打ち、グローバルなアプリは解析するよりも書き直したほうが早いです。属人化とはちょっと違いますがアプリの質が属人化に影響を及ぼしますね。

ほえほえ＠スプシマン @hoehoe1234

リスク／リターン、費用／リターンの話になるので、アプリの規模、複雑制、重要度、会社の都合、上司の考え方などで「なにをどこまでやるか」は個別に考えざるを得ないですね。こんなごたごたがいやなので結局は自分専用だけにしとくのがお得というのも合理性があります。面倒事は避けたいですからね。

ほえほえ＠スプシマン @hoehoe1234

何度も書いていますが、属人性の排除が費用の問題である以上、この問題はマネージャの問題です。属人化をきらってエクセルVBAを嫌うなら結局は個人が隠れて効率化をするだけですね。マクロブックと対象データを分ければ良いのですから。マネージャの責任は経営者の責任。すべては経営者の考え方ですね