奇策！レガシ撤退の混乱を避けるーレイヤードアプローチ

美味しい水をお探しですか？
定額制だからお水は使い放題！全て“月額料金”にコミコミ！
利用料金は業界最安値！

お荷物となったレガシから撤退して新しいシステムに移行したいと思っても、ユーザ業務の混乱を考えると気が重くなるという情シスは少なくないだろう。

新しいシステムに移行することでユーザ業務に対しても御利益があれば、まだユーザからの協力も得られやすい。しかし、そうではなく単にシステムだけが新しくなる場合、ユーザ業務が混乱したら苦情の嵐にさらされることになる。

とはいえ、いつまでもレガシを抱えたままでは扱えるエンジニアも居なくなり、ユーザ業務の変革に柔軟かつ迅速に対応するだけでなく、障害対応さえも難しくなる。そうなれば、情シスの存在価値を問われることになるのは火を見るより明らかだ。

なんとかユーザ業務の混乱を避けつつ、レガシから撤退する方法はないものか？

その手段の一つとして、入出力インターフェースだけを今まで通り同じとして、背後の仕組みだけ新しくするという奇策がある！

私が運用保守を担当していた出図管理システムも稼働から数十年を経過した極めつけのレガシだった。開発言語はPLI、データベースはIMSというメインフレームで稼働していた。

これをJavaとRDBMSによるオープン系のシステムにすることとなった。そこで、入出力画面はレガシのもととほぼ同じ構成として、データベース構造も既存の階層型から表形式にマッピングした。データベースは安全策としてメインフレームに配置した。

JavaのアプリケーションサーバからメインフレームのRDBMSにJDBC接続する構成は当時としては事例が少なかったようだ。

ユーザからは画面がメインフレームの端末からHTMLとブラウザになった程度で、業務的には何も変わっていないように見せた。その結果、業務に混乱をきたすこともなく、レガシを脱却し、新システムに移行することができた。

その後、新たな業務要件にも柔軟かつ迅速に対応することができるようになった。また、オープン系の性能向上に伴いメインフレームに配置していたRDBMSをオープン系に移行した。

この時はデータベース構造は全く変更なく、JDBS接続のデータソースをアプリケーションサーバ上で設定変更するだけなのでほぼノーリスクで実施できた。

さらに、入出力画面もHTMLの特性を活かしたリッチインターフェースへと進化し、より使いやす物へと変遷した。この場合も、業務の混乱は全く無かった。

このようなアプローチをレイヤードアプローチと言うのを後に知ることとなった。ようはユーザから見えている表の部分（プレゼンテーション層）と裏の仕組み（アプリケーション層、データベース層等）を切り分ける。そして、表の部分は変えずに裏の仕組みだけ変えることで業務の混乱を避けるわけだ。

ERPなどのパッケージ製品であっても、同様のアプローチをとることで業務の混乱を避けることができる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　●企業システム戦略兵法三十六計　混戦の計　第二十一計　金蝉脱殻
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

金蝉脱殻（きんせんだっこく）「金蝉、殻を脱す」

蝉が抜け殻を残して飛び去るように、あたかも現在地に留まっているように見せかけておいて主力を撤退させるのである。撤退の場合だけでなく、戦略的な目的で主力を移動させたい場合にもそのまま使える手段である。