古式ゆかしき銀行の夜間バッチがGitHub CopilotとAzureで生まれ変わる

ラスボスCOBOLを倒すために、7チームはなにを選択し、なにを捨てたのか？

「あえてCOBOLを残す」という選択肢もあった

　今回のGitHub Copilot Lv3の特徴の1つは、移行先の自由度が高いこと。Azure上にデプロイされていれば、技術スタックはどれを利用してもよい。こうした中、言語特性を考えて、あえてCOBOLを残すという選択を行なったチームもあった。

　富士通のチームは「各機能の特性に応じた言語を選択してマイグレーションする」を掲げ、外部接続と登録、帳票出力はPythonとpsycopgに移行したが、計算に関しては計算精度の維持を目指してCOBOLをあえて残した。

計算精度の維持を目指してCOBOLプログラムをあえて残した富士通チーム

　これに対して、比毛氏は「COBOLの得意なところ、そうでないところを判断しています。実案件でもCOBOLをやめたいという方もいますが、『COBOLの得意な部分はありますよ』とお話しをします。COBOLの課題は膨大な量なので、（富士通のチームのように）取捨選択して利用するのはベストプラクティスなのではないかと思いました」とコメントした。

　コメンテーターの日本マイクロソフト 藤原淳子氏も、「言語の得意、不得意は確実にあります。『モダナイゼーションせよ』と言われると、絶対に他の言語にしなければいけないと思いがちですが、実際は工数や作業量を考慮しなければならない。残さなければならないのは、コンピューターがやるべきところ、言語が得意なところ、人間が得意なところ。今回はPythonのような”ハイカラな言語”とCOBOLをコラボレーションした素晴らしいシステムだと思います」と高く評価した。

開発現場を知るからこそのコメント連発だった日本マイクロソフト 藤原淳子氏

　野村総合研究所チームも、COBOLリライトの優先順位をあえて落とした。「私たちは金融系システムを担当しているので、勘定系システムはおいそれリライトできないのではないかと身構えてしまった」というのが背景だ。まずは全モジュールをリホストして、正しい挙動を確認し、ストレッチとしてリライトを検討することにした。金融系チームならではの手堅いアプローチだ。

リライトにこだわらず、アーキテクチャの刷新を目指した野村総合研究所のチーム

　実際、リライトまでは進めなかったが、アーキテクチャを刷新したことで、現行システムの課題の多くはクリアされた。一体型・密結合だったCOBOLプログラムは、フロントをReactで再構築し、API経由でCOBOLコンテナを呼び出す構成に。UI/API/業務処理/データアクセスなどの責務や影響が分離され、柔軟性や拡張性、評価検証まで可能になった。リライトにこだわらず、現行システムを換骨奪胎し、あるべき姿にモダナイゼーションしていくフローは、現場でも役立ちそうだと感じられた。