メインフレームの出口戦略を際立たせるCIO達

「メインフレームの死」はまだ先のことかもしれませんが、企業は現在大型コンピュータからの出口戦略を模索しています。最近では、物流の多国籍企業であるFedExが、年間4億ドルのコスト削減を目指して2024年までにすべてのメインフレームを撤去すると発表して話題になっています。

FedExは、2040年までにグローバルでカーボンニュートラルなオペレーションを実現するという目標の一環としてデータセンターゼロ/メインフレームゼロの環境を採用し、コンピューティングの半分をコロケーション施設で、半分をクラウドで運用しています。この動きは、グローバルな物流プロバイダとしてより柔軟で安全、かつコスト効率の高いサービスの提供にもつながると同社のグローバル情報技術担当執行副社長であるKen Spanglerは語ります。

「メインフレームは当社の長期計画にはありませんでした。10年以上かけて、当社はメインフレームベースからゆっくりと進化してきました。基本的には、撤去、置き換え、リエンジニアリングという戦略です」と述べています。

これまでのところ、FedExの大型コンピュータアプリケーションの90%は同社のメインフレームから移行していますが、10%は相互依存のレイヤによる統合の問題から「厄介である」とSpangler氏は述べ、FedExのポートフォリオには、多くの依存関係が含まれる独自の技術を持つ「ユニークな事業会社」があると付け加えています。

このプロジェクトは状況からみてかなり大規模なものです。メインフレームのコンピューティング負荷の高いシステムをデータセンターからクラウドに移行することは、気弱な企業には困難でしょう。

それでも、IBMなどの企業は、企業のメインフレームアプリケーションのクラウドへの移行を進めていますし、多くの企業は、最新の大型コンピュータにさらに投資するなど既存のメインフレーム戦略をデジタル時代に合わせてモダナイズするといった行程に乗り出しています。

しかしFedExのようにメインフレームの資産を売却してクラウドに移行しようとする企業にとって、系統的アプローチは不可欠です。GartnerのマネージングバイスプレジデントであるMike Chuba氏は、移行する動機はさまざまだと言います。それは、「スキルの高齢化」、または「機器の老朽化やコスト」の場合もあると同氏は指摘します。

「私はよく、「もしあなたが家を持っている場合」という例えを使います。10～15年間基本的なメンテナンスをしておらず、建物が老朽化してしまった場合、その状態を回復するために多額の投資をするか、それとも他の場所に引っ越すかという非常に難しい決断を迫られるでしょう」とChuba氏は述べます。

「大幅に遅れをとっており、メインフレームが戦略的アセットや競争上の差別化要因になっていない」小規模なメインフレームショップの場合、そう単純明快に選べない可能性があります」と同氏は述べています。「サポートされていないソフトウェアを使用した10年前のハードウェアで稼働している場合などは、モダナイゼーションを試みるには規模が大きすぎます」

ここでは大型コンピュータを社内で維持することなく未来を実現できる可能性がある企業のために、そのプロセスを開始したITリーダーからの貴重なインサイトを紹介します。

ビッグデータのタイムラグを警戒する

ケーブルメーカーのSouthwireの場合、メインフレームからの脱却のきっかけは機器の老朽化でした。送配電用の電線やケーブルを製造するSouthwireのIT担当上級副社長であるDan Stuart氏は、「データセンター事業に参入したいのか、それとも他にもっとうまく処理できる企業があるのか」という問題になったと説明します。

また、機器の更新サイクルやソフトウェアの契約更新が迫っていたため、「コスト回避」も要因の一つになったとStuart氏は語ります。同社は、更新する代わりに、SAPのコア環境と同社の製造リソースシステムを含むTier1システムをGoogle Cloud Platform（GCP）に移行することを選択しました。

移行は2020年7月のコロナ禍の最中に行われ、社内スタッフ、Googleサービス、サードパーティーのプロバイダの合同で実施されたとStuart氏は述べています。同氏によると、SouthwireのコアSAPシステムは現在もGCP内のIBM DB2データベースで稼働していますが、その他のTier 1アプリケーションはGoogle Cloud VMwareで稼働しています。

