はじめに｜「マクロが動かない」は、なぜいつも私に飛んでくるのか
今すぐ会社を辞める予定はない。
でも、いつか辞める日は来る。
これはもう、かなり確度の高い未来だと思っている。
そして、そのときに起きることも、だいたい想像できる。
「マクロが動かない」
「この自動化ツール、誰か直せない？」
「急ぎなんだけど、これどうすればいい？」
そうなったとき、なぜか私のところに連絡が来る。
いや、知らん。
そもそもそれは、正式な業務命令で作ったものではない。
専任の担当でもない。
手当があるわけでもない。
評価が上がるわけでもない。
ただ、現場の仕事を少しでも楽にしたくて、Excel VBAや小さなプログラムを使って業務改善をしてきただけだ。
それなのに、気づけばその仕組みは“業務のインフラ”のように扱われる。
作った人がいるうちは便利に使う。
でも、保守する人はいない。
引き継ぎの仕組みもない。
教育制度もない。
これが一番イヤだった。
だから、あるとき考えた。
属人化が問題なら、先に手を打った方がいい。
自分以外にも、VBAや簡単なプログラミングができる人がいれば、保守も相談も分散できる。
少なくとも、自分だけに負荷が集中する状況は避けられる。
会社に言われたわけではない。
でも、「このままではまずい」と思って、若手にVBAを教え始めた。
属人化をなくすために、若手にプログラミングを教えた
当時、私は書類作成やデータ整理を自動化するマクロを作り、日々の業務を少しずつ潰していた。
手作業なら数時間かかる作業が、ボタンひとつで終わる。
転記ミスが減る。
確認作業が楽になる。
残業も減る。
効果が目に見えるタイプの改善だった。
だから、若手4人に声をかけた。
VBAが使えれば、面倒な作業を一瞬で終わらせられる。
定時で帰れる確率が上がる。
自分で改善できる人間は、社内でも社外でも強い。
もちろん強制ではない。
完全に自主参加だ。
質問があれば個別に答えた。
サンプルコードも作った。
実際の業務に近い題材で、「これができると仕事がかなり楽になる」というものを選んだ。
狙いはひとつだった。
まず、動かして感動してもらうこと。
プログラミングの理屈は後からでいい。
最初から変数だのオブジェクトだのを説明しても、たぶん面白くない。
それよりも、自分が普段やっている面倒な作業が、一瞬で終わる体験の方が大事だ。
「え、これ自動でできるんですか？」
「今まで手でやっていたの、何だったんですか？」
この感覚を一度味わうと、仕事の見え方が変わる。
プログラミングは、エンジニアだけのものではない。
現場で働く人間こそ、少し使えるだけで大きな武器になる。
そう思っていた。
結果｜3人脱落、1人覚醒
理想は、全員が少しずつVBAを触れるようになり、属人化が解消されることだった。
しかし、現実はそこまで甘くなかった。
4人のうち、3人は途中でフェードアウトした。
「難しいです」
「エラーが出ると何もできません」
「呪文にしか見えません」
「忙しくて勉強する時間がありません」
気持ちはわかる。
VBAに限らず、プログラミングは最初が一番しんどい。
エラー文は冷たいし、何を直せばいいのかわからない。
少しでも記号が違えば動かない。
慣れていない人からすれば、本当に呪文に見えると思う。
しかも、業務の合間に学ぶのはかなりきつい。
勉強には時間だけでなく、心の体力がいる。
通常業務で疲れたあとに、新しいことを覚えるのは簡単ではない。
こちらも本業がある。
教育は大事だと思っていても、結局は善意の追加コストだ。
毎週のように教え続ければ、自分自身も削れていく。
そんな中で、唯一残ったメンバーがいた。
理解が早い。
まず試す。
エラーが出ても自分で調べる。
少し直して、また動かす。
そして何より、
「これ、面白いですね」
と言ってくれた。
その瞬間、かなり手応えがあった。
そこからは、教育というより共闘に近かった。
お互いにコードを見せ合う。
「ここ、もっと短く書けますね」と話す。
「この作業、10秒で終わらせてみます」とゲーム感覚で改善する。
気づけば彼は、ひとりでマクロを組み、改善提案も出すようになっていた。
正直、こう思った。
この人に託せば大丈夫だ。
自分だけに集まっていた保守や改善の相談も、少しずつ分散できるかもしれない。
属人化が解消される未来が見えた気がした。
そして、その有能が辞めた
ある日、彼が言った。
「転職が決まりました」
思わず、マジかと言ってしまった。
でも、驚きより先に納得もあった。
VBAを覚える。
業務改善で成果を出す。
自信がつく。
改善提案もできるようになる。
職務経歴書に書ける実績ができる。
転職市場で武器になる。
そして辞める。
流れがきれいすぎた。
自分で“辞めるルート”を完成させてしまったようなものだ。
もちろん、恨みはない。
むしろ応援したいと思った。
実行力がある人。
自分で学べる人。
仕事を楽にする発想がある人。
そういう人材は、いずれ外でも評価される。
そして、外で評価される人は、条件が良い場所へ移っていく。
これは自然なことだと思う。
ただ、会社に残る側からすると、なかなか皮肉な現実でもある。
属人化をなくすために人を育てた。
でも、育った人は市場価値を上げて辞めていく。
結果として、属人化は別の形で戻ってくる。
そして残った側だけが、またこう言われる。
「誰か教えて」
「また保守して」
「このマクロ、直せる人いない？」
結局、最初の状態に戻ってしまう。
気づいたこと｜属人化は技術ではなく、構造の問題だ
この経験で気づいた。
属人化は、単に「VBAがわかる人が少ない」という技術の問題ではない。
もっと根本的には、会社の構造の問題だ。
属人化をなくしたいなら、本来は全員が最低限触れるようになるのが理想だ。
でも、現実にはそうならない。
興味を持つ人は少ない。
興味を持っても、続く人はさらに少ない。
伸びる人はもっと少ない。
そして伸びた人は、社外でも通用するようになる。
つまり、「育った人が辞めていく」のは、ある意味で避けにくい。
問題は、辞めることそのものではない。
人が辞めた瞬間に仕組みが崩れる状態を放置していることだ。
そもそも属人化が生まれる原因は、だいたい次のようなものだと思う。
改善活動が正式な業務として定義されていない。
引き継ぎや教育の時間が確保されていない。
できる人にだけ仕事が集まる。
でも評価や報酬は増えない。
責任だけが増えていく。
これは、技術の話ではない。
制度の話だ。
Excel VBAでも、Pythonでも、Power Automateでも、生成AIでも同じだ。
便利なツールを作れる人に仕事が集まる。
でも、その人を正式に評価しない。
保守体制も作らない。
教育の時間も与えない。
それでいて、いざ動かなくなると「困った」と言う。
それは、少し都合がよすぎる。
善意に責任を乗せるな
「マクロが属人化して困る」と言われることがある。
でも、作った側からすると、こう言いたくなる。
頼まれて作ったわけではない。
正式な業務命令でもない。
専任担当でもない。
ただ、現場の仕事を楽にするために善意で作っただけだ。
それなのに、壊れたら呼び出される。
改修が必要になれば、当然のように頼まれる。
他部署からも相談が来る。
でも、評価は増えない。
給料も変わらない。
担当業務として正式に認められるわけでもない。
それは、契約がおかしい。
善意で作ったものを、いつの間にか責任に変えられるのはしんどい。
もちろん、業務で使う以上、最低限の引き継ぎやコメントを残すことは大事だと思う。
実際、私もコードにはコメントを入れるし、マニュアルもできる範囲で残す。
でも、そこから先を個人の責任にされるのは違う。
会社が本気で困りたくないなら、やるべきことはシンプルだ。
教育制度を整える。
業務時間内に学ぶ時間を確保する。
できる人を正当に評価する。
改善や自動化を正式な職務として扱う。
給料を上げて、辞めない理由を作る。
これをしないなら、便利な人は辞めていく。
それだけの話だ。
生成AI時代でも、この問題はたぶん変わらない
最近は、生成AIを使えばプログラミングのハードルはかなり下がった。
Excel VBAも、Pythonも、GASも、Power Automateも、昔よりずっと始めやすい。
エラーの原因もAIに聞ける。
コードのたたき台も作ってもらえる。
だから、現場の人が小さな自動化ツールを作る時代は、むしろこれからもっと広がると思う。
ただし、ここで問題が消えるわけではない。
むしろ、別の形で増える可能性がある。
AIで作った便利ツールが現場に増える。
でも、誰が保守するのか決まっていない。
作った本人しか中身を理解していない。
異動や退職で誰も直せなくなる。
これは、VBA時代の属人化とほとんど同じだ。
ツールが新しくなっても、職場の構造が変わらなければ、問題は繰り返される。
「AIで効率化しよう」
「DXを進めよう」
「現場改善をしよう」
そう言うなら、同時に考えないといけないことがある。
誰が作るのか。
誰が保守するのか。
誰が引き継ぐのか。
その人は評価されるのか。
ここを曖昧にしたまま便利な人に甘えると、結局また同じことが起きる。
まとめ｜便利な人が辞めない職場をつくれるか
できる人に頼るのが悪いとは思わない。
現場は忙しい。
得意な人が前に出るのは自然だ。
困ったときに、詳しい人へ相談するのも当然だと思う。
でも、節度がなければ、それは搾取になる。
無償の善意に依存した職場はもろい。
その人がいなくなった瞬間に崩れるなら、それは仕組みではない。
ただの属人化だ。
VBAが古いとか、Pythonが新しいとか、AIを使えば解決するとか、そういう話ではない。
本質はもっと単純だ。
便利な人に甘えすぎる職場は、便利な人から辞めていく。
そして、辞められてから慌てても遅い。
属人化をなくしたいなら、個人の努力に頼るだけでは足りない。
教育の時間を作る。
改善を業務として認める。
保守する人を評価する。
できる人に責任だけを乗せない。
それができない職場であれば、また同じことが起きる。
私は、「マクロが動かないから戻ってきて」と言われても戻らない。
頼まれてもいないことに、いつまでも責任なんか持てない。
VBAの引き継ぎは難しい。
プログラミング教育も簡単ではない。
でも、一番難しいのはたぶんそこではない。
本当に難しいのは、
便利な人が辞めない職場をつくること
なのだと思う。
