わたしが自分が「ベテラン」の情報処理職人だと思ってからしばらくして、本物のveteran (アメリカの退役軍人)と情報処理技術のからんだニュースに出会った。
Slashdot日本語版
http://it.slashdot.jp/story/13/07/14/0555217/
COBOLで書かれた米国防総省の給与システム700万行、実質的に更新不可能
ストーリー by headless 2013年07月14日 16時27分
Slashdot英語版
http://yro.slashdot.org/story/13/07/10/2028213/the-pentagons-seven-million-lines-of-cobol
The Pentagon's Seven Million Lines of Cobol
Posted by Soulskill on Wednesday July 10, 2013 @05:23PM
さらにさかのぼると、
ロイター
http://preview.reuters.com/2013/7/9/wounded-in-battle-stiffed-by-the-pentagon
http://www.reuters.com/article/2013/07/09/us-usa-pentagon-payerrors-special-report-idUSBRE96818I20130709
How the Pentagon’s payroll quagmire traps soldiers
Filed Jul 2nd, 2013, Updated Jul 10th, 2013
By Scot J. Paltrow and Kelly Carr
もとの記事の話題の中心は、「戦場でけがをして帰ってきた軍人に、適切な給料が払われていないことがたびたびある」という問題だ。兵士が勤務すべきなのにいなかったとき、本人が勝手にさぼったのか、やむをえない事情があったのかによって、払われるべき額は大きく変わってくる。その判断に必要な情報が正しく計算に入れられていないことがあるのだ。
そして、計算がうまくいっていない理由として、そのために使われている計算機プログラムが1960年代にCOBOL言語で書かれたもので、そのうちにはプログラムの仕様のドキュメントも残っていないものさえあり、軍の事情が変わった場合も、プログラムのまちがいに気づいた場合も、修正がほとんどできなくなっているのだそうだ。手作業で補っているが能率が低く、いったんまちがいにぶつかると手続きに年月がかかるのだ。Slashdotがとりあげたのは、このような情報処理の課題としてだった。
わたしはCOBOL言語については、多数のプログラム言語を列挙した本で大まかな特徴を理解したにすぎない。また、給与計算などが今はどんなプログラム言語で書かれているか知らない。
しかし、Fortranならば1960年代に書かれたプログラムがどんなものかを知っている。読んだのは1980年代だった。1960年代に「GO TO」文を駆使していたプログラムの制御構造を、1970年代に確立した概念体系(順次処理、条件分岐、ループ)[わたしが1990年代に書いた教材ページ]で表現しなおし、Fortran 77標準の構文を使って書きなおす、ということをずいぶんやった。(Fortran言語の標準の大部分は過去と互換性をもって作られているので、1960年代のプログラムは少しだけなおせばFortran 77コンパイラを通るのだ。しかしわたしはそれでは満足せず、Fortran 77の時代にふさわしいスタイルで書くことを心がけた。) 今でも必要となればやれると思う。1960年代にプログラムを書いた人自身が現役であることはもはや少ないと思うし、わたしよりも若い人ではこのような経験をした人は少ないと思うので、1960年代のプログラムをなんとかしたいのであれば、わたしのような経験をした人をさがすのがよいと思う。ただし、わたしは残念ながらFortran 90以後のFortran言語や、その他の新時代のプログラム言語を、自分の仕事の出力言語にできるほどよく知らない。Fortran 77がもはや現役の言語でないのならば、わたしの出力を読んで現役の言語に書きなおす職人がもうひとり必要だ。
旧言語を解読した経験者がいなくなってしまったら、残るのは歴史学的方法だ。過去の言語で書かれたプログラムを解読するのは、ギリシャ語かラテン語かアラビア語か古典漢文で書かれた数学の証明を解読する訓練ができている科学史家の出番かもしれない。
たぶん、アメリカ国防総省の給料計算プログラムは、修理して使い続けるのではなく、初めからつくりなおすべきなのだろう。それでも、問題確認のため、これまで使ってきたプログラムのどの部分がどのような判断をしているのかの理屈を理解するべきなのかもしれない。COBOLの場合も、2000年問題のころ(事前に対策しようとしたのだから1990年代後半ごろ)には、経験者が動員されてプログラムの解読と修理をしたはずだ。その人たちが今も働けるのならば、新しい言語に書きなおすことはできなくても、解読はできるのではないだろうか。ただし、解読が役立つものになるためには、解読結果の表現のしかたをうまく設計する必要があると思う。その設計には新旧の言語を知っている(あるいは任務となれば勉強することができる)人が必要かもしれない。
同じ題材ではないのだが、関連する話題の次の記事も見た。
http://www.publickey1.jp/blog/13/post_232.html
「技術的負債」とは何か。原典とその対応策を探る
Junichi Niino（jniino）
2013年7月29日
(これを見て、「負債」よりもむしろ「不良債権」ではないかと言っていた人がいたようだったが記憶が定かでない。いずれにしても比喩なのでこだわることはないかもしれない。)
