Solution

効率化を求めないために

＄引用＄

＄引用元＄
TOP > Solution > 効率化を求めないために

概要

トム・デマルコ氏の講演を聴きに行き、効率化によってゆとりがなくなり、自由で新しい発想が阻害されることを改めて感じた。他の企業との競争に打ち勝つためには、効率化を行い、人員を削減し、作業期間を短縮することによって短期納入と投資額の減少を求めようとする。
〈効率化〉により、私達（あるいは私自身）は何を求めているのか、また、〈効率化〉により、将来的に
何を得る（あるいは失う）ことになるのか、を再考する。

内容

まず、企業（あるいは個人）が効率化によって求める事柄を列記する。
「効率化することによって、何がよくなるのか？」


図 1 効率化することによって、何を望むのか？

単純作業を、自動化して〈効率化〉する。
→　ハンドアセンブルからコンパイラを使ってコンパイルする
→　ユニットテストのチェックをテストフレームワークを使って自動化する
→　ページのノンブル打ちを、手作業からワープロのページ機能を使って印刷する
煩雑な作業を、自動化して〈効率化〉する。
→　住民票の取り出しを、帳簿からデータベースにして、どこでも印刷できるようにする
→　複雑なパズルを、プログラムを組み上げてたくさんの解を見つけ出す
間違いを減らすために、自動化して〈効率化〉する。
→　住所の宛名を見て判断すると間違いが多いので、郵便番号をみて自動で振り分ける
→　センター試験の答えをチェックするために、マークシートを使って自動化する

この場合、「自動化する」＝「効率化」を意味している。
「自動化する」ためには、ソフトウェアの開発が必要であるために、いわゆるIT業界は、IT化するメリットとして「自動化する」ことによる〈効率化〉を売りにしている。
単純作業、煩雑な作業からの解放や、自動化することによって間違い正す作業がなくなることは、かつての非効率的な作業から比べると、作業時間が減ることになる。


図 2 〈効率化〉することによって、あまった時間ができた



図 3 レッドドワーフ号の乗組員は80%の力で仕事をこなしていた



図 4 ある日、効率化ツールを導入したら、60%の力で仕事をこなせるようになった



図 5 経費削減のため、リマーを解雇してしまおう！



図 6 リマーを解雇したために、前より忙しくなってしまったリスター達…

最初、リスター達は４人で作業をしている。作業率は80%で、そこそこ忙しい気分だ。
そこに、「効率化ツール」を導入して、「もっと〈効率化〉しましょう！」ということになった。
リスター達４人は、効率化ツールの導入によって、作業率が80%から60%になった。つまり20%の効率アップができたのである。
そこで、リスターは考えた。「効率化ツールを導入して、経費がかかっている。今、60%になって、そこそこ暇になった。このあまった時間はどう使おう？どうすれば、効果がでるかな？」
そして、思いついた「そうだ！リマーを解雇してしまおう。リマー担当分の仕事は、俺たち3人で分担すればなんとかなる。そうすれば、1人分の人員削減になって、万々歳だ！」
というわけで、リマーを解雇して、リマーの仕事を3人で分担することにした。
すると、作業率は、93%にアップしてしまった。
キャットは叫ぶ。「何故なんだ？　効率化ツールを入れたけど、前より忙しくなっているよ！」

こんな風に、〈効率化〉をすることによって、それぞれの作業時間は減るのだが、そのあまった時間を人員削減に利用すると、逆に忙しくなってしまう。〈効率化〉による余剰時間の使い方を誤ると、かえって忙しい状況になってしまう。


図 7 余剰時間を別の仕事に当てると、かえって忙しくなる

