メインフレーム開発環境モダナイゼーションにおける課題 - 前置き

# はじめに
メインフレーム(IBM z/OS)は基幹系業務を支えるプラットフォームとして長年に亘って使い続けられてきました。現在でも世界中の多くの企業で利用されています。
一方で、ITを取り巻く環境や技術は変化し続けており、このような変化に対応していくことも求められています。IBMはメインフレームに対して継続的な投資を行うことにより、新しい環境に適用するための機能拡張を続けています。
新しい技術に柔軟に適用していくためには、使い方や考え方を継続的に"モダナイズ"していくことが必要だと考えます。しかし既存のシステム、特にメインフレームの使い方を"モダナイズ"していくにあたっては過去のしがらみ等から様々な課題が生じ得ることも事実です。"課題があるから変更を避ける"ということだと塩漬けシステムであればよいかもしれませんが、長期的な視点での活用を考えた場合にはそれらの課題は"乗り越えていくべきもの"と捉えています。

ここでは"メインフレーム開発環境のモダナイゼーション"にフォーカスし、そこで生じうる課題/考慮点を取り上げて整理します。今後メインフレーム開発環境をよりよいものにしていくために、共通的な課題はなるべく広く共有し、解決策についての情報共有の一助となることを期待するものです。

## 関連記事

