アジャイルなメインフレーム コンピュウェアがメインフレームを再活性化 Robin Bloor, Ph.D. & Rebecca Jozwiak ホワイトペ ーパ ー アジャイルなメインフレーム メインフレームの世界 Google や Facebookなどの企業が分散コンピューティングの力をベースにしている一方、他の大企業は メインフレームの方がうまく動作するタスクがあることを知っています。銀行や通信、小売などのトランザ クションの処理量が多い企業では、メインフレームが十分なパフォーマンスと確実性を維持してきたた め、何十年もの間、トランザクション処理を任せてきました。メインフレームで動作するアプリケーショ ンは、ビジネスをサポートし価値を創造しており、テクノロジーが新しい需要を満たすために進化してき たのと同じように、働き者のメインフレームも、今日のビジネスニーズに対応するため進化しています。 IBM が 2015 年 1月に世界に向けて発表したz13メインフレームは、地球上で最も高性能なビジネスコ ンピューターであり、5 年にわたる10 億ドルの開発プロジェクトの成果です。構成を最大にした場合、1 日当たり25 億件のトランザクションを処理できます。モバイル コンピューティングを考慮して構築され、 莫大な数のモバイル トランザクションを処理できます。また、暗号化や分析も迅速に実行します。実際、 非常にセキュアな運用、極めて高い信頼性、管理のしやすさ、作業負荷の多様性、そして超高速パフォー マンスといったメインフレームの特性は、モバイル コンピューティングのために用意されたものです。 もちろん注目したのはそれだけではありません。「プライベート クラウド」という用語が考え出されるより ずっと前から、IBMは仮想サーバー環境としてメインフレームを育んできました。z13はこの性能を強化 したもので、8,000 台の仮想サーバーを実行・管理できます。これはある意味、物理的に完全に分散 されていないだけの分散コンピューティングであり、分散による苦労の多くを避けることができます。 技術的に詳しく説明すると、z13は「一般的なサーバー プロセッサーの 2 倍の速度を誇る世界最速の マイクロプロセッサー、300% 増のメモリー、100% 増の帯域幅、ベクトル処理解析」を備えています。 最大 10テラバイトのメインメモリーを搭載でき、マルチスレッドや並列処理に対して、アーキテクチャ面 から革新的な改善を行っています。もし疑いを持っている人がいたとしても、これなら依然としてIBM が メインフレームにしっかり取り組んでいる証拠と認めるでしょう。 寿命とメインフレーム 1990 年代初め、クライアント/ サーバー コンピューティングの到来とインターネットの幕開けと共に、メ インフレーム コンピューティングの衰退が予想されましたが、それは間違いでした。振り返ってみると、 理解するのは容易です。分散コンピューティングへの大きなパラダイム シフトがあり、その結果、IBMよ り小さな企業のメインフレームなど、サーバー コンピューターの多くのモデルは、確かに姿を消しました。 Unix サーバーや Windows サーバーの市場が急成長し、インターネット市場の大半を獲得しました。 IBM のメインフレームは、低価格市場で顧客の一部を失い、厳しい年月を過ごしました。しかし一方で IBMは、急速に変化するテクノロジー環境に迅速に順応しようともしていました。 それにもかかわらず、IBM のメインフレームは最も強力な商取引エンジンであり続けており、非常に要求 の高い世界中のシステムの多くが、IBM のメインフレームをベースに実装されました。それに匹敵するプ ラットフォームはありませんでした。結果、メインフレームは生き残り、IBMはその性能への投資と改善 を続け、一部の顧客を失いはしたものの、新たな顧客を獲得しました。 規模の経済 様々な調査が繰り返し示すように、最悪だった1990 年代でさえ、メインフレームは依然として最も経済 的なコンピューティング プラットフォームでした。今なお、これに変わりはありません。たとえば、2012 年から2015 年にかけてRubin Worldwide が 498 社の大企業を調査した結果によると、分散コン ピューティングのコストとメインフレームのコストの差は広がっています。テクノロジー要件の密度が高く なっているためです。実際、計算能力は過去 5 年間で 2 倍になった一方、サーバー中心の企業のコスト は、メインフレーム中心の企業より63% 高くなっています。さらに15 の業界を分析した結果、平均的な IT 商品コストはメインフレーム中心の企業が（業界を平均すると）35% 低く、その差が最も大きいのが 金融部門で、平均コストは何と69%も低くなっています。 1 アジャイルなメインフレーム これは、少しも不思議なことではありません。メインフレー ムは、可用性が 99.999%に達するだけでなく、最高ランク の EAL5 セキュリティ区分を獲得でき、100%に近いリソー ス使用率も実現できます。さらにメインフレームは、特に混 合した作業負荷に適しています。分散環境では、混合した 作業負荷に、確実かつ低コストで対応するのは困難です。 またメインフレームは、Linux 仮想マシンの収容能力に優 れています。VMwareよりすでに数年前に、IBMはその機 能を組み込み利用可能にしていました。このイニシアチブ は大きな成功を収め、今日ではIBMは、最大 8,000 台の 仮 想マシンを収 容 できるLinux 専 用のメインフレーム （LinuxONE）を提供し、KVM、Apache Spark、Docker など、多くのオープンソース製品を効果的にサポートしてい ます。ただし、ほとんどのメインフレーム ユーザーは、この 機能を利用してLinux の作業負荷をメインフレームの作業 負荷と混合しています。 メインフレームの経済性 メインフレームは、実働作業負荷の 68% を 処 理 し な が ら、IT 支 出 の 6% 1 しか占めていません。 過去 5 年間に、サーバー中心の IT 企 業のコストは、メインフレーム中心 の企業のコストより 63% 高くなって います。2 平均的な IT 商品コストは、メインフ レーム中心の企業が 35% 低くなって います。2 1IBMが委託したSolitaire International Analyst Report 2014 2Dr. Howard Rubin、Rubin Worldwide、Gartner シニア アド バイザー 現在メインフレームは、サーバー市場（ハードウェア売上）の約 10%を占めています。また、多くの大 企業のコンピューティング インフラで主要な役割を果たしています。その人気の理由は、他に類を見な い規模の経済にあります。メインフレームは、多くのサーバー統合プロジェクトの中心となってきました。 多くのメインフレーム ユーザーは、アプリケーションをメインフレームに移行した結果、分散コンピュー ティングへの投資を減らしています。メインフレームに有利に働いたもう1 つの傾向は、「アプリケーショ ン拡張」です。メインフレームは、業務処理システムの有用性を拡張または強化するモバイル アプリケー ションの拠点になりました。また、こうした傾向を引き継ぐ形で、Internet of Things（IoT：モノのイ ンターネット）で重要な役割を果たす可能性もあります。 敬遠される理由 コーポレート コンピューティングにおいて費用対効果が最も高いことを考えれば、メインフレームにもっ と人気が出ないのは少し意外なことです。しかし、 これには理由があります。メインフレーム コンピューティ ングの初期導入費が高いためです。そのため、新たに導入しようとするには、本来の利点が効果を出す レベルまで、その価値を急速に拡大できるという確信が必要になります。 躊躇させるもう1 つの理由は、熟練スタッフを確保できるかという点です。ソフトウェア開発スキルとメイ ンフレーム運用スキルの両方を備えた人材は限られています。その原因の 1 つは、世界中の大学がメイ ンフレームは衰退の一途をたどっていると考えており、メインフレームにほとんど注目しないためです。 これは広範囲に影響を及ぼしました。大学の環境で育まれ、その後、新興企業の成長環境を生み出す 新しいアイデアとテクニックの絶え間ない流れは、メインフレーム コンピューティングにはほとんど貢献し ませんでした。Unix、Linux、Windowsは、イノベーションを育み、新しいアイデアに刺激された新し い開発言語や革新的な開発製品を生み出しました。それには、グラフィカル ユーザー インターフェイス、 オブジェクト指向、ドキュメント ストア、多層ソフトウェア アーキテクチャ、Web サービス、メッセージン グ システムなどがあります。対照的に、メインフレーム ソフトウェアの世界は、ますます孤立するように なりました。自社の製品をメインフレームに組み込み、従来のメインフレーム ソフトウェア ベンダーと競 合する必要を、ほとんどのソフトウェア新興企業が感じなかったためです。さらに、ITスタッフがメインフ レームを導入したり拡張したり、あるいはメインフレームへ転向する際の妨げにもなりました。 2 アジャイルなメインフレーム これまでのやり方に固執した、それが IT 文化でした。経験豊富なメインフレームのスタッフは、メインフ レーム以外の IT 界にほとんど関心を示しませんでした。メインフレームのスタッフの高齢化が、スキルの 危機を徐々に誘発していなければ、無関心のままだったかもしれません。しかし、この危機が結果として、 IBMとコンピュウェアのような他のメインフレーム ソフトベンダーを行動へと駆り立てることになりました。 一方で、メインフレーム界以外の技術開発は、メインフレーム コンピューティングの品質と経済性に匹 敵する代替プラットフォームを生み出すことに失敗しました。したがって、多くのアプリケーションにとっ て移行は意味がありませんでした。移行する先がないからです。他方でメインフレームのスキル危機は 迫ってきており、時とともに悪化していくのみでした。2005 年には、メインフレームの科目を提供する大 学の数は、世界中で 24にまで減りました。 IBMはこの状況を徐々に正そうと、z Systems Academic Initiativeを立ち上げました。今日では、 66 か国の 1,000を超える大学が、IBMメインフレーム テクノロジーの科目や研究室を備えています。 IBMはこれを、クラウドを経由してメインフレームへのアクセスを可能にすることによってサポートしてい ます。また、学生向けの Master The Mainframeコンテストを年 1 回開催し、SystemzJobs.comと いうWeb サイトを設置することによって、z Systems の労働市場を刺激しています。この Web サイトでは、 大学卒業者を含む求職者が履歴書を投稿し、多くの求人情報を参照できます。 これらの投資は状況を変えるのには役立ちましたが、スタッフ不足は解消されず、メインフレームは今も 過去に固執する文化のおかげで先に進めません。メインフレームは、ソフトウェア環境の最近のイノベー ションに一部参加していますが、その歩みは常に遅れがちです。先導することは決してなく、追従するの が常であり、時にはまったく参加しないこともあります。たとえば、アジャイルなソフトウェア開発がメイン フレーム開発の特徴であると考える人はいません。実際そうではないからです。 メインフレームの見直し メインフレームは、コーポレート コンピューティングの中心で、安定した揺るぎない地位を占めています。 先進の技術、極めて高い可用性、最高レベルのセキュリティ、繰り返し実証されてきたIT 経済性を提 供しています。次世代のメインフレーム スタッフが労働力となりつつあり、退職していくスタッフと徐々に 交替します。以前は、当然のようにCIOにもメインフレームの経験がありましたが、今ではそれほど一 般的ではありません。 不幸なことに、次世代 CIO のほとんどがメインフレーム界に触れたことがほぼないまま、メインフレーム を統轄することになります。Unix、Linux、またはWindows 環境から来たCIOは、開発サイクルが長く、 現代的なインターフェイスがないことにおそらく驚き混乱するでしょう。そしてこれは、ほとんどのメインフ レーム ソフトウェアにも当てはまります。次世代 CIOはおそらくLinux の機能に改めて感動します。しか しすぐに、メインフレームは優れたLinuxプラットフォームではあるものの、メインフレームで動作する格 段に効率的なソフトウェアが本来の z/OSソフトウェアであることを理解するでしょう。本来の z/OSアプリ ケーションは、保守・拡張され続けます。しかし、ソフトウェア開発文化、プロセス、ツールが変化し なければ、Linux 環境外で新しいものが作成されることはほぼありません。 メインフレームの運用特性を考えると、これは賢明ではありません。メインフレームでは、今でも少なか らずウォーターフォールの手法や考え方に基づいていますが、メインフレーム ソフトウェア文化を活性化 するには、 アジャイル開発の手法やテクニックを取り込む必要があります。 アジャイルな分散コンピューティ ングの世界の実績ある有効性と革新的な精神を、メインフレーム ソフトウェア開発に吹き込めないという 技術的な理由はありません。 3 アジャイルなメインフレーム COBOL や PL/1 のアプリケーションを開発・保守するためのアジャイルなツールについて考えるのは、 奇妙に思えるかもしれません。しかしアジャイルなツールは、C++ や Javaで利用されており、これらの 言語は、多くのメインフレーム サイトで、主要開発言語としてAssembler や COBOLまたはPL/1に取っ て代わっています。そのため、Java 用に考案されたEclipse 統合開発環境（IDE）は、メインフレーム 開発環境でもかなり普及しており、今日ではCOBOL や他のメインフレーム プログラミング言語をサポー トしています。Eclipseは、世界中でプログラミング教育の事実上の標準となっています。ガートナーに よると、開発者の 98% が Eclipseに精通しています。 アジャイル ソフトウェア開発ツールの総合パッケージがメインフレームで利用可能であれば、分散ソフト ウェアの世界と同様に、アジャイル開発のテクニックや実践がそこで花開かない理由はありません。この ことは、メインフレーム ソフトウェア開発の旧態依然の文化に切望された進化を引き起こし、メインフレー ムの利点を活用するイノベーションの機会をさらに復活させると私たちは見ています。アジャイル開発を 採用したメインフレームを想像してください。職種を超えた共同チーム、迅速なデリバリー、頻繁なリリー ス、変化と継続的な改善への迅速で柔軟な対応、このような復興が可能なのです。実際、それはすで に始まっているのかもしれません。 コンピュウェアとメインフレーム 上述のメインフレームの復興は、アジャイルなメインフレームへの進化をリードする洞察力を持つ会社、 コンピュウェアのビジョンとなっています。これは、マーケティングの豊かな想像から生まれた空想ではあ りません。コンピュウェアが最初に自らに適用した文化的変化です。つまり、自社のソフトウェア製品の 点からだけでなく、CEOであるChris O’Malley がコンピュウェアに課した文化的変化に従ったからで あり、コンピュウェアは「自身が説く教えに改宗」しているのです。 したがってコンピュウェアは、頻繁にソフトウェアをリリースするというアイデアを推進するだけでなく、そ れを実現するために開発チームも編成しました。アジャイルな開発や継続的なデリバリーを推奨するだ けでなく、それを顧客に実証しています。たとえば主要製品であるTopazを、過去 1 年間で 4 回リリー スしています。 「コンピュウェアの推奨する継続的なデリバリーとは？」という疑問が、すぐに湧いてきます。それは単な るスローガンではありません。図 1に示すように、それはDevOps 手法全体に基づきます。 図が示すように、ソフトウェア開発プロセスは反復的であり、運用配備と絡み合っています。開発側では ユーザー要求が処理されると、アプリケーションとデータが分析されます。ソースコードとデータが編集 され、変更が継続的に構築、テスト、デバッグされ、製品に組み込まれます。このプロセスは、顧客と 一緒に製品を検証する、継続的なスプリント レビューをサポートします。適切なユーザー エクスペリエ ンスが実現するまで、このプロセスに変更がフィードバックされ続け、実現してから製品が導入されます。 その時点で、自動で導入サイクルが始まります。アプリケーションの使用は監視・監査され、問題があ れば分析されてアプリケーションのパフォーマンスが調整されます。顧客からのフィードバックや運用上 の問題が開発者に提供されるに従って、開発と運用との間のコラボレーションは、さらに活性化されます。 提案された変更は、自動的に追跡・承認・導入されます。ここでは単一のアプリケーションで説明しま したが、この二重サイクルの範囲は、複数のアプリケーションからなるシステム全体にも及びます。 4 アジャイルなメインフレーム デバッグ 整 導入 テス 調 ト ードバック フィ Ops（運用） ビル 診断 Dev（開発） 析 分 監 ド 編集 視 監査 図 1 コンピュウェアの DevOps 手法：概要 このアジャイルなDevOps 手法は、大型クラスターの新しい Hadoop の世界に普及している、フルスタッ ク開発文化特有のものです。これは、ウォーターフォール開発手法や 1 年以上が必要なゆっくりした開 発サイクルによる、サイロ化された重々しいメインフレームの世界と明確に異なり、新鮮なコントラストを なしています。 コンピュウェアは、Topaz の導入によって、自身が採用し今では推奨するアジャイルなDevOps 手法を 顧客が採用できる態勢を整えました。一方で、1 つのベンダーが単独で、必要なソフトウェア ツールを すべて提供することはできないことも認識しています。そのミッションを先へ進めるため、 コンピュウェアは、 2016 年の最初に2 つの重要なイベントを発表しました。まずコンピュウェアは、クロスプラットフォーム 開発のための主要アジャイル ソースコード管理、リリース自動化ソリューションであるISPW の資産を買 収しました。次にコンピュウェアは、オープンソース プロバイダーを含む、非メインフレームDevOpsリー ダーとの広範囲に及ぶパートナーシップと統合を発表しました。 Topaz スイート 単一の開発チームが、COBOLであろうとJavaであろうと、あらゆるタイプのコードをサポートできるよう、 メインフレーム ソフトウェア開発を革新しようとするコンピュウェアの取り組みを証明するのが、Topazで す。古いメインフレーム開発者のスタイルから大胆かつきっぱりと離れ、コンピュウェアの多数の主要ソ リューションを活用した、最新の開発環境を提供します。 またTopazは、エンタープライズ データ エディターや直観的な視覚化機能など、非メインフレームでト レーニングを受けた開発者にさらにパワーを与える、新しい機能も提供します。新しい世代の開発者は、 メインフレーム開発の難解さを回避できる一方で、従来のメインフレーム開発者も、より生産的な環境 や機能を利用できます。 以下は、Topazスイートの最新ツールの代表的な例です。 5 アジャイルなメインフレーム Topaz Workbench 安定した信頼できるコンピュウェアのコンポーネント、Abend-AID、File-AID、Hiperstation、Strobe、 Xpediterを採用したTopaz Workbenchは、従来のメインフレーム インターフェイスの複雑さを解消し ます。その統合インターフェイスは、Linux や Windows、OSワークステーションでも場違いな感じがし ません。 つまり製品の基本機能はそのままですが、操作方法がまったく異なります。 その中身を見ると、以下のようなコンピュウェアのメインフレーム製品で構成されています。 •Abend-AID – アプリケーション不具合の素早い解析と解決のためのソースコードおよびデータ 解析ツール •File-AID – データの再フォーマットを可能にし、テストデータやファイルへの迅速で便利なアクセ スとそれらのセキュアリングを提供するデータ管理ツール •Hiperstation – 品質保証およびデータ違反抑止のための自動テスト・監査ツール •Strobe – パフォーマンスやスループットの問題と効率低下を特定し解決するためのアプリケー ション パフォーマンス監視・解析ツール •Xpediter – 対話型テストを可能にし、 アプリケーション機能についての知識を明らかにするデバッ グ・解析ツール ただし、Topaz Workbench のポイントは、その中身を見る必要がないという点にあります。 コンピュウェアは、一般的なオープンソースIDE、Eclipseを活用することによって、現在のプログラマー がなじんでいる使いやすさを実現しています。Eclipseは、Topaz Workbenchに、ベテランのメインフ レーム開発者が何年もの経験を通じて獲得したすべての能力を提供します。これらは、従来のメインフ レーム言語をサポートしながら、すでに人気のメインフレーム プログラミング言語であるJavaを通して 提供されます。定年を間近に控えたメインフレーム開発者は、慣れ親しんだ言語を使い続けるかもしれ ませんが、Javaは今や十分にサポートされています。クロスプラットフォーム開発においても、適切であ れば、現代的な言語を使用できます。これは、旧態依然の古臭い環境を活性化するのに役立ちます。 Topaz for Enterprise Data メインフレームのデータへのアクセスとその管理は、常に独特であり、メインフレームのデータと非メイン フレームのデータを組み合わせたビューの具体化は、決して容易ではありませんでした。ベテランのメイ ンフレーム プロフェッショナルの面々と新世代の開発者との間の文化的断絶は、この課題によって常に 拡大してきました。 Topaz for Enterprise Dataでは、その双方が、まったく異なるプラットフォームや DBMS 上で、同じ 形式でデータにアクセスしデータを操作できます。これによって、組織全体で生産性が大きく向上します。 Topaz Enterprise Data Editorによって、ソース固有のツールに頼ってメインフレームのレベルにある データを管理する必要がなくなり、メインフレームのデータと分散型データの両方に対応した、単一の ユーザー インターフェイスによる操作が実現しました。 Topaz の Relationship Visualizerでは、非常にグラフィカルな視覚化を通して、企業全体のデータ オブジェクト関係を表示し管理できます。チームによって利用する企業データのビューが異なる場合、複 雑なデータ関係を本当に理解しているチームは、ほとんどありません。Relationship Visualizerは、 特にこの問題に対応します。 6 アジャイルなメインフレーム Topaz for Program Analysis 20 年間稼動しているメインフレーム プログラムの詳細を知っている人間が 1 人しかいない、それどころ か誰にもよく分からない、というのは珍しいことではありません。メインフレーム専門スタッフの人数が減 るにつれて、誰かが足を踏み入れ、非常に貴重でかけがえのないメインフレームのプログラムの保存と 発展を引き継ぐことが、ますます重要になっています。特に何年にもわたるコード変更が文書化されてい ない場合、ベテランが十分理解しているメインフレームのプログラムを、新人がまったく理解できないと いうこともありえます。そうなると、やがて退職する開発者の後継者を探すことが、解決困難な課題にな る可能性があります。 Topaz for Program Analysis の目的は、理解が進まずやる気を損なわせがちな状況を、シームレス な移 行に変えることです。このコンポーネントは、 稼 働中のメインフレーム プログラムを分 析し、 Runtime Visualizerを通して、結果をグラフィカルに返します。アプリケーションが起動されたときにメ インフレームのプログラムが互いにどう対話するか、ある時点でプログラムがどの外部呼び出しを実行し ているか、それらの呼び出しがどれほどの頻度で行われているか、そうしたことを含む詳細が視覚化さ れます。さらに、現在の動作を理解し変更の影響を確認するため、編集している間にプログラムを視覚 化できます。 Topaz Runtime Visualizerは、画期的な機能にグラフィカルな表示を提供し、実行中のプログラム間 の複雑なインタラクションを分かりやすく示します。IT 部門は、文書化が不十分な古いシステムさえ、自 信を持って高度化や手直しを行うことができます。 またTopaz for Program Analysisは、各プログラムに関連したコードやコピーブックをドリルダウンで きる、インパクト解析機能も備えています。状況によって開発者は、ソースコードに触れることなく、デバッ グやトラブルシューティングなどの保守タスクを実行できます。 Topaz for Java Performance 企業が Javaテクノロジーを採用するにつれて、Java 仮想マシン（JVM）の導入は、はるかに一般的 になりました。今や多くのメインフレーム環境が、バッチ処理にJavaを、アプリケーション ミドルウェア やインテグレーション ミドルウェアにWebSphereを活用しています。Topaz for Java Performance は、大規模なWebSphere 環境とは異なる方法でこのマーケットに貢献します。Java Batchは、メイン フレームでは比較的新しいテクノロジーですが、IBM の非常に最適化されたCOBOLと同じレベルの、 慣れ親しんだパフォーマンスを顧客が維持するのを支援するツールを必要とします。 Topaz for Java Performanceは、Java Batch および WebSphere のパフォーマンス用の動的な視 覚分析ツールです。たとえばユーザーは、CPU 稼働率を監視し、JVMに割り当てるリソースを追加す る必要があるか判断できます。JVM のヒープ メモリーを確認し、必要に応じてメモリー割り当てを調節 できます。またTopaz for Java Performanceは、メモリー リークやスレッドのブロック化などの問題 も可視化します。 Javaクラス ライブラリは巨大であり、パフォーマンスの問題が発生すると、どのクラスが問題の原因で あるかを判断するため、クラスを次々と調べるのに途方もない時間を費やす場合があります。Topaz for Java Performanceは、呼び出されたJavaクラス メソッドを割り出し、CPU 稼働率を基準にクラス メ ソッドをソートできます。それにより、パフォーマンスを悪化させサービスレベルに悪影響を及ぼしている クラスを発見するために必要な時間が短縮されます。 7 アジャイルなメインフレーム 変更を促進し品質を改善する ISPW コンピュウェアは、ウォーターフォール手法に固有の、時代遅れのメインフレーム ソースコード管理製 品が引き起こす、開発とデリバリーの遅延を減らす必要性を認識しました。ISPW の買収によって、コン ピュウェアは、現代的な洗練されたソースコード管理とリリース自動化の機能をそのポートフォリオに加 えました。ISPWは、並行同時開発を可能にすることによって、アジャイル開発と継続的な導入をサポー トします。ソースはISPW のセントラル ライブラリで保管され、ユニバーサル アクセスを可能にします。 開発者はアプリケーション プロセスの各段階で、同期、可視性、通知から恩恵を受けます。ISPWは さらにエンドツーエンドの追跡を行い、実働環境で、または何らかのレベルで動作するコードに影響を 与えるあらゆるアクションを表示できます。コードをチェックアウトするとき、ISPWは他のプログラムへ の考えられる影響について通知します。承認者や管理職向けのブラウザー インターフェイスでは、モバ イル デバイスからでもいつでも承認できます。Topaz Workbenchと共に使用すると、開発者はコンピュ ウェアの開発ツールすべてにアクセスできます。 パートナーシップおよび Topaz のエコシステム 協力と管理 デバッグ 整 導入 テス 調 ト ードバック フィ Ops（運用） ビル 診断 Dev（開発） 析 開発者の 生産性 コード の品質 継続的な統合 分 ソースコード 管理 視 監 ド 編集 監査 リリースの 自動化 データ管理 アプリケーションの パフォーマンス管理 図 2 Topaz のエコシステム 図 2では、絡み合ったDevOps サイクルの中心にTopazを配置し、図の上部では、補完的なDevOps テクノロジーの最高のベンダーとの戦略的パートナーシップによって、Topaz のエコシステムを豊かにす るコンピュウェアの取り組みを示しています。ここでの目標は、メインフレームと分散処理の世界の両方 にわたる、最新かつフル機能の環境を提供することです。 コンピュウェアが、DevOpsを可能にする重要なステップに最初に選んだパートナーは、次のとおりです。 •Atlassian Jira Software: Jiraは、アジャイルで総合的なチーム計画・プロジェクト管理製品 です。アプリケーションのビルド、テスト、リリース全体からバグ追跡や問題解決まで、すべてを カバーします。 •Jenkins: Jenkinsは、Javaで構築されたクロスプラットフォームの継続的なビルドおよび統合 のツールです。MIT のライセンスの下でリリースされるオープンソースでありフリーソフトです。豊 富なビルド済みプラグインが付属し、非常に幅広いソース構成管理（SCM）およびテスト/ 開発 テクノロジーとの統合が可能です。バージョン管理システムでのコミット、cronライクなスケジュー ラーによるスケジューリング、関連ビルドの完了、さらには特定のビルドURLを要求することで、 ビルドをトリガーできます。 8 アジャイルなメインフレーム •SonarSource: SonarSourceツール（SonarQube や SonarLintなど）は、継続的なコード 検査とコード品質管理を提供します。重複するコード、コーディング エラー、傾向を見つけ、新 しいコードや書き換えられたコードが統合されたことを自動的に確認します。SonarSourceツー ルは、ダッシュボードおよび視覚化を提供し、コードの品質と管理の粒度の細かい可視化を可能 にします。この機能の重要性を軽視することはできません。コードへの変更は避けられないため、 継続的で自動化された管理プロセスがなければ、システムに「技術的負債」が発生し、開発や リリース サイクルの速度が低下します。SonarSourceツールでは、無駄の多いまたは不完全な コードを書くことによる、一時しのぎの手法を用いることができません。 •AppDynamics: AppDynamicsは、広範囲の分散環境に対して、アプリケーション パフォー マンス管理および IT 運用分析を行います。一般的なすべてのプログラミング言語、JMSなどの複 雑なエンタープライズ プラットフォーム、TIBCO、WebMethodsなどのキューイング技術を採用 しています。 •Dynatrace: Dynatraceは、代替のアプリケーション パフォーマンス管理機能を提供します。 それには、トランザクションの深い追跡、シンセティック監視、リアルユーザー監視、ネットワー ク監視など、具体的なユーザー エクスペリエンス機能が含まれます（この企業は以前コンピュウェ アの一部であったため、その製品はコンピュウェア中心の環境によく導入されています）。 •Splunk: エンタープライズ運用環境で一般的によく使用されているSplunkは、 「機械生成」デー タを検索、監視、分析できます。通常、「機械生成」データとは、データセンターまたはクラウ ドにある何らかの種類のアプリケーションまたはデバイスによるログファイルを意味します。この機 能はほぼリアルタイムに動作し、便利なグラフやレポート、警報、ダッシュボード、視覚化を生成 するよう構成できます。 •BMC: このパートナーシップによってコンピュウェアとBMCは、BMC の Cost Analyzer for zEnterprise (CAZE) およびその MainViewをコンピュウェアの Strobeと統合し、アプリケーショ ンを意識した作業負荷管理およびコスト最適化を行います。これによって、作業負荷によるリソー ス消費の理解を深め、非能率な箇所を正確に特定でき、IBM の毎月のライセンス料金を最小限 に抑えるのに役立ちます。この統合は、より広いパートナーシップの一環であり、2 社が計画中 の統合のうち最初の統合になります。 これらの最上のパートナーシップに共通のテーマは、メインフレームとクロスプラットフォーム開発のため の、現代的でアジャイルなDevOps 環境の作成です。当然これは、Topaz の背後にある基本設計概念 である、文化の破壊を伴う現代的かつアジャイルで生産的なプラットフォームと一致します。 メインフレームの再定義 メインフレームの基本的な経済性と、それが収容する基幹アプリケーションおよびデータの重要さは、リ ソースの最大限の利用と、その使用を自然に拡張していこうという動きを加速させます。多くのメインフ レーム ユーザーが持つアプリケーション拡張のニーズ―モバイル ユーザーに対応するためのメインフ レーム アプリケーションの現在の拡張と、さらに急速に出現しつつあるInternet of Things（IoT：モ ノのインターネット）に対応するためのメインフレーム アプリケーションの将来の拡張―が、この傾向 を強める要素となっています。 9 アジャイルなメインフレーム メインフレームの主な弱点は、そのソフトウェア環境が時代遅れで難解なこと、また熟練スタッフが高齢 化し徐々に定年退職を迎えることです。これらの重大な2 つの問題を解決し、プラットフォームの違いが シンタックスのみであるようにすれば、メインフレーム エコシステムが、かつての活気を取り戻さない理 由はありません。それが今可能に思われることは、注目に値します。 もしそうなれば、コンピュウェアによるメインフレームの再定義が大いに役立ったことになります。メイン フレームは、完全に現代的なコンピューター環境であり、ソフトウェアの補完的なエコシステムに囲まれ たアジャイルな開発ツールが、メインフレームとクロスプラットフォームの両方の開発と配備をサポートす るのです。 そのような環境では、スキルの問題は自ずと改善に向かいます。メインフレーム導入に向けた開発と他の プラットフォームに向けた開発との間に違いはほとんどありません。一部のプログラミング言語の場合と 同様、データ コーディングが異なる場合がありますが、継続的な開発スタイルは同じになります。ツー ルの使用感も同じであり、同じ現代的なインターフェイスを備えています。メインフレーム文化は徐々に 変わり、長い開発サイクルと変化に対する独りよがりな抵抗も徐々に消えつつあります。 すでにコンピュウェアは、その将来に向けたビジョンの大部分を明確にしており、自身のリリース スケ ジュールによって、メインフレーム向けの継続的でアジャイルな開発を有言実行しています。 コンピュウェアは、2014 年中頃にTopaz への取り組みを開始しました。最初に、5 社の大規模なメイン フレーム顧客から、メインフレームにどのような可能性があるかの詳細な評価と、問題への現実的なソ リューションがどのようなものになるのかについて意見を聞きました。その後、アジャイル開発のために 組織されたコンピュウェアの開発チームが活動を始め、2015 年 1月に最初のデリバリーの目標を達成し ました。この文書の執筆時点では、それからまだ 1 年も経過しておらず、Topazに対する関心は高まり 続けています。 Topazに関心を示している顧客の良い例に、大規模金融サービス企業があります。Topazに関心を示 した理由は2 つあります。 •継続的な開発と導入が必要なメインフレーム プロジェクトがあり、何が可能であるか調査してい た。 •スキルが問題となっていた。ISPF (Interactive System Productivity Facility) の経験がない スタッフが使っても生産性の高いプラットフォームを必要としていた。 その差し迫った要件に対して、顧客が特に興味を持ったコンポーネントは、Topaz Program Analysis および Runtime Visualizer 機能でした。アジャイル開発手法への移行が可能であることが分かったと いう文化的な意味と、期待した生産性の向上が実現できたという実際的な意味で、プロジェクトは成功 を収めました。 Topazはまだ、初期段階にあると思われます。この製品は疑いなく、生産性だけが理由で採用されてい くでしょう。現代的なアジャイル開発は時間を短縮でき、 イノベーションに必須の手法です。またコンピュ ウェアは、ISPW の追加によって強化された、それを可能にするツール（およびエコシステム）を提供し ています。さらにコンピュウェアには、時間と共に確実に新しいツールに移行する、しっかりした顧客基 盤があります。 もっと興味深いのは、メインフレーム界の文化がどれほど急速に変化するか、という点です。予想より 速やかに変化すると考える理由がいくつかあります。高齢となったメインフレームの番人達が定年退職を 迎えつつあり、彼らが築き上げ長年維持してきたメインフレーム文化も、それと共にほぼ確実に衰退す るのは純然たる事実です。コンピュウェアが推奨し、実現し、採用したアジャイル文化は、それに取って 代わる可能性があり、そして私たちは取って代わるべきだと考えています。 10 アジャイルなメインフレーム The Bloor Group について The Bloor Groupは、コンサルティング、調査、テクノロジー分析企業であり、オープン リサーチおよ び最新メディアの使用によって、知識を収集しIT ユーザーに広めることを中心に取り組んでいます。詳 細は、www.TheBloorGroup.com および www.InsideAnalysis.comをご覧ください。 The Bloor Groupは、この刊行物の唯一の著作権者です。 Austin, TX 78720 | 512-524–3689 11
© Copyright 2024 Paperzz