効率化前は、全体の作業時間（勤務時間）のうちの80%を使っていたとする。あとの20%は何をしているかというと、次の仕事が回ってくるのを待っている状態である。この普通、この20%の暇な時間はあまり目には見えない。タバコを吸いに行ったり、雑談をしたり、インターネットを眺めたりして、余剰の時間をすごしている。管理者側から見れば、遊んでいるように見えるかもしれない。しかし、20%の仕事を詰め込んだところで何ができるだろうか。せいぜい、機械的な処理をちょっとだけさせて働かせるに過ぎない（そういう管理者もいるかもしれないが…）。
そこで、管理者は、もっと〈効率化〉をして、あまった時間を多くしようと考える。あまった時間は、他の仕事をさせることにする。効率化ツールを導入すると、いままで80%だった作業量が、60%になったとしよう。すると、余剰時間は、20%から40%にアップする。作業量は25%減少している。これに対して、余剰時間は100%増加している。つまり、いままで雑談をしていた時間が、2倍に増えるのである。たとえば、１日のうちで、８時間働いているとして、効率化前には1時間半を雑用に費やしていたとすると、効率化後には３時間も雑用に費やさなければならない。おそらく、管理者あるいは経営者にとって、以前よりも倍の時間、遊んでいる社員を見つけるのはたやすいだろう。
勤務時間が８時間のうち、１時間半ぐらいは、メールを読んだり、雑談をしたり、インターネットを見て最新情報を紐解いてみたりしているだろう。たぶん、効率化が進んだからといて、３時間もメールを読んだり雑談をしたりするのは無理だと思う。社員にとっても、なにか暇な時間が増えたことによって、不安になってしまうはずだ。
よって、管理者（経営者）とスタッフ（社員）との合意の上で、仕事を上積みしていしまう。管理者（経営者）は効率化ツールの効果をアップするために、スタッフ（社員）にとっては、暇であることがわからないように、忙しくするために仕事をする。
新しく請け負った仕事は、本当に効率化された20%だけの仕事になるだろうか。社員は、１日の20%を雑談に費やすことができるだろうか。おそらく、効率化以前の20%のような短い時間では、まとまった仕事はできないが、１日のうち40%もの時間があれば、それなりに仕事がこなせてしまう。よって、新しく請け負った仕事は、社員の余剰時間を食いつぶし、いままでメールを読んだり、雑談をしたり、今後のために技術を学んだりしていた時間を奪い取ってしまう。そして、社員は効率化以前よりも忙しくなってしまう。


図 8 余剰時間を次の仕事のためのスキルアップに使う



図 9 スキルいっぱいに仕事を請け負うと

おそらく、このグラフに異論があると思う。熟練者と呼ばれる人たちは、作業を幾度と繰り返すことによって作業効率をアップする。たとえば、新米の銀行員が電卓を打つ速度と、勤続ン十年の銀行員とでは、電卓を打つスピードはずいぶん異なるし、ミスの数も違うだろう。このときに、熟練した銀行員は特に電卓を打つ練習をしてきたわけではない。日常的な作業をするうちに自然と電卓を打つ速度が早くなったに違いない。しかし、よく考えてほしい。勤続ン十年の銀行員が電卓をら早く打つことができても、それで仕事は終わりだろうか？勤続ン十年ならば、それなりに責任のある地位に付き、後輩の指導にあたり、営業ができるような銀行員にならなければいけない。
同様なことは、プログラマにも言える。COBOLプログラマがVBやC言語を勉強せざるを得なかったように、C言語のプログラマがJavaを学ばなければならなかったように、IT業界では実に変化に富んだ知識や技術が必要になる。ひとつの仕事（プロジェクト）に熟達し、洗練されれば洗練されてしまうほど、ひとつの仕事に縛り付けられてしまうものだ。変化が多い仕事ほど、次のステップに進むための余剰時間は多くとる必要がある。企業が、ひとりのプログラマを使い潰そうとするのならば、ひとつの仕事にべったりとくっ付けるとよい。かのプログラマの最大の効率で最大の作業量を引き出し、その後、仕事（プロジェクト）が終われば用済みにすればよいわけだ。しかし、企業は新人教育を経て、ある年数をこなし、社の機微がわかっている従業員に対して、どちらが得なのかをもう一度考えるべきだろう。また、社員はひとりのプログラマとして、どのように余剰時間を使い、どのような比率で実作業とスキルアップのための時間とを振り分けていくのかを、考え直さなければならないだろう。

主にどのように作業を効率化させているのだろうか？

そうして、効率化した後に何をするのだろうか？

効率化することにより、何を失うか？

何故、効率を上げようとするのか？

おそらく、「効率化」という言葉には、社会学的な幻想がある、と思われる。
「ザ・ゴール２」にもあるが、いままでは、「仕事をしていない人がいる　→　時給を捨てている　→　製品単価が高くなる」という間違った発想があり、「時給×作業時間＝製品単価＝資産」という計算に幻想がある。生産された製品は、顧客に売られ金銭としてフィードバックされるまで、資産とはみなせない。よって、時を経ることによって古くなり資産価値を失う場合には「製品単価×時間による減価＝資産」と考えられる。
仕事をしていない期間に、無理矢理、作業をこなすことによって製品を生み出したとしても、適切なフィードバックがなければ、「時給を捨てている」ことと変わらない。

では、ソフトウェア開発の場では、効率化を行い、その間にした作業は時を経ることによって資産価値を失うものなのか？
短期納入が目的の場合には、効率化によりあまった時間は、次の仕事にまわされることになる。
つまり、短期納入が続く　→　需要が多い状態、あるいは、短期で小さい仕事をたくさんこなすことでしか、目標金額を達成できない、という理由がある。
copyleft by masuda.t