text＝田口 智大 日本アイ・ビー・エム システムズ・エンジニアリング
メインフレームは長期にわたって、ミッション・クリティカルな業務を支え続けてきた歴史がある。それゆえにCOBOL、PL/I、アセンブラなどの言語を中心としたIBM zSystems上のアプリケーション開発の現場では、旧来からのやり方に引きずられ、開発生産性を上げにくい状況が発生している場面が多々見られる。
そこで本稿では、IBM zSystems上のアプリケーション開発環境をモダナイズする技術、手法について解説する。
IBM zSystemsでの
「モダナイゼーション」の位置づけ
「モダナイゼーション」という言葉は、語り手や文脈によって多様な意味合いを持つ。
たとえばメインフレームを廃止して別のプラットフォームに置き換えるようなアプローチを、「モダナイゼーション」のソリューションとして提供している場合もある。
これにはリホスト（既存の言語をそのまま別プラットフォームで動かす）、リライト（COBOL→Javaのように機械的に言語を変換する）、リビルド（完全に作り変える）といったアプローチも含まれる。
ただしこれらのアプローチには、次のような課題もある。たとえばリホスト／リライトは既存システムの構造に依存する部分がそのまま移植されることになり、かえってメンテナンスが難しくなる可能性がある。またリビルドの場合は、期間や必要リソースが膨大になる懸念がある。
これに対してIBMの戦略は異なり、メインフレームを活用しつつ新しい技術を取り入れていくことで、「モダナイゼーション」の実現を目指している。このことは、以下のサイトやニュース・リリースで明確に打ち出されている。
◎IBM Zに関するIBMの戦略的取り組み（IBM Z憲章：2020年版）
◎IBM、IBM Z and Cloud Modernization Centerを新設し、ハイブリッドクラウドを加速
◎IBM Z & Cloud モダナイゼーション共創センター
IBM zSystemsでは、コアとなるビジネスロジックやデータは従来から実績を積み重ねてきたプラットフォーム上で確実に稼働させつつ、クラウドやOSS（Open Source Software）などに代表される新しいオープンなテクノロジーを取り込むことで、DX戦略にも柔軟に対応できるような新しい利用方法、連携方法を提供するよう拡張を続けている。つまり、双方の「いいとこ取り」ができるプラットフォームであると言える（図表1）。
IBM zSystemsが掲げる「モダナイゼーション」は、メインフレームを捨て去ってクラウドに乗せ換えるという意味ではなく（単純なリホスト／リライト／リビルドではなく）、IBM zSystems上の「実績を積み重ねた価値ある資産」をベースに、新しいテクノロジーを活用した利用形態に変えていくことを意味している。
その意味で、COBOL、PL/I、アセンブラなどの言語で書かれたアプリケーションをメンテナンスしていくための開発環境をモダナイズしていくことは、非常に重要なポイントになる。
開発環境モダナイゼーションの3つの観点
アプリケーションの開発サイクル（図表2）全体を見た時には、IBM zSystems上でも新しい技術や手法が適用できる場面が増えてきている。
それぞれのフェーズで適用できる手法の選択肢も増えているが、ここでは軸となる3つの観点で開発環境をモダナイズするテクノロジーについて解説する（フェーズでいうと、基本的には図表2の赤枠で囲ったコーディング～テストの部分に相当する）。
（1）開発／テスト環境をクラウドにオフロード
メインフレームの開発／テスト環境の課題として、「限られたリソースをやりくりしてテストを実施しなければならない」「占有利用が難しい」といったことが挙げられる。このような課題は、クラウド環境を活用することで改善が見込める（図表3）。
これまでもインテル・アーキテクチャのLinuxマシン上でz/OSをエミュレートする製品として「ZD&T」（IBM Z Development and Test Environment）が提供されている（旧RD&T）。
これを利用することで、実際のIBM zSystems上の負荷を下げ、安価なPCサーバーでの開発を実現していたが、最近ではクラウド上でもこの技術が利用できるよう拡張されている。
具体的には、「IBM Wazi Developer for Red Hat CodeReady Workspaces」が提供されている。これを使用することで、クラウド上のRed Hat OpenShiftクラスタ上でIBM zSystemsのエミュレータが稼働することになる（z/OSがPodとして稼働するイメージ）。
開発者など利用する側にとってみれば、PCOM（3270エミュレータ）やMicrosoft Visual Studio Code （以下、VS Code）、Eclipseベースのツールなど（後述）からアクセスするので、接続先が実際のIBM zSystemsなのか、クラウド上のWaziによる疑似z/OS環境なのか、その違いを意識することなく同じように操作できる。
クラウド上に環境を構築することで、必要な時に環境を複製して利用し、不要になった環境は破棄する、という操作が柔軟に実行しやすくなる。少人数のグループ単位（極端に言えば個人単位）に環境を払い出すことも容易になるので、環境の棲み分けや占有利用のための時間調整といった苦悩から解放される。また、若手育成という観点での研修／教育用プラットフォームとしての利用も有効と考えられる。
ZD&TやWazi Developer for Red Hat CodeReady Workspace といった製品は、通常のソフトウェアとして提供されており、ライセンスを購入すれば、オンプレミス環境／クラウド環境のいずれでも製品を導入して利用できる。IBMは2022年2月、これをさらにクラウド環境に適した形で提供するため、「Wazi as a Service」というオファリングの開発意向表明を行った。
◎IBM、ミッション・クリティカルなアプリケーションのモダナイゼーションをハイブリッドクラウドでシンプルに実現
これは2022年下半期に提供される予定なので、まだ正式リリースではないが、これによりクラウド上でLinuxの仮想サーバーをプロビジョニングするのと同じようなイメージで、z/OS環境を構築できるようになる。また従量課金などにも言及されており、クラウドに適した新たなライセンス料金体系になるため、よりクラウド環境を活用しやすくなると期待される。
（2）リッチなUIの活用
メインフレームの操作に使われるUIとしては、PCOM（Personal Communications）に代表されるようないわゆる3270端末エミュレータがある（図表4）。
最近では、z/OSMF （z/OS Management Facility：z/OS V2.2からz/OSのベースに組み込まれて提供される管理用コンポーネント）によるWebベースの操作や、USS（Unix System Service）によるUNIXライクな操作も可能となっている。しかし実際の現場では、今でも3270ベースのUIを使用する場面は多く、「メインフレームは古い」という印象を与える大きな要因になっている。これはアプリケーション開発ツールの観点でも同様である。
マウスを使わないファンクションキーを駆使したオペレーションや、1画面がキャラクタベースの限られた情報量であるがゆえの軽量な動作、といった感覚に慣れているユーザーにとって、3270端末エミュレータは使い勝手がよいかもしれない。しかし今時のUIや分散系アプリケーションのリッチな開発支援機能を備えるツールと比べると、コード開発支援機能としてはかなり貧弱に思える。
これまでz/OS上のCOBOL、PL/I、アセンブラ等の開発支援ツールとして、IDz（IBM Developer for z/OS）というEclipseベースのツールが提供されていた。最近ではこれに加え、オープン系のアプリケーション開発ツールとして人気の高いVS Codeでも、z/OSアプリケーションを開発できるように拡張が進んでいる。
VS CodeにIBM Z Open Editor という無償のExtensionを組み込むことで、VS Codeからz/OSに接続してCOBOLソースコード編集、JCLサブミットなどができるようになる。その際、リアルタイムの構文検査やポップアップでCOPY句の中身を表示するなど、リッチな開発支援機能が提供される（図表5）。
この機能は、Zoweと呼ばれるフレームワークの一部がベースになっている。Zoweは、z/OSのリソースをオープンな技術を使って活用するためのフレームワークを提供する。
このフレームワークの中にはWindowsやLinux環境からCLI（Command Level Interface）でz/OSを操作するためのZowe CLIというコンポーネントがあり、VS CodeのExtensionでは内部的にはそれを利用している。
VS CodeをUIとして利用する大きなメリットとしては、大きく以下の2つ挙げられる。
1つ目は、Eclipseと比較すると軽量であること。起動時間は圧倒的にEclipseよりも速い（Eclipseのほうが1日の長があるだけに機能も豊富なので、そこはトレードオフになると思われる）。軽量さだけで言うと、3270エミュレータにも分があるが、開発ツールとしての機能が限定的すぎる。VS Codeはリッチな開発支援機能を提供している上に軽量な操作感で扱えるので、バランスの取れたUIを提供している。
2つ目は、コスト面でのメリットである。VS Codeそのものが無償で利用できる上に、IBM Z Open Editor Extension、そのベースとなっているZowe CLIなど、これらはすべて無償で利用できる。接続先となるz/OS側は、z/OSMFの構成を行えばよく、こちらも追加のライセンスコストは不要である。VS Codeと連携してデバッガーやビルド操作を行いたい場合は、別途有償のツールが必要になるが、無償の範囲で実施できるCOBOLソース編集やJCLサブミットなどの操作だけでも、メリットは充分に感じられるだろう。
VS Codeはあくまで開発支援機能という位置づけであるため、システム管理の側面などを見ると、3270端末エミュレータを完全に置き換えるまでには至らないが、開発目的に特化したUIとして有用なツールと考えられる。
とくに役割分担を明確に行える開発体制が組めるのであれば、z/OSの操作に馴染みのない開発者でも、VS CodeやEclipseを使うことで、COBOLやPL/Iなどのアプリケーション開発に専念できるだろう。
（3）開発プロセスの見直し
前述した例は、UIとして使用するツールを変えるという話だったが、ここで取り上げるのは、それをもう1歩進めて開発プロセスを改善することを考える。
オープン系のアプリケーション開発でも用いられるCI/CD（Continuous Integration/Continuous Delivery）パイプラインに関する技術をz/OSアプリケーションの開発にも応用できるので、その具体的な方法を紹介する。
ここではGitでソースコードを管理し、個別のソースコードのメンテナンスはVS Code（もしくはEclipse）上で行う。またIT環境でのビルド、デプロイ、テストなどの自動化のために、Jenkinsパイプラインの利用を考える。
Gitを使用した個別ソース修正プロセスの改善
COBOL、PL/I、アセンブラなどの言語で書かれたz/OS上のアプリケーションであっても、オープン系のアプリケーション開発と同じように、Gitでソース管理を行うための仕組みが整いつつある。
ただしオープン系のアプリケーションと決定的に違うのは、開発言語の可搬性である。Java、JavaScript、Pythonなどオープン系でよく使われる言語は、開発環境とビルド／テスト環境が一体となっており、編集したその場で（開発PC上で）ビルドや単体テストがすぐに実行できる。
一方でCOBOLやPL/I、アセンブラの場合、ソース編集自体はVS CodeやEclipseで実行できたとしても、ビルド（コンパイル／アセンブル）、テスト実行などはPC上では行えないので、その部分はどうしても実際のz/OS環境（もしくはZD&T/Waziなどの疑似テスト環境）が必要になる。
そこを補うために、DBB（Dependency Based Build）という有償製品、およびzAppBuildという無償提供のフレームワークが利用できる。
DBBではDBB Toolkitと呼ばれる、ソースのコピーやコンパイル／リンクの実行などz/OS関連の操作を行うためのJava APIを提供しており、さらにGroovyでビルド用のスクリプトを書くためのライブラリが提供される。
つまり、コンパイル／リンクを行うJCLを書く代わりに、Groovyのスクリプトでビルド（＝コンパイル／リンク）の処理を記述できる。
このGroovyのスクリプトはUSS上のJVM上で稼働するので、SSH経由で外部から容易にキックできる。
これらの機能を使って、VS CodeやEclipseのUIからビルドを実行するための仕組みが提供される。
たとえばVS Codeを使う場合、実際の操作としてはCOBOLソースを編集後、そのソースを開いているエディタを右クリックして「Run IBM User Build」というメニューを選択する。それだけで、裏では必要なファイルが事前定義されたUT環境（z/OS）に転送され、Groovyのスクリプトが呼び出されて、ビルド処理（コンパイル／リンク処理）が行われ、実行モジュールが作成される。
この時に実行されるGroovyのスクリプトも、ゼロからすべて自前で作成する必要はなく、汎用的に使えるスクリプトがzAppBuildというフレームワークとして無償で提供されている（GitHubから入手可能）。
実行モジュールが生成されると、それを単体テストすることになるが、これはプログラムの作りや使用しているミドルウェアにも依存するため、その形態に応じてテスト方法を考える必要がある。本稿では詳しく触れないが、Eclipseベースのツールであれば、JUnitライクなZUnitと呼ばれている機能が提供されている。またGalasaと呼ばれるz/OSアプリケーションもターゲットにしたテスト用のフレームワークなどもあるので、必要に応じて参考にされたい。
単体テストを実行する際、デバッガーを使って修正したコードをステップ実行させて動作を確認したい場合も多いだろうが、z/OS上にデバッガー製品（有償）を導入すれば、VS CodeやEclipseの画面にデバッガーの画面を飛ばしてステップ実行の制御を行う、などが可能である。
たとえばバグ修正など、特定コードを修正する具体的なイメージは以下のようになる（図表6）。
❶ 修正対象のソースをローカルのPC上にクローンしてブランチを作成
❷ VS Codeを使ってソースを修正
❸ VS Codeからビルド実行（UT環境に実行モジュールが作成される）
❹ UT／デバッグ実行
❺ 修正が完了したら修正したソースをGitに反映
パイプラインを使用した自動化
Gitでソースコードを管理していると、その後のフェーズへの展開する際の自動化にもつなげやすくなる。
JenkinsのAgentをz/OSのUSS上で稼働させられるので、ここではJenkinsのパイプラインを利用した自動化の適用を考えてみる。
前述したような個別のコード修正が集積されて、ある程度まとまった単位で新しいバージョンをリリースする、という流れを想定する。
たとえばIT環境へソース一式を転送、一括でのビルド、リグレッションテストといったスクリプトをJenkinsパイプラインとして準備し、GitHub上で修正用のブランチがMainのブランチにマージされたことをトリガーにしてそのパイプラインを実行する、といったことが可能となる（図表7）。
上記の例だと、操作としてはGitHub上で開発者がpull requestというメインのブランチへのマージリクエストを出し、管理者が実際のマージ処理を行うだけでよい。あとは事前に用意されたスクリプトにより、一連の処理が自動的に行われる。
自動化する処理の中身についてはスクリプト次第だが、JenkinsのパイプラインはUSS上でJenkins Agentから呼び出され、USS上のシェルで実行できるのであれば容易に組み込める。たとえば、以下のような機能が利用できる。
ソースの転送については、Rocket社が提供するRocket Gitを使用することで、Linux／UNIX環境での操作と同じように、USS上にGit Serverからリポジトリをクローンできる。
また一括のビルドについては、前述したDBB、zAppBuildを利用できる（Groovyスクリプト実行）。そのほか、テスト自動化のツールと組み合わせたり、実行モジュール配布の仕組みと組み合わせたりすることで、自動化の範囲を広げることが可能となる。
スモールスタートのためのアプローチ
VS Codeでも触れたように、オープンソースを利用したモダナイゼーションの手法が多く提供されているため、追加のソフトウェアのライセンスコスト不要で利用できるものが増えている。
きっちりと導入計画を立てて、一気に全体へ展開するよりは、開発環境なのでまずは試しに使ってみて、使いながらよりよい活用の方法を探っていく、うまく活用できそうであれば広げていく、というアプローチがよいのではないかと考える。
VS CodeによるUIモダナイゼーションの機能を整理すると、図表8に示す赤枠の範囲が追加コストなしでできる範囲に相当する。
また今回紹介した開発環境でのモダナイゼーション手法に限らず、運用管理系やクラウドとの連携など、USS上のオープンな技術を活用したソリューションが次々と登場している。
従来からのやり方に固執するのではなく、そのような新しい技術を使い慣れておくことで、新しい利用形態への移行もスムーズになるはずだ。
若手技術者の育成が困難であるという課題に関連する声として、「新しい技術を学ぶ機会が少なく、モチベーションが上がらない」という意見も聞く。積極的に新しい技術を取り込んでいくことは、このような課題に対する解決の糸口にもなると考える。
メインフレーム上では新しい技術、とくにOSSは利用できないという誤解がまだまだ根強いと思われるので、図表9に現時点でz/OS上でも利用可能なオープンな技術を参考までに挙げておく。
以上、本稿で紹介した3つの観点でのモダナイゼーションについては、具体的に環境を構築して実施した内容が、以下の参考情報にまとまっているので、ぜひ参照されたい。本稿がメインフレーム開発環境のモダナイゼーションを検討するきっかけになれば幸いである。
◎クラウド上でのメインフレーム開発環境構築
◎Wazi：OpenShift上でのメインフレーム開発環境構築
◎VSCodeを使用したメインフレーム・アプリケーション開発
◎Eclipseを使用したメインフレーム・アプリケーション開発
◎Jenkins – z/OS連携
著者
田口 智大氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ミドルウェア・テクノロジー
シニアITスペシャリスト
1998年に入社以来、主にCICS関連製品（TXSeries、CTG、CICS TS）を中心に技術支援に携わる。近年はメインフレームのモダナイゼーションに関する技術情報を積極的に外部発信している。
［i Magazine・IS magazine］
