バッチはもともとメインフレームの上で動くシステムで使われていた。しかし、アプリケーションが動作するコンピューター（プラットフォーム）をメインフレームからオープンシステムに乗り換えてコストを削減する動きが20年以上続いている。いわゆる「レガシーマイグレーション」だ。とりわけ近年はDX（デジタルトランスフォーメーション）を推進させるためにレガシーマイグレーションが活発になり、移行先にクラウドサービスを選ぶケースも目立っている。
レガシーマイグレーションの際には当然のことながらバッチも移行する必要がある。「クラウドでバッチができるのか」。オンプレミスのバッチに慣れた技術者ほどそう感じるだろう。そこで今回は、クラウドにバッチを移行したり、クラウドで新たにバッチを実装したりする際に知っておくべき、3つの「新常識」を紹介しよう。
新常識1：プラットフォーム移行ではバッチの内容は「見ない」
最初の新常識は「バッチが動作するプラットフォームをメインフレームからクラウドやオープン系サーバーに移行する際、バッチの内容は見ないほうがいい」ということだ。
「ツールなどを利用してバッチをなるべくそのまま移行するのがよい」。こう語るのはアクセンチュアのテクノロジーコンサルティング本部インテリジェントソフトウェアエンジニアリングサービスグループに所属する中野恭秀アソシエイト・ディレクターだ。いちいちバッチの内容を確認して移行先に合った処理やオンライン処理（リアルタイム処理）などに人手で書き換えていると、移行にかかる時間がどんどん延びてしまうと指摘する。
特に、メインフレームの更新時期が迫っている場合、そこまでに移行を終わらないと、再び更新費用がかかってしまう。まずはそのまま移行することに専念し、バッチ処理については新しいプラットフォームの上で見直すという2段階で分けて考えるのが賢いやり方だ。
アクセンチュアは、三菱重工業の相模原拠点がメインフレーム上のシステムを2020年にプライベートクラウドに移行するプロジェクトを支援した。アプリケーションは4万5000本のCOBOLプログラムから成り、1500万ステップという規模。これを自動変換ツールで全てJavaに書き換えた。テストなども全て自動化し、品質を担保しながら短期間で移行した。
同システムの処理のうち、約7割がバッチ、約3割がオンラインだったという。三菱重工からは「バッチ処理で回していた業務をオンライン化したい」という要望があった。だが、巨大システムでそれを実現するには、プログラムの内容や業務フローを大幅に変える必要があり、膨大なコストと時間がかかる。そこで実際にはバッチ処理には手を入れずに移行することになった。
三菱重工の事例では、システムの維持管理費用を移行前の10分の1にまで圧縮できたという。中野氏は「ここまで費用を削減できれば、浮いた費用を使って移行後にバッチ処理を書き換えていけばいい」と語る。
「例えば、いったんそのまま移行し、毎年1割のプログラムをクラウドに適したようにつくり変えていけば、10年後にはシステムが生まれ変わる。メインフレームで動いているシステムは、長く稼働している経緯もあり保守すればするほど処理やプログラムがからみあって内部構造がひどいことになっている。移行で浮いた維持管理費をクラウド向けの改修に回せば、（複雑さがリセットされるため）保守すればするほどシステムがきれいになる仕組みを実現できる」（中野氏）。
