Contents
業務システムは、大別すればオンラインとバッチ
業務システムは昭和30年代後半にバッチ処理から始まり、昭和40年代中ごろからオンライン機能が拡張されだしました。
以来、業務システムの実装はこの２つに大別することが出来ます。
「オンラインバッチ」という形式もありますが、要は組合せ（オンラインからキックされるバッチ）なので、分けることが出来ます。
オンライン処理は、多くの開発者にとって楽しい領域のようです。
目に見えてモノが出来上がり、ユーザーの受けもよい。
一定の複雑さはあるけども、図画工作をするようなワクワク感があって、時間を忘れて没頭する人も少なくありません。
一方、バッチ処理は「見えない敵との戦い」といった側面を持っています。
特に業務知識がなければ、どんなデータがインプットになりうるのかが理解しきれず、設計書を書くのも大変です。
大変さを乗り越えればその努力が報われるという世界ではなく、多くの場合は設計漏れ（理解不足・知識不足）があり、後日の障害に繋がります。
当然ながら、バッチ処理も要件定義が必要
正しい処理設計をするためには、「ユーザー部門から正しい情報を貰うべき」と思いこんでいるＳＥは少なからずいますが、この考えでは失敗している場合が多いように思います。
一番多いのは、「ユーザーが初期に提示した資料が全てと判断し、ＳＥ自ら能動的に不足情報を取得しようとはしない」タイプですが、これは失敗すべくして失敗していると思います。（偶然の成功はある）
私の考えは、「ユーザー部門や世間一般から、自ら正しい情報を引出す」です。
バッチ処理の検討は、経験値が求められる
バッチ処理へのインプット形式が、正しく整理できたと仮定します。
これ以降は、システム実装の経験値とセンスがものをいう世界です。
いかに障害検知に優れ、不良データの特定が容易で、リランが可能な状態を維持できるか。
それでいて保守性（今後のシステム改修に対する吸収性）が高いか。
上記２行は、あるべき論としては簡単に書けますが、その実現は容易ではありません。
もう少し踏み込んで書くと、まずは処理前のバックアップ。
そして多様な源泉からデータを収集し、エラーチェック（オンラインとバッチで二段階）、クレンジングの上、ログや中間データを適切（多すぎても少なすぎても後で困る）に残しながら、処理を重ねるよう設計する。
処理結果が決算システムや外部システム（受発注システム、物流システム、自動倉庫）に連携する場合、あるいはユーザー部門の翌日業務が止まりかねない（生産指示、出荷指示、検査指示、棚卸作業表、振込み一覧、入金予定一覧、など）場合など、いわゆる業務上のクリティカルな処理では、想定時間までに正常終了したことを確認する機構を備える。
処理時間の長いプログラムでは、固まっていないことを確認できるようなログ出力のあり方や、処理時間短縮、第三者が直観的に分かりやすいことを目的に、処理の分割に工夫をします。
これらは、障害対応に苦労してきたという「痛い思い」を通じて経験が溜まり、上記の実装が少しずつ可能になっていく訳ですが、ＳＥ・プログラマの全員が網羅的にエラー体験などは出来ません。
現実的には、個々の技術者が、先達からの伝承、疑似体験などを積極的に取得し、自分の中にナレッジを積み重ねていく必要があります。
こういった土台の上で、下記３点を実現していきます。
①夜間バッチ処理で落ちかねない要素は、可能な限り就業時間内に自動で事前チェックする。
②夜間バッチ処理で落ちたとしても、翌日対応可能なものは警告を残した上でスキップし、後続処理を自動で続ける。
③夜間バッチ処理で即日対応が求められる処理は、可能な限り設計しない。（日中に実現するよう工夫する）
バッチ処理の実装に失敗すると、悲しい人生に
言うは易く、行うは難し、の世界ではあります。
ユーザー要求を丸呑みしたり、花形のオンライン処理に注力してバッチ処理を軽視したり、事前の全体設計が出来ていないといったシステムでは、悲惨な夜間対応が待っています。
実際の業務システムでは夜間障害が少なくないもので、いざ発生したら、翌日朝までに何事もなかったかのような対応が求められることもあります。
多くの場合は、予め想定できていなかったから障害な訳です。（想定できていたら、そもそもエラーになっていない）
夜中22時に電話が来るのも嫌ですが、深夜2時、3時に起こされるのはもっと勘弁です。
特に小さなお子さんがいる家庭では、障害連絡の電話は申告な問題です。
交代勤務やアウトソーシングなどで夜間処理を監視する部隊を作ったとしても、重要システムは対応にも専門性が求められるので、その監視部隊で解決できることには限界があり、結局は担当ＳＥの対応が求められます。
最後に
自分の人生の為にも、夜間バッチ処理の設計を重視しましょう。
試行に思考を重ね、スマートな処理体系に育てていくやり方がよいと思います。
私は自分のチームで、5年以上かけて王道（ジョブ管理ソフトでどのような骨格を作り、スクリプトとEXEでどのような汎用プログラムを整備して基盤とし、業務ロジックをどのように開発していくか）を作り上げました。
こういった仕組みが、ジョブ管理ソフトのテンプレートとして数パターンでも提供されればベストだと思うのですが、そのような流れは聞こえてきません。
個人的には中身に踏み込んで書きたいのですが、自分たちで考えた内容とはいえ、仕事中に考えた結果（成果物）であるので詳述は控えておきます。
身バレが怖いというのもあります。