[メインフレーム開発環境モダナイゼーションにおける課題 - 前置き](https://qiita.com/tomotagwork/items/572fc93374d5166b8491)
[メインフレーム開発環境モダナイゼーションにおける課題 - 1. オープン系とメインフレームの差異に関する課題](https://qiita.com/tomotagwork/items/31aee03050edc55c56a6)
[メインフレーム開発環境モダナイゼーションにおける課題 - 2. プロジェクト固有の利用方法に関する課題](https://qiita.com/tomotagwork/items/ea3bba8158058857ce46)
[メインフレーム開発環境モダナイゼーションにおける課題 - 3. 組織/人材に関する課題](https://qiita.com/tomotagwork/items/99b494cb1248be29ca83)

# メインフレーム開発環境モダナイゼーションとは

メインフレームのアプリケーションはCOBOL、PL/I、アセンブラなどの言語で書かれているものが多く、開発環境としてはメインフレーム固有のツールが使われていることが多いと思います。開発/テスト環境としてはオンプレのz/OSに専用の区画を用意してそこを使用し、開発者はPCOM(3270端末エミュレーター)を使用して開発/テスト等の作業を行うといった流れがまだ主流かと思います。

メインフレーム開発環境の"モダナイゼーション"と言った場合に、細かい観点では様々な考え方やツールがありますが、大きな方向性としては、できるだけ標準的な技術や考え方に基づいて開発サイクルを変えていく、ということです。もっと言ってしまえば、いわゆるクラウド・ネイティブと言われる技術(あるいはクラウド環境そのもの)を活用してメインフレーム上のアプリケーション開発も行っていきましょうということです。

ハイブリッド・クラウド環境での開発環境の構成としては、例えば以下のような利用方法が理想だと考えています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/39e90a02-5752-2e87-db4d-1a57371c0e7f.png)
IT以降のテストや本番環境はオンプレのz/OSを使用する必要がありますが、開発環境やUT,ITの一部についてはできるだけクラウド環境を利用できるとよいのではないかと考えます。

開発環境のモダナイゼーションの核となりそうな所としては、例えばGitによるソース管理、および、UIの改善(VS Code、Eclipse)の辺りになるかと思います。これに付随して、z/OS開発/テスト環境のCloud環境へのオフロード(Wazi aaS)、CICD pipelineによる自動化(Jenkins)、既存アプリケーションの分析(ADDI)、などなど...、範囲を広げていけます。

余談ですが、若手メインフレーム技術者のコミュニティーに参加したメンバーから話を聞く機会がありました。そこでは自由に使える(言ってしまえば壊してもいい)環境が無いのでなかなか実機を使ったスキル習得が難しいという声が多かったようです。Wazi as a Serviceというクラウド上でz/OSの仮想環境を必要な時に必要な分だけ立ち上げるということもできるようになってきていますし、UIとしてもPCOMのようなz/OS特有のインターフェースよりはVS Codeのような広く使われているツールを活用すると、初心者にとってもメインフレーム利用のハードルもだいぶ下がるのではないかと思います。


どこから始めるのがよいかはプロジェクトの状況や課題の優先度などにも依存するので決まった正解というのは無いと思います。また、これらをクラウド上で実装するのにハードルがある場合もあると思うので、これらの技術をまずはオンプレ環境で適用してみるというやり方も可能です。

# Git中心の開発プロセス改善イメージ

オープン系アプリケーション開発ではGitによるソース管理を行うのがスタンダードになってきていると思います。メインフレームのアプリケーションもこの考え方をベースに開発サイクルを回すことを考えると、環境としては以下のようなイメージになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/af355b36-e517-59ff-4f05-7c638ea9331a.png)

以下のあたりが基本的な使われ方のポイントとなります。

【Gitによるソース管理/変更管理】
ソースのマスターはメインフレーム上ではなく、Git Server(Git Labなど)上で管理することになります。CD/UTフェーズではVS Codeなどの開発ツールのある開発環境にコピーされて改修作業が行われます。IT環境ではGitからIT環境にコピーされてビルド(コンパイル/リンク)される、という流れで使用されます。

参考: 
[z/OSにおけるGitの活用](https://qiita.com/tomotagwork/items/ea5b1ec89dd8d32c655d)

【UI改善】
Gitとの連携、ソース編集(エディター)の機能は、VS CodeやEclipseベースのツール(IDz)を利用することができます。PCOMに比べるとリッチな機能が利用できますし、オープン系開発でも広く使われるツールを使用することで新しくメインフレーム開発を行う要員にとっても抵抗感が大幅に低減できると思われます。
ビルド(コンパイル/リンク)の実施についてはz/OS環境が必要になりますが、DBB(Dependency Based Build), zAppBuildを利用することで、VS Code、IDzからビルド実行することもできるようになります。

参考: 
[VSCodeを使用したメインフレーム・アプリケーション開発 - (4)ソース管理ツール/ビルドツール連携](https://qiita.com/tomotagwork/items/4bdd0b5a7284b5102d10)
[Eclipseを使用したメインフレーム・アプリケーション開発 - (4)ソース管理ツール/ビルドツール連携](https://qiita.com/tomotagwork/items/da039208be2f77c21285)
[DBB/zAppBuildについてのメモ](https://qiita.com/tomotagwork/items/d3b08b10137a0d87416d)

【Jenkinsによる自動化】
CD/UT後のITのフェーズで変更されたソースを一括でビルド処理を行うなど自動化を組み込むことができます。定型的な処理をスクリプト化することができればそれをJenkinsのパイプラインとして記述しておくことで自動化できます。
リグレッション・テストや別環境へのデプロイなど後続処理の自動化も行えれば、それをパイプラインとして組み込むことができます。

参考:
[Jenkins - z/OS連携](https://qiita.com/tomotagwork/items/d2c90c1f29e07d3b7c19)

# 課題概要

上で示したような環境でクラウド・ネイティブな技術を使った開発サイクルに変えていくことが理想であると考えていますが、実際に既存のアプリケーション開発環境をそのように変更していく場合には様々な課題も出てくることが想定されます。

状況によりますが、例えば以下のような課題が生じることが想定されます。

**1. オープン系とメインフレームの差異に関する課題**
これまでメインフレームに閉じた環境で完結していたものが、新しい環境ではオープン系のLinuxやWindowsプラットフォームのツールとやりとりしながら開発サイクルを回すことになります。文化や考え方の大きく異なる環境間でのやり取りが各所で発生しますので、両者のギャップにより不都合が生じるケースが出てきます。特に日本語環境の場合は文字コードに関する課題が発生し得ます(これは開発環境だけに限らずオープン系とメインフレームを連携する際に必ず付いて回る課題ですが)。

**2. プロジェクト固有の利用方法に関する課題**
現在使用しているS/Wやミドルウェアと、新環境で使おうとしている仕組みとの相性によって不都合が生じる場合があります。例えば古いバージョンのS/Wを使用している場合や、World Wideで見た場合にマイナーなツールを使っている場合に新しいツールの対応が遅れている、といったことがあります。
また、開発サイクル上でのプロジェクト独自の複雑な運用方法や特殊なツールを使っている場合には、それらを新しい環境にどのように適用させていくのかを個別に検討していく必要があります(新規にやり方を考えるのか、既存のやり方をなるべく踏襲して新しい環境での実現を模索するのか、などを含めた検討)。

**3. 組織/人材に関する課題**
これまでメインフレームに閉じた環境で完結していたものが、オープン系も含めた環境を活用するということで、インフラ担当者もアプリ担当者も必要なスキルエリアが広がります。これまでの役割分担、組織構造では対応が難しい場合もあり、その辺りの体制も見直す必要があります。メインフレーム、オープン系をまたがって全体を把握できる要員も必要となります。

以降の記事ではこれらの課題の具体例についてそれぞれ見ていきたいと思います。