興味深い記事ではあるが…
COBOLだからダメ、という気はないが、いまだにCOBOL？と思うのも確かなんだよなぁ。
問題になってる名寄せ、巧く処理できなかったのは、当時、別の言語で作ったとしてもやはり同様の問題は発生しただろうなぁ、多い少ないはあっても、と。
でも、その間違った状態を正常に直そうとしたとき、COBOLのインターフェイスで何ができるだろう？と思う。できない、という訳じゃないけど。
恐らくだが、生年月日や下の名前などから、関連の深いと思われるデータを一覧表示して、それを職員が関連付ける、という作業を行うには、手間がかかりすぎる気が…
それに、COBOLかどうかは別にして、基本設計が40年前のプログラム（という事だと思うのだが。違うの？それとも40年前のコンパイラを使ったというだけの、数年以内にリライトされたプログラム、なの？）は、やっぱり失笑の対象にせざるをえないと思うがなぁ。
もうかなり前のことになるが、2000年問題、のように、開発当初は性能が劣る部分をごまかしごまかしやってきたおかげで、後になって想像も出きなかった障害が起こり易くなってるだろう。
しかも想定外の計算結果に対して、もうその想定外のため、だけ、の回避ロジック組んでたりする場合もあるわけで。ライブラリのミス、なんだが、そこを正しく直すと、ライブラリのミスを前提に書かれたほかの部分に逆の影響が出る、とか。
で、その例外回避ロジックが何故埋め込まれてるのか知らないまま放置されてたり。一応ドキュメントは残ってるけど、紙やインクの問題でおもっきし劣化してたり、構築当時のメンバーは年金もらう年齢になってたり。
なんらかのタイミングで１度スクラッチ＆ビルドするべきだとは思うがなぁ。開発費をケチってごまかしごまかし保守しつづけると、いずれもっとでかい爆弾踏みそうな気がするんだが。
オレの今の職場、割と古い資産もいっぱいあって、COBOLで作られた、月に１度夜間処理で実行されて、大量の紙が吐き出されるシステムなんかも。
自由度が低いし（出力条件かえられるの、月１回とか）、見た目も古臭い（全角文字が使えないとか）。何よりもバグが発覚した時に、簡単に直せない、ので、「こーゆー処理をしたときは、こーゆー例外が発生するので、このフィールドの値分減算しろ」のように運用でカバーしなくてはいけない、という状況すらあったりする、らしい（直せよ…）
ということで、オープン系のシステムでExcelファイルとして吐き出すようにスクラッチ＆ビルド、なんてプロジェクトがあったりするんだがなぁ（オレは参画してないけど）
文化人をバカにして悦に入りたいだけの人に見えるんですが。
超電波ですね；；
筆者はシステム屋さんなんですかね？
視野が狭いというか…