【その6】基本設計書 ③バッチ
今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
クソみたいな案件にヘルプに行った中で、いろいろと思い出しながら書いてたんやねー。
そのせいか、途中のメールの文章が切れてる部分があるｗ
バッチって言ったら JP1 一択だったなー。
Java 屋だったから余計かも。
へぇ～！クラウドでもイケるんや。AWS 限定っぽいけど。
とある客先常駐案件で「（夜間バッチのスケジュールがぎゅうぎゅうで）ジョブを走らせる時間がありません！」って地獄のような言葉がずっと頭に残ってるんよね。今でも。
ジョブスケジュールを見たけど、ほんとにぎゅうぎゅう。どこかでジョブが異常終了したら、絶対にデッドライン（朝 9 時）を超えるのが目に見えてるのが地獄味深かったなー。
結局、バッチの構造や処理内容を見直したんだっけ。
当時オンプレだったから、インフラ増強は無理。最後まで頑張らされる（？）のはアプリ屋。
※以下、当時の文章。
バッチは画面や帳票と違って、処理内容、処理結果が見えにくいです。
（ファイルに書き出すのなら別ですが）
また、大量データを扱うことが多いので、帳票同様ヘタなプログラムを書くとムダにリソースを食ってしまいます。
（複雑な処理になりがちなので尚更です）
バッチについては、簡単でもいいのでできるだけフロー図を描くことをお勧めします。
不具合が後々になって出てくるのもバッチが多いです。
「それまで業務データで処理していない（＝テストデータを使っていた）から分からなかった＆気づけなかった」ような不具合が、リリース後に出てくる場合も多いです。
特に、月 1 のみ実行されるバッチなんかは要注意です。
バッチ設計とは
- バッチ設計の意味
バッチ処理（一括処理）とは - IT用語辞典 e-Words
1）バッチ処理とは、複数のプログラムからなる作業において、あらかじめ一連の手順を登録しておき、まとめて連続的に実行する方式。または、一定期間や一定量ごとにデータをまとめて一括して処理する方式。
→ 主に、即時性を求められないもの＆オンライン処理に向かないもの（大量データ集計、更新、等）が対象。
バッチ設計で決めること
大きく分けて、以下の 3 つです。
- 基本情報（バッチ仕様）
- 処理の流れ（バッチ全体）
- 処理の流れ（個別バッチ）
１. 基本情報（バッチ仕様）
バッチの基本的な仕様を決めます。
主に、バッチの起動や入出力を決めます。
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 起動間隔 | 日次や月次等、バッチの起動タイミングを記載します。 |
| 起動時間 | バッチが起動する時間を記載します。 タスクスケジューラー等を使用する場合必須です。 |
| 入力元 | バッチ処理で扱うデータの入力元を記載します。 入力元の場所（DB or ファイルの場所）を記載します。 |
| 出力先 | バッチ処理で扱うデータの出力先を記載します。 出力先の場所（DB or ファイルの場所）を記載します。 |
| 説明 | バッチについての説明を記載します。 |
２. 処理の流れ（バッチ全体）
まずはバッチ全体の処理フローを記載して、バッチ全体の実行時間がバッチ稼働時間内に終わるかどうかを確認します。
全てのバッチがバッチ稼働時間内に終わらない場合、方式を変更する等の対策が必要となります。
例）バッチ → オンバッチ（ディレード）にする、等
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 項目名 | 帳票項目名を記載します。 |
| バッチフロー | バッチ一覧を基に、全てのバッチの起動順番を図式化し、想定時間を記載します。 |
＜補足＞
バッチ事項を管理する製品もあります。例えば、金融系でよく使われる「JP1」（日立）では、バッチ全体の処理の流れを「ジョブネット図」と呼んでいます。
（JP1 に設定するために作成必須となっています）
３. 処理の流れ（個別バッチ）
バッチ全体のときと同様、処理フローを記載します。
バッチ実行時間内に終わらない場合や、リソース不足等実行方法に無理がある場合、方式を変更する等の対策が必要となります。
例）バッチ → オンバッチ（ディレード）にする、等
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 項目名 | 帳票項目名を記載します。 |
| 処理フロー | 個別バッチの起動タイミング～処理終了までを図式化します。 |
| 処理概要 | 処理フローにある項目ごとに、処理の概要を記載します。 |
＜補足＞
処理概要をどこまで書くか？という問題がよく出てきます。
※以下、私見です！！
個人的には「詳細設計書があるなら概要のみ、詳細設計書が無いなら処理概要に詳細を書く」方が良いと思います。
バッチ設計のコツ
- 処理効率を考えて設計すること
バッチ処理は大量データを夜間に処理することが多いです。バッチの稼働時間が決められている場合がほとんどであるため、その中で処理が終わるように設計してください。
また、想定外のデータ量が来る可能性がありますので、できれば予想最高データ量を基本設計書に記載しておくと、テストの際にも役立ちます。
（性能・負荷テストの範囲内です）
- オンバッチの場合、特に処理速度に留意すること
オンバッチ（ディレードとも言います）は、オンラインと連動したバッチです。
（例：画面上でボタンを押したタイミングでバッチが起動する。この場合、バッチは画面と非同期で処理するため、画面上ではすぐレスポンスを返すことができる）
オンバッチを使用する場合、オンバッチの処理結果を基に次の業務が回ることが多いため、あまりに処理結果の戻りが遅いと業務に支障をきたしてしまいます。
また、画面からの複数の実行が考えられますので、スレッド式にする等、工夫が必要となります。
（以前、オンバッチで画面上から複数実行をされて、キューに詰まって処理が終わらない、というケースもありました）
