企業IT業界では、「メインフレームは時代遅れで、いずれ消えていくプラットフォームだ」という根強い誤解があります。しかし、Software AG の主席システムエンジニアである Bob Jeffcott 氏は最近のウェビナーで、「メインフレームの終焉が近いという話は大げさに語られすぎている」と指摘しています。
実際、IBM Z のワークロードは増加の一途を辿っています。IBM や業界アナリストによれば、メインフレーム利用企業の 70% が毎年ワークロードを増やしており、IBM システムの 95% は依然としてミッションクリティカルなアプリケーションに COBOL を大きく依存しています。しかし、この成長には限界があります。容量の逼迫、コストの急騰、そして重要なサービスレベル契約（SLA）を満たせなくなるリスクが常につきまとっているのです。
では、組織は大規模な移行による混乱を招くことなく、この成長にどう対応できるのでしょうか。その答えは、すでに所有しているハードウェアの中にあります。
モダナイゼーションのパラドックス：なぜ書き換えは失敗するのか
汎用プロセッサ（GP: General Processor ）の容量逼迫に直面すると、多くの組織は COBOL ワークロードのモダナイゼーションプロジェクトに踏み切らざるを得ないと感じます。そして、こうした取り組みは一般的にいくつかのパターンに分類されます。
- リライト(書き換え)：アプリケーションを最新の言語で再構築すること。
- リプレース：アプリケーションを新しいクラウドネイティブの代替システムで丸ごと置き換えること。
- リホスト：ワークロードを別のプラットフォームへ移すこと。
しかし、これらのアプローチには多くのリスクが伴います。予測しづらいコスト、長期化しがちな導入期間、そして新しいシステムが元の COBOL コードに何十年も蓄積されてきたビジネスロジックを再現できないことで機能が失われる、といった問題が発生しがちです。さらに、多くの場合、すべてを実行するか、何も実行しないかの二者択一的な選択肢となり、モダナイゼーションが行き詰まった時には、もはや後戻りができない状況になっていることも少なくありません。
新しい選択肢：JOPAZ で GP の余力を取り戻す
JOPAZ は、業務を止めない新たな選択肢を提供します。メインフレームから移行するのではなく、JOPAZ を使えば既存のプラットフォームを維持しながら、GPへの負荷を大幅に軽減できます。これは、COBOL のバッチワークロードを IBM zIIP エンジンで実行可能にすることで実現されます。
ワークロードを zIIP 上で実行することで、組織は GP のキャパシティを即座に解放し、他の優先度の高いタスクに振り向けることができます。
JOPAZ の仕組み：内部で何が起きているのか
標準的な COBOL バッチワークロードを zIIP 対応のワークロードへ移行するプロセスは、4 つのフェーズで進みます。
- 識別：GP リソースを最も消費しているバッチジョブを特定する
- コンパイル：JOPAZ は既存の COBOL ソースコードを直接 Java バイトコードへコンパイルする
- 実行：このバイトコードは Java 仮想マシン（JVM）上で動作し、ワークロードを zIIP エンジンで実行可能にする
- スケール：必要に応じて、対象となるバッチジョブの数を増減できる。JOPAZ は段階的にワークロードを最適化するアプローチであり、業務を止めることなく進められる
重要なのは、COBOL コードを一切変更する必要がないという点です。ビジネスロジックはそのまま維持され、開発者は従来の環境で引き続き作業できます。
リアルな効果
導入事例 1：小売エネルギー事業者
この組織は、DB2 の重いワークロードに悩まされていました。そこで、データベース負荷の高いバッチ処理をどれほど効率的に扱えるかを確認するために、JOPAZ を導入しました。
- わずか１基のzIIP エンジンで、バッチ COBOL の GP CPU 使用量を 76％ 削減することに成功
- zIIP エンジンを 2 基に増設：初期の成功を受けて 2 基目を追加したところ、CPU 削減率は 92.9％ に到達
- 効果：大量の SQL 処理があっても、JOPAZ は実行コードだけでなく、関連する DB2 の SQL 処理まで zIIP エンジンにオフロードできた
導入事例 2：北米の会員サービス組織
この大手自動車・金融サービス企業にとって、コスト抑制は最重要課題でした。彼らは JOPAZ の効率性を検証するため、2 つのバッチ処理ストリームを連続して実行しました。
- 結果：バッチ COBOL の CPU 使用量を驚異の 94.84％ 削減
- 効果：確保した MSUにより、組織は既存のインフラで新たなワークロードにも対応できるようになった
セキュリティと統合
JOPAZ に関して最もよく寄せられる質問のひとつが、既存のメインフレームのセキュリティとどのように連携するのか という点です。JOPAZ は、メインフレームのエコシステムにおける“良き住人”として設計されています。
- データアクセス：既存の Db2、VSAM、Adabas のセキュリティメカニズムをそのまま利用
- セキュリティ：Java のセキュリティモデルを活用しつつ、RACF、TopSecret、ACF2 といった標準的なメインフレームのセキュリティマネージャーに準拠して動作
- 運用フロー：標準的な JCL（Job Control Language）で JVM の実行を起動するため、既存のスケジューリングや運用ワークフローにシームレスに適合
段階的な導入
負荷の高いアプリケーションから着手し、効果を確認してから他領域へ拡大することで、従来のモダナイゼーションに伴う不確実性を排除できます。
すでに持つ力を最大限に引き出す
メインフレームは依然として、安定性・セキュリティ・高トランザクション処理の面で最高水準の存在です。JOPAZ を使えば、プラットフォームを変えることなくモダナイズでき、キャパシティ回復・SLA 達成・CPU 削減を同時に実現できます。
JOPAZ が、スマートな COBOL ワークロード分散によって処理リソースをどのように取り戻せるのか、さらに詳しくご確認ください。
How Global Leaders are Solving the Mainframe Capacity Crisis: 3 Real-World Case Studies
Companies improved CPU efficiency by redistributing COBOL workloads with JOPAZ, achieving substantial cost savings and performance enhancements without altering existing applications.
エキスパートはいつか引退します。しかし、その知識は引退させる必要はありません。
経験豊富なAdabas & Naturalの開発者が定年退職を迎えるにつれ、組織は彼らと共に数十年にわたるミッションクリティカルなビジネス知識を失うリスクに直面しています。Software AGの開発近代化ツールと手法は、長年にわたり在籍してきたチームが持つ深いアプリケーションロジックや運用上の知見を組織が維持できるよう支援します。
Adabas & Natural の次世代エキスパートを育てる
Organizations face a growing risk as Adabas & Natural experts retire; bridging knowledge gaps through training, mentorship, and modern tools ensures system continuity.