飯島 裕一（日本電気株式会社 クラウドプラットフォーム事業部）
「COBOLで書かれていてスパゲッティ状態になっているから・・・」
「COBOLプログラムがスパゲッティ状態なのでメンテできない・・・」
というようなフレーズをよく聞きます。
このとき、「COBOLプログラム≒スパゲッティプログラム」という構図で話されていることが多い気がしますが、はたして、本当に「COBOLプログラム≒スパゲッティプログラム」なのでしょうか？
読者の皆さんは、「スパゲッティ状態」と聞いて、どのような状態のプログラムを思い浮かべますか？
スパゲッティの「麺が絡まった」状態から思い浮かぶのは、GO TO文であっちこっちに処理が移っていくようなプログラム、あるいは、条件式が複雑で理解に苦しむようなIF文がいくつも出てくるプログラムではないでしょうか。
スパゲッティプログラムという言葉の定義を見てみましょう。
上記から、解読困難、修正困難なプログラムをスパゲッティプログラムというようです。
筆者は冒頭で述べたGO TO文だらけの「スパゲッティ状態」のCOBOLプログラムを実際に見たことがありません。しかし、一方で、解読困難なCOBOLプログラムは見る機会が多々あります。
２例ほど、ご紹介します。
ある機械系メーカーA社での話です。「現在のシステムはCOBOLで出来ており、プログラムはスパゲッティ状態だからCOBOLはやめて今後は別の言語で開発したい」という話がありました。
筆者は「スパゲッティ状態」とはどういうことか興味が沸き、A社のCOBOLプログラムを見せていただきました。さぞや、複雑なコーディングがされているのかと思いきや、コーディング自体は実に綺麗に記述されており、とても見やすいものでした。IFのネストもほとんどありません。
これのどこが「スパゲッティ」なのか、さっぱりわかりませんでしたが、よくよく話を聞いてみてわかりました。
A社では、通常の索引ファイルを使って、ネットワーク型のデータベースもどきを作っていたのです。そして、その自前データベースの仕様書がメンテナンスされておらず、既存のCOBOLプログラムを読んで自前データベースの参照方法（索引ファイルのアクセスロジック）を理解し、最新仕様を確認しながらプログラムを修正するということをしていたのです。
つまり、自前データベースの最新の仕様書がなかったことにより、COBOLプログラムの修正を困難にしていただけだったのです。
もう１つの事例です。
金融系B社もまた、「手を入れたくないほど複雑なCOBOLプログラムが山ほどある」ということで、今後COBOLを使っていくかどうか検討をしていました。
こちらもCOBOLプログラムを見せていただきましたが、プログラムステップ数が多いことを除いては、特にコーディング自体は綺麗に記述されており、こちらのプログラムも「スパゲッティ」とはとても思えませんでした。
どうして「手を入れたくない」のか話を聞いてみたところ、次のような理由でした。
B社では、税制などの法改正のたびに、例えば、○○年４月１日以降の税率はＸＸ％で計算するが、それ以前の日付のデータの場合は税率△△％で計算する、というようなロジック修正をCOBOLプログラムに加えていたのです。
法改正によるプログラム修正は、20年以上に渡って続けられており、既に通過しないロジック（デッドコード）が多々ありました。しかし、担当者が変わっているため、本当に通過しないロジックなのか判断することができず、今に至っているということでした。（ロジック削除による不具合発生が怖くて、そのままにしておこうという心理が働くことはよくありますね。）
その結果、プログラムステップ数は膨大なものになり、どこに手を加えていけばよいかという検討だけでもかなりの工数を要するようになり、「手をいれたくないプログラム」になったということです。
上記２件の例を整理してみましょう。修正困難なプログラムとなった背景は次のようなものでした。
ちょっと待ってください。どちらも全然COBOLのせいではないですよね。
仕様書を最新化する習慣がない、定期的なプログラムのリファクタリングをすることがない場合には、言語を変えても、将来的に同じことが発生します。
筆者は「スパゲッティプログラム」はバズワード(*2)の１つと考えています。
本来の課題は別のところにあるにもかかわらず、「プログラムがスパゲッティ状態だから」と決めつけて、思考停止してしまっていることが多いのではないのでしょうか。
もし、「プログラムがスパゲッティ状態だ」というフレーズが読者の皆様に聞こえてきたときには、それはどういう状態なのか、どうしてそうなったのか、是非その理由を掘り下げて考えてみてください。
決して、「COBOLだから」という理由ではないはずです。
以上
(*1)プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること
(*2)定義が曖昧ながら特定の分野の人々の間で通用する言葉