RPAなどの業務改善ネタ探しを、手が空いてるからと暇な社員にやらせるのは悪手である


 ちょっと最近忙しい。ブログ名にある通り「単騎」なので、助けはない。ひたすら1人で忙しく日々を過ごしている。積んでは崩しの不条理神話のような仕事に振り回されている。

 そんなある日、ある社員が私の元に寄ってきた。

 同じ部門にいるものの、普段からあまり話さない社員である。どちらかというと、あまり忙しくない社員である。どちらかと言うと、あまり業務を振りたくないタイプの社員である。要するに、ちょっと性格的、パフォーマンス的に”使えない”タイプの社員である。

 こっちは昼メシも抜きでやっているのに、何か?と顔を向けると、一応申し訳なさそうに「ちょっとお話を聞かせて欲しくて・・・」と言う。

 捨てられた子犬のような感じで、ちょっと情にほだされて、緊急性の高いメールをさておき、話を聞くことにした。

 その話とは、要するに

 ①最近はやりのRPA(Robotic Process Automation;後述)を全部門で導入することになった。

 ②各部門でRPA対象ネタを探すことになり、業務改善ネタを各部門で担当者を割り当てている。自分がこの部門の担当になった。

 ③ついては、お忙しいところ申し訳ないが、RPAできるネタがないか教えてくれないか

 と言うものである。正直がっくりきて、上手く誤魔化してお引き取り願った。

 ・・・RPAネタを探す人間を完全に人選ミスしているのである。

 RPAとは、オフィスワークの業務効率で複数の異なるソフト群を使った動作を、上位系ソフト上にある仮想ロボットからプログラム的に順序を決めて動かすことができるようにすることで事務系ワークを無人化・自動化できるサービスのことである。従来から、マクロなどで一部記述できてはいたが、IT技術の進歩によって、よりユーザフレンドリかつ複数ソフトにまたがって実行できるようになったことが、ここへ来て流行めいた状況になっている背景であろう。

 話を戻す。何故、彼がRPAネタを探す担当になったか?それは間違いなくこの部門内で最も暇で、業務が空いていたからであろう。私含め他の社員はバタバタしており、頼めるのはたしかに彼くらいしかいない。

 しかし芯を食った業務改善ネタは、業務ができない人間からは決して出てこないのである。仮に出てきたとしても、それは全く的外れなポイントであろう。何故なら、業務を改善するマインドがない人間、改善ポイントを見る目のない人間が見つける改善ポイントは100%間違っているからである。要するに業務に振り回されている人間には、その業務を俯瞰する視点はなく、業務に従属された視点しかないのである。つまり、業務の存在を前提にして、お互いの共生を満たすような答えしか出てこない。本来は、その業務を乗り越え、否定する視点があるべきであろう。

 本質的な改善ネタをすぐに探すのであれば、最も忙しい人間にやらせることがベストであろう。常に仕事に直面し、その負荷をどう効率的にすれば良いかを考え、常にアンテナを張っている人間。業務自体をコントロールしようとし、超克しようとしている人間でないと、本当の意味で業務改善はできないのである。ちなみに誤解なきように言っておくと、その仕事パンパン人間が、パフォーマンスが優秀であるということではない。仕事パンパンで、常にギリギリのところで直面しているという状況こそが重要なのである。

 だが、そうした人間は結局そのギリギリの仕事ぶりを積極性と勝手に解釈されて、当てにされるので常に仕事はパンパンになっている。常に忙しいので、ここへきて更に業務改善もやってよ、とは言いにくい。だが、その人間をメインに据えない限り、業務改善ポイントは芯を外しまくるのである。

 そしてRPAは、開始する時間が早いほど、効果が上がる。素早く効率化すれば、それ以降の時間で効果が出続けるからである。要するにイニシャルコストは多少高くても、ランニングコストの低減で回収できるという論理である。

 したがって素早く、効率化よいポイントを探すべきなのに、最も仕事が遅くポイントをズラす人間が最も暇なので、その仕事を回されやすいという逆説的状況が発生しているのだ。

 最悪、RPAを実行するルーチンフェーズなら良いかもしれない。要件を決定した後の実行フェーズである。要件を定義する部分は、これは間違いなく、誰でもいいから今暇そうにしているヤツにやらせてはいけないのである。

 こうした事例は、それ以前でも同様な構図がある。

 人間が従来実施していた業務フローをIT化する際に、人間が現在やっている内容をそのまま要件定義すると、例外処理の嵐になり、結果的にシステムは高いものになり、例外処理が多いのでITによる効率も上がらず、ユーザからも使いにくいソフトになる。不満が渦巻く、IT化の典型的失敗例である。

 この原因ははっきりしており、フローをIT化する前の段階で、十分に効率化・標準化の観点からフローを十分に見直し、徹底的に改善した上で、IT化を進めなくてはいけないのに、それを怠ったことが原因である。

 結局、組織というものは微妙で、暇な人間がいるのは仕方ないが、暇であるが故に与えてはいけない業務も与えてしまう余地が生まれ、それにより却って組織を疲弊させることがあるということも、マネジメントでは肝に銘じる必要があろう。

 そんなことを思っていたら、「○○さん(私のこと)だけが、RPAネタ無いって言ってるけど」と、任命者が近づいてきた。非協力的態度はまずかったか。

 「本当は○○さん(私のこと)に、RPAお願いしたいんだけど。アイツにネタ集めさせたら、全然整理できてなくてさ」予想通りである。だから言ったのに(言ってない)。

 では、やはり組織のために引き受けるべきなのであろうか。

 しかし、私の答えは「すいません、忙しいので、できません」であった。

 アタマの中ではやった方が良い、引き受けるべきと思っている、しかし、やることによる更なる業務量オーバーが、Yesを口に出せなかったのである。トータルでは楽にあるが、短期的には苦しいのは耐えられない。こうした心理が働いたのである。

 結果、個別最適になってしまった。この全体最適解を実現するためには何かが足りていない。それは何なのであろうか。

Share