仕事を改善しようとするとき、多くの場合は「編集」から始まります。
値を変える
式を修正する
操作を短縮する
自動化で代行させる
これらは確かに効果がありますが、本来はもっと後の工程です。
現場で先に必要になるのは設計です。
編集では解決しない例
先日、請求処理に関する自動化の相談がありました。
業務仕様では
決済日から営業日2日後に処理する
という決まりがありました。
ここまでは問題ありません。
ところが自動化を作る段階になったとき、この「営業日2日後」が
基準日＋2日
として扱われていました。
自動化としては自然な考え方です。
しかし業務では一致しません。
営業日と日付加算は一致しません。
週末や祝日をまたいだ瞬間に、結果がずれます。
実際にその自動化は止まり、確認のために人が介入しました。
このときに困っていたのは技術ではなく、仕様でした。
編集より前に必要なこと
このケースで本当に必要だったのは、次のような設計です。
・「営業日」をどの範囲で定義するか
・休業日と祝日をどう扱うか
・基準日は何か
・どこで切り替えるか
・誰が決めるか
これらが決まらない状態で編集を行っても、自動化も改善も安定しません。
設計は、編集より前に行うものです。
編集は設計の後に軽くなる
編集とは、すでに設計されたものに手を入れる行為です。
逆に言えば、設計がない状態で編集を始めると、次の現象が起きます。
・例外処理が増える
・自動化が止まる
・人が介入する
・仕様が人に依存する
・周辺の運用で吸収する
技術ではなく、設計が未確定なだけです。
設計が決まった瞬間に、編集も自動化も急に軽くなります。
技術ではなく構造の話
現場ではよく
「もっと強く作れないか」
「例外に耐えられないか」
といった言葉が出ますが、例外処理が増えるのは技術不足ではありません。
構造が未確定なだけです。
ここを押さえておくと、改善は無理なく進みます。
まとめ
改善は編集ではなく設計から始まります。
設計が決まると編集が軽くなり、編集が軽くなると自動化が安定します。
業務改善や自動化がうまく定着しない理由は、技術ではなく前段の設計によるものが多いです。
もし職場で
・編集を繰り返しているのに落ち着かない
・自動化が止まる
・例外処理が増え続ける
・業務仕様が人に依存している
といった状況があれば、一度“設計”から見直すことで改善します。
前段設計や用途整理など、技術ではなく構造の部分を扱っています。
詳細はこちらからどうぞ。