移行には約8〜9カ月かかりましたが、Stuart氏はその結果に満足しています。SAPをクラウドで運用するうえで「問題はほとんど発生していない」と同氏は言います。「オンプレミスよりも問題は少ないと言えるでしょう。」

しかしデータに関する「綿密なプロジェクト計画」がなかったために問題が生じたとStuart氏は述べています。「もしもう一度やるなら、データベースをカットオーバーする前にサイズを見てクリーンアップし、過去のデータの多くをアーカイブするでしょう」と同氏は言います。「当社にとって本当の『問題』は、この作業を行うためにダウンタイムが丸2日ほど必要だったことです。24時間365日稼動している当社にとって、それ以上の時間を割くことはできませんでした」

次は、他のTier 1製造システムのいくつかを移行することです。Stuart氏は、ITがSD-WANを実装したため、これらはすでにクラウドの準備ができていると述べ、

「パフォーマンスに関するあらゆる課題を軽減するためには、帯域幅を拡大する必要があることはわかっていました」と説明します。「当社では、ダウンタイムを減らし、通過する帯域を増やすために、ネットワークプロバイダによるデータ回線を冗長化したSD-WANの展開を始めたところです」

Stuart氏はその経験から、メインフレームのアプリケーションをクラウドに移行する前にデータのクリーニングとパージを行うよう、ITリーダーたちにアドバイスしています。「『余分なデータ』を持ち越したくないのは、その分のお金を払いたくないからです。ですから、その環境の適正化を強くおすすめします。そうすることで、持ち越したいデータを正確に把握できます」と同氏は語ります。

クラウドに移行することで、Southwireはディザスタリカバリのプロセスも合理化することができました。また同社は「ESGとサステナビリティに非常に力を入れている」ため、メインフレームの運用と保守から解放されることで、二酸化炭素排出量を削減できるとStuart氏は述べています。

戦略的であること、そしてアーキテクチャを正しく理解すること

これに対して、オンプレミスのメインフレームからの脱却を目指すFedExのアプローチは多面的です。たとえば、「撤去、置き換え、リエンジニアリング戦略」の一環として、これら10%の「定着した」メインフレームアプリケーションの一つであるFedExの運送会社環境は「完全にリエンジニアリングして多額の費用を投資する価値がなかった」ため撤去する予定であるとSpangler氏は述べます。

「当社は効率的なエンタープライズソリューションを実現したいと考えていますので、2年後に廃止されるメインフレームからのリプラットフォームを行っており、新しいエンタープライズソリューションが導入されます」と同氏は説明します。Spangler氏は、「ただ一般的にリプラットフォームしないよう、非常に慎重に作業を進めています」とも述べています。

FedExのメインフレームの廃棄作業は全体として、内部と外部のチームの合同で行われています。メインフレーム撤退計画の「重要部分」は2021年に始動し、2023年までの実現を目指しています。

しかしメインフレームにはまだ「驚異的な技術力」が存在することから、Spangler氏はITリーダー達に対して、何を移行すべきかについて「経済的な視点を持つ」ことをアドバイスしています。「理論的な観点だけで判断できるものではありません」と同氏は言います。「40年以上の歴史がある当社のテクノロジーは古く、どちらにしても置き換える必要があることはわかっていました。しかも当社の企業戦略を考えるとこれはまさに理にかなっていました」

Spangler氏は、ITリーダーはエンジニアリングとアーキテクチャの原則も念頭に置くべきだと言います。「多くの人がメインフレームから撤退することに集中するあまり、混乱してしまうことがよくあるのです」と同氏は言い、強力なエンジニアリングとアーキテクチャを前もって把握しておくことが、最新かつワールドクラスであり、拡張可能で安全、および修正可能な移行の実現に役立つとも述べています。

