DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

年初めのブログのテーマはダウンサイジング。何を今さら？と思われる方も多いと思われるが、依然としてメインフレームを保有している企業は思いのほか多い。その用途は金融機関の勘定系をはじめとする大手企業の基幹系業務アプリの実行基盤が殆どである（基幹でなければとうにオープン化されている）。「ベンダーによる数年先の部品供給もＣＯＢＯＬエンジニアの確保も出来ているので、今はそっとしておこう」とお考えのCIOも多いと思われる。これはこれで１つの戦略であるが、希少性による今後のコスト増を考えれば、１０年先を考えて今から手を打っておく事を推奨したい。なぜなら、その上で稼働するアプリの規模が大きく、短期間でオープン環境に移行することが難しいからだ。ましてや、歴史的経緯からマスタデータの発信元や社内外システム間の通信機能等の、ＨＵＢ的役割を担っている場合はなおさらである。

今回はこのような状況下にあるメインフレームの、撤去に至るまでの道筋についてお話したい。幸運にも1990年代後半〜2000年代にERPによるビッグバン・ダウンサイジングを成し遂げた企業でも，ＥＲＰとともにマスタデータがロックインされパッケージ製品の置き換えがままならないケースも同類である。以下にその手順を示したので、図１とともにご覧いただきたい。

①最初にやるべき事はメインフレームが有する上記のHUB機能の外出しである。これをやらない限り、部分的ダウンサイジングを実行しても、データ流通経路としてメインフレームが君臨し続ける。具体的にはバックナンバーに度々記載したMDH（マスタデータハブ)や、TDH（トランザクションデータハブ)、さらには通信ＨＵＢをオープン環境に作ることを指す。この段階での共通マスタ及び共通トランザクションデータの流れはメインフレーム又はオープン系発生元アプリ→HUB→配信先オープン系アプリとなる。

②オープン系データHUBの環境が整った段階で、次なる施策はメインフレーム上に残っているマスタ入力システムのオープン環境移行である。これにより共通マスタデータの流れは全て、オープン環境→HUB→配信先オープン系アプリとなりマスタデータのメインフレーム依存が解消される。またこの段階で、共通マスタを必要とするメインフレーム上の残存アプリへは、ＨＵＢ→メインフレームへと逆の流れとなる。一方、メインフレーム発の共通トランザクションデータの流れは依然としてメインフレーム→MDH→オープン系アプリである。

③上記①②の後、はじめて業務アプリケーションのダウンサイズを実行することになる。ダウンサイジングには大きく２通り存在する。１つはビジネスニーズに基づく“再構築”であり、もう１つはオープン系への単純コンバージョンである。優先順はビジネスニーズによる再構築が先で、次に（メインフレーム外しによる）コストダウンを前提とした単純コンバージョンが続く。この２通りのダウンサイジングをミックスさせ、綿密なロードマップを作成する。この段階で重要なことは、あくまで新規アプリのＲＯＩが優先であり、ダウンサイズだけを目的としない事である。そして、各種業務アプリを順次オープン系へ移行する過程では、ＴＤＨによる“疎結合アーキテクチャ”が移行リスクを担保することになる。

④最終段階では、メインフレーム上に残存する幾つかの小規模バッチシステム群を、まとめてオープン系へ移行する“ミニプロジェクト”を企画実行し、全ての業務アプリのダウンサイジングを終える。ここでは”メインフレーム撤去”を強く意識する。そして、長い間、活躍していただいた”ホスト”に別れを告げる。（余談であるが、前職でのメインフレーム撤去時にはそのエンブレムを剥ぎ取り、しばらくオフィスに飾っていた。）

今回は巨大なレガシーシステムの無理ないダウンサイジングのやり方をご紹介した。この方式は移行リスクを最小化し緩やかなダウンサイジングを可能とするものであり、同時に企業システムをデータ中心アーキテクチャーに変えて行くものである。この方式の成功要因は用意周到な計画と一貫したアーキテクチャポリシーにある。「時間もかかりそうだし、どうもいろいろ面倒だね。」と思われる御仁に対して、ビッグバンによる一括ダウンサイジングの敢行を止めはしないが、今一度、リスクを考えてみてはいかがであろうか。ＩＴ戦略は、CIO自らが理解し、そのシナリオが”勝算アリ”と納得できるものでなければならないので。