バッチは小さく
バッチとはバッチ処理のバッチですが、ここでそのバッチ処理をするリソースはエンジニア自身の作業を対象に取り上げます。
そういえばバッチはもともとどのような意味があったっけ、と思って辞書を引いてみると
《名詞》(1)一束，一組；一団，群れ (2)（パン・陶器の）一焼き，一焼き分 (3)【コンピュータ】バッチ
（3）にコンピュータとあるのでこの意味で良いですね。さてコンピュータ用語の意味としてはどの意味を指しているかといえばやはり（1）でしょう。ある塊をバッチと呼ぶわけです。
ではバッチ処理というとある塊を処理する、という意味に変わります。もちろん、コンピュータですからデータを処理するのが機能ですから、データの塊を処理する機能がバッチ処理になるのです。
ではエンジニアはバッチ処理をするかといえば、人の所作を観察することでわかります。作業をアサインされ、情報を集め作業を行い成果を出すのでエンジニアの作業もIPO（input/process/output）になっているので人も作業をするのはバッチ処理をしているということができます。
バッチサイズ
事務処理系、例えば管理会計の集計処理などに限らず、バッチ処理は業務要件から制約を受け、業務で求められるタイムスパンで処理を求められます。
処理には日次、週次、月次などの処理の単位があり、要件によりどのスパンで処理をするかを洗濯します。
こんなバッチ処理はいやだ
もし日次処理、週次処理を行わずいきなり月次処理だけするとしたら何が起きるでしょう。
考えられることはデータ量がわからないといつ終わるかわかりません。
さらに、月次処理の最後にデータの不整合が発生したら今やっていた月次処理はデータの不具合の扱いを決めてから、最初からやり直しです。
だから、そうした工夫として日時や週次で小さい時間で処理を済ませておいて、扱いたい集計の単位で括り直すことで小さな時間で処理を確実に完了させるのです。
エンジニアは仕事のバッチサイズを考えているの？
エンジニアが仕事の対象としての処理設計では上の図のように処理の単位を小さく分けて処理する工夫をするのに、エンジニア自身は仕事を小さく分けて作業をしているでしょうか。
日次の単位で作業をせずに月次の単位で作業をしていないでしょうか。もしかすると作業計画自体の単位が大きすぎるのかもしれません。
作業自体のサイズが大きすぎると赤い×印のように終わる直前になって×がわかることになるのです。
でも、×とわかってからでは遅いですよね。それまで掛けた時間、コストは戻ってきませんから。
事務処理のバッチ処理を小さな括りで処理するように、エンジニアの仕事も小さくして、小さいサイズで処理をして結果を検証して、次に進めたほうが確実時に終わりますし、途中で×が出たとしても、それまでの処理結果はパーになることはありません。
×になった処理の入力を整えるか、×になった処理をピボットして別の処理に置き換えて進めれば、それまで終わっている小さな作業が無駄になったりしないのです。
エンジニアのバッチ作業も小さくしましょう。
