レガシーマイグレーション～できれば姑息なマイグレーションはしたくない～

はじめに

私、最近思うんです。

何年か前から「レガシーマイグレーション」とか「ホストマイグレーション」というプロジェクトを見聞きしますが、どうにも姑息なものが多いのではないかと。

もちろん、色々な事情があってそうなっているとは思いますが、今回は、一部理想論や絵空事（願望）も含みつつ、どんなマイグレーションが理想なのかを考えてみたいと思います。

そもそも「レガシーマイグレーション」とは

レガシーマイグレーションとは、レガシーシステムをイマドキのシステムにマイグレーション（移行）することを指します。

レガシーシステムの多くは「汎用機」とか「メインフレーム」と言われるようなコンピュータシステムの黎明期の産物で、今ではこのシステムのベンダーはIBM社や富士通社などごく少数しかなく、2022年には富士通社も2030年度に撤退するとのニュースがありました。

そして、経産省のDXレポートではレガシーシステムについて「老朽化、肥大化・複雑化、ブラックボックス化したシステム」と記載されており、マイグレーションする理由もこの辺りにあります。

姑息なマイグレーションとは

「なぜレガシーマイグレーションをするのか」というと、上述の通り、ベンダーの撤退等によるサポート切れの対策や、コンピュータシステム黎明期から改修を重ねた末の肥大化・複雑化、ブラックボックス化の解消が目的です。

しかしながら、実際に私が見聞きするマイグレーション案件だと、

• （サポート切れとなる）汎用機から、
  （今のところサポートのある）別の汎用機へのマイグレーション
• レガシーシステム内のCOBOLプログラムを、
  ツールを用いて自動変換で新システムへマイグレーション

等といった方針の案件が多いです。

果して、これでレガシーシステムの根本的な問題（マイグレーション案件を起こした理由）が解決するのでしょうか。

①については、世界的な動きとして、もう数十年前からレガシーシステムはなくなると言われてきており、事実なくなりこそしていない物の先細りしており、今後汎用機がメインのプラットフォームとして再び脚光を浴びることは考えにくいです。①は次のサポート切れまでの一時しのぎにしかならないのではないでしょうか。

②については、「肥大化・複雑化、ブラックボックス化」が全く解決されません。むしろツールで自動変換するとなると、ブラックボックス化については、より進行してしまう、とすら言えるのではないでしょうか。

これでは、レガシーマイグレーションの本来の目的が失われてイカンと思うのです。

理想的なマイグレーションとは

簡単に言えばレガシーシステムの根本的な問題（マイグレーション案件を起こした理由）が解決するマイグレーションです。

しかし現実的には、最早システム的なマイグレーションだけでは解決できず、（そのシステムを使う）業務レベルでマイグレーションしないと不可能だと考えています。

なぜ、システム的なマイグレーションだけでは解決できないのか

システム的に理想的なマイグレーションを行うためには、

• マイグレーション元となる（肥大化・複雑化、ブラックボックス化した）レガシーシステムを読み解き
• マイグレーション先となる近代的なシステムに最適化して構築する

必要があります。

①を担える技術者は高齢化や引退が進んでおり、若手が進んでこの分野を習得するメリットも薄いので、まず対応できる要員の確保が難しいです。さらにand条件として、②の近代的なシステムに合わせて構築できる技術者となると、さらに要員確保は困難になります。

②は実は①をインプットとせずに行う方法として、イチから業務をシステム化するアプローチが取り得るのですが、これも今となっては難易度が高いでしょう。

今の現役世代の多くは、新入社員の時代から業務システムがあり、それを日常的に活用してきました。その結果、事業会社の人間であっても現行業務をシステムなしでは完遂できなくなっているケースが珍しくありません。（時間さえあれば紙と鉛筆で、、、ではなく、システムで何をやっているかを把握できていない。2011年の東日本大震災に端を発する計画停電などで少し表面化しましたね。）

このため、事業会社にマイグレーションの要件を出してもらおうとすると「現行通り」が横行してしまい、結局「現行」はレガシーシステムの中にあるので、①を担える技術者のみぞ知る有様になってしまうのです。

業務レベルでのマイグレーションとは

ここからは、理想論や絵空事（願望）も含めた内容になります。

業務レベルでのマイグレーションとは、システム目線では、最早マイグレーションではなく、「モダナイゼーション」や「リプレイス」の方が近いです。

レガシーシステム構築当時はなかった、新たな技術やパッケージを用いて、イチから業務要件とシステムをセットで構築するのです。

この手法であれば、システム的には新規構築なので、レガシーシステムが移行元として登場することがなく、レガシーシステムに対する知見は必要ありません。

この方針に基づいてプロジェクトを起こすにあたっては、事前に業務要件をイチから描けるメンバーの育成が必要となり、時間もコストもかかると思われます。

しかし、これができればレガシーシステムに縛られずに、優れた拡張性や柔軟性を持った近代システムの上で事業展開ができるのではないかと思うのです。

コンサル会社の一社員としては、いずれは、このような大業な理想論を事業会社の方と共有し、現実に向けて並走できるような未来を描いていきたいと思います。