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

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

成果にこぎつけるためには、各チームはなにを選択し、なにを捨てたのか？

　今回のハッカソンのポイントは「取捨選択」に尽きると思う。難易度の高い課題を、限られた時間でこなし、成果にこぎつけるまで、なにを選択し、なにを捨てるか？　各チームの決断と実行が最大の見どころであった。

　個人的に、もっともチャレンジングな取り組みだと思えたのは、日本アイ・ビー・エム システムズ エンジニアリングだ。「単なる『機械的な移行』ではなく、AIネイティブな再設計に挑む」を掲げ、22のサブシステムの業務ロジックを保持したまま、マイクロサービス＋バッチパイプラインに分割。コンテナ化、IaC、宣言的なデプロイなどのクラウドネイティブなシステムに移行するというもっとも大胆な移行計画だった。

AIネイティブな再設計に挑んだ日本アイ・ビー・エム システムズ エンジニアリングのチーム

　技術スタックも、業務ロジックをJava21とSpring Boot 3.3で手堅く仕上げつつ、外部連携や明細はPython、マスタ／照会APIのバッチ内サブルーチンはGo、3270 TUI想定のオペレーターUIはTypeScriptをそれぞれ採用。実行基盤もAzure Kubernetes Service (AKS)のコンテナを用い、TerraformでAKS、PostgreSQL、ネットワークをIaC化している。「インフラ屋」の皮をかぶったAuzreチームだからこそ、こうしたクラウドネイティブ化が実現できたのだと推察する。

　チャレンジの代わりにあきらめたのは、現行システムと真システムの処理のべき等性を担保する「現新比較」だ。「モダナイゼーションでもっとも重要な現新比較ってどうなりそうですか？」という比毛氏の質問に対して、「正直、うまくいかないと思っています（笑）」との答えが返ってきた。比毛氏の指摘通り、現新比較は重要だが、ハッカソンの限られた時間で得意分野を活かしたチャレンジに振り切ったのは素晴らしかった。

　逆に「安全側に倒した」のは、NTTデータグループだ。午前中の解析でアプリが複雑なことがわかった段階で全面移行をあきらめ、とにかく動きそうなところを探したという。特に難易度の高いデータ周りは、基本いじらず、既存構成もなるべく保持・抽象化し、VM上で稼働させることにした。

安全側に倒したNTTデータグループのチーム

　インフラの検討を短期に決着させた結果、チームはアプリに集中できたという。COBOLのコアロジックや周辺のサブシステムを段階的にJava化しつつ、レガシーコードとの依存を可能な限り排除する設計を目指した。安全に倒しつつ、どこまでAIに任せるかに悩み、Issue管理に悩み、知らない言語仕様に悩みつつ、なんとか走りきった若手チームにもエールを送りたい。

　BIPROGYチームは、COBOLからJavaのモダナイゼーションを実現し、少しでもAzureで動作させることを目標とした。ただ、コードの解析からすべての機能のモダナイゼーションは難しいと判断。マスタ参照系に絞ってデプロイすることにした。動作環境もAKSではなく、Azure Container Appsを採用し、アプリのモダナイズにパワーを割いた。まさに取捨選択の連続だ。

　実際のモダナイゼーションでは、GitHub Copilotでコードを解析し、仕様書・設計書を生成する「Code to Doc」を実施。「コードの解析・実装はすべて任せできた」とのことで、GitHub CopilotやAutopilotは非常に優秀だったとのこと。これまで使う機会のなかったCodespacesに関しても初めて体験できてよかったという。普段使い慣れないツールを試せるハッカソンの面目躍如だ。

GitHub CopilotによるCode to Docで仕様書や設計書を作成したBIPROGYチーム

　BIPROGYのチームが痛感したのは、人間の認知負荷がボトルネックになったことだった。COBOL、Azure、Javaそれぞれで詳しいメンバーはいたが、仕様の理解と再設計に時間がかかってしまったため、ある程度の実装までを最初に作って、あとから修正した方がよかったという反省もあった。とはいえ、ランチのときに「絶望です」と話していたメンバーがいたのも考えれば、すばらしい成果だったと思う。