効率化の前に、「やめる理由」を一行で決める

「効率化しましょう」と言うと、会議の空気は前向きになります。誰も反対しにくい言葉です。けれど現場で起きるのは、効率化の名目で入力欄が増え、確認表が増え、チャット通知が増えることです。速くするために始めたはずなのに、前より細かく管理される。これは珍しい話ではありません。

効率化が失敗する理由のひとつは、やめる仕事を決めないまま、速くする方法だけを足すことです。足す改善は説明しやすいです。新しいツール、新しいフォーム、新しいチェックリスト。どれも「やっています」と言いやすい。一方で、やめる改善は少し怖いです。なぜやめるのか。誰が困らないのか。何を見なくてもよくなるのか。そこを言葉にしないと、現場は不安になります。

tugiloでは、効率化の相談を受けたとき、最初に「何を導入するか」よりも「何をやめられそうか」を聞くことがあります。さらに言えば、やめる対象そのものより、やめる理由が一行で言えるかを見ます。理由が弱いまま削ると、しばらくして戻ります。戻るときは、たいてい「念のため」という顔をして戻ってきます。

速くするだけでは、仕事は減らない

たとえば、日報を早く書けるテンプレートを作ったとします。入力時間は短くなるかもしれません。でも、その日報を誰が読んでいるのか、読んだあと何が変わるのかが曖昧なら、仕事は減っていません。書く時間が短くなっただけで、書く理由の確認は残ったままです。

同じことは、見積、問い合わせ、会議メモ、営業報告にも起きます。作業を速くすることは大切です。ただ、速くなった作業が本当に必要かを問わないままだと、現場は「速く無駄をこなす」状態になります。本人は忙しい。管理側は効率化したつもりになる。数字だけ見ると改善したように見える。でも、仕事の総量はあまり減っていない。

「とりあえず手入力」をやめるだけで、会社は軽くなるでも触れているように、軽くなる瞬間は「入力を速くする」より「入力しなくていいものを決める」ときに来ることがあります。効率化の入口を間違えると、軽くするつもりが、仕事を細かく刻むだけになりやすいです。

「やめる」は、否定ではなく設計です

やめる話をすると、現場から「今までの仕事が無駄だったと言われている気がする」という反応が出ることがあります。これは自然です。誰かが続けてきた作業には、たいてい理由があります。昔は必要だった。ある事故を防いだ。上司に求められた。顧客から言われた。始まりには背景があります。

だから、やめるときに必要なのは、過去を否定することではありません。今も同じ形で必要かを確認することです。始めた理由と、続ける理由は違います。始めた理由が正しくても、続ける理由が薄くなっている仕事はあります。

ここを雑に扱うと、やめる話は対立になります。「いる」「いらない」の言い合いになる。そうではなく、「今この作業は何を守っているのか」「別の形で守れるのか」「守らなくてもよくなったのか」を分ける。分けられると、やめるは感情ではなく設計になります。

一行にすると、戻りにくくなる

やめる仕事を決めるとき、議事録に「廃止」とだけ書くと弱いです。数週間後に誰かが不安になったとき、理由が思い出せません。理由が思い出せないと、廃止したはずの作業は戻りやすいです。戻るときは大げさな復活ではありません。「念のため、今月だけ」「一応、ここにも書いておいてください」という形で戻ります。

だから、やめるときは一行で理由を残します。

「この確認表は、同じ内容を受注システムで確認できるため、月次の二重確認をやめる」

「この日報項目は、週次会議で使われていないため、次の1か月は入力対象から外す」

「この承認メールは、金額条件が満たされる場合のみ必要とし、それ以外はフォームの記録で代替する」

大事なのは、格好いい文章ではありません。何を守っていた仕事を、どの情報で代替するのかが分かることです。一行があると、戻すときにも理由を見直せます。戻すことが悪いのではなく、理由なしに戻ることが問題です。

効率化の前に、会議で聞く問い

効率化の会議では、「どうすれば早くできますか」と聞きがちです。この問いは悪くありません。ただ、最初の問いにするには少し早いことがあります。先に聞きたいのは、次の三つです。

一つ目は、この作業は誰の判断を助けているかです。誰の判断にも使われていないなら、作業は記録ではなく儀式に近づきます。二つ目は、同じ情報がどこかにないかです。別のシステムや帳票にあるなら、二重入力の可能性があります。三つ目は、やめたときに何が困るかです。困ることが具体的に言えないなら、作業の役割が薄れているかもしれません。

この三つを聞くと、現場から細かい話が出ます。「あの人がたまに見ている」「昔、抜け漏れがあった」「月末だけ必要」。その細かさが大切です。細かく分かるほど、全部廃止ではなく、条件付きで減らす道が見えます。

小さくやめる

やめると言うと、いきなり全面廃止を想像しがちです。でも、最初から大きくやめなくても構いません。むしろ、最初は小さくやめたほうが現場に合います。1か月だけ入力項目を減らす。1部署だけ確認回数を減らす。週次ではなく隔週にする。必要なら戻せる形で試す。

「小さく試す」を並べるほど、どれも深くならない理由と同じで、小さく試すこと自体が目的になると散らかります。けれど、やめる理由を一行で置いた小さな試行は違います。試す対象がはっきりしているから、振り返りやすいです。

「やめても困らなかった」だけで終わらせず、「何が困らなかったのか」「代わりに何を見たのか」を残す。ここまでできると、やめる経験は次の改善の材料になります。

現場で最初に見る三つの場所

やめる仕事を探すとき、いきなり全業務を棚卸ししようとすると止まります。量が多すぎるからです。最初は、現場で重くなりやすい三つの場所だけで構いません。

一つ目は、二重入力です。同じ顧客名、同じ金額、同じ日付を別の場所に入れているなら、やめる候補になります。二つ目は、読まれていない報告です。作成者は時間をかけているのに、読み手が次の判断に使っていないものです。三つ目は、念のための確認です。昔の事故をきっかけに残った確認が、今も同じ形で必要かを見る。

この三つは、現場で見つけやすいです。しかも、いきなり廃止しなくても、頻度を下げる、対象を絞る、条件付きにする、という小さな試し方ができます。

やめる理由は、責任を曖昧にしないためにある

やめる仕事を決めるときに理由を残すのは、説明のためだけではありません。責任を曖昧にしないためでもあります。理由がない廃止は、あとで問題が起きたときに「誰がやめると言ったのか」という話になりやすいです。理由がある廃止は、「何を前提にやめたのか」を見直せます。

たとえば、「月次確認をやめる」だけだと怖いです。でも、「受注システムのステータスで同じ確認ができるため、月次確認をやめる」なら、見直しの場所が分かります。もし問題が起きたら、受注システムのステータスが正しく使われていたかを見る。人を責める前に、前提を確認できます。

効率化の目的は、現場に我慢を求めることではありません。判断の場所を減らし、迷いを減らし、必要なところに時間を戻すことです。やめる理由の一行は、そのための小さな保険になります。

まとめ

効率化は、速くする話として始まりやすいです。けれど、現場の仕事を本当に軽くするには、速くする前にやめる理由を置く必要があります。理由があると、仕事は戻りにくくなります。戻るとしても、なぜ戻すのかを話せます。

やめることは、過去の否定ではありません。今の現場に合わせて、守るものと手放すものを分ける設計です。分けるためには、会議で大きなスローガンを掲げるより、まず一行で十分です。

もし今週、効率化の話が出るなら、最後に一つだけ聞いてみてください。これは何をやめるための改善ですか。その問いに答えられない改善は、もしかすると、仕事を減らす前に仕事を増やすかもしれません。