はじめに｜効率化の報酬は労働だった
会社ではよく「業務効率化しよう」「DXを進めよう」「AIを活用しよう」と言われる。
私自身も、Excel VBA、Python、AIツールなどを使って、業務効率化に取り組んできた。
書類作成を自動化する。
転記作業を減らす。
確認作業を楽にする。
現場の面倒な作業を仕組み化する。
もともとは、楽をするためだった。
同じ作業を何度も繰り返したくない。
人間がやらなくてもいい作業に時間を使いたくない。
どうせなら、もっと早く、もっと正確に、もっと楽に仕事を進めたい。
そう思って、効率化や自動化のスキルを身につけてきた。
しかし、会社で効率化を進めていくと、少しずつ見えてくる現実がある。
効率化できる人は、楽になるとは限らない。
むしろ、仕事が増える。
「これもできる？」
「あれも自動化できない？」
「ちょっと相談していい？」
「この業務も何とかならない？」
気づけば、自分の業務だけでなく、周囲の業務改善まで背負うようになる。
つまり、効率化の報酬は評価ではなかった。
労働だった。
効率化はゆっくり社内になじむので、評価されにくい
業務効率化の成果は、意外と見えにくい。
なぜなら、効率化は一気に劇的な変化として現れるというより、少しずつ社内になじんでいくからだ。
最初は「便利になった」と言われる。
次に「これが普通」になる。
最後には「前からこうだった」ような扱いになる。
書類作成にかかっていた時間が短くなる。
確認作業のミスが減る。
転記作業がなくなる。
手順が標準化される。
誰でも同じように作業できるようになる。
現場では、確実に良くなっている。
しかし、その変化はゆっくり進む。
ゆっくり進むからこそ、周囲は変化に慣れてしまう。
そして、慣れたものは評価されにくい。
「助かっている」
「便利になった」
「すごいね」
そう言われることはある。
しかし、それがそのまま人事評価に反映されるとは限らない。
効率化の成果は、会社の日常に溶け込む。
日常に溶け込んだ瞬間、それは成果ではなく「当たり前」になる。
これが、効率化の難しいところだと思う。
自動化できる人ほど、仕事を頼まれる
プログラミングを覚えた理由は、人それぞれだと思う。
私の場合は、楽をしたかったからだ。
面倒なExcel作業をなくしたい。
同じ書類を何度も作りたくない。
手作業によるミスを減らしたい。
人間がやる必要のない仕事は、機械にやらせたい。
そう思って、VBAやPythonを覚えた。
しかし、会社の中で「プログラムを組める人」と認識されると、状況は変わってくる。
自分の仕事を楽にするために覚えたはずなのに、いつの間にか、他人の仕事を楽にする役割になっていく。
しかも、その範囲はどんどん広がる。
Excelの自動化。
書類作成。
データ整理。
集計。
チェック作業。
現場の困りごと。
部署をまたいだ調整。
よくわからないIT相談。
最初は小さな相談だったものが、次第に「あの人に聞けば何とかなる」に変わっていく。
これが便利屋化である。
問題は、便利屋的な仕事は評価されにくいことだ。
なぜなら、それは直接お金を生んでいるように見えにくいからである。
売上を増やしたわけではない。
新製品を出したわけでもない。
大きな契約を取ったわけでもない。
だから、こう言われることがある。
「それって、どれくらい利益になったの？」
もちろん、効率化は利益に貢献している。
人の時間を減らし、ミスを減らし、属人化を減らし、業務を安定させている。
しかし、その価値は見えにくい。
結果として、効率化できる人ほど仕事を頼まれ、しかし評価はされにくいという構造が生まれる。
楽をするために覚えたスキルで、なぜか仕事が増えていく。
なかなか皮肉な話である。
できると分かった瞬間、それは評価ではなく基準になる
効率化や自動化の怖いところは、一度できると分かった瞬間、それが基準になってしまうことだ。
最初に自動化したときは感謝される。
「すごい」
「助かった」
「便利になった」
そう言われる。
しかし、次からは少しずつ空気が変わる。
「前もできたよね」
「今回もできるよね」
「これも同じようにできないの」
「なぜ今回はやらないの」
最初は加点だったはずのスキルが、いつの間にか最低ラインになる。
そして、それをやらないと「やる気がない」「最近サボっている」「前はやってくれたのに」と見られることすらある。
しかし、不思議なことに評価は上がらない。
できることは当たり前になる。
やらないことだけが目立つ。
評価されないのに、期待値だけが上がっていく。
これはかなりつらい構造だと思う。
効率化できる人は、仕事を減らすためにスキルを身につけたはずなのに、結果として自分への要求水準を上げてしまう。
しかも、その要求水準の上昇に対して、給料や評価が連動するとは限らない。
つまり、社内で効率化スキルを見せることには、明確なデメリットもある。
できれば便利。
できなければ不満。
でも評価は普通。
これでは、効率化できる人ほど損をする。
「効率化の報酬は労働」と言われることがあるが、まさにその通りだと思う。
効率化した人に返ってくるのは、空いた時間ではない。
次の仕事である。
外部には高い金を払うのに、内部人材は便利屋扱いされる
もう一つ、強い違和感がある。
会社は、外部のシステム会社やコンサルには高いお金を払う。
業務改善ツール。
システム導入。
自動化支援。
DXコンサル。
データ整理。
RPA導入。
こうしたものには、普通に数十万円、数百万円、ときにはそれ以上のお金を払う。
しかし、同じようなことを社内の人間がやると、なぜか急に価値が低く見られる。
「詳しいならお願い」
「ついでに作って」
「ちょっと直して」
「空いている時間でできない？」
こうなる。
本来、プログラミングや自動化は希少スキルである。
現場を理解し、業務を分解し、ツールを作り、運用まで落とし込める人材は多くない。
外部に頼めば高額になる。
要件定義にも時間がかかる。
現場理解も浅い。
完成後の修正にも費用がかかる。
それなのに、内部にできる人がいると「ラッキー」で済まされる。
これはかなりおかしな話だと思う。
会社にとっては、安く使える便利な人材かもしれない。
しかし本人からすれば、希少スキルをほぼ無償で提供している状態に近い。
もちろん、会社員なので業務命令の範囲で働くのは当然である。
ただ、それが正式な役割でもなく、評価にも反映されず、給料にもつながらないなら話は別だ。
外部に頼めばお金を払うのに、内部にいると評価しない。
この構造がある限り、社内DX人材は便利屋になりやすい。
裏で大きな仕事をしていても、主業務に影響が出ると評価されない
便利屋になると、単に仕事が増えるだけではない。
主業務に影響が出る。
他部署を巻き込み、現場の課題を拾い、仕組みを作り、運用まで落とし込む。
これは本来、かなり大きな仕事である。
ただのExcel作業ではない。
ただの便利ツール作成でもない。
課題発見、要件整理、関係者調整、実装、運用設計まで含む、かなり重い仕事だ。
しかし、それが正式なプロジェクトとして扱われていない場合、評価上は「裏で勝手にやっていること」になりやすい。
その結果、主業務の進捗が少しでも遅れると、こう言われる。
「本来業務をもっと頑張ってほしい」
「期日管理が課題」
「周囲をもっと巻き込んでほしい」
いや、巻き込んでいる。
むしろ、他部署まで巻き込んでかなり大きな仕事をしている。
しかし、それが評価項目に入っていなければ、評価されない。
会社員の評価は、必ずしも実際の貢献度で決まるわけではない。
評価シートに書かれていること。
上司が把握していること。
組織として正式に認められていること。
こうしたものが重要になる。
どれだけ裏で動いていても、正式な仕事として認識されていなければ、「主業務を圧迫している余計なこと」に見えてしまう。
ここが、効率化人材のつらいところだ。
何となく引き受けるのは、本人にも責任がある
もちろん、会社だけが悪いわけではない。
何となく相談されて、何となく引き受けて、何となく作ってしまう。
これを続けていれば、便利屋になってしまうのは当然でもある。
「ちょっとだけなら」
「自分ならできるし」
「困っているなら助けよう」
「まあ、作った方が早いか」
こうして引き受けた仕事は、正式な業務にならないまま積み上がっていく。
そして、気づいたときには自分の首を絞めている。
だから、本来は最初に確認すべきなのだ。
これは誰の業務なのか。
どの評価項目に入るのか。
工数は確保されるのか。
作った後の運用担当は誰なのか。
保守は誰がやるのか。
正式な依頼なのか、ただの相談なのか。
技術力がある人ほど、すぐに作れてしまう。
だからこそ、境界線を引く力が必要になる。
効率化できることと、何でも引き受けることは違う。
ここを間違えると、会社にとって都合のいい便利屋になってしまう。
便利屋は感謝されるが、評価はされない
便利屋は感謝される。
しかし、評価されるとは限らない。
「改善ありがとう。今期はS評価だ」
現実には、なかなかこうはならない。
なぜなら、多くの改善は「勝手にやったこと」と認識されやすいからだ。
会社から正式に任命されたプロジェクトではない。
評価項目に入っていない。
売上に直接つながっているように見えない。
上司が詳細を把握していない。
相対評価の中で、誰かの評価を下げてまで上げる理由になりにくい。
これが現実だと思う。
会社の評価は、絶対評価に見えて、実際には相対評価の要素が強い。
誰かを上げるということは、誰かを下げるということでもある。
その中で、上司が「この人は裏で業務改善を頑張っているから、他の人より高く評価しよう」と判断するとは限らない。
むしろ、多くの場合はこうなる。
「助かっている」
「ありがたい」
「でも評価は普通」
これが便利屋の立ち位置である。
感謝と評価は違う。
ここを勘違いすると、かなり苦しくなる。
それでも効率化スキルは、強い武器になる
では、効率化などやらない方がいいのか。
私はそうは思わない。
むしろ、効率化スキルはかなり強い武器になる。
自分で課題を見つける。
対策を考える。
関係者を巻き込む。
実際にツールや仕組みを作る。
最後は運用に落とし込む。
これができる人は、かなり少ない。
単にプログラムを書けるだけではない。
現場の課題を理解し、業務の流れを見て、実際に使われる形にする。
この力は、多くの会社から見れば喉から手が出るほど欲しい人材だと思う。
実際、効率化の実績を職務経歴書に書くと、反応はかなり変わる。
「効率化1000時間以上」
「VBA・Pythonによる業務改善」
「現場課題の発見から仕組み化まで実施」
こうした実績は、社内では軽く見られても、社外では強い武器になる。
社内評価では拾われないものが、市場価値としては評価されることがある。
これはかなり重要な視点だ。
なぜ私は、それでも効率化を辞めないのか
ここまで書くと、こう思う人もいるかもしれない。
「評価されないなら、効率化なんてやめればいいのでは？」
たしかに、それも一つの答えだと思う。
評価されない仕事を続ける必要はない。
便利屋として消耗する必要もない。
会社に都合よく使われる必要もない。
それでも私は、効率化を完全には辞めないと思う。
なぜなら、そもそも効率化がやりたくて今の会社に入った部分があるからだ。
現場には課題が山ほどある。
非効率な作業も多い。
改善できる余地も大きい。
見方を変えれば、会社は実験場でもある。
自分で課題を見つけ、ツールを作り、現場に入れ、反応を見て、改善する。
普通ならなかなか経験できないことを、会社の中で実践できる。
もちろん、評価されるとは限らない。
むしろ、評価されないことの方が多い。
それでも、スキルは異常に身についた。
現場を理解する力。
業務を分解する力。
自動化する力。
他部署を巻き込む力。
仕組みに落とし込む力。
そして、自分の市場価値を言語化する力。
これらは、会社の評価とは別に、自分の中に残る。
だから私は、会社に評価されるためだけに効率化をしているわけではない。
会社を使って、自分のスキルを伸ばしている。
会社を実験場として活用している。
そして、いつでも外に出られる状態を作っている。
会社の便利屋で終わるのか。
現場改善ができる人材として市場に出るのか。
その違いは、自分で決めるしかない。
おわりに｜自分のキャリアまで便利に使われてはいけない
効率化できる人は、会社の中で便利な存在になりやすい。
困ったときに頼られる。
面倒な仕事を任される。
よくわからない相談が集まる。
そして、できて当たり前になっていく。
しかし、自分のキャリアまで便利に使われてはいけない。
効率化は、会社のためだけにあるものではない。
自分のスキルを伸ばし、市場価値を高め、選択肢を増やすための武器でもある。
社内で評価されないなら、記録すればいい。
数字にすればいい。
職務経歴書に書けばいい。
社外で評価される形に変えればいい。
効率化の報酬が労働だけなら、かなり苦しい。
しかし、その労働をただの便利屋仕事で終わらせず、自分の実績に変えられるなら話は変わる。
評価されない会社で消耗するのではなく、会社を実験場として使う。
そう考えれば、効率化で得たものは決して無駄ではない。
少なくとも私は、そう思っている。