最後にSpangler氏は、「これは戦いであり、計画を常に更新すること」をITリーダー達に推奨しています。これは困難な作業です。大変困難なのです。当社では、四半期ごとにこのビジネスケースを文字どおりゼロベースにして、最初から構築しなおしています」

FedExはそのためにすべてのコストと節約の要素を確認し、仮定が現実と釣り合うかどうかを判断するために白紙の状態から始める必要があります。これにより、何か変化があった場合は関係者がその変化を認識できるようになると同氏は言います。

「週単位、四半期単位、年単位で、より多くのことを把握しています」と同氏は語ります。「今は非常に安定しています。全体的な見通しにはかなり自信があり、非常に力強く業務を遂行しています」

重要なアプリケーションに害を及ぼさない

自社の大型コンピューターのホスティングから移行するかどうかを決定する場合、考慮すべき変更事項がいくつかあります。メインフレームの運用とアプリケーションをモダナイズするコストや、メインフレームとそのアプリケーションの稼働を維持するために必要な社内スキルを考慮することに加え、企業は可用性、セキュリティ、復元力、トランザクションの整合性といった価値を考える必要がありますが、これらは定量化が困難なことが多いとGartnerのChuba氏は言います。

「ここ10年から15年、メインフレームからの移行が試みられており、多くのCIOも同様の方針を取ってきました。…メインフレームからの移行という大義名分を掲げて参入し、失敗してきたのです」と同氏は指摘します。「ベンダーが過大な約束をしたことも原因の一部ですが、移行は容易ではないというのが真相です。アプリをより効率的に移行できる場所があるため、容易に達成できるものは（メインフレームから）取り除かれました」しかし、ミッションクリティカルなアプリケーションを移行した後にそのアプリケーションがダウンしてしまうと、事業が立ち行かなくなる可能性があるとChuba氏は指摘します。

クラウドプロバイダ、特にハイパースケーラーはこの10年間、企業によるメインフレームからアプリケーションへの移行をある程度容易にするために、多くのリソースと投資を投入してきたと同氏は説明します。しかし、機能は進化し続けています。

従ってほとんどの組織、特に大規模なメインフレームショップでは、「『ビジネスクリティカルなアプリケーションに害を与えない』ことが信条なのです」とChuba氏は述べます。「確固としたビジネスケース、および移行がシームレスに行われ、クラウドでもメインフレームと同レベルでパフォーマンス、復元力、トランザクションの整合性、セキュリティでアプリケーションが動作する確実性が必要です」

CIOがメインフレームの移行について熟考する場合、次のいくつかの重要点を考慮するべきだとChuba氏は言います。「スキルの問題がある場合、まず第一に、クラウドに移行するか、MSPに移行するかについて何かしらの手を打つ必要があります」とChuba氏は指摘します。「（メインフレームの）スキルがないのならば、あまり多くの選択肢はありません。ただ扉を閉ざして外部から遮断し、物事がうまくいくよう祈るだけではだめなのです」

メインフレームアプリケーションをクラウドに移行するか、またはモダナイズするかを検討する場合、「どの程度のリスクを許容するかという議論になります」と同氏は述べ、メインフレームの移行プロジェクトが3～6年、9～12年と長引く場合、ITリーダーはその間に多くのコストを発生させることになると指摘します。

「FedExは、ポーカーテーブルの前に座って、『オールインする』と言っているようなものです。もしそれができて、タイムリーに実行できれば、間違いなく…勝利を手にすることができるでしょう」とChuba氏は述べています。「しかしこのようなプロジェクトで足を引っ張られたり、勢いを失ったりした顧客は、容易に達成できる目標から始めた後にプロジェクトが泥沼化し、次の魅力的な目標を追い求めることになります。そのような場合、コストはかなり大きくなります」

FedExのSpangler氏は、撤退する環境かどうかにかかわらず、ITと企業はコミットメントを維持しなければならないことに同意します。「この種のテクノロジーは非常に統合的なものなので、それを主導し、しっかりと推進しなければなりません。そして、集中力を切らさないこと。そこが困難なのです」と同氏は語っています。