はじめに
仕事を工夫して、これまで一時間かかっていた作業を30分で終わらせられるようになった。
表計算を整理した。
定型文を作った。
前月のデータを使えるようにした。
AIで文章や資料の下書きを作るようにした。
こうした改善によって、確かに仕事は早くなる。
ところが、早く終わったところへ、
「手が空いたなら、これもお願い」
と次の仕事が入ってくることがある。
会社全体で処理できる仕事が増えること自体は、悪いことではない。
むしろ、それは業務改善の成果とも言える。
しかし、
改善する。
早く終わる。
次の仕事が増える。
また改善する。
さらに仕事が増える。
という経験が何度も続いたとき、それでも人は次の改善を続けるだろうか。
今回は、
効率化できるかどうかではなく、効率化が続く状態になっているか
というところから考えてみたい。
早く終わった人へ次の仕事を渡すこと自体が問題なのではない
例えば、毎月一時間かかっていた請求処理が30分になったとする。
残りの30分で別の仕事ができれば、会社全体では処理できる量が増える。
顧客対応へ時間を回すこともできる。
確認を丁寧にすることもできる。
新しい仕事へ着手することもできる。
その意味では、
「効率化した結果、別の仕事が増えた」
というだけで、改善が失敗したとは言えない。
会社が発展して仕事が増えるなら、それも自然なことだろう。
ただし、そこで一つ確認しておきたいことがある。
効率化した結果として仕事が増えたとき、
その変化は、効率化した人からどう見えているだろうか。
仕事が増えたことで評価が変わったのか。
給与や賞与へ反映されたのか。
裁量が増えたのか。
単純作業から離れられたのか。
新しい仕事へ挑戦できるようになったのか。
あるいは、
仕事量だけが増えたのか。
確認対象だけが増えたのか。
責任だけが広がったのか。
同じ「効率化」でも、その後に何が起きたかによって、現場から見える景色はかなり違う。
「のんびり仕事をする」のは、いつも意欲の問題なのか
仕事を早くできる人が、いつも最大速度で仕事をしているとは限らない。
それを見ると、
「もっと効率よくやればいいのに」
と思うこともある。
もちろん、人による違いはある。
新しい方法を試したい人もいれば、今のやり方を安定して続けたい人もいる。
仕事への関心や、発展を望む度合いも同じではない。
ただ、それだけでは説明できない場合もある。
過去に、
早く終わらせる。
すると仕事が追加される。
さらに早く終わらせる。
さらに仕事が追加される。
という経験が何度も続いていたらどうだろう。
その職場では、速く終わらせることによって、自分の仕事が軽くなるとは限らない。
むしろ、
「早く終わらせると、その分だけ次の仕事が増える」
という経験が残る。
そうなると、仕事を早くできる能力があっても、それを常に表へ出す理由は弱くなる。
急いで終わらせない。
自分だけの工夫に留める。
作ったテンプレートを共有しない。
AIで短縮できても、大きく処理速度を変えない。
改善案をわざわざ提案しない。
あるいは、改善そのものが個人の中に閉じ、職場へ共有されにくくなることもある。
これらをすべて、
「やる気がない」
と説明してしまうと、見えなくなるものがある。
その人自身だけではなく、
改善したときに、仕事の割り振りや評価がどう変わる職場なのか
も見た方がよい。
人は仕事だけでなく、仕事の結果も覚えていく
給与計算も、請求も、会計も、一度で終わる仕事ではない。
毎月繰り返される。
同じように、業務改善も一回で終わるとは限らない。
一度改善する。
その結果を経験する。
また改善する。
その繰り返しの中で、現場には経験が残っていく。
例えば、
改善する。
作業時間が短くなる。
追加の仕事が入る。
という流れが毎回続けば、
改善すると仕事が増える
という経験が残る。
反対に、
改善する。
単純作業が減る。
確認する時間が取れる。
新しいことへ挑戦できる。
工夫したことが共有される。
という経験が続けば、改善そのものへの見え方も変わる。
つまり業務改善では、
今回何分短縮できたかだけでなく、その改善が次の改善へどんな経験を残したか
も長期的には重要になる。
効率化できる会社と、効率化が続く会社は、少し違うのかもしれない。
システム化に成功しても、現場では失敗に見えることがある
この違いは、AIやシステム導入でも起こる。
例えば、一日8時間かかっていた仕事が、自動化によって4時間で処理できるようになったとする。
技術的には大きな成功である。
以前の半分の時間で同じ処理が終わっている。
ところが、残り4時間に別の仕事が入り、一日の仕事量が再び8時間になったらどうだろう。
さらに、
担当案件が増える。
確認するものが増える。
AIが作った内容を確認する。
例外への対応が増える。
責任範囲が広がる。
という変化まで加われば、担当者から見ると以前より仕事が複雑になっている場合もある。
その結果、
「AIを入れたのに楽にならなかった」
「システム化したのに、むしろ忙しくなった」
という感想が出ることもある。
ここでは一度、問題を分けてみたい。
処理時間を短くするという技術的な改善は成功したのか。
そこで生まれた時間を、会社は何へ使ったのか。
増えた仕事や責任を、誰が引き受けたのか。
その変化は現場へどう返ったのか。
これは、それぞれ別の問題である。
技術的には成功していても、その後の運用によって現場の負担が増えることはある。
反対に、現場で負担が増えたからといって、システムやAIそのものが失敗していたとは限らない。
この区別をしないと、本来は改善後の運用にあった問題まで、
「システム化は失敗だった」
「AIは役に立たなかった」
という一つの評価へまとめられてしまう。
効率化で生まれたものは、どこへ流れたのか
効率化した人へ何を返すべきか、と考えると、給与や賞与の話が浮かぶ。
もちろん、それも重要である。
ただし、効率化によって現場へ返せるものは金銭だけではない。
単純作業が減る。
裁量が増える。
担当する仕事を整理できる。
新しい仕事へ挑戦できる。
休みを取りやすくなる。
突然の問い合わせへ対応する時間を残せる。
判断や確認に時間を使える。
こうした変化もある。
実際、AIで短縮された情報処理の時間を、住民説明など別の対人業務へ再配分する運用も観測されている。
一方で、
効率化によって会社全体の処理能力は増えた。
しかし担当者には、
追加の仕事、
追加の確認、
追加の責任
だけが戻ってきた。
という状態もあり得る。
どちらが正しいという単純な話ではない。
会社には会社の事情がある。
仕事が増えている時期なら、その処理を誰かが引き受ける必要もある。
ただ、
効率化によって生まれた利益と負担が、毎回同じ方向にだけ流れていないか
は見ておいてよい。
なぜなら、その流れ自体が、次の改善が生まれる条件になっているからである。
改善を求めるなら、改善後の仕事の割り振りも見る
業務改善というと、
どうすれば作業を減らせるか。
どうすれば自動化できるか。
どのAIを使えばよいか。
どのシステムを入れればよいか。
というところへ関心が向きやすい。
もちろん、それらは必要である。
しかし、長く改善を続けるなら、
改善したあと、仕事の割り振りや責任がどう変わったか
も同じくらい重要ととらえる必要がある。
毎回、
「早くできるなら、もっとやって」
だけが返る職場と、
「早くできるようになったから、次はどこへ時間を使おうか」
と確認できる職場では、同じ効率化でも次に生まれる行動は変わる。
これは、社員を甘やかすという話でもない。
仕事を増やしてはいけないという話でもない。
改善によって仕事の条件が変わったなら、その変化をもう一度、仕事の仕組みとして扱うということである。
GIMCALCが支えられるところと、支えられないところ
GIMCALCが支えるのは、給与計算や請求処理など、毎月繰り返される仕事の摩擦を減らし、次回も同じ仕事へ戻りやすくするところまでである。
前月のデータを利用する。
同じ入力を必要以上に繰り返さない。
過去の状態へ戻れるようにする。
制度が変わっても、毎月の業務全体をできるだけ壊さずに続ける。
そうした仕組みによって、仕事に必要な時間が短くなる場合はある。
しかし、
そこで生まれた時間を何に使うのか。
誰にどの仕事を渡すのか。
評価や待遇をどうするのか。
どの程度の余力を残すのか。
そこまでを製品が決めることはできない。
それは、それぞれの会社が判断する領域である。
だからGIMCALCが実装できるのは、
仕事を速くすることそのものより、毎月の仕事へ戻りやすい条件を整えること
である。
そして、その結果生まれた変化をどう扱うかは、現場と組織の側に残る。
この境界を分けておけば、
システムの成果と、
その後の運用の成果を、
少し冷静に見分けやすくなる。
次の改善が生まれる会社であるために
仕事を早く終わらせると、次の仕事が増える。
それ自体は、会社が動いている以上、自然なことでもある。
ただし、
改善する。
仕事が増える。
また改善する。
さらに仕事が増える。
という経験が繰り返されれば、人は改善する能力を失うのではなく、
改善が共有されにくくなったり、その能力が表へ出にくくなったりする。
もし会社が改善を続けたいなら、今回何時間短縮できたかだけでなく、その改善によって生まれた利益と負担が、
その後どこへ流れたのか
も見ておきたい。
そして、その改善を経験した現場に、次の改善がもう一度生まれる条件が残っているか。
そこまでを含めて考える。
仕事を速くする仕組みを作ることと、改善が続く状態を作ることは、同じではない。
改善は、一度の時間短縮では完了しない。
改善後に生じた仕事・責任・利益の配置が、次の改善をもう一度可能にするか。
そこまで含めて、業務設計なのだと思う。