Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
バッチ処理個別仕様
各バッチ処理の実行条件、処理内容、データフロー、エラー処理、通知方法を明確に定義し、チームが一貫性のある実装と安定したバッチ運用を実現するための個別仕様書です。
🎯 概要
- 目的: 各バッチ処理の実行条件、処理内容、データフロー、エラー処理、通知方法を明確に定義し、開発チームが一貫性のある実装を行い、運用チームが安定したバッチ運用を実現できるようにする
- スコープ: 定期実行バッチ、オンデマンドバッチの個別仕様(実行スケジュール、起動パラメータ、処理対象データ、処理フロー、更新対象、エラー処理、通知仕様、リカバリー手順)をカバーする。バッチ実行基盤の技術仕様(ジョブスケジューラー、監視ツール)は対象外
- 推奨する実施タイミング: 基本設計の中盤~後半で、データベース設計、アプリケーション共通処理方式、バッチ実行基盤方式の定義後に実施する
- 関連するステークホルダー: バッチ開発チーム、データベース設計者、システム運用チーム、業務担当者、インフラチーム
📥 重要な前提知識・インプット
- 前提知識: バッチ処理の基本概念、トランザクション管理、エラー処理パターン、ジョブスケジューリングの理解、SQL最適化の知識
- インプット: 業務要件定義書(バッチ処理要件)、データベース設計書、アプリケーション共通処理方式、バッチ実行基盤仕様、非機能要件(性能・可用性)、運用要件
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]バッチ処理個別仕様書
- 必須要素: バッチ処理一覧、各バッチの個別仕様書(概要、実行スケジュール、起動パラメータ、処理対象データ、処理フロー図、集計・変換ロジック、更新対象テーブル、エラー処理、通知仕様)
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 処理対象の明確性 | 処理対象データ、抽出条件、想定件数が明確に定義されている |
| 処理フローの完全性 | 正常処理、異常処理、エラーハンドリングの流れが図示されている |
| エラー処理の網羅性 | 想定されるエラーケースごとに対応方法が定義されている |
| 性能要件の充足 | 想定処理時間、タイムアウト設定が業務要件を満たしている |
| データ整合性の担保 | トランザクション境界、ロールバック条件が明確である |
| 依存関係の明確化 | 前提バッチ、後続バッチとの実行順序が整理されている |
| 通知仕様の妥当性 | 通知条件、通知先、通知内容が運用要件に合致している |
| リカバリー手順 | 障害発生時の再実行方法、データ復旧手順が定義されている |
👁️🗨️ レビュー観点:
- 業務要件との整合性: 業務で必要な処理内容、実行タイミング、集計ロジックが正確に反映されているか
- 性能・処理時間の妥当性: 想定データ量に対して処理時間が適切か、タイムアウト設定が妥当か
- データ整合性の担保: トランザクション制御、排他制御、重複チェックが適切に設計されているか
- エラー処理の適切性: エラーケースが網羅され、リトライ・スキップ・異常終了の判断が適切か
- 運用性: 監視、ログ出力、通知、手動実行の容易性が考慮されているか
- 依存関係の整理: バッチ間の実行順序、データ依存関係が明確で矛盾がないか
🧪成果物のサンプル
# BAT-001: 日次売上集計バッチ
## 概要
前日の売上データを集計し、日次売上サマリーテーブルと月次売上集計テーブルを更新する。部門別・商品別の売上金額、数量を算出する。
## 実行スケジュール
- **実行タイミング**: 毎日 2:00 AM
- **実行頻度**: 日次
- **想定処理時間**: 15分
- **タイムアウト設定**: 30分
## 起動パラメータ
| パラメータ名 | 必須 | データ型 | デフォルト値 | 説明 |
|-----------|------|---------|-----------|------|
| target_date | 任意 | 日付(YYYYMMDD) | 前日 | 集計対象日 |
| mode | 任意 | 文字列 | normal | normal: 通常実行、force: 再集計モード |
## 処理対象データ
- **対象テーブル**: 売上トランザクションテーブル (sales_transactions)
- **抽出条件**: 対象日の0:00~23:59の取引データ
- **想定件数**: 約50,000件/日
## 処理フロー
```mermaid
graph TD
A[バッチ起動] --> B[パラメータ取得]
B --> C{target_date指定?}
C -->|なし| D[前日を対象日に設定]
C -->|あり| E[指定日を対象日に設定]
D --> F[対象日の売上データ抽出]
E --> F
F --> G{データ存在?}
G -->|なし| H[警告ログ出力]
H --> I[処理終了]
G -->|あり| J[部門別集計処理]
J --> K[商品別集計処理]
K --> L[日次サマリー作成]
L --> M{再集計モード?}
M -->|Yes| N[既存データ削除]
M -->|No| O[データ重複チェック]
N --> P[集計データ登録]
O --> Q{重複あり?}
Q -->|Yes| R[エラーログ出力]
R --> S[異常終了]
Q -->|No| P
P --> T[月次集計テーブル更新]
T --> U[処理件数ログ出力]
U --> V[正常終了]
```
## 集計ロジック
### 部門別集計
```
SELECT
department_id,
department_name,
SUM(amount) as total_amount,
SUM(quantity) as total_quantity,
COUNT(DISTINCT customer_id) as customer_count,
COUNT(*) as transaction_count
FROM
sales_transactions
WHERE
transaction_date = :target_date
AND status = 'completed'
GROUP BY
department_id,
department_name
```
### 商品別集計
```
SELECT
product_id,
product_name,
category_id,
SUM(amount) as total_amount,
SUM(quantity) as total_quantity,
COUNT(*) as transaction_count
FROM
sales_transactions
WHERE
transaction_date = :target_date
AND status = 'completed'
GROUP BY
product_id,
product_name,
category_id
```
## 更新対象テーブル
| テーブル名 | 更新内容 | 更新方式 |
|----------|---------|---------|
| daily_sales_summary | 日次売上サマリー | INSERT |
| department_sales_daily | 部門別日次売上 | INSERT |
| product_sales_daily | 商品別日次売上 | INSERT |
| monthly_sales_summary | 月次集計 | UPDATE (累計加算) |
## エラー処理
| エラーケース | 対応 |
|-----------|------|
| 対象日のデータが0件 | 警告ログ出力、正常終了 |
| 集計データ重複 | エラーログ出力、異常終了 |
| DBエラー | リトライ(最大3回)、失敗時は異常終了 |
| タイムアウト | エラー通知、異常終了 |
## 通知仕様
| 通知条件 | 通知先 | 通知内容 |
|---------|-------|---------|
| 正常終了 | - | 通知なし |
| データ0件 | 業務担当者 | 「対象日のデータが存在しません」 |
| 異常終了 | システム管理者 | エラー内容、スタックトレース |
---
# BAT-002: 会員ステータス更新バッチ
## 概要
会員の過去1年間の購入履歴を集計し、累計購入金額に応じて会員ステータス(ブロンズ/シルバー/ゴールド/プラチナ)を更新する。
## 実行スケジュール
- **実行タイミング**: 毎日 3:00 AM
- **実行頻度**: 日次
- **想定処理時間**: 30分
- **タイムアウト設定**: 1時間
## 起動パラメータ
| パラメータ名 | 必須 | データ型 | デフォルト値 | 説明 |
|-----------|------|---------|-----------|------|
| target_member_id | 任意 | 文字列 | - | 特定会員のみ更新する場合に指定 |
| batch_size | 任意 | 数値 | 1000 | 一度に処理する会員数 |
## 処理対象データ
- **対象テーブル**: 会員マスタ (members)、売上トランザクション (sales_transactions)
- **抽出条件**: アクティブ会員全件
- **想定件数**: 約100,000会員
## 会員ステータス判定ロジック
| ステータス | 条件(過去1年間の累計購入金額) |
|----------|---------------------------|
| プラチナ | 500,000円以上 |
| ゴールド | 300,000円以上 500,000円未満 |
| シルバー | 100,000円以上 300,000円未満 |
| ブロンズ | 100,000円未満 |
## 処理フロー
```mermaid
sequenceDiagram
participant B as バッチ
participant M as 会員マスタ
participant S as 売上トランザクション
participant L as ログ
B->>M: アクティブ会員取得 (バッチサイズ単位)
loop 会員ごと
B->>S: 過去1年間の購入履歴取得
S->>B: 累計購入金額返却
B->>B: ステータス判定
alt ステータス変更あり
B->>M: 会員ステータス更新
B->>L: 更新ログ出力
else ステータス変更なし
B->>B: スキップ
end
end
B->>L: 処理完了ログ出力
```
## 更新対象テーブル
| テーブル名 | 更新カラム | 更新方式 |
|----------|----------|---------|
| members | member_status, status_updated_at | UPDATE |
| member_status_history | 履歴テーブルへINSERT | INSERT |
## エラー処理
| エラーケース | 対応 |
|-----------|------|
| 個別会員の更新エラー | エラーログ出力、当該会員スキップして処理継続 |
| DBエラー | リトライ(最大3回)、失敗時は異常終了 |
| タイムアウト | 処理途中まで確定、次回実行時に継続 |
---
# BAT-003: データバックアップバッチ
## 概要
重要な業務データ(会員情報、売上データ、在庫データ)をバックアップファイルとして出力し、外部ストレージに保存する。
## 実行スケジュール
- **実行タイミング**: 毎日 4:00 AM
- **実行頻度**: 日次
- **想定処理時間**: 1時間
- **タイムアウト設定**: 2時間
## バックアップ対象テーブル
| テーブル名 | バックアップ形式 | 圧縮 | 保持期間 |
|----------|-------------|------|---------|
| members | SQL dump | Yes | 90日 |
| sales_transactions | SQL dump | Yes | 90日 |
| inventory | SQL dump | Yes | 30日 |
| orders | SQL dump | Yes | 90日 |
## 処理フロー
```mermaid
graph LR
A[バッチ起動] --> B[バックアップ日付設定]
B --> C[対象テーブルループ]
C --> D[テーブルデータ抽出]
D --> E[SQLダンプ生成]
E --> F[ファイル圧縮 gzip]
F --> G[ローカル保存]
G --> H[外部ストレージ転送]
H --> I{転送成功?}
I -->|Yes| J[古いバックアップ削除]
I -->|No| K[リトライ]
K --> H
J --> L[次のテーブル]
L --> C
C --> M[全テーブル完了]
M --> N[バックアップ検証]
N --> O[完了ログ出力]
```
## バックアップファイル命名規則
```
{table_name}_backup_{YYYYMMDD}_{HHMMSS}.sql.gz
例: members_backup_20251120_040000.sql.gz
```
## 保存先
- **ローカル**: /var/backup/database/
- **外部ストレージ**: S3バケット (s3://company-backup/database/)
---
## バッチ仕様記載のガイドライン
各バッチの個別仕様を記載する際は、以下のテンプレートを使用する:
### バッチ仕様テンプレート
```markdown
# BAT-XXX: [バッチ名]
## 概要
[バッチの目的と処理内容を簡潔に記述]
## 実行スケジュール
- **実行タイミング**: [cron形式または時刻]
- **実行頻度**: [日次/週次/月次]
- **想定処理時間**: [XX分]
- **タイムアウト設定**: [XX分]
## 起動パラメータ
| パラメータ名 | 必須 | データ型 | デフォルト値 | 説明 |
|-----------|------|---------|-----------|------|
| [記載] | [記載] | [記載] | [記載] | [記載] |
## 処理対象データ
- **対象テーブル**: [テーブル名]
- **抽出条件**: [WHERE条件]
- **想定件数**: [XX件]
## 処理フロー
[Mermaidフロー図で記載]
## 更新対象テーブル
| テーブル名 | 更新内容 | 更新方式 |
|----------|---------|---------|
| [記載] | [記載] | [記載] |
## エラー処理
| エラーケース | 対応 |
|-----------|------|
| [記載] | [記載] |
## 通知仕様
| 通知条件 | 通知先 | 通知内容 |
|---------|-------|---------|
| [記載] | [記載] | [記載] |
```
---
## 備考
- バッチ実行順序は依存関係に注意し、前提バッチが完了してから後続バッチを実行すること
- 処理時間が長いバッチは、業務時間外に実行すること
- 障害発生時は、リカバリー手順に従って手動実行または再実行を行うこと
- バッチ実行ログは保持期間(90日間)経過後に自動削除される
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: バッチ処理一覧の整理と優先順位付け
設計対象:
システムで必要となるすべてのバッチ処理を洗い出し、実行順序と依存関係を整理する。
具体例:
- 日次で実行する集計バッチ(売上集計、在庫集計、会員ステータス更新など)
- 週次・月次で実行するレポート作成バッチ
- データ連携バッチ(外部システムとのデータ送受信)
- データバックアップ・アーカイブバッチ
- データクレンジング・メンテナンスバッチ
設計原則:
- 業務要件の網羅: 業務要件定義書から必要なバッチ処理を漏れなく抽出する
- 実行順序の明確化: バッチ間のデータ依存関係を整理し、実行順序を決定する
- 実行時間帯の考慮: 業務影響を最小限にするため、バッチ実行可能時間帯を確認する
- 優先度の設定: 業務への影響度、緊急度に応じて優先度を設定する
文書化の推奨表現:
- バッチ処理一覧表の作成: バッチID、バッチ名、実行頻度、実行タイミング、想定処理時間、優先度を一覧化する
- 依存関係図の作成: バッチ間の実行順序と依存関係を視覚的に表現する
- 実行スケジュール表: 時系列でバッチの実行計画を示す
🏗️ プロセス2: 個別バッチの処理仕様定義
設計対象:
各バッチの詳細な処理内容、起動パラメータ、処理対象データ、処理フロー、エラー処理を定義する。
具体例:
- 起動パラメータ:処理対象日、再実行モード、バッチサイズなど
- 処理対象データ:対象テーブル、抽出条件、想定件数
- 処理フロー:データ抽出→集計・変換→データ更新の流れ
- 集計・変換ロジック:SQLやビジネスロジックの詳細
- 更新対象:更新するテーブル、カラム、更新方式(INSERT/UPDATE/DELETE)
設計原則:
- 処理の明確化: 何を入力とし、何を出力するのか、処理内容を具体的に記述する
- トランザクション境界の設計: どの単位でコミット/ロールバックするかを明確にする
- 冪等性の考慮: 同じバッチを複数回実行しても結果が一貫するように設計する
- パフォーマンスの最適化: 大量データ処理の場合は、バッチサイズや並列処理を検討する
- 処理フローの視覚化: Mermaidなどで処理フローを図示し、理解しやすくする
文書化の推奨表現:
- バッチ仕様書テンプレートの活用: 統一されたフォーマットで各バッチの仕様を記述する
- 処理フロー図の作成: フローチャートやシーケンス図で処理の流れを表現する
- SQLやロジックの明記: 集計・変換の具体的なロジックをコードブロックで記載する
🏗️ プロセス3: エラー処理・リカバリー仕様の定義
設計対象:
想定されるエラーケースごとに、エラー処理方法、通知仕様、リカバリー手順を定義する。
具体例:
- データ0件の場合:警告ログ出力、業務担当者への通知
- データ重複エラー:エラーログ出力、異常終了
- DBエラー:リトライ(最大N回)、失敗時は異常終了とシステム管理者への通知
- タイムアウト:処理中断、エラー通知、手動再実行の手順
- 部分的なエラー:エラー行をスキップして処理継続、エラーログ出力
設計原則:
- エラーケースの網羅: 発生しうるエラーを事前に洗い出し、対応方法を定義する
- 適切な通知設計: エラーの重要度に応じて、通知先と通知内容を設定する
- リトライ戦略: 一時的なエラーはリトライ、恒久的なエラーは即座に異常終了する
- データ整合性の保証: エラー発生時にデータが不整合にならないよう、トランザクション制御を適切に行う
- 運用手順の明確化: 障害発生時の運用対応手順(手動実行、データ修正など)を文書化する
文書化の推奨表現:
- エラー処理一覧表の作成: エラーケースごとに対応方法を表形式で整理する
- 通知仕様の明記: 通知条件、通知先、通知内容を具体的に記載する
- リカバリー手順書の作成: 障害時の対応手順をステップバイステップで記述する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『エンタープライズアプリケーションアーキテクチャパターン』(マーチン・ファウラー)、『Spring Batch 徹底活用』、バッチ処理設計のベストプラクティス
- 関連する他のガイド: データベース設計ガイド、アプリケーション共通処理方式、バッチ実行基盤仕様、運用設計ガイド、性能要件定義ガイド
- ツール・テンプレート: draw.io、Mermaid(フロー図作成)、バッチ仕様書テンプレート
テンプレートサイト: 📄テンプレート集