シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計（本記事）
TRACERYプロダクトマネージャーの haru です。
バッチ処理は、大量のデータをまとめて収集・加工し、あらかじめ定められたスケジュールや条件に従って一括実行する仕組みです。
売上集計や在庫更新、帳票作成などに広く用いられ、リアルタイム性よりも業務開始前など定められた時間内に正しく処理が完了していることが重視されます。
要件定義では、処理の機能面に加え、完了期限、利用可能なリソースの範囲、バックアップやメンテナンスとの調整方法、失敗時の再実行方針など、非機能要件を明確にしておく必要があります。
本記事では、要件定義とバッチ処理設計の関係を説明します。
機能要件とバッチ処理設計
バッチ処理の設計では、要件定義で作成された開発品目一覧でリストアップされたバッチ処理（【例】売上データ集計処理）を詳細化します。
以下は、売上データ集計処理の機能要件です。
| 開発品目 | 機能要件 |
|---|---|
| 売上データ集計処理 | - 売上ダッシュボード画面に表示するデータを定期的に作成する - 日次で日別／商品別／地域別に、前日分をクロス集計する。 - オプションで指定した日付範囲で集計できる。 - 売上データ集計処理が完了した際、業務ユーザーに処理完了を通知する。 - 通知には完了日時と対象期間を含め、ユーザーが次の業務（レポート確認や承認作業）を開始できるようにする。 |
このような機能要件から 入力（パラメータ）・処理内容（ビジネスロジックの流れ）・出力（戻り値） を具体化します。
以下の表では、売上データ集計処理の機能要件を基に入力・処理・出力へと整理し、設計内容として具体化した例を示します。
| 項目 | 内容 |
|---|---|
| 入力（引数） | 集計対象期間の指定period_start（開始日）、period_end（終了日）を任意パラメータとする。指定しない場合、前日が集計対象となる。 |
| 処理内容（ビジネスロジック） | 前処理 集計対象期間を算出する。引数が指定されている場合は内容を検証し、値が正しければ集計期間として採用する。値が不正の場合、エラーを通知して、処理を終了する。 集計 対象期間の売上データを取得し、返品・値引・キャンセルを控除して、日別／商品別／地域別に売上額・数量・純売上を集計する。 結果格納 daily_sales_summary テーブルに集計結果を格納する。通知処理 処理完了時に完了日時と対象期間を含むメッセージを生成し、メールとSlackに通知する。 |
| 出力（戻り値） | 処理件数を返却する。 |
バッチ処理設計におけるクラス設計・DB設計との関係
さらに、クラス設計で整理されたドメインモデルや、DB設計で確定したエンティティやスキーマ設計もバッチ処理設計の入力として参照します。
これにより、バッチ処理の処理内容とデータ永続化をどう関連づけるかが明確になります。
また、バッチ処理設計ではクラス設計やDB設計との間で整合性を確認しながら相互に調整を行うことが重要です。
たとえば、バッチ処理で取得、保存に必要な情報がDB設計に不足していればスキーマを見直す、といったフィードバックをすることで、設計全体の整合性を確保します。
非機能要件とバッチ処理設計の連携
非機能要件は下図に示す要素で構成されます。
バッチ処理設計では、これらの非機能要件のうち、主に利用品質の効率性、満足性、プロダクト品質の性能効率、信頼性、セキュリティ に着目します。
効率性
効率性*1は、ユーザーが操作にかける時間に対して、どの程度の成果が得られるかを示す度合いです。
たとえば、売上データ集計処理において、大量の取引データを効率よく読み込み・加工し、定められた締切（例：毎朝6時まで）までに日次や月次の売上指標を安定的に算出できる場合、効率性が高いといえます。
| 設計観点 | 内容 |
|---|---|
| 処理時間SLO*2の明確化 | 「毎日AM6:00までに完了」などの締切をSLOとして定義し、計測と可視化を行う。 |
満足性
満足性*3は、利用者（エンドユーザーや運用担当者）がシステムを使って「満足できるかどうか」 を表す指標です。
「効率性」が客観的な達成度を測るのに対し、満足性は主観的な体感や心理的な評価を含みます。
| 設計観点 | 内容 |
|---|---|
| 進捗・状態の可視化 | 実行中／処理件数／処理進捗を即把握できるようにする。 【例】 - ログや監視画面にジョブのステータス（待機中／実行中／完了／失敗）を表示する - メールやSlackに処理結果や進捗を通知する。 |
性能効率
性能効率*4は 、指定された条件下でシステムが必要な性能をどれだけ効率的に提供できるかを表します。
性能効率は、「時間効率性」「資源使用効率性」「容量」など3つのサブ特性に分類されます。
以下の表は、性能効率のサブ特性をバッチ処理設計に落とし込む際の設計観点をまとめたものです。
| サブ特性 | 設計観点 |
|---|---|
| 時間効率性（Time behavior）*5 | 入出力や計算処理を最適化し、限られたリソースで大量データを期限内に処理できるようにする。 【例】 - I/O最適化：一括読み書き、バッファ利用、ストリーミングで入出力待機時間を最小化。 - 並列化・分散処理：AWS Lambdaなどの FaaS*6 を用いて、並列分散処理を実行する。 |
| 資源利用性（Resource utilization）*7 | CPU・メモリ・I/Oなどのリソースを無駄なく活用し、処理負荷を平準化することで、安定した基盤運用と効率的な実行を実現する。 【例】 - リソース利用の最適化：CPU・メモリ使用量を測定し、過剰消費を防止。ジョブ単位のリソース制御を行う。 - キャッシュ活用：中間結果や参照データをキャッシュし、繰り返し計算やI/Oを削減。 - スケジューリングと負荷分散：業務ピークを避け、依存関係順序と同時実行数を制御して負荷を平準化する。 |
| 容量（Capacity）*8 | 将来のデータ増加やピーク時の負荷を見越して処理件数やデータ量に耐えられる設計とし、容量超過による遅延や障害を防ぐ。 【例】 - 処理対象データ量の見積り：将来的なデータ増加を見越し、ピーク時の最大件数・容量を試算する。 |
信頼性
信頼性*9は、「成熟性」「可用性」「障害耐性」「復旧性」の4つのサブ特性に分類されています。
以下の表は、信頼性のサブ特性をバッチ処理設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 設計観点 |
|---|---|
| 成熟性（Maturity）*10 | 欠陥を防ぐ設計とテスト、実行状況の継続的な監視・分析により、処理の安定性と品質を高める。 【例】 - コード品質とテスト：ユニットテスト・リグレッションテストで欠陥混入を防ぐ。 - 監視メトリクス蓄積：エラー率・実行時間・リトライ回数を蓄積し、品質改善に活用する。 - 変更時の安心 ：本番データを汚さない試行（ドライラン*11）やカナリア実行*12で影響を可視化する。 |
| 可用性（Availability） *13 | 基盤の冗長化や監視体制を整備し、障害や遅延が発生しても処理を継続または迅速に復旧できるようにする。 【例】 - 冗長化と切替：ジョブスケジューラや基盤をクラスタ構成にし、障害時でも実行可能にする。 - 監視と通知：遅延・失敗を即時検知し、適切に通知する。 |
| 障害耐性（Fault Tolerance） *14 | 一時的なエラーや異常時にも安全に制御し、誤処理や影響拡大を防ぎながら処理を継続または安全に停止できるようにする。 【例】 - エラーデータのスキップ：入力エラーを検出した際に、全体を止めずにスキップ・隔離して残りを処理継続する仕組み - 自動リトライとバックオフ*15：一時的なエラーに対し、指数的バックオフで再試行し影響を吸収する。 - フェイルセーフ設計：異常時はデータ破壊を避け、安全側で停止する。 - ジョブ依存関係の制御：前工程失敗時に後工程を止め、誤処理拡散を防ぐ。 - 隔離実行：高負荷ジョブを分離し、他システムへの影響を回避する。 |
| 回復性（Recoverability） *16 | 障害発生時にも安全に再実行や再開ができ、結果の整合性を保ちながら迅速に処理を復旧できるようにする。 【例】 - 再実行効率（チェックポイント）：中断点を記録し、障害発生時に途中から再開できるようにする。 - 冪等性の確保：再試行や二重投入でも結果が重複・破壊しない入出力設計にする。再実行を安心して行える基盤。 |
セキュリティ
セキュリティ*17は、「機密性」「完全性」「否認防止」「責任追跡性」「真正性」の5つのサブ特性に分類されています。
以下の表は、セキュリティのサブ特性のうち、機密性と真正性をバッチ処理設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 設計観点 |
|---|---|
| 機密性（Confidentiality） *18 | 個人情報や機密情報が不必要に露出しないよう制御し、処理中・成果物・ログを通じて情報漏えいを防止する。 【例】 - データマスキング：ログや成果物に個人情報/機密情報を残さない。 |
| 真正性（Authenticity） *19 | サービス間通信や外部連携において認証や署名を用い、処理対象や連携先が正当なものであることを保証する。 【例】 - サービス間相互認証： 外部API連携はmTLS*20や署名付きリクエストで相手を確認。 |
まとめ
バッチ処理設計は、単に大量データを自動処理する仕組みを構築することにとどまりません。
売上集計や在庫更新といった機能要件を入力・処理・出力に落とし込むだけでなく、効率性・満足性・性能効率・信頼性・セキュリティといった非機能要件を適切に組み合わせることで、業務と経営の双方に安定性と安心感をもたらします。
非機能要件が欠ければ、処理遅延による出荷や請求業務の停止、誤集計による経営判断の誤り、情報漏えいによる信用失墜といったリスクが現実化します。
一方、堅牢に設計されたバッチ処理は、運用現場の負担を軽減し、経営判断に必要な正確でタイムリーな情報提供を可能にします。
バッチ処理は要件定義の段階から非機能要件を明確にし、それに基づいて設計することが重要です。
*1:ISO/IEC 25010:2011に定義されている。
*2:Service Level Objective：サービスレベル目標。サービスの提供品質を測定するために定める組織内部の具体的な数値目標のこと。上位概念に SLA（Service Level Agreement：サービスレベル合意） があり、SLAは利用者との契約として定めるもの。
*3:ISO/IEC 25010:2011に定義されている。
*4:ISO/IEC 25010:2023に定義されている。
*5:指定された条件下での応答時間、処理時間、スループットなど、システムやコンポーネントの応答が、性能要求やユーザーの期待に対して適切か
*6:Functions as a Service：クラウド上で小さな処理単位（関数）をイベントに応じて実行できるサービス形態。利用者はサーバを構築・管理する必要がなく、コードを関数としてデプロイし、必要に応じてクラウドが自動で実行・スケーリングする。
*7:指定された条件下で、システムやコンポーネントがどれだけ効率的にハードウェアやソフトウェアの資源（CPU、メモリ、ネットワークなど）を利用するか。
*8:システムが、パフォーマンスを保ちながら処理できる最大ユーザー数、データ量、トランザクション数などの上限が要求を満たしているか、または想定された負荷に耐えられるか
*9:ISO/IEC 25010:2023に定義されている。
*10:ソフトウェア製品またはシステムが、欠陥の発生頻度や障害の発生確率が低く、安定して期待されるサービスを提供できる度合い
*11:本番と同じ処理フローを 実際の更新や副作用を発生させずに試行することを指す。「空回し」「試運転」であり、処理の影響を事前に確認する手法。
*12:本番と同じ処理フローを 実際の更新や副作用を発生させずに試行することを指す。「空回し」「試運転」であり、処理の影響を事前に確認する手法。
*13:必要なときにサービスや機能を利用できる度合い
*14:ハードウェアやソフトウェアの障害、または操作ミスが発生しても、許容できる性能レベルで動作を継続できる度合い
*15:処理が失敗したときに すぐ再試行するのではなく、一定時間待ってから再実行する仕組み。特に「指数的バックオフ（Exponential Backoff）」が一般的で、再試行のたびに待機時間を倍増（例：1秒 → 2秒 → 4秒 → 8秒…）させていく
*16:障害や停止が発生した後、必要なデータを復旧し、望ましい運用状態を一定時間内に回復できる度合い
*17:ISO/IEC 25010:2023に定義されている。
*18:権限を持つユーザーのみが情報にアクセスできるように制御し、データが不正に閲覧・漏洩されないことを保証するか
*19:ユーザー、デバイス、システム、通信が真正であることを確認し、なりすましを防止できるか
*20:Mutual Transport Layer Security。TLS（Transport Layer Security）による通信暗号化に加えて、通信の両者（クライアントとサーバ）が相互に認証し合う仕組み。
