モジュール分割の考え方 ― なぜ分けるのか、現場の構成例

導入

COPY句とCALL文という2つの道具を学んだところで、この章の締めくくりとして「なぜプログラムを分割するのか」という設計の考え方を整理しておきましょう。

説明

大規模なCOBOLシステムを、1つの巨大なプログラムファイルとして書くことは技術的には可能ですが、実務ではまず行いません。理由は、他の多くの言語での「モジュール分割」「関数分割」の理由とも共通しています。

役割ごとに責任を分離できる … 「入力チェック」「計算」「ファイル出力」のようにサブプログラムを分ければ、それぞれが何をする部品なのか把握しやすくなる。
再利用できる … 「消費税を計算する」サブプログラムを一度作れば、複数のシステムから呼び出せる。
チームで分担しやすい … サブプログラム単位で担当者を分ければ、並行して開発を進められる。
修正の影響範囲を狭められる … 1つのサブプログラムを直すだけで済むなら、システム全体への影響を最小限にとどめられる。

実際の現場でよく見られる構成の例を示します。

graph TD
    MAIN["MAIN-BATCH<br/>（メインの制御プログラム）"] --> READ["READ-CUSTOMER<br/>（顧客データ読み込み）"]
    MAIN --> CALC["CALC-INTEREST<br/>（利息計算）"]
    MAIN --> VALIDATE["VALIDATE-DATA<br/>（入力チェック）"]
    MAIN --> WRITE["WRITE-REPORT<br/>（帳票出力）"]
    CALC --> COMMON["COMMON-ROUTINES<br/>（共通の日付計算などcopy句）"]
    VALIDATE --> COMMON

「メインの流れを制御するプログラム（MAIN-BATCH）」が、各処理を担当するサブプログラムを順番に CALL していく構成が典型的です。
日付計算やコード変換のような、複数のサブプログラムから共通して使いたい小さなロジックは、さらに小さな共通サブプログラムに切り出されたり、COPY句で共有されたりします。
段落によるPERFORM分割（同じファイル内での整理） と、CALLによるサブプログラム分割（別ファイルへの分離） は、どちらも「大きすぎる処理を小さくする」目的は同じですが、粒度が違います。ちょっとした処理のまとまりはPERFORM、独立した部品として再利用・分担開発したい単位はCALL、という使い分けが一般的です。

保守エンジニアとして大規模なCOBOLシステムに向き合うとき、まず「このプログラムはどんなサブプログラムをCALLしているか」「どんなCOPY句を使っているか」を洗い出すことが、全体像を理解する第一歩になります。この章で学んだCOPY句とCALL文は、その全体像を読み解くための、とても重要な地図の読み方です。

試すには

もし自分が「毎月の給与計算バッチシステム」を設計するとしたら、どんなサブプログラムに分割するか（例: 「基本給計算」「残業代計算」「税額計算」「明細書出力」など）、この章の図を参考に自分なりの構成図を考えてみましょう。