Text＝田口 智大（日本アイ・ビー・エム システムズ・エンジニアリング）
メインフレーム（IBM z/OS）は、基幹系業務を支えるプラットフォームとして長年にわたり使われ続けており、現在でも世界中の多くの企業で利用されている。
一方で、ITを取り巻く環境や技術は変化し続けており、このような変化に対応していくことも求められている。IBMはメインフレームへ継続的に投資することで、新しい環境に適用するための機能拡張を続けている。
新しい技術に柔軟に適用していくには、使い方や考え方を継続的に「モダナイズ」していくことが必要である。しかし既存のシステム、特にメインフレームの使い方を「モダナイズ」していくと、過去のしがらみから、さまざまな課題が生じ得ることも事実である。
塩漬けシステムであれば、「課題があるから変更を避ける」でよいかもしれないが、長期的な視点での活用を考えた場合は、それらの課題は「乗り越えていくべきもの」と捉える必要がある。
本稿では「メインフレーム開発環境のモダナイゼーション」にフォーカスし、そこで生じ得る課題／考慮点を取り上げて整理する。今後メインフレーム開発環境をよりよいものにしていくために、共通的な課題はなるべく広く共有し、解決策に向けた情報共有の一助となるよう期待する。
メインフレーム開発環境のモダナイゼーションとは
メインフレームのアプリケーションはCOBOL、PL/I、アセンブラなどの言語で書かれ、開発環境としてはメインフレーム固有のツールを使用しているケースが多い。開発／テスト環境はオンプレミスのIBM Z上に専用区画を設定し、開発者はPCOM（3270端末エミュレータ）から開発／テスト等の作業を行うといった流れがまだ主流である。
メインフレーム開発環境の「モダナイゼーション」と言った場合、細かい観点から見れば、さまざまな考え方やツールが存在するだろうが、大きな方向性としては、できるだけ標準的な技術や考え方に基づいて開発サイクルを変えていくことを意味する。
さらに言えば、いわゆるクラウドネイティブと言われる技術（あるいはクラウド環境そのもの）を活用してメインフレーム上のアプリケーションを開発していくこと、と捉えてもよい。
ハイブリッドクラウドを利用した開発環境の構成としては、たとえば図表1のような例が理想である。
結合テスト（IT）以降のテストや本番環境では、オンプレミスのz/OSを使用する必要がある。しかし開発環境や単体テスト（UT）、結合テストの一部は、できるだけクラウド環境を利用するのが望ましい。
開発環境のモダナイゼーションの核は、たとえばGitによるソース管理、ユーザー・インタフェース（UI）の改善（Visual Studio Code、Eclipse）といったあたりになる。
これに付随して、z/OSの開発／テスト環境に関するクラウドへのオフロード（IBM Wazi as a Service。以下、Wazi aaS）、CI/CDパイプラインによる自動化（Jenkins）、既存アプリケーションの分析（IBM Application Discovery and Delivery Intelligence。以下、ADDI）などへと範囲を広げていく。
余談だが、若手メインフレーム技術者のコミュニティに参加したメンバーから話を聞く機会があった。そのコミュニティでの議論では、個人で自由に使える（つまり壊してもいい）環境がないため、実機を使ったスキル習得が難しいという声が多かったとのことである。
Wazi aaSというクラウド上でz/OS仮想環境を必要な時に必要な分だけ立ち上げられる環境を活用する、またUIとしてもPCOMのようなz/OS特有のインターフェースではなく、Visual Studio Code （以下、VS Code）のような広く使われているツールを活用することで、初心者にとってのメインフレーム利用のハードルを低くすることが期待される。
どこから始めるのがよいかは、プロジェクトの状況や課題の優先度などにも左右されるので、決まった正解はない。またユーザーの要件次第では、これらをクラウド上で実装することが大きなハードルになることもあり得るので、これらの技術をまずはオンプレミス環境で試すというやり方も考えられる。
Git中心の開発プロセス改善イメージ
オープン系アプリケーション開発では、Gitによるソース管理が標準的である。この考え方をベースにメインフレーム・アプリケーションの開発サイクルを回す場合、環境としては図表2のようになる。
基本的な使い方のポイントを、以下に示す。
Gitによるソース管理／変更管理
ソースのマスターはメインフレーム上ではなく、Git Server（Git Labなど）上で管理することになる。コーディング／単体テストのフェーズでは、VS Codeなどの開発ツールが稼働する開発環境にソースをコピーし、改修作業を行う。
結合テストフェーズでは、GitからIT環境にソースをコピーし、ビルド（コンパイル／リンク）するという流れで使用する。
UI改善
Gitとの連携、ソース編集（エディター）の機能は、VS CodeやEclipseベースのツール（IBM Developer for z/OS。以下、IDz）を利用できる。こうしたツールの利用により、PCOMに比べてリッチな機能が提供されるだけでなく、オープン系開発で標準的なツールを使用することで、若手のメインフレーム開発者にとっても抵抗感を大幅に低減できる。
ビルド（コンパイル／リンク）の実施ではz/OS環境が必要になるが、IBM Dependency Based Build（以下、DBB）という製品、およびzAppBuildというフレームワークを利用することで、VS Code、IDzからスマートにビルド実行することも可能になる。
Jenkinsによる自動化
メインフレーム上の定型的な処理をスクリプト化できれば、その自動化の仕組みについてもオープン系で広く使われている技術を応用できる。
たとえば、コーディング／単体テスト後の結合テストフェーズで変更されたソースを一括でビルド処理するなど、Jenkinsのパイプラインとして記述しておくことで自動化できる。
またリグレッション・テストや別環境へのデプロイなど後続処理も自動化できれば、それをパイプラインとして組み込める。
メインフレーム開発環境の
モダナイゼーションにおける課題
ここまではクラウドネイティブ技術を活用すれば、メインフレーム・アプリケーションの開発サイクルも、オープン系アプリケーション開発と同じような形に変えられることを紹介した。ここまでの話は、ある意味「理想」として、こういう形を目指したいということであるが、実際に変えようとすると、さまざまな課題や考慮点が出てくるのが現実である。
以下では、真摯に「現実」と向き合い、メインフレーム・アプリケーション開発にクラウドネイティブ技術を活用する際に直面するであろう課題を整理する。社内でPoCを実施した時の情報をベースに共通しそうな課題について、次のように大きく3つの観点で分類した。
課題1: オープン系とメインフレームの差異に関する課題
オープン系プラットフォームとメインフレームでは、歴史的経緯やコンセプトの違いなどから管理方法や考え方に大きな相違点がある。
図表2で示したGitを中心とする開発プロセス改善イメージを、図表3のように色分けしてみると、水色部分で示したオープン系の世界とグレー部分のメインフレームの世界が一体となって開発環境を構成していることがわかる。
このように新しい開発環境では、オープン系とメインフレーム間で頻繁かつ密な連携が必要となる。これまでメインフレームの中だけで考慮されていた開発プロセスをオープン系の世界にも広げることになるため、この両者の文化間に横たわるギャップの部分で課題や考慮点が発生することになる。
ソース管理に関して、プラットフォーム間の主な差異を図表4にまとめる。
このような違いにより、具体的にどのような課題／考慮点が生じるかを以下に示す。
① 日本語（DBCS）を含むソース
日本語（DBCS）を含むソースを編集する場合、EBCDICだとSO/SIというDBCSとSBCSの区切り文字が1バイトずつ含まれるため、エディター上でもその分のエリアが確保される。
COBOLやPL/Iなどの言語は、桁位置を厳密に意識して記述する必要があり、どこからどこまでの範囲に何を書くべきかが決まっている。具体的には、73桁目以降はシーケンス番号と呼ばれる領域として使われたりするので、桁がずれるとシンタックス・エラーやコンパイル・エラーにつながる。
これは根本的にはエディター側で対応する必要があるが、残念ながら現時点ではVS Codeのエディターでは対応が不十分である（改善要望により対応はされつつある）。なので、シーケンス番号はできるだけ使用しない方針で対応するのが王道と言える（図表5、図表6）。
② ファイル管理体系
図表4でも示したように、オープン系とメインフレームではファイルシステムの考え方から大きく異なる。たとえばメインフレーム上ではソースはPDSのメンバーとして保持されるのに対し、オープン系ではディレクトリ下のファイルとして保持される。
またオープン系では、アプリケーションはGit Server上のリポジトリと呼ばれる単位で管理し、編集する場合にはリポジトリ単位でローカルにクローン／ブランチを作成して管理する。各種操作を行う場合、ファイル種別を判断する際には拡張子を用いる。
このような概念はメインフレームには存在しないが、最終的にソースはMVS上のデータセットとして転送し、コンパイル／リンクを行う必要があるため、両者間でのマッピングのルールを新たに考える必要がある。
Gitでソースを管理し、DBBやzAppBuildの仕組みでビルドする場合のファイル管理に着目すると、たとえば図表7で示す観点での考慮が必要になる。
③ 日本語の文字コード
メインフレーム世界での日本語の文字コードは、英小文字系と呼ばれるもの（CCSID:939/5035/1399）と、カタカナ系と呼ばれるもの（CCSID:930/5026/1390）の2種類に大別される。
もともと英小文字系のコード体系をベースに半角カタカナを使いたいという要望に応えて、英小文字部分のコードを犠牲にし、そこに半角カタカナを割り当てて新たな文字コードが作られたという背景がある。日本のシステムではそれが脈々と受け継がれ、いまだにこのカタカナ系の文字コードを使用しているケースは多い。
半角カタカナと英小文字のコードが入れ替わっているだけならまだよいが、やっかいなのは一部の記号についても入れ替わっている点である。具体的にはカタカナ系文字コードを使用していて、かつメンバー名として「￥」マークを使用している場合に不都合が生じるケースがある。
たとえば、COBOLのCOPYBOOKやPl/Iのインクルードファイルのファイル名に「￥」を含むメンバーがあり、それをソースから参照している場合、うまく参照できないケースが見られる。これはソースの中身とファイル名が同じように文字コード変換できない場合があるからだ。
またWindows上では、「￥」はディレクトリの区切り文字であるバックスラッシュと同様の表記になるため、余計にややこしい問題につながる。
従ってファイル名のルールとして、「￥」を使用しないネーミングルールを検討するのが望ましい。使用する手法によっては逃げ道を検討できる余地はそれぞれあるが、そのような対症療法は将来的には負の遺産となるのが目に見えて明らかなので、まずはなくす方向での検討が推奨される。
④バイナリー・データ
メインフレームに閉じた環境で情報を扱う場合、人間が解釈できるいわゆる「文字列」ではなく、バイナリー・データを直接扱うことができる。たとえば、PCOM上でのISPFのエディターの機能で「HEX ON」とすると、各行が3行表示になって、1行目が通常表示上の文字列、2～3行目が1行目に対応するHEXのコード（縦2文字で1バイトのコードを示す）が表示される（図表9）。
このようにエディター上ではHEX部分も編集できるため、「文字列」として扱えないものでも直接HEXで編集できてしまう。
異なるプラットフォーム間でファイルをやり取りする際は、文字コード変換が発生することになるので、文字として扱えないものが含まれることは基本的に避けるべきである。ソース中のバイナリー・データについては、排除するしか対応の余地はない。どうしても排除できないものは既存の仕組みを残すなど、例外として対処することを考える必要がある。
たとえば既存の仕組みの中でバイナリー・データを直接扱っている例として、ソース中に制御コードの値をHEXモードで直接埋め込んでいるようなケースがあるが、テキストベースでのHEXコード指定方法に置き換える必要がある（図表10）。
テスト用のデータとしてバイナリ情報をハンドリングしている場合もあるが、それはソース管理とは別の話になるので、テストのやり方に応じて検討する必要がある。既存のツールを利用する、あるいは単純なものでよければ、テキストベースでHEXコードを編集できる自作ツールで対応する、といったことも検討する必要がある。
課題2: プロジェクト固有の利用方法に関する課題
現在使用しているソフトウェアやミドルウェアと、新しい環境で使おうとしている仕組みとの相性によって不都合が生じる場合がある。
また、開発サイクル上でのプロジェクト独自の複雑な運用方法や特殊なツールを使っている場合には、それらを新しい環境にどのように適用させていくのかを個別に検討していく必要がある。
以下に、具体的な例をいくつか挙げる。
① 現在使用しているソフトウェアや機能との相性
たとえば以下のような機能を使用していると、利用できる機能が制限される場合がある。
◎PL/Iマクロ
アプリケーション開発言語としてPL/Iを使用し、そのマクロを多用している場合、残念ながらVS CodeのIBM Z Open EditorではPL/Iマクロに対応していないためにエディターでのSyntax Checkがうまく機能せず、エラーを示す赤い下線が大量に表示されることになる。
図表11のように、Pl1: Disable Problemにチェックを入れることで、エディター上のエラーが無視されるようになる。
Syntax Checkの部分は実質無効化となるが、エディター機能として使う分には、PCOMに比べればリッチな機能が提供されるので、UIとしてはかなり改善されるはずである。
◎SAIL、CAP-A
SAILやCAP-Aという金融系ソリューションのパッケージ製品を使用している場合、業務プログラム間の呼び出しはSAILやCAP-Aの制御コードを介して実行される。このためADDIというソース分析ツールや、IDzのzUnitという単体テスト支援ツールとは相性があまりよくないので、別ツールの利用や個別の考慮が必要になる。
◎旧バージョンコンパイラ
Enterprise COBOL、Enterprise PL/I 以前の古いコンパイラを使用していると、使用したいツールに機能制限が生じる場合がある（IDz zUnitなど）。
このように、現在使用しているソフトウェアや機能と、新しい開発スタイルに置き換えた場合に使用したい機能がマッチするかは個別に精査していく必要がある。一部の機能については制約がある前提で割り切って使用する、といった判断も必要になる。
② ロードモジュール作成／管理方法
ソースの管理方法だけでなく、それをどのようにビルド（コンパイル／リンク）してロードモジュールを作成／管理しているかは、プロジェクトの方針やアプリケーションの特性によってさまざまである。
後々の監査のために、オブジェクトモジュールやJOBLOGなども含めエビデンスとして何をどう残すのかも、プロジェクトそれぞれの事情がある。新しい開発スタイルの中でこれまでの管理方法をどう実現するか、あるいは新しいスタイルに合わせて変えていくのかを個別に検討する必要がある。
たとえばDBB、zAppBuildを利用してロードモジュールを作成する（コンパイル／リンクする）ことを想定すると、zAppBuildは汎用的に作成されたフレームワークなので、複雑な管理を行わせたい場合は考慮が必要になることもある。
図表12に示すように、ソースと実行モジュールが1:1となるケースは非常にシンプルでわかりやすく、適用が容易と言える。
一方で、いったんソースからロードモジュール（単体ロードモジュール）を作成し、それらをバインドして最終的な実行可能モジュールとして作成する、というようなケースもある（図表13）。
zAppBuildはこのような操作を想定していないので、仕組みは個別に考慮する必要がある。どのモジュールをどのモジュールにまとめるかといった情報は、当然外から与える必要がある。またそれらをどう実装するかは、別途検討する必要がある（提供されているzAppBuildをカスタマイズするか、新たな仕組みを自作するか、など）。
zAppBuildは汎用的なビルドの仕組みを提供するフレームワークであるが、DBBが提供するAPIを使用したGroovyスクリプトをベースに作られている。ソースはGitHub上に公開されているので、それをカスタマイズして利用することもできる。
GitHub ― zAppBuild
③ 単体テストと内部結合テストの組み込み方法
一般的な開発サイクルでは、コードの作成／改修を行う際に合わせて単体テストを実施するのが定石である。しかし、テストのやり方は対象アプリケーションの形態（オンライン／バッチ）、起動方法、使用するミドルウェアなどによって変わってくる。
特にメインフレーム・アプリケーションの場合は、完全に新規で作成するプロジェクトはあまりなく、既存のアプリケーションをベースに改修する例が多い。しかもアプリケーションの規模も大きいので、「アプリケーション基盤」と呼ばれるような共通機能を作っている、あるいはSAILのような業界共通のミドルウェア機能を使用しているケースも多く、業務アプリケーションのモジュールを単体テストする場合は、その利用環境の作法に従う必要がある。
単体テストの基本的なイメージは、図表14のとおりである。
一般論としては、テスト対象のモジュールの動作確認に必要な環境をドライバ（Driver）やスタブ（Stub）として準備し、各種テストパターンを入力データとして準備し、出力データを期待値とチェックする、というのが基本的な考え方になる。
メインフレーム・アプリケーションの場合、テストの考え方は業務プログラムの利用形態、あるいは使用するミドルウェアや共通機能に大きく依存する。
ポインターで渡されるメモリの一部のエリアが使われていて必要な入力データが明確になっていない、あるいは制御用に数百ものフィールドが必要で業務アプリ担当者がすべてのフィールドを把握しきれない、というケースもよく見られる。
そのため、このような基本的な単体テストを実行しにくい状況が生じることも多い。そもそもプロジェクトによっては、個々のプログラムの単体テストを行わない場合もある。
新しい開発サイクルに変更していく際に、単体テストや内部結合テスト（Ita）をどのように組み込んでいくかは重要な検討課題になる。理想的には、単体テストを実行しやすいようにアプリケーション全体のリアーキテクトを行い、テスト用のフレームワークも準備するという方向性が望ましい。
しかし規模の大きいメインフレーム・アプリケーションを、一度にすべてそのような形に変えていくのは時間もコストもかかる。そこで落としどころとして、まずは内部結合テストのテストシナリオを実行することで単体テストをカバーできるような仕組みにし、将来的には単体テストを行えるような構造に順次置き換えていくという方針も考えられる（図表15）。
ある程度バッチ的にテストを実行可能にしておくことで、将来的な自動化につなげやすくなる。たとえばJenkins等に代表されるようなCI/CDパイプラインをメインフレームの開発サイクルに組み込んでいくためには、テストの自動化は非常に重要な要素となり得る。
課題3: 組織／人材に関する課題
メインフレームに閉じた世界で完結していた環境が、オープン系も含めたエリアに広がることは、インフラ担当者、アプリ担当者それぞれに必要なスキルエリアが広がることに直結する。
これまでの役割分担、組織構造では対応が難しい場合もあり、運用／管理体制も見直す必要がある。メインフレーム系、オープン系をまたがって全体を把握できる要員も必要となる。
前述したようなGitを中心とするソース管理など、クラウドネイティブな技術をメインフレーム・アプリケーション開発に取り入れた際の必要なスキルを挙げる。
◎従来のスキル
・z/OS、MVSデータセット、JCL、コンパイラ、LE
・COBOL、PL/I、Assembler
・ミドルウェア（IMS、Db2、CICS、MQ、SAIL…）
◎新環境関連スキル
・z/OS UNIX System Service、SSH、DBB、zAppBuild、z/OSMF、Java、Groovy、Shell Script
・VS Code、Eclipse、Git、Jenkins
・（Cloud、Wazi aaS、ZD&T）
※青字で示した部分はオープン系システムでも活用できるスキルを意味する
メインフレームの技術エリアとオープン系の技術エリアは明確な線引きがされ、分断されがちな状況も多いが、新しい開発スタイルに合わせて必要なスキルセットや役割分担、サポート体制、組織構造などを見直す必要がある。
必要なスキルエリアが広がることによって、担当者の負荷が増大する側面はあるが、新しい技術を活用していくために新しいスキルを常に広げていくことは、IT全般で必要である。それを否定すると、進歩は望めない。
メインフレームの世界にオープン系の技術を取り込むことは人材流動性の活性化、メインフレームを担当する若手技術者のモチベーション向上にもつながると言える。
役割分担例
役割分担、各担当者のカバーエリアの例を以下に示す（こうせねばならないというわけではなく、あくまでも考え方の例である）。
◎インフラ担当者
各種必要なコンポーネントの導入／構成を行う。また、z/OS以外のコンポーネントとのネットワーク通信もそれぞれ行われるので、ネットワーク構成もカバーする必要がある。必要なスキルは、図表16の赤線部分のインフラ構築、運用である。
◎ビルド・エンジニア
ビルドに関するインフラ寄りの各種設定を行う。ビルド全体の仕組みを統括してインフラ担当者とアプリケーション担当者の橋渡しとなることも期待される。必要なスキルは、図表17のビルドの仕組みに関する全般的なスキル、Groovyによるビルドの仕組み（DBB、 zAppBuild）の構築／カスタマイズである
◎アプリケーション管理者
ビルドに関するアプリケーション寄りの各種設定を行う。また、アプリケーション変更管理の責任者としての役割を担う。必要なスキルはアプリケーション、Git、Jenkinsパイプラインによる自動化の仕組み構築／運用である。
◎アプリケーション開発者
開発者はソースの改修（コーディング／単体テスト）にのみ専念する。必要なスキルはアプリケーション、Git、VS Code／IDz、デバッガー、テストツールなどである。
メインフレームをベースとしたシステムは歴史も長く、規模も大きく、しかもミッションクリティカルな業務で利用されることもあり、「変えること」に対するハードルが高い。新しい環境に適用していく、より便利な機能を使えるようにしていく、長期にわたって効率よくメンテナンスしていくには、継続的なモダナイズが欠かせない。
本稿ではメインフレーム開発環境のモダナイゼーションを行う際に生じる課題／考慮点の例を示した。
課題／考慮点は一意に解決策が明確な場合だけではなく、対象システム／プロジェクトの状況を踏まえて個別の考慮／検討を必要とするケースがほとんどである。
つまり、インフラや新しいツールを導入すれば、それですべてハッピーな世界が広がるわけではない。それらを利用して、開発サイクルをどう改善していくかを検討することが、メインフレーム開発モダナイゼーションで一番のコアとなる作業である。
実際にモダナイゼーションを進める際には、既存環境に合わせて個別検討を必要とする部分が多いので、PoCによりフィージビリティや方向性を見極める、小さい範囲で始めて広げていく、一部の機能から使ってみる、といったアプローチが必要になるだろう。
メインフレームのモダナイゼーションの大きな方向性として、オープンな技術を取り入れるという流れがある。オープンな「技術」だけでなく、オープンな「文化」も取り入れて、使いながら不都合があるところは改善していく、みなで使ってよくしていく、オープンな場で情報を共有していくことが、メインフレームの世界でも広がっていくよう期待したい。
著者
田口 智大氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
Technical Competency Center, Cloud Integration #2
シニアITスペシャリスト
1998年の入社以来、主にCICS関連製品（TXSeries、CTG、CICS TS）を中心に技術支援に携わる。近年はメインフレームのモダナイゼーションに関する技術情報を積極的に外部発信している。
［i Magazine・IS magazine］
ISEのトップエンジニアが作ったISE Showroom（体験型デモ）「ISE Offering」はこちらから。あなたのビジネスに最適な技術ソリューションを探しに行きましょう！ （下記のテキストをクリックすると当該コンテンツへリンクします）
