この記事は、株式会社FIXERの cloud.config Tech Blog に掲載の記事を再編集したものです。
レイチェルです。以前にopensource COBOL 4Jを用いてCOBOLソースをJavaに変換する簡単な例を示した記事を書きました。
今回は、COBOL変換を含めたもっと広義のモダナイゼーションを行う際のことについてお話させていただきます！
モダナイゼーションを行う際は、実際の変換・移行作業を行う前の 準備 が非常に重要です！
そこで、最低限ここは抑えておきたい！というポイントを 3つ に絞ってご紹介させていただきます。
その1. 事前調査
まずはモダナイゼーション対象のシステムに、どのような技術が使用されているのかを調査することが重要です。
事前に知っておきたい情報には、以下のような例があります。
- COBOL資産にはベンダー独自の仕様が含まれているのか
- 含まれているとしたら、どのような仕様のCOBOLなのか
- COBOLランタイムの仕様書は手に入るのか
- ベンダー独自のライブラリは使用されているのか
- ミドルウェアはベンダー独自のものか
- 利用しているDBMSはどのような仕様なのか
- インフラ構成とシステムの絡み方
- etc...
挙げ始めるときりがないですが、要するに 現行システムについて少しでも多くの情報をかき集め、まとめておく 必要があります。
これをしていないと、以下のような問題が頻発することでしょう。
- Javaに変換後のシステムの動作が、現行システムと異なる
- 動作差異の原因がわからない
- 動作差異の修正を行って、再度COBOLを変換しても、別の差異が発生する
- 差異発生→修正→変換→差異発生…を延々と繰り返して工数が膨大になる
- COBOLからJavaに変換した際に、パフォーマンスが著しく劣化する
- オンプレからクラウドにリフトした際に、パフォーマンスが著しく劣化する
- DBMSを移行した際に、動作しないSQL文が大量に出てくる
- DBMSのパフォーマンスが著しく劣化する
- etc...
地獄ですね。無限の予算と無限の時間があるのであれば事前調査無しで挑んでもいいですが
賢く低コスト・短期間でモダナイゼーションを実現したいのであれば、事前調査をすっ飛ばすことはかえって遠回りとなることでしょう。
その2. 現行システムのデバッグ環境構築
現行システムがどのように動作するのかを知る方法として、仕様書を読み込んだり、ソースコードを眺めたりするのもいいでしょう。
しかし、詳細な動作を知ることができる最強の手段は 現行システムのプログラムをデバッグ することです。
デバッグ環境構築さえ準備してしまえば、コンパイラの動作・ランタイムの動作・現行DBMSの動作 を実際のプログラムやSQLの動きを見ながら確認できます。
そして、デバッグで理解した動作をCOBOL→Java変換に盛り込めば、より現行システムと動作が一致した状態でモダナイゼーションを実現することが可能となるでしょう！
逆に、デバッグ環境が構築されていない場合は詳細なプログラムの動作を知ることができず、前述の通り 地獄の差異修正ループ に陥ってしまうことでしょう。
怖いですね。
その3. CI / CDパイプラインの構築
ここまでは 地獄の差異修正ループ を如何に無くすのか、ということに焦点を当てていました。
しかし、システム開発とは身も蓋もないことを言えばトライ・アンド・エラーの繰り返しです。
どんなに入念に事前準備を行っても、多少の行ったり来たりは発生してしまうことでしょう。
その際に、ビルドやデプロイの手順ミスや単体テストの不実施・実施ミスなどにより、しょうもないデグレーションが発生してしまっては、さらなる工数増加へと繋がっていってしまいます。また、そんな環境で生み出されたシステムは信頼性も不安まみれです。
そこで重要となるのが、モダナイゼーションの本格実施前にCI / CDパイプラインを予め構築しておくことです。
CI / CDが何なのかという詳しい解説はこちらの記事でも見ていただくとして、ミスが発生する余地のある作業は徹底的に自動化してしまえば、無駄な工数を削減することに繋がることでしょう。
ミスをするのはいつだって人間なのですから。
まとめ
今回は、モダナイゼーションを行う上で重要な事前準備3点をご紹介しました。
- 事前調査
- 現行システムのデバッグ環境構築
- CI / CDパイプラインの構築
これらの事前準備を怠らないことで、地獄の差異修正ループ や しょうもないデグレーション を削減、工数も削減！いいこと尽くしですね。
皆様も焦ってマイグレーション後のことばかり考えず、まずは今あるシステムに目を向けてあげてください。