本文へスキップ
自動化

自動化の前に、まず工程を削る

HushOperator 編集部 2026.06.03 4分で読めます
自動化の前に、まず工程を削る

TL;DR

  • 自動化を考える前に「その工程をやめられないか」を先に問うと、残るコストが変わる。
  • 「置き換える」と「やめる」は別の作業で、後者のほうが保守の手間が小さい。
  • 工程の棚卸しを先にすると、自動化すべき対象が自然に絞り込まれる。
  • ひとり運用では、増やした仕組みほど壊れたときの負担も大きくなる。

同じ業種で独立した二人の事業者を思い浮かべてほしい。片方は請求書の作成、入金の確認、顧客へのリマインド送信を、見つけられる限りのツールでつないだ。もう片方は、そもそも送っていたリマインドの半分をやめ、入金確認の頻度を週次に落とし、残った工程だけを小さな仕組みに移した。半年後、手が止まりにくかったのは後者だった。理由は単純で、動く部品が少なかったからである。

自動化の話になると、私たちはすぐ「どう速くするか」を考える。けれど、ひとりや少人数で続く運用にとって、速さよりも先に効く問いがある。「この工程は、本当に必要か」だ。

「置き換える」と「やめる」は違う

ある作業をスクリプトやツールに置き換えると、その作業は消えたように見える。しかし実際には、設定・監視・更新という新しい作業が増えている。置き換えは仕事の総量をゼロにはせず、形を変えて残す。一方、工程そのものをやめれば、後続の保守も発生しない。

中小企業庁の『中小企業白書』は、人手不足を背景に小規模事業者でのIT活用が課題になっていることを継続して指摘している。ただ、そこで語られるのは「導入すれば解決する」という話ではなく、業務の見直しと組み合わせて初めて効果が出るという文脈である。導入の前段にある業務整理が抜けると、ツールだけが増えていく。

棚卸しが先に来る理由

私が最初に自動化で失敗したときは、毎朝15分かけていた集計をマクロに移して満足していた。ところが三か月後、参照元の表の列が一つ増えただけでマクロが止まり、原因を探すのに40分かかった。15分の作業を消すために、稀に発生する40分の作業を抱え込んでいたことになる。

このとき足りなかったのは、工程の棚卸しだった。手作業の流れを一度すべて書き出し、頻度と所要時間を測る。すると「毎日やっているが、誰も見ていない集計」のような工程が見つかる。見られていない出力は、速くするのではなく止めるのが筋だ。自動化が壊れた日のための備えでも触れるが、止められる工程を先に止めておくほど、後で守る対象は減る。

自動化が向くのはどこか

棚卸しのあとに残る工程のうち、自動化が向くのは「頻度が高く」「手順が決まっていて」「失敗してもすぐ気づける」ものだ。逆に、判断が必要だったり、月に一度しか起きなかったりする工程は、自動化の費用対効果が低い。月一回の作業を仕組みにしても、仕組みの存在自体を忘れた頃に壊れている。

ジェイソン・フリードとデイヴィッド・ハイネマイヤー・ハンソンは著書『It Doesn’t Have to Be Crazy at Work』で、忙しさそのものを成果と取り違える働き方に繰り返し疑問を投げかけている。彼らの主張を運用に引き寄せれば、仕組みを足すことではなく、足さずに済む状態を保つことが、結果として静けさを生む。

もっとも、すべてを削れるわけではない。削れない工程は確かにあり、そこにこそ自動化の価値がある。要は順番の問題だ。最小化してから残りを仕組みに移すか、すべてを仕組みに移してから困るか。ひとり運用では、壊れたときに代わってくれる人がいない。だからこそ、自動化の前に立ち止まって工程を減らす一手間が、長く効いてくる。道具立て全体をどう絞るかはひとり運用の道具立てを最小にするでも続けて考えたい。

出典

  • 中小企業庁『中小企業白書』(人手不足と中小企業のIT・デジタル活用に関する記述)
  • 情報処理推進機構(IPA)『DX白書』(業務見直しとデジタル活用の関係)
  • Jason Fried, David Heinemeier Hansson『It Doesn’t Have to Be Crazy at Work』(2018)

関連する記事

更新のお知らせ

新着記事を、静かに、まとめてお届けします。