最初はもっとキャッチーなタイトルにしようと思ったんだが、そんなしょうもないことしてもしょうもないんで。
「語るに落ちる」とはこのことである。この人はCOBOLに親でも殺されたのだろうか？ こんな炎上芸で問題が解決したら、何の苦労もない。
COBOLのメリットを一々挙げて反論する気はない。しかし、事実として現にCOBOLは多くの場所で使われている。その理由は何か。
あれこれあるのであるが、最大のメリットにして最大のデメリットとして挙げたいと思うのは、
後方互換性の高さ
である。
後方互換性が高いことについてのメリットは、誰でもわかることだろう。COBOLもそれを売りにして来た。「古いCOBOL」のコードであっても、現代の最新のCOBOL規格から見てvalidであって、正しく同じ動作をするバイナリが出て来る。COBOLは実に60年近い歴史があるのだが、そのごく初期のコードですら、現代の規格からはvalidなのである。
これはエンドユーザにとっては実に都合が良い。動作環境さえ保てるのであれば、古いコードであっても使える。それこそ「遺産(レガシー)」として価値があるのだ。減損しない資産だとも言える。一度作ったプログラムが古くなっても使えなくなることはない。エンドユーザから見ると、実に素晴しい。
他方、これはIT屋にとっては厄介な問題となる。古いコードを書き直す必要がないということは、何らかの理由で改修の必要があった時、「古い」という理由でコードを書き直すことが忌避されることになり、「最低限のコストでITシステムを維持したい」というエンドユーザの要望を満たそうとすると、
ちょっとパッチを当てる
というような修正になってしまう。いろいろ思考停止してしまえばその方が楽ちんなので、双方の利害が一致して、大々的に書き直すというような機会はなくなる。
この時の厄介な問題は、「ちょっとパッチを当てるだけ」に過ぎない修正なので、仕様書等の修正をしなかったりすることである。まぁ、「ちょっと」の間ならそれでもいいんだろうが、それが積もり積もると
秘伝のタレ
状態になってしまう。これを現代のIT屋の言葉では、
レガシー化
と呼ぶ。つまり、「レガシー」というのは、
現に動いているけど、どうして動いてるかよくからんし、いじったら何が起きるかわからん
という状態である。仕様書がコードと乖離し、もちろんテストコードもあるのかないのかわからず、それでも後方互換性に助けられて、現に動いている。現に動いているのは良いのだが、どうして動いているかよくわからんし、いじった時に何が起きるかわからんし、簡単にそれが予測出来ない。そういった厄介な状態である。別に古典的言語で書かれているかどうかは関係ない。モダンな言語でもレガシーコードは出来てしまうし、古典的言語でもレガシーでない状態にすることは可能だ。
こうなってしまった時にするべきは、
レガシーマイグレーション
である。「正しいレガシーマイグレーション」とは、そういった「現に動いているけど、どうして動いているかよくわからんし、いじったら何が起きるかわからん」状態を解消することである。
ところが、世の中にダウンサイジングの嵐が起き、2000年問題が後押しし… といった時に流行った「レガシーマイグレーション」は何だったかと言えば、
単にメインフレームからオープンシステムへの移行
であったり、
コードコンバータによるCOBOLからJavaへの書き換え
であったりした。
そもそも「正しいレガシーマイグレーション」を行うには、まず
コードとドキュメントの一致
が必要であるにも関わらず、その部分を「工数ガー」ということでサボってしまい、「COBOLやメインフレームは追い出したが、レガシーであることに変わりがない」という、何の役にも立たないものにさせてしまった。
COBOLが悪であるなら、ここで問題が解決したはずだった。「COBOLというレガシー言語のコード」が「Javaというモダンな言語のコード」変換出来たのだから。
ところが、「正しいレガシーマイグレーション」をしなかったツケはやって来る。
まず、オープンシステムはメインフレームと違って変化が激しい。そうなると、それに追従しなければならない。また同じくモダンな言語も変化が激しい。COBOLなら60年前のコードが動いても、Javaなら20年前のコードも動かない。無理やり動かしてしまうと、今度はミドルウェアで問題を起こす。Struts1の問題とか、おっさんにとっては記憶に新しかろう。まぁ幸いなことに、モダンな言語やオープンシステムは後方互換性をあまり意識してないので、古いコードは自動的に動かなくなってしまい、「レガシー」という問題が消えてくれるというメリットがあるわけだ。それは早死にすれば老後の心配は不要というのと同じとも言える。
まぁそんなわけで、単にCOBOLやメインフレームを「撲滅」してしまった結果、前よりもタチの悪いことになってしまったのである。
IT屋や日経コンピュータがしばしば勘違いしていることがあるのだが、こういった人達は
世の中はITを中心に回ってない
ということを忘れがちである。「先進のIT技術」なんてものはエンドユーザにも社会にも、何の価値ももたらさない。そのことを忘れている。いや、わざと無視しているのかも知れない。
エンドユーザにとって価値があるのは、
本業の売上や利益(=自分達の幸せ)
であり、
それをもたらしてくれる技術
なのだ。それに関係ないものに金は払いたくない。従業員の給料すらケチる現代、自分達に直接関係のない「先進のIT技術」なんぞに払う金はないのである。
もちろん、「先進のIT技術」が本業の売上や利益に直結するようなものであれば、そこに投資を惜しむのは馬鹿げていることであるが、逆にそうでもないのにそこに投資するのは、単なるムダ使いでしかない。昔、「見栄」のために身の丈に合わないデカいコンピュータを入れていた会社があったのだが、使われてないので単なる置物でしかなかった。今の「先進のIT技術」はどれも実体(物理)としてはショボいので、「見栄」にすらならない。IoTやAIをどれだけバズらせようと、それに用がない人達にとっては、単なるバズワードである。賢い消費者はIT屋のバズワードには乗らない。なんせ、「狼少年」ばっかりだからな。IT屋や日経コンピュータって奴は。
「後方互換性」というのは、こういったニーズにぴったり合っている。問題のないコードであれば、せいぜい再コンパイルをする程度で動くのであれば、「必要のないIT投資」を減らすことが出来る。エンドユーザにとっては、とても都合が良い。
COBOLとは直接関係ないのだが、実は弊社にはPHP4で書かれた会計システムが現用で動いている。10年以上前の古いものであるのだが、動かし方を工夫することによって何の問題もなく運用出来ている。それで何の問題も起きてないし、よく言われるセキュリティー上の問題も起きないような動かし方にしている。まさにレガシーシステムである。「紺屋の白ばかま」と言われるかも知れないが、「会計」なんてのはそんなものである。うちは会計事務所ではないし、オペレータは私一人なので、それで何の問題もない。だから、ここに手間や金をかける気もない。
とは言えちょっと不自由なこともあるので(機能追加したくても手が出せない)、更新しようとは思っている。でも、その時には単にPHPを最新にするということでなく(そもそも私は公式にはPHPは知らない)、何か他の言語で書き直すことを考えている。って、入力以外は既にRubyで書いてしまったのであるけど。これこそが「正しい」レガシーマイグレーションなのである。単にPHPを最新にするだけでは、問題の解決はしないからね。
最初の話に戻ると、「正しいレガシーマイグレーション」をするには、まずは
コードとドキュメントの一致
が必要なのだ。レガシーコードでそれを行うには、そのコードを正しく読み解き、仕様書に昇華するという能力が必要なる。そのためには、「COBOL技術者」は当然に必要になるし、そういった作業の結果コードも仕様書も最新の状態になってしまえば、もはや「レガシー」ではなくなる。その時は冷静にバイアスのない状態で、
COBOLを使い続けることは果して有用か？
という問いについて考えることが出来るようになる。
個人的には「レガシーでないCOBOL」になってしまっているなら、無理して不安要素の増えるモダンな言語に移行する必要はないと思う。今はOpenCOBOL(GnuCOBOL)があるので、Linux上でも最新のCOBOLが動いている。とは言え、それはそれぞれの事情だろう。と言うか、レガシー状態でなくなれば、「それぞれの事情」だけで判断出来るようになるのだ。その結果、世間がCOBOL絶滅の方向に動き出せば、それはそれで良いシナリオである。これは「禅譲」であって、「クーデター」ではない。「引退」であって「撲滅」ではない。
ところが、「COBOLは親の敵」とばかりに悪口を言い続けても、絶滅したりしない。その理由は以下のエントリに書いておいた。
また、COBOLで書かれたシステムが絶滅する前に、COBOL技術者が絶滅してしまったら、ますます亡霊のような「レガシーCOBOL」が生き続けることになってしまう。そんなものでも、強力な後方互換性のお陰で動いてしまうからだ。
しかし、「正しいレガシーマイグレーション」のためには、コードを仕様書に昇華させる能力のある技術者が必須だ。モダンな言語で1から書き直すにしても、仕様書がなければ始まらない。1から設計を始めて到達する仕様書は、おそらくは元の仕様書と大差ないもので、その後の「パッチ」のような仕様は含まれていない。それは「現に動いているけど、どうして動いているかよくわからんし、いじったら何が起きるかわからん」という悲惨なものを読み解かなければわからないのだ。
ところが、あーゆー「炎上芸」のためにCOBOL屋が減って行けば(あのおっさんが、どんだけCOBOL屋のネガキャンをやったよ？)、COBOLで書かれたシステムが絶滅する前にCOBOL技術者がいなくなってしまう。今の調子からすると、当然のようにそうなるだろう。そうなった時、どうせ件のおっさんはその責任取る気はないだろ。それどころか「COBOLが絶滅して素晴しい」みたいなエントリを書くに違いない。いたずらにCOBOL屋を減らすようなことを放談して悦に入る。それが「語るに落ちる」と言うのだ。
PS. 日経コンピュータの皆様へ、
日経BP社の社員は既に出禁です。仮にメールを送って来ても、全てのメールは無視されるか、ここで晒されるだけです。
なんならこの前のメールも公開しようか？
また、現在の私はCOBOLどころかいわゆるIT屋ですらないので、この件について何か話があってもお相手するつもりもございませんので、あしからずご了承下さい。
PS2.
まぁ、「COBOLでプログラムを書き、COBOLのシステム設計をし、COBOLのミドルウェアを作り、COBOLの処理系を書き、COBOLの言語仕様策定に参加」した私が、今はCOBOLに全くかすりもしない仕事をしているというのは、ちょっと面白いね。今やってるのは、潜水艇の電装系の開発と実装だったり。
こういったのを作っている。これは潜水テストをしている様子だ。水圧センサーと深度の校正のために、実際に潜水してデータ取りをしているところ。この「船」の電気系統は全て私の設計と施工である。最初は「制御装置の開発」だったのが、いつの間にか配線するハメになるとは思ってなかったわ。