日経コンピュータの木村岳史氏が「そろそろCOBOL絶滅のシナリオを考えようか」という刺激的なタイトルの記事を投稿しています。COBOLという言語そのものは悪くは言わないが、COBOLプログラムは新規システムに使われることはなく、保守的な仕事に埋没することになる。若手をそのような仕事につかせることはよくないので、COBOL絶滅に向けたシナリオを作るべきだという論調です。
若手がいつまでもCOBOLプログラムの保守に明け暮れてしまうことは指摘の通り良くないと思うのですが、安易に「COBOLを捨てる」といったことを強調することはどうかと思います。単純に事務机を買い替えるのとは訳が違って、プログラムにはその企業の根幹を支えるロジックの塊になっています。
今まで、何十年も運用されてきたシステムでは、ドキュメントとして記載される内容とソースプログラムでコーディングされている内容の不一致も多く存在している可能性もあります。
ドキュメントを信じずに、プログラムを単純にCOBOLから他言語を書き換えれば良いではないかと思う方も多いと思います。しかし、そんなに単純な話しではなくなることが多々あります。
レガシーシステムの刷新はなぜ苦労するか
例えば、プログラムの実行環境が変わるだけでも、プログラムの構造自体に大きな変更が加わる場合があります。
・データベースアクセスにCODASYL型のデータベースからリレーショナル型データベースに変更する
・クライアントサーバー的なシステムからWEB型のシステムに変更する
・システムの中核はパッケージソフトウエアを使うようにして、外回りをカスタマイズすることで現行を踏襲する
このようなプログラムの構造自体に大きな変更が生じるような状況になると、一行一行を単純に他言語に書き換えるような作業ではなくなってしまいます。
刷新の道筋
以前、データ中心設計の勉強をしているときに、「システムの刷新をするときには下記のような道筋で考えなさい」と書いてある本がありました。堀内一氏の「データ中心システム設計」という書籍だったと思います。
現行 提案
論理 Ｂ．現行論理 → Ｃ．提案論理
↑ ↓
物理 Ａ．現行物理 Ｄ．提案物理
（ＢからＣの矢印では新規の要件が入る）
物理モデルというのは、現状の実装方式を踏まえたモデルということになります。ＣＯＢＯＬ、ＣＯＤＡＳＹＬ型ＤＢ、ＣＳシステム等の実装要件です。一方で論理モデルとは、実装方式を排除したシステムが本来持つべき要件にそぎ落としたモデルになります。あまり大変さを知らないと、Ａ（現行物理モデル）からＤ（提案物理モデル）に簡単に書き換えられそうな気がしますので、その程度の予算しか組まないことが多々あります。
しかし、プロジェクトが始まってみると、そんなに単純な話しではないことが判ってきて、現行のプログラムから要件を抜き出してＢの現行論理モデルを作るためにドキュメントを補完しようという話しになります。しかし、プログラムには今の実行基盤の上でどのように動くかはコーディングされているものの、要件（なんのためにそのようにコーディングされているか）については書かれていません。従って、何が本来の要件なのかが判らないまま、どれが使っていないロジックなのかも判別できぬまま、ＣからＤへと突入していくことになります。お客様も本来の仕様をすべて定義するだけの工数を捻出できないため、「現行と同じ仕様にしてもらえれば良い」という話しになっていき、その現行と同じ仕様が何なのかがグレーなままで、プロジェクトが混乱していくことになります。
従って、刷新するためのプロジェクトにどの程度の費用がかかるかは、お客様とシステム構築業者が一体となって、ＡからＢの作業を一旦終わらせないと、概算を見積もることは難しいでしょう。
また、トランザクション量や取り扱うデータ量が大きなシステムであれば、新方式が性能等の非機能面でうまく行くとも限りませんので、先行してＣからＤの部分の基幹的な部分の検証も必要になります。
一気に刷新するとお客様側の有識者がネックになり上流工程の品質が確保しきれない場合もありますので、サブシステムごとに段階的に刷新化するシナリオを作るということも、プロジェクトの成功確率を上げるための一つの選択肢となるでしょう。
上記の「データ中心システム設計」は1980年代に出版された非常に古い書籍になりますが、最近では、Ｎ字モデルと呼ばれる場合もあるようです。
設計→製造→試験のＶ字モデルの前段で、まずは業務仕様を復元するという考え方は、同じだと思います。
刷新と機能追加は切り離した方がいい
刷新をするというと、ついでに様々な機能追加をして、機能的にもグレードアップさせたいという話しになりがちです。しかし、現行システムと刷新後のシステムの処理結果がまったく同一になるかという同値性確認を行いにくくなっていくので、純粋な刷新と機能追加は別フェーズとして分け、一旦は機能追加なしの刷新を完了させて十分に現行システムとの同値性を保証したうえで、機能追加を実施するとした方がプロジェクトの成功確率は高くなります。
日経コンピュータでは、動かないコンピュータなどの特集で、刷新システムが頓挫してしまったような話しはよく紹介されています。
しかし、どうすればプロジェクトの成功確率が上がるかという記事はまだまだ不足しているような気がします。安易に「ＣＯＢＯＬ絶滅」などという言葉であおる前に、成功させるためにどうすれば良いかという視点での情報提供を強化してほしいと思います。
コメント