COBOLプログラムをきれいに!モジュール構造の見直しとリファクタリングの基本
生徒
「先生、古いCOBOLプログラムを読んでいるのですが、数千行も続いていてどこで何をしているのか全然わかりません…。」
先生
「それは大変ですね。長年修正を繰り返したプログラムは、中身がスパゲッティのように絡まってしまうことがよくあります。」
生徒
「これを整理して、もっと読みやすく、直しやすくする方法ってないんでしょうか?」
先生
「ありますよ!それを『モジュール構造の見直し』や『リファクタリング』と呼びます。プログラムの動作は変えずに、中身をきれいに掃除する技術を学んでいきましょう。」
1. モジュール構造の見直しとは?
モジュール構造(もじゅーるこうぞう)とは、巨大な一つのプログラムを、役割ごとに小さな部品(モジュール)に切り分けて組み立てる仕組みのことです。
プログラミング未経験の方には、「料理」に例えると分かりやすいでしょう。 一人のシェフが下ごしらえから調理、盛り付け、皿洗いまで全て一つの場所で同時並行で行うとパニックになりますよね。 これを「野菜を切る担当」「焼く担当」「洗う担当」と場所と役割を分けるのがモジュール化です。
古いCOBOL資産の多くは、この役割分担が不明確で、一つの箱に全てが詰め込まれた「密結合(みつけつごう)」という状態になっています。 これを見直して、部品ごとに独立させることで、一部を直しても他に影響が出にくい、安全なシステムに生まれ変わらせることができます。
2. リファクタリングの基本概念
リファクタリング(Refactoring)とは、プログラムの「外側から見た動き」は一切変えずに、「内部の構造」だけを整理して改善することです。
「計算結果が変わるわけじゃないのに、なぜそんなことをするの?」と思うかもしれません。 しかし、ぐちゃぐちゃなコード(プログラムの命令)をそのままにしておくと、次に新しい機能を追加したい時に、思わぬ場所でエラーが起きる原因になります。
リファクタリングは、いわば「プログラムの定期清掃」です。 部屋が散らかっていると探し物に時間がかかるように、プログラムも整理整頓されていないと、修正に余計な時間とお金がかかってしまうのです。
3. なぜ今、見直しが必要なのか(モダナイゼーション)
現在、多くの企業が古いCOBOL資産を現代的なシステムへ移行するモダナイゼーション(近代化)を進めています。 その際、中身が複雑なままでは新しいシステムへ移すこともできません。
モジュール構造を見直し、リファクタリングを行うことで、以下のようなメリットがあります。
- 保守性の向上: どこに何が書いてあるか一目でわかるようになります。
- 再利用性の向上: 一度作った「消費税計算部品」などを他のプログラムでも使い回せるようになります。
- 属人化の解消: 特定のベテランしか触れなかったプログラムが、誰でも直せるようになります。
4. 具体的なリファクタリングの手順
まずは、プログラムの中にある「意味のある塊」を見つけ出すことから始めます。
① 重複しているコードをまとめる
同じ計算式や処理が、プログラムのあちこちに何度も出てくることがあります。 これを一箇所にまとめて名前をつけることで、修正が必要になった際も一箇所直すだけで済むようになります。
② 分かりにくい名前に「適切な名前」をつける
昔のプログラムでは、変数の名前に X-01 や WK-02 といった、意味のわからない記号が使われることがありました。
これを URIAGE-GOKEI(売上合計) のように、誰が見ても中身がわかる名前に書き換えます。
③ 長すぎる処理を分割する
一つの PROCEDURE(処理) が数百行にわたる場合は、それを「データ読み込み」「税金計算」「画面表示」といった小さなステップに分割します。
5. モジュール化のビフォー・アフター
実際のCOBOLコードで、リファクタリングのイメージを見てみましょう。
【改善前】ダラダラと続くスパゲッティ状態
PROCEDURE DIVISION.
IF KBN = "1"
COMPUTE TAX = AMT * 0.10
DISPLAY "TAX: " TAX
ELSE
COMPUTE TAX = AMT * 0.08
DISPLAY "TAX: " TAX
END-IF.
* この後も延々と処理が続く...
【改善後】役割ごとに部品(サブルーチン)化
PROCEDURE DIVISION.
MAIN-LOGIC.
PERFORM CALC-TAX-RTN
PERFORM DISPLAY-RTN
STOP RUN.
CALC-TAX-RTN.
IF KBN = "1"
COMPUTE TAX = AMT * 0.10
ELSE
COMPUTE TAX = AMT * 0.08
END-IF.
DISPLAY-RTN.
DISPLAY "TAX: " TAX.
PERFORM(実行する) という命令を使って、「メインの道筋」と「具体的な作業内容(部品)」を分けることで、全体の流れが劇的に読みやすくなります。
6. リファクタリングの注意点:テストの重要性
「掃除をしたついでに、大事な書類を捨ててしまった」ということがあってはいけません。 リファクタリングを行う際は、必ず単体テスト(たんたいてすと)をセットで行います。
整理する前の計算結果と、整理した後の計算結果が「1円の狂いもなく一致するか」を、コンピュータを使って厳密にチェックします。 これを繰り返すことで、安全にプログラムをきれいに保つことができます。
7. 構造化プログラミングへの転換
昔のCOBOLでは GO TO という「指定した行へジャンプする」命令がよく使われていました。
しかし、これがあちこちで使われると、処理の流れが追い切れなくなります。
現代のリファクタリングでは、この GO TO を廃止し、 IF や EVALUATE (条件分岐)、 PERFORM (繰り返しや部品呼び出し)だけで構成する構造化(こうぞうか)プログラミングへ書き換えることが推奨されます。
これにより、上から下へ素直に流れる、美しいプログラムが完成します。
8. 外部への「共通部品化」のすすめ
プログラム内部で整理ができたら、次は「他のプログラムからも使えるように外に出す」ことを検討します。 これを CALL(呼び出し) 機能と言います。
例えば「和暦から西暦へ変換する処理」を一つの共通部品として外に置いておけば、100個のプログラムで同じコードを書く必要がなくなります。 資産を「持たない」のではなく「共有する」ことで、システム全体のボリュームをスリムにすることができます。
9. ドキュメントとの同期
プログラムをきれいに直したら、忘れずに「設計書(せっけいしょ)」も更新しましょう。 家をリフォームしたのに、古い図面のままでは将来の住人が困ってしまいます。
最近では、プログラムの構造から自動的に図面を作成してくれるツールもあります。 「中身」と「説明書」が常に一致している状態を作ることが、リファクタリングの真のゴールです。
10. 小さな一歩から始めるリファクタリング
いきなり数万行のプログラムを全て直すのは不可能です。 まずは「一番よく修正が入る場所」や「一番読みづらい部分」から、少しずつ手をつけていきましょう。
「昨日の自分よりも少しだけ読みやすいコードを書く」。 その積み重ねが、何十年も続くレガシーシステムを、未来へつなぐモダンなシステムへと変えていくのです。