orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

仕事における定型業務と非定型業務の間にある大きな谷

f:id:orangeitems:20211217123308j:plain

 

 

 

オペレーションの方法が決まっていて、マニュアルに則って動けばいい、という種類の仕事を「定型業務」と呼びます。

一方で、マニュアルが無くて、その時に最善を考えて動き結果を出す仕事を「非定型業務」と呼びます。

「非定型業務」ができるととても他人からの評価は高まるのですが、一方で、別の人が同じようにできるかわからない仕事です。人によって最善は異なります。あなたができるからといって隣の人ができるとは限らない。

会社においては、誰かしかできないことがあると、その誰かが退職したときに誰もできなくなります。ですから、「非定型業務」はできるだけ仕事の内容を洗い出し、マニュアル化し、「定型業務」に落とし込もうとすることはごくごく普通のことです。

単なるマニュアル化の場合は文書化するだけですが、コンピューターに任せる場合は、プログラミングを行います。基本的には、プログラムは毎回同じように動きますから、プログラムが書けるということは、「定型業務」に落とし込むための記述に成功したということになります。

RPAが「〇〇時間の削減」と言っているのは、この定型業務を人が実施していたのですが、代わりにコンピューターができるようになったということを意味します。

さて、この定型業務。新しい人が現場に入って一番初めに覚えるしごとです。マニュアルはあるけれど、初めは誰かがそばにいて、一通りできるまでコーチしてくれますよね。マニュアルを読んだだけでは理解できないかもしれないので、ここはこういう意味だよ、こうやってやるんだよ、と教えると、だんだんできるようになるのが人です。

そして時間が経つと、定型業務の数が増えていきます。いろんな定型業務を時間とともにおぼえ、あたかも定型業務の博士みたいにもなります。

でも最近思うのが、この定型業務をいくつおぼえたとしても、非定型業務ができるようになる人材になるにはならないということです。

逆に言えば、一つの会社で長年いて、その会社の定型業務を知り尽くしたとして、他の会社に行ったときにその定型業務の知識が使えなければ、ほぼゼロからのスタートになってしまうということです。

転職しても成功しない人って、まさにそういう人じゃないかな、って。

しかも最近は前の例の通り、非定型業務を定型化するときって、人にやらせようという発想より、コンピューターにやらせるという発想を初めからした方が効率的ではないですか。ということは、他の会社でも、定型業務しかできないような人材への需要はどんどん減っているということです。

非定型業務を把握でき、かつそれを定型業務化できるような人材は、引く手あまたです。それがプログラミングではなくともです。要件定義しベンダーにシステムを作らせることができれば十分です。定型化をどうやるかはいろんなやり方はありそこにスペシャリストはいますが、そうさせるに当たっては、非定型を定型にする発想が重要で、それはいくら定型的な業務を積み重ねても、到達できる分野ではありません。

じゃあ、どうやれば非定型的な仕事ってできるようになるの?。

これが、実はあまり必勝法的なものがないんです。

必勝法的なものがないからこそ、これは人の話を聴いたり、他の人がうまくやっている事例を観察して自分のものにしたり。定型的とされている仕事を疑ってかかってそもそもやるべきものなのか、という仮説を考えたり。

よくよく考えると、「科学的手法」というものに似ています。仮説を立て、考察し、検証し、結論を得る。大学などで教えるこの手法自体が、非定型業務なんじゃないか。

定型業務こそ仕事と考える人や職場も多いので、ぜひこのトリックに引っ掛からないようにしてみてください。その仕事、必要ですか?。ビジネスの目的を踏まえ、何が最善か。科学的手法に基づき行動し、結果を出す。このような態度でいないと、意味があるのかないのかわからない定型的業務にうずもれて、自分の価値を下げてしまうかもしれません。