2018年12月25日

【ＩＴの引っ越し～持っていけば動くわけではありません～】

～ＡｍａｚｏｎでＣＯＢＯＬ？～

またクラウドに関連した話題ですが、ひと月ほど前の11月末にCOBOLというプログラミング言語の名前がネット界隈で久しぶりに飛び交う事件がありました。Amazonが11月29日に開いたre:Invent2018の中で、COBOLがAWS Lambdaでサポートされると発表されたのがその原因です。

COBOLと言えば私が就職した1980年台末期頃にはすでに古臭くて効率が悪いコンピュータ言語の代名詞のような扱いでした。パーソナルコンピュータとインターネット環境やUNIXを中心としたオープン系システムがビジネスの世界に普及し始めた1990年台から、メインフレームやミニコンとCOBOLで構築されたレガシーなシステムをいかにしてこれらの現代的なシステムに置き換えていくかが課題として語られ続けています。つまり、この30年ほどにわたって語られ続けているということが示すのは、「置き換えきれないほどの数と規模のシステムがいまだに稼働している」という事実です。

COBOLの悪い評判ですが、古臭いであるとか記述が冗長になる、巨大なスパゲッティコードになって保守性に劣るなど、言語使用の古臭さに起因する面があるのは間違いないのでしょう。しかし日本国内のシステムに限って考えてみると、もともと保守性がよろしくないシステムに日本的でその組織内でしか通用しないビジネスロジックを組み込んでしまうことに原因があるような気がします。

稼働しているシステムに何らかの理由でその場限りのつもりで機能追加や改修を加え、その当事者が担当している間は問題がなくても、担当者が交代してからあらためて見直してみると、なぜそのようになっているのか理由がわからない、その部分に手を加えるとどのような結果が出てくるのかわからないといった謎のシステムが継承されていきます。これらのレガシーなシステムをオープン系のシステムで動くERPパッケージなどで置き換えるプロジェクトも今まで数多く行われてきていますが、これらのプロジェクトで当初の計画通りに行かなかった事例を見聞きしています。出来合いのパッケージに収まらないその組織独自の例外的な処理をカスタマイズという形で追加しようとしてうまく行かずに暗礁に乗り上げてしまうということが多いようで、先に書いたような標準的なビジネスロジックとは異なる例外的な処理をその組織固有の機能としてどうにかして組み込もうとするとうまく行かない結果を招きます。

このような話は、COBOLという言語がどうこうというよりは、プロジェクトの設計自体に原因があったあと考えるのが本筋だと思いますが、大抵の事例がCOBOLで組まれているために象徴として嫌われているようで、言語自体に起因するというよりは、COBOLを採用したシステムを開発・運用する組織の問題が押し付けられているように思えます。実際、医療機関のレセプト管理システムとして普及しているORCAというシステムはCOBOLで構築されているシステムですが、日本国内で1万8千ほどの医療機関で継続して利用されている実績をあげているものもあります。

AWS LambdaでCOBOLが利用可能になるという話題に戻りますが、いまだに数多く稼働しているCOBOLベースのレガシーシステムをAWS上で動くオープン系のシステムにリプレースするリスクを冒させるのではなく、COBOLで現に動いているままでクラウドに移行させられることができれば、現在ユーザーが運用している現行システムをAWS側に移行させるハードルを下げることが期待できるとAmazonが割り切った結果ではないでしょうか。

2018年12月