はじめに

メインフレーム開発環境をできるだけ標準的な技術を使ってモダナイズしていく際に直面するであろう課題の具体例を取り上げていきます。
ここでは組織/人材に関連する課題を見ていきます。

関連記事

メインフレーム開発環境モダナイゼーションにおける課題 - 前置き
 メインフレーム開発環境モダナイゼーションにおける課題 - 1. オープン系とメインフレームの差異に関する課題
 メインフレーム開発環境モダナイゼーションにおける課題 - 2. プロジェクト固有の利用方法に関する課題
 メインフレーム開発環境モダナイゼーションにおける課題 - 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)

※青字で示した部分はオープン系システムでも活用できるスキルです

メインフレームの技術エリアとオープン系の技術エリアは明確な線引きがされて分断されがちな状況も多いのではないかと思われますが、新しい開発スタイルに合わせて必要なスキルセットや役割分担、サポート体制、組織構造などを見直す必要があると思われます。

役割分担例

具体的に役割分担、各担当者のカバーエリアの例を示してみます。
(こうしなければならないという類のものではなく、こういう役割の人が必要になるよね、というあくまでも考え方の例です。)

【インフラ担当者】

各種必要なコンポーネントの導入/構成を行います。また、z/OS以外のコンポーネントとのネットワーク通信もそれぞれ行われることになりますので、ネットワーク構成についても考慮する必要があります。

※赤線部分の主担当

必要なスキル:

上の図の赤線部分のインフラ構築、運用

【ビルド・エンジニア】
ビルドに関するインフラ寄りの各種設定を行う必要があります。ビルドの全体の仕組みを統括してインフラ担当者とアプリケーション担当者の橋渡しとなることも期待されます。

※赤線部分の主担当、および、全体のビルドの仕組みの統括

必要なスキル:

上の図のビルドの仕組み全般的なスキル
Groovyによるビルドの仕組み(DBB, zAppBuild)の構築/カスタマイズ

【アプリケーション管理者】
ビルドに関するアプリケーション寄りの各種設定を行う必要があります。また、アプリケーション変更管理の責任者としての役割を担います。

※赤線部分の主担当

必要なスキル:

アプリケーション
Git
Jenkins Pipelineによる自動化の仕組み構築/運用

【アプリケーション開発者】
開発者はソースの改修(CD/UT)にのみ専念します。

※赤線部分の主担当

必要なスキル:

アプリケーション
Git
VS Code/IDz
デバッガー、Testツールなど

補足

必要なスキルエリアが広がることによって担当者の負荷が増大するというような側面はあるかもしれませんが、新しい技術を活用していくために新しいスキルを常に広げていくことはIT全般において必要なことですし、それを否定してしまっては進歩は望めません。メインフレームの世界にオープン系の技術を取り込むことによって人材流動性の活性化や、メインフレーム担当の若手技術者のモチベーション向上にもつながると考えます。

おわりに

メインフレームをベースとしたシステムは歴史も長く規模も大きくしかもミッションクリティカルな業務で使われているということもあって"変えること"に対するハードルが高いように思います。新しい環境に適用していく、より便利な機能を使えるようにしていく、長期に亘って効率よくメンテナンスしていく、ということをしていくためには、継続的なモダナイズが欠かせないと考えます。

当シリーズ記事ではメインフレーム開発環境のモダナイゼーションを行う際に生じうる課題/考慮点の例を挙げてきました。課題/考慮点としては一意に解決策が明確になっているものばかりではなく、対象システム/プロジェクトの状況を踏まえて個別の考慮/検討をしなければならないことがほとんどです。つまり、インフラや新しいツールを導入すればそれで全てハッピーな世界が広がるというものではなく、それらを利用して開発サイクルをどのように改善していくかを検討することがメインフレーム開発モダナイゼーションにおいて一番のコアとなる作業と言えます。
実際にモダナイゼーションを進める際には、既存環境に合わせて個別検討が必要な部分が多いため、PoCを行ってフィージビリティーや方向性を見極める、小さい範囲ではじめてみて広げていく、一部の機能から使ってみる、といったアプローチが必要になるでしょう。

メインフレームのモダナイゼーションの大きな流れとしてはオープンな技術を取り入れるということがあります。オープンな文化も取り入れて、使いながら不都合があるところは改善していく、みんなで使って良くしていく、オープンな場で情報を共有していく、といったことがメインフレームの世界でも広がっていくことを期待します。