見えない非効率 ー 今、動いているんだからいいじゃないか

新任の取締役が、あるとき担当する事業部の支社を見に行った。一通り見学し、支社長らと懇談した後、かえろうとしたら、ある部署だけ灯りがついているのを見つけた。現場仕事はもう終業しているのに、管理部門の1セクションだけ、忙しそうに机にむかって仕事している。

「何をしているの?」と彼がたずねたところ、「本社に送る書類を作成しているんですよ。毎月、数字をまとめて送らなけりゃいけないんで、残業になるんです。」との答えだ。資料を見て、さらにたずねる。「本社は、この統計資料を見てどう役立てるんだろう?」「・・存じません。本社にたずねてください。」

その取締役は本社に戻ると、早速、送付先の企画部門にいって、その書類のことをきいてみる。すると、「ああ、その書類ですか。工場が毎月送ってくるんでね、ファイルして保管しているだけです」という。「でも、なんで工場はその書類を送ってくるのかな?」「さあ・・。」

いろいろ調べた結果、事情が分かった。彼の前任者が、ある時、工場に指示して数字をまとめさせたのだ。それは投資か何かの判断材料だったのだろう。その時は役に立った。しかし、工場側はそれを毎月作成すべきものだと理解して、担当者が残業して送り続けてきたのだった。そして本社側も、彼が気づいてやめさせるまで、誰も止めなかったという訳だ。

役に立たないものに努力を費やすことを、非効率という。上の例は、経営学者のC・N・パーキンソンの本にあったエピソードである。無駄な作業をやめれば改善効果は明らかだから、この例は分かりやすい。だが、現実はいつでもそうとは限らないのだ。

N社の工場を見学に行った。ハイテク産業向けに部品材料を作っている工場だ。高度な機械エンジニアリングの工夫を凝らした、自慢の製造装置を見せてもらった。下流側の加工・出荷工程も拝見する。どうしても手作業が介在するが、人々は忙しそうにキビキビと働いている。

ところで、見ているうちに奇妙なことに気がついた。自慢の製造装置から作られた品目は、いったん中間部品として在庫されるのだが、その倉庫がレイアウト上、いやに遠い所にあるのだ。なぜあんな、中途半端な位置にあるのか。いったんそこまで運んで保管し、また取り出して加工工程まで運ぶ。移動時間としては数分程度だろうから、コスト換算ではたいしたことがないが、なんだか無駄ではないか。なぜ、そんな半端な場所に倉庫があるのか? たずねてみたが、「さあ・・前からあそこにありましたから」という答えが返ってくるだけだった。

工場をよく見ていると、うっすらとその事情が推測できた。おそらく、昔はその製造装置自体が、工場全体のボトルネックだったのだ。製造は難しく、不良も発生しがちだった。そして、できた中間品目はすぐに加工工程に送られたに違いない。だから中間在庫はほとんど発生しなかったのだ。しかし、技術力が上がるに従い、装置の製造能力も上がった。不良も減った。

他方、形態の多品目化や、顧客の短納期要求のために、加工・出荷工程の方が小ロット化した。そのために、いったん中間在庫の取り置きが必要になってきたのだろう。だが、工場を作ったときは、そういう発想がなかった。だから、スペースの空いた端っこに中間倉庫を置くしかなかったのではないか。

工場全体をよく見ると、自慢の製造装置より、加工・出荷工程の方が稼働率が高い感じだ。つまりボトルネックが移動したのであろう。だとしたら、ボトルネックに合わせて、中間在庫の量を見ながら製造装置を動かすべきである。そうしないと作りすぎで在庫の山ができてしまう。しかし、肝心の中間倉庫が遠くの場所にあるから、その無駄が見えにくくなっているのだ。

むろん、これは推測に過ぎない。本当ならば工程別の稼働率や在庫変動を調べて検証すべきだろう。だが、そのときは別にコンサルとして呼ばれた訳ではなかった。だから、推測があたっていたかどうかは分からない。とはいえ、そんな変な場所に中間在庫があったら、何かシステム全体に非効率が隠れているとみて、間違いはない。

本人達は一所懸命に働いているのに、端から見ると非効率なことが、よくあるものだ。日本の産業の生産性が欧米に比べて低いことは、つとに問題になっている。よくサービス業がやり玉に上げられるが、製造業だって決して威張れたものではない。では、なぜ、そうした非効率が放置されがちなのか。わたしは以前は、主に分業病のためだと考えていた。つまり、部門単位に仕事がサイロ化されていて、システム全体を見て気づく人がいないため、という理由である。気づきが足りないから、改善されないのだ、と。最初の例などは、まさにその典型だ。これはまあ、経営層の人間が怠慢だ、ということもできる。

しかし最近は、もう一つ別の障害もあるのではないかと、考えるようになった。それは、実務層に起因する問題である。実務層が無能だから、ではない。逆だ。実務層が勤勉で真面目すぎるから、仕事のシステムが多少おかしくても、一所懸命にカバーして動かしてしまう。その結果、かえって問題が隠れて見えなくなってしまうのだ。ボトルネックが下流工程にうつって、中間在庫が沢山発生するようになっても、空きスペースに倉庫の棚を作ったり、搬送のパレットを集めたりして、仕事を回してしまう。

仕事が今ちゃんと動いているんだから、いいじゃないか。どこの現場も、ギリギリまで人減らしが進んでいるから、他のことなんか落ち着いて考えている暇もない。そのことが、本当の問題を隠してしまうのである。

図を見てほしい。業務改善とは、今ある姿(現状業務)から、新しい業務の姿(改善後の業務)に、変えていくことだ。改善後の姿は、現在よりもパフォーマンスが高い。図の縦軸はパフォーマンスである。ただし、改善のためには、時間や、労力や、コストがかかる。また、現状動いている業務を変える訳だから、リスクもありそうだ。横軸は、そうした現状からの変化のためのコスト・リスクである。
e0058447_23012731.jpg
現状から新しい姿にうつるための改善の経路は、いくつか考えられる。コンサルタントだったら、ゴールのイメージを示すのみで、途中の経路は関知しないかもしれない。それが点線で描いたルートXである。だが現実は、こんな直線的に行きはしない。

では、Aのようなルートは可能か。先にパフォーマンスの成果が上がって、それから変化の労力を費やす。だが、こんなルートは現実にはあり得ない。なぜなら、何も変化しないうちにパフォーマンスが上がるはずはないし、第一、仮にそれが可能だったら、その先わざわざコストを費やして図の右に移動する必要はないからだ。つまり、図で、<上→右>という経路はあり得ないのである。

であるから、ふつうはルートBのように、最初に変化のための労力を費やし、後でパフォーマンス上の効果が現れてくるはずである。つまり<右→上>という経路だ。じつは、これは心理的に困難な経路だ。だって、何も成果は上がらないのに、仕事のやり方だけは変わり、やりにくくなるからである。「いつかそのうちにパフォーマンスが上がるから」と説明されても、ついて行ける人ばかりではない。

まして、実際に一番多いのは、ルートCのように、業務のやり方を変えたために、いったんパフォーマンスが下がってしまうパターンである。その後、皆が新業務になれて、システムが落ち着いたら、きっと成果は上がるだろう。だが、こういう話を聞いたら、皆は何というだろうか。「なぜ、自分がそんなリスクを背負わなければいけないの? 現に今、仕事は一応動いているんだから、何も変える必要はないじゃないか!」 とくに、やり方を変える部署と効果の出る部署が異なる場合、抵抗は大きい。設計側で属性データをCADに入力すれば製造側システムで活用できる、みたいな例はよくあるが、そうした「フロントローディング」に対して、設計部門がこころよく協力するとは限らない。

だって現に今、動いているんだからいいじゃないか? これが、多くの組織で改善をはばむ最大の心理的障害なのだ。たとえ出来のわるい業務の仕組みでも、現場の人たちが真面目で優秀だと、なんとかだましだまし動かしてしまう。もしかしたら効率は低いのかもしれない。だが、現に今、動いているんだ。何の文句があるんだ? それを変える時間などないほど、忙しいんだし。

これはちょうど、よくある「木こりジレンマ」のたとえ話と同じである。ある日、旅人が森の中で木こりに出会う。木こりは必死に木を切り倒しているが、その斧は錆びついて刃こぼれがしている。そこで旅人が、「斧を研いだらどうですか?」というと、木こりが「俺は毎日必死に働いているんだ。斧を研ぐ暇なんて無い!」と怒鳴る、という話だ。少し手を止めて、道具を改善すれば、ずっと効率は良くなる。だが、「少し手を止める」ことで仕事量がいったん下がるのを怖れて、木こりは無駄な苦労を重ね続けるのだ。

現代の組織はご丁寧なことに、『時間管理』と称して、日々の作業の稼働率まで監視したがる。稼働率低下への恐怖心は大きい。それが個人の業績評定にまで結びついたりする。稼働率が下がれば、人減らしも始まる。そうなればますます、手を止めて斧を研ぐことへの抵抗が高まるだけだ。そのくせ管理職は、なぜウチの組織は生産性が低いのだろう、なぜ皆、改善がヘタなのだろう、などとなげいたりする。挙げ句の果ては、Karoushiなどという不名誉な言葉が英語の辞書に載ったりする。

必要なことは、「システムの不備」を現場の頑張りでカバーすることではないのだ。不備を見つける視点を持つことである。そしてもう一つ。大事なのは、目の前の仕事を懸命に支えることではない。いったん仕事の手を止めてでも、あるべき姿を考えて、問題解決に向かう勇気を持つことなのである。

by Tomoichi_Sato | 2016-11-13 23:09 | ビジネス | Comments(0)
<< パフォーマンス問題へのシステム... アカウンタビリティとは「命令責... >>