信用調査会社のExperianは、メインフレーム環境向けDevOpsの導入で行き詰まっている大手企業の1社だ。同社には信用情報を個人に関連付ける「ピンニング（pinning）」というプロセスがデータ取得業務の一環として存在している。このプロセスにより、社会保障番号よりも一意で信頼できるID情報が生成される。同社で使用しているIBMの「IBM z3」メインフレームはピンニングの重要な役割を果たしている。IBM z3はそのコンピューティング負荷の大きいワークロードを、高いパフォーマンスと確かな信頼性で処理する。同社が所有するメインフレームの6つのインスタンスはいずれも3年以上にわたって機能が停止したことがない。

　ExperianもアジャイルとDevOpsによる一連の戦略に乗り出した。運用分散システムにおけるセルフサービスとインフラの自動化に慣れてきた開発者にとって、IBM z3が妨げになっている。

　「IBMは状況を認識しており、『z/OS』と『IBM Z』に変更を加えている」と話すのは、米カリフォルニア州コスタメサに拠点を置くExperianでグローバル最高情報責任者（CIO）を務めるバリー・リベンソン氏だ。例えば、「IBM UrbanCode Deploy」CI/CD（継続的インテグレーションと継続的デリバリー）ツールはメインフレームにおけるアプリケーション導入の自動化をサポートする。「当社が懸念しているのは、開発者が独自の運用インフラや、ネイティブな構成管理機能をz/OSにプロビジョニングできるツールがまだ存在しないことだ。Chef Softwareの『Chef』やPuppet Labsの『Puppet』のような構成管理機能がない」（リベンソン氏）

　ChefはIBMのLinuxサーバ「IBM LinuxONE」との統合を通じてIBM Zメインフレームをサポートする。しかしExperianの大半の上級メインフレーム専門家はz/OSを支持し、「LinuxONE」に難色を示している。Puppetでもz/OSのサポートを提供する。リベンソン氏によると、z/OSのネイティブ管理ツールからこれらの機能を利用できる方が好ましいという。

　IBMの「z Systems Development and Test Environment V11」には、下位環境でのアプリケーション導入用に一部のセルフサービス機能が用意されているが、Experianの開発者は、IBM Zの論理区画（LPAR）など、運用サービス用の自社製ツールを作成した。これらの自社製ツールはメインフレーム上のLPAR、コンテナ、仮想マシン（VM）の利用状況も監視する。そして、これらが一定時間アイドル状態になっていたら自動的に停止するか、手動で停止するよう管理者に通知する。

　「これらのシステムはこうした動作を行うようには設計されておらず、それには高いコストも掛かる。コモディティハードウェアには多くの選択肢がある。だが、メインフレームの処理能力が足りなくなった場合はIBMから追加エンジンを購入するしかない。また、メインフレームを理解している人材を探すことも難しくなっている」（リベンソン氏）

　Experianで雇用している1人のメインフレーム専門家は、バックエンド管理者にありがちな視野が狭くて変化を拒むタイプではないとリベンソン氏は言う。しかしそのメインフレーム専門家は無限のリソースでもなければ、一生現役でいるわけでもない。

　「彼には私よりも先に辞めようとしたら承知しないとよく言っている」とリベンソン氏は話す。

　リベンソン氏によると、最終的にExperianはメインフレームから移行することを計画しており、現在メインフレームアプリケーションでの製品開発は停止しているという。メインフレームからの移行プロセスには3～5年掛かる見込みだ。

メインフレーム向けDevOpsの進化

　古くて規模の大きいメインフレームを抱える企業でも、数年がかりでメインフレームから移行するにはコストが高過ぎる場合がある。

　「ある保険会社の顧客からは3000万ドルが必要だと聞いた。メインフレームプラットフォームから撤退する十分な理由がなくても、DevOps固有の多くの機能を実現する方法は幾つかある」とForrester Researchでアナリストを務めるクリストファー・ガードナー氏は話す。

　CA Technologies、IBM、Compuwareなどのメインフレームベンダーには、メインフレーム向けDevOpsと日常業務の距離を縮めるツールがある。IBMのUrbanCode Deployエージェントは、メインフレームを扱うDevOpsチームにアプリケーション導入の自動化とオーケストレーションワークフローを提供する。同社は、Gitリポジトリからz Systemsへのコード導入のサポートも最近追加した。また、オープンソースのCI/CDツール向けのz／OSコネクタ「Jenkins」もある。Jenkinsの他に、Electric CloudやXebiaLabsが提供するCI/CDツールでもメインフレームアプリケーション導入をサポートする。

　CA Technologiesは同社の「Mainframe Operational Intelligence」ツールでメインフレームでのAIOps（Algorithmic IT Operations）サポートを提供する。2018年6月にはSaaSツールの「Mainframe Resource Intelligence」も導入した。これはメインフレーム環境をスキャンして最適化を提案する。Compuwareのツールはメインフレームでの更新とプロビジョニングを高速化するもので、顧客によるメインフレームの近代化を促すことを狙う。Compuware自体もこの4年間で独自のDevOps変革を実行した。

　この分野のベンダーと専門家が口をそろえて、メインフレーム環境でのDevOpsでは文化が最大の課題になるという。開発者とIT運用担当者の間で激しい文化の衝突が起きることがある。

　この課題を解決するために、メインフレームの専門家がソフトウェア開発戦略に参加することが不可欠だとガナパシー氏は指摘する。同氏の顧客は職務上の枠を超えたチームを用意し、パブリッククラウドからバックエンドメインフレームまでのインフラプラットフォーム全体でDevOps手法の標準化方法を判断している。

　「そこではメインフレームの知識が非常に大きな価値を持ち、企業レベルで役割を果たす可能性がある。重要なのは、特定の事業部門にとらわれることなくメインフレーム専門家が発言できるようにすることだ」（ガナパシー氏）

　メインフレームは、分散システムのような速度やアジリティで運用されることは決してないだろう。ただし、速度はDevOpsの効率を評価する1つの指標にすぎないとForrester Researchのガードナー氏は言う。

　「品質も文化もDevOpsの一部であり、継続的なフィードバックループの一環でもある。バグを早々とリリースしてしまったり、チームを過度に働かせ過ぎたりすることで多くの従業員が離職するような事態になったら、DevOpsでの責務を果たしていないことになる」（ガードナー氏）