orangeitems’s diary

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

仕事を仕組み化したときの良くないところ

 

日々の仕事、観察するとどこか繰り返しや条件分岐の法則性がある。それらを取りまとめて、誰でも理解できるように整理することを仕組み化、と呼ぶ。仕組みにしてしまえば、仮に参加者が変わったとしてもその仕組みを学べば、同じ品質の仕事を再現することができる。

仕組み化すると、何か部門の中で不具合が起こっても、そのメンバーが悪い、とはならない。

そのメンバーが仕組み通りやっていたのに間違えたとしたら、仕組みに欠陥がある。間違えを誘導するような原因が仕組みに隠れていて、その存在に誰も気づいていなかった。だから次にやるのはメンバーへの叱責ではなく、仕組みの改善だ。

もしくは、仕組みは悪くはないが、メンバーの不注意や不勉強で起こったとしたら。これは、そんなメンバーをどう指導し技量を上げていくかについても仕組み化しておく。一定の学習を行い、改善されたと確認されたらまた復帰する、など。

 

そうやって、仕組みで考えることについては、私も特に積極的だった。仕組みをどんどん突き詰めて一つのシステムのようにし、最後は私がほとんど手を動かさなくてもまわる仕組みが理想だった。

そして、結果はどうなったか。いくら仕組みを作ったところで、その仕組みを熟知するメンバーの数を確保できなければ機能しなかった。仕組み自体が高度に作り込んだせいで、メンバーが変わったときにすぐ適用することが難しい。だからこそ、いくら仕組み化したところで、メンバーが職場に定着しなければ、絵にかいた餅である。仕組みはある。で、それ誰がやれるの?と。

だからこそ、仕組み化したら職場が素晴らしくなるかと言うと、これは過大評価し過ぎである。仕組み化と同時に、メンバーが職場により定着するような仕掛け、いわゆる人のマネジメントが効果的でないといけない。

仕組み自体が仕事をしてくれるのではなく、その仕組みを動かすのは人である。人を大事にした上での仕組みということを十二分に踏まえておかないと、作った仕組みがゴーストタウンのようになり、廃墟のような職場になるから要注意だ。

まあ、仕組みがあると、新しい人の立ち上げは早くなるからいいところもあるが、新しいメンバーも大量の高度な仕組みを目の前にして、この職場でやっていけるんだろうか・・と不安を持ちやすくなることも忘れてはいけない。

 

また、仕組み化のもう一つ悪いところを知っている。仕組みの例外条件の存在だ。仕組みが想定していなかったことが起きたとき、全部仕組みを作る人にエスカレーションされることとなる。メンバーは逃げやすくなる。想定されていないので私はこれ以上できません、と。

確かに、想定されていないことに対して勝手に手を動かし、後から指示していないだの越権だのと、責任を追及されたらたまらないという心理もわかる。仕組みは、逃げるための格好の言い訳になりやすい。

ただ、仕事と言うのは、例外が必ずあるのだ。その例外処理を、毎回私はやる羽目になることが多くて、これってこの例外処理そのものが一番、高度でかつ、商売のタネなんじゃないの?と思うこともあってモヤる。

その例外条件を今日もまた、仕組み化してメンバーに引き渡し、同じようなことが起こったらもうやってくれるよね、とは思うけど。明日にはまた亜種の例外が出てくるに違いなく、仕組み化に違和感を持つ最大の理由となっている。

想定外のことがあっても、誰かが最後はやらなきゃいけないからなあ・・。

仕組み化をあまりにも過剰評価すると、こんな目に遭うよね、と言う話であった。