脱COBOLを掲げてローコード化したら、思ったより大変だった話

技術を置き換えるだけでは、現場は楽にならない

レガシーシステムの現場では、「脱COBOL」という言葉を聞くことがあります。

COBOLは古い。若手が触りにくい。保守できる人が減っている。将来的な人材確保が難しい。そう考えると、COBOLから別の仕組みに置き換えたいという発想は自然です。

私自身も、以前は「COBOLを使わずに業務を作れるなら、その方がよいのでは」と思っていました。

特にローコードツールを使えば、プログラムを書かなくても画面や処理を作れる。若いSEやお客さんも触りやすい。専門的なCOBOL知識がなくても改修できる。そう考えると、かなり魅力的に見えます。

実際、ある業務で、COBOLではなくローコードツールを使って仕組みを作ることになりました。

対象は、出力された資料を仕分けるような業務です。単純に見える業務であれば、わざわざCOBOLで作らなくても、ローコードで十分対応できるのではないか。そう考えたのです。

しかし、いざやってみると、想像以上に大変でした。

ソースコードとして扱えない難しさ

まず大きかったのは、「ソースコードとして扱えない難しさ」です。

COBOLであれば、ソースを読めば処理の流れが追えます。分からない部分があれば検索できます。似た処理を探して流用できます。最近であれば、AIにソースを読ませて処理概要を整理したり、修正方針を相談したりすることもできます。

ところがローコードツールの場合、処理が画面上の設定や部品の組み合わせとして表現されます。もちろん、それがローコードの良さでもあります。しかし、裏を返すと、テキストとして一括で読み解くことが難しい場合があります。

AIに「この処理を解析して」と渡しにくい。差分を確認しにくい。レビューしにくい。処理の全体像をつかみにくい。

この点は、実際に触ってみて初めて大きな負担だと感じました。

「COBOLならこうできるのに」と思ってしまう

さらに精神的にきつかったのは、「COBOLならこうできるのに」と何度も思ってしまうことです。

COBOLは古いと言われますが、業務処理を書くという意味では非常に素直です。条件分岐、繰り返し、ファイル入出力、帳票処理。長年使われてきただけあって、業務ロジックを表現する力はあります。

一方で、ローコードツールでは、ツールの考え方に合わせて処理を組み立てる必要があります。

「この条件ならこう分岐したい」「このタイミングでこのデータを見たい」「この単位で処理をまとめたい」。

COBOLならすぐに書けそうなことでも、ローコード上では設定方法を探したり、回避策を考えたりする必要がありました。

つまり、COBOLをやめたことで楽になるはずが、別の難しさが発生したのです。

新しい技術ほど、社内ノウハウが足りない

もう一つ大きかったのは、ノウハウ不足です。

COBOLであれば、社内に過去資産や経験者がいます。似たような処理もあります。困ったときに調べる先があります。しかし、新しく導入したローコードツールでは、社内に十分なノウハウがありません。

その結果、相手側とのQAが増えます。

「この設定で合っているのか」「この動きは仕様なのか」「この制約は回避できるのか」「この業務要件はどう実現すればよいのか」。

確認が増えるほど、作業工数も増えます。回答待ちも発生します。認識齟齬も起きます。結果として、当初想定していたよりも大きな工数になってしまいました。

「脱COBOL」は目的ではない

ここで学んだのは、「脱COBOL」は目的ではないということです。

本当に大事なのは、業務を安定して動かし、将来的に保守しやすくし、現場の負担を減らすことです。COBOLを使わないこと自体が目的になってしまうと、別の技術に置き換えた結果、かえって保守が難しくなることがあります。

もちろん、ローコードが悪いわけではありません。

画面作成や簡単なワークフロー、部門内の小規模な業務改善には非常に有効な場面があります。お客さん自身が設定を変更できることもメリットです。短期間で形にできることもあります。

ただし、複雑な業務ロジック、細かい例外処理、大量データ処理、長期保守、AIによる解析や自動化との相性まで考えると、ローコードが常に最適とは限りません。

単純な技術比較では判断できない

「COBOLは古いからやめる」「ローコードは新しいから良い」。

この単純な判断は危険です。

大切なのは、どの業務をどの技術で実現するのが一番保守しやすいかを考えることです。

COBOLで残すべき処理もあります。ローコードに向いている業務もあります。JavaやPythonで作った方がよい場合もあります。AIで解析・補助しやすい形にするという観点も、これからは重要になります。

今回の経験で、私は「脱COBOL」という言葉を少し慎重に見るようになりました。

古い技術を変えることは大切です。しかし、変えた先で現場が苦しくなるなら、それは改善ではありません。

まとめ

技術選定で大事なのは、流行ではなく、業務との相性、保守性、ノウハウ、AI活用のしやすさ、将来の運用まで含めて判断することです。

脱COBOLを目指すなら、COBOLを否定するのではなく、COBOLで担うべき部分と、別技術へ移すべき部分を見極めること。

それが、レガシーシステム改善の現実的な第一歩だと思います。