コンテンツに移動
アプリケーション モダナイゼーション

メインフレームの最小化

2022年5月17日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 5 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

ミニマリズム - 余計な「モノ」を持たず、すっきり整理するという概念。最小限主義。

アプリケーションのモダナイゼーションでは、ミニマリズムの概念がまさに手本となります。ビジネス アプリケーションは、何十年にもわたりさまざまな言語やプラットフォームで開発されてきました。「不変なものは変化のみ」と表現されるように、絶えず変化するビジネスモデル、コンプライアンスや規制の要件、ユーザーの行動や期待に対応するため、ビジネス アプリケーションはさまざまに変化し続けてきました。また、マネージド サービスモデルの進化に伴い、こうしたビジネス アプリケーションはライフサイクルの中でさまざまなチームに引き継がれてきました。開発チームやサポートチームは日々のソフトウェア アセットの管理のことを忘れてしまいがちで、アプリケーション コードのインベントリは時間の経過とともに膨れ上がり、コードの大部分が無効になったり、冗長になったりしています。

アプリケーション アセットのミニマリズムでは、「ときめかなくなった」(参考: https://konmari.jp/)アセットの破棄に重点が置かれます。メインフレームのモダナイゼーションにおける従来のリフレームワークでは、これは「廃止」戦略に該当します。この記事では、「廃止」がきわめて高い効果を生むモダナイゼーション戦略となりうること、またあらゆるモダナイゼーションの実務担当者が「廃止」戦略を取る必要があることについて説明します。

メインフレーム環境の最小化では、3 つの主要領域を重視します。

1. 非アクティブなインベントリ: 前述のとおり、変化の連続にもかかわらず、使用されなくなった古いコンポーネントが削除されないことから、アプリケーション インベントリには使われなくなったコードがどんどんたまっていく傾向にあります。メインフレームを使用すれば、アクティブなインベントリを簡単に識別できます。SMF ログでタイプ 30 のレコードを分析すると、ジョブ入力サブシステム(JES)で送信されたジョブ制御言語(JCL)の詳細を確認できます。JCL の名前、開始プログラム、CPU 秒、経過時間といった詳細を読み取り可能なファイルにエクスポートしたり、ダウンロードしてさらなる分析に使用したりすることも可能です。同様に、SMF タイプ 110 レコードでは、アクティブな CICS トランザクションに関する分析情報を確認できます。この SMF レコードでは、過去 15~18 か月分を分析して、包括的な一連のアクティブな JCL および CICS トランザクションを確認します。そのうえで、そのリストを Endevor や Panvalet といったソースコード ライブラリ内の JCL およびトランザクションと比較します。ソースコード ライブラリのリストから、SMF からのリストを引いたものが非アクティブのリストとなります。

インベントリ全体の 60% 以上が非アクティブであった例もあります。インベントリの 3 分の 2 が何の役割も持たず、ただそこにあったことになります。実際、その非アクティブなインベントリは IT 運用に悪影響を与えています。

  1. デベロッパーは毎日のマネージド サービスタスクのインパクト分析を行いますが、その作業が増えます。

  2. ビジネス要件に合わせた変更の実装に向けた作業も増えます。

  3. モダナイゼーションの範囲が人為的に広がります。

冗長なインベントリと非アクティブなインベントリを削除すれば、メインフレームのインベントリがスリム化されるので、デベロッパーの生産性が向上します。また、大きくなりすぎているメインフレーム ポートフォリオを把握するという課題にも対処でき、モダナイゼーションの範囲と予算費用を、適切な大きさ、適切な額にすることができます。

2. 孤立したジョブとトランザクション: 定期的に実行されるにもかかわらず、所有権のないジョブとトランザクションです。孤立したジョブは通常、次のような状況から生まれます。

  1. 市場の需要に合わせてビジネス要件とビジネス プロセスが変化し、それがアプリケーションの変更につながり、新しいジョブやトランザクションが古いものに置き換わる。ほとんどの場合、新しいジョブが導入され、古いジョブがそのまま残ります(「また必要になるときのために」と考えて)。

  2. プロダクト タイプによっては頻繁に廃止されるものがある。不適切な管理により、古いプロダクトに関連したアプリケーション コンポーネントがメインフレームで実行され続けることになります。

  3. 規制やコンプライアンスに関連した変更によって使われなくなったアプリケーション コンポーネントが、メインフレームのソースコード ライブラリから必ずしも削除されるわけではない。

孤立したジョブの識別はきわめて重要です。そうしたジョブは MIPS を消費するうえ、コスト削減に直接影響を及ぼすからです。ところが、孤立したジョブの識別は簡単ではありません。アプリケーション チームやオペレーション チームは、ビジネスチームと連携して、こうしたジョブの関連性と処分の可否を把握する必要があります。所有権やスポンサーのないジョブの場合、しばらく停止して、所有権を主張するユーザーがいないか待ちます。その後、これらのチームで連携して、そういったアプリケーションの処分を決めます。

3. ビジネス価値の低いアプリ: ポートフォリオ内のアプリケーションのうち、企業にとって他のミッション クリティカルなワークロードと比べてビジネス上の重要性が低いアプリです。こうしたアプリケーションは必要ではありますが、それを実行するプラットフォームとしてメインフレームが適切だとは言えません。ポートフォリオ内の他の類似したアプリケーションと機能を統合した後に廃止するか、メインフレームの外部にリフト&シフトする必要があります。Google Cloud には、非干渉型サービスであるメインフレーム アプリケーション ポートフォリオ評価が用意されています。このサービスは、ビジネス価値と技術的な複雑さに基づいてアプリケーションをランク付けします。このランク付けにより、ビジネス価値が低いアプリケーションを識別したうえで処分方法を決めるのが容易になります。

古くて非アクティブなコードを識別して削除する際に、メインフレームにインストールされているソフトウェアに対しても同様の監査を行う必要があります。「お金の動きを追う」ことが、ソフトウェアのリストを明らかにする最適な方法と思われます。会計、財務チームと連携して、請求書や明細書を確認する必要があります。サブキャパシティ レポートツール(SCRT)のレポートを調べれば、インストールされているソフトウェアとその使用状況のリストを別の方向から明らかにできます。必要なソフトウェア、あるとよいソフトウェア、冗長なソフトウェアに分類したうえで、ソフトウェアの処分とライセンスのコストに応じて、冗長なソフトウェアのアンインストールを計画してください。

データは、テープに移されて永久に忘れ去られることがあるため注意が必要です。「持つ人がその対価を払う」という格言があるように、テープと仮想テープについて定期的に分析を実行する必要があります。アーカイブ テープには、ビジネス、規制、コンプライアンスの要件を満たすために必要なデータだけを保存することが必要です。ずいぶん前に廃止されたプロダクトに関連していた 40% 以上のテープを削除したという事例もありました。

メインフレームの最小化に着手すると、最終的にびっくりするような意義深い結果が生まれます。メインフレームがスリム化、鋭敏化、軽量化され、次の変革フェーズに移行する準備が整えられます。メインフレームの最小化には追加の資金もツールも不要です。必要なのは、決意と自制力だけです。ガイダンスやサポートが必要な場合は、Google のメインフレーム チームにお気軽にお問い合わせください。


- メインフレーム ソリューション スペシャリスト Aman Gupta
投稿先