私たちはUberを利用し、Pinterestを閲覧し、Tweetを送り、Facebookをアップデートします。ハイテクの世界に最新のガジェットを実現したことで一夜にして生まれる百万長者や、増え続ける億万長者の話題を聞かない日はありません。一方で私たちは、ビジネストランザクションの70パーセント以上がいまだメインフレームで処理されている、という事実を無視しています。画像やオーディオの世界には、若い才能がわずかな期間で作り上げたツールがあふれていますが、私たちの座る椅子や換金する小切手、利用しているヘルスケアは、メインフレームが管理するデータを通じて実現されている、という現実があります。まさに製造業や銀行や医療業界の80パーセント以上はメインフレームが頼りなのです。
新たなマーケットの収益化に関する数多くのハイプを耳にする一方で、私たちは、そのようなメインフレームコードの重要性を認識できていません。さて、ここにひとつ、些細な問題があります ... メインフレーム開発者の大部分はベビーブーマであって、定年が近いか、あるいは定年を過ぎているのです。彼らは退職するだけでなく、亡くなっているという、より厳しい現実的側面もあります。(数年前に亡くなった、優れたメインフレーム開発者であった私の友人たち、Jim StanickiとJohn Stalherの冥福をここで祈りたいと思います。)
リライトの必要性
古いメインフレームアプリケーションを書き直せないものでしょうか？確かに簡単なことではありませんし、そのような話は何年も前から出ている、とあなたが言うのも分かります。しかしながら、Visual BasicやdBase III、PHPのアプリ(要するにメインフレームアプリではないもの)のほとんどが5年毎にリライトされてきたのは、それらが長期的な利用を前提に書かれていなかったからなのです。これに対してメインフレームアプリは、数十年にわたって適切に機能しています。メインフレームアプリを書き直す投資に値するメリット(ROI)が、そこにはありません。典型的な例として、80年代に私がHanover Brands Inc.で開発した交通システムは、今日でもまだ運用されています。
しかしながら、ここで挙げたように、開発者の引退ないし死亡という問題があります。困難は覚悟の上、書き直してみませんか？
リライトは決して簡単ではなく、大規模なアプリケーションでは失敗も少なくありません。 私も数週間前に、ごくごく小さなPHPアプリケーションをRubyとRailsで書き直しました。私はRubyもPHPもかなり自信がありますし、1,000行を少し越えた程度の規模だったのですが、それでも失敗した部分がありました。メインフレームのCobolやRPGアプリケーションはもっと複雑です。RPGプログラムでも10,000行、Cobolならば20,000行に達することも珍しくありません。それに数百ないし数千というプログラム数を掛ければ、数百万行のアプリケーションを保持していることになります。さらに悪いことに、こういったプログラムの大部分は、モジュール式プログラミングの技術が普及する前に書かれたものなのです。ひとつのプログラムがとてつもなく大きかったり、変数がすべてグローバルであったりするのは、その典型的な例です。10年以上前、私は記事やセミナで、メインフレームコードからローカル変数をDiogenes(訳注:古代ギリシャの哲学者)的に検索する、というジョークを使っていました。Diogenesが正直な人を見つけられなかったように、70年代のコードからローカル変数を見つけることは難しかったのです。
特にRPGは、読んで理解することがとんでもなく難しい場合があります。RPGでは長い間、変数名として6文字しか使用できませんでした。実際はそれ以上に醜悪です。RPGには、２つの異なるテーブルで同じ列名を使用すると、同じメモリ空間が共有されるというバグがありました。そのためRPGプログラマは、列名の貴重な6文字のうち2～4文字を、関連するシステム名とテーブル名を識別するために使用していました。このバグは数十年前に修正され、今日では変数とデータベース列の名称として、少なくとも32文字までサポートされるようになったのですが、RPGプログラムでは相変わらず6文字の変数名が使用されています。
私は1992年頃、当時メンバであったCircuit City(訳注:米国の家電量販店会社)のコーディングチームを対象に、Cobolのモジュール化テクニックについてプレゼンテーションを行なったことがあります。プレゼンテーションの後、Circuit Cityで最高のCobolプログラマのひとりは、Cobolをモジュール化することのメリットが分からない、と言っていました。
その一方で、メソッドを6～9行以内で収めるべきかどうかで、他のRuby開発者と取っ組み合いの議論をすることもあります。Rubyでの開発にグローバル変数を無節操に使うと、職を失うことにもなりかねません。そんな時には、10,000～20,000行のプログラムに取り組んでいた頃を思い出して、思わず微笑んでしまいます。CobolやRPGの化け物をメンテナンスするのは、もはや理解よりも呪術の領域です。直感的にうまくいくと思ったことを試したら、香を焚き、聖水を注ぎ、変更が成功するようにさまざまな神に祈るのです。
CobolやRPGに蔓延する開発プラクティスは、旧式の構文の使用を広め、醜悪なコードが語られるようになります。ひとつのプログラム内で、数千行のコードがコメントアウトされていることも珍しくありません。まったく使われないセクションもたくさんあります。このようなコードを覘くのは、収集家の家に踏み込むようなものです -- 無駄なジャンクでいっぱいなのです。さらにこのアナロジを続けるならば -- ますますジャンクが積み重なり、腐敗の可能性が増し、ついには悪臭を発することになります(そして次には、そうしたコードの“臭い”が話題に上るのです)。問題なのは、メンテナが引退あるいは死亡したような、この古く腐ったコードを通じて流れている、あなたが毎日使用しているプロセスやマテリアルなのです。
アジリティ
正直に言いましょう ... 私がメインフレーム開発の現場から自分のキャリアを転換したのは、ベロシティ -- あるいはその欠如が理由です。RPGとCobolの開発プラクティスとツールセットには進歩がありません。テスト駆動開発、ソース管理、現代的なエディタ、リファクタリング、アジリティ ... 何年にもわたって私は、記事やセミナでこのような概念への転換を促してきましたが、その大部分が無視されただけでなく、そういったプラクティスを実践しようというプロジェクトも皆無でした。
この段落の中で、重要な言葉は“アジリティ”です。メインフレームのアプリケーション開発プラクティスにはアジリティが欠如しているため、市場の要求への対応が遅くなります。このような古いアプリが時代にそぐわなくなり、サポートスタッフの引退が差し迫ってくると、やり手を自認する経営幹部たちが高価なERPシステムの調達や、あるいは完全なリライトを提案するようになります。そして私たちは皆、そのようなプロジェクトの悲惨な体験談を知っているのです。
最新のマシン
メインフレームは決して時代遅れではありません。旧式のSystem 360やAS/400ではなく、IBM z/OSやIBM i64-bitオペレーティングシステムであれば、LinuxやWindowsでは達成不可能な信頼性とスケーラビリティを備えていますし、複雑なデータセンタの総所有コスト(TCO)も低く抑えられます。メインフレームは垂直ではなく、水平方向にスケールします。最新のソフトウェアも実行可能です。例えば、1台のメインフレームがあれば、数千のDockerイメージを実行することができます。DB2 for iはおそらく、世界で最も優秀なデータベースです。最新技術に関しては、私は数年前まで、RubyとRailsをネイティブのIBMiオペレーティングシステムに移植するチームにいました。銀行業務アプリケーションがメインフレームで運用されているのは、おもにセキュリティ上の理由からです。RailsのIBMiプラットフォームへの移植にも、銀行が資金を提供していました。 メインフレームには、膨大な水平拡張性や極限的なセキュリティ、100パーセントに近い信頼性など、大きなメリットがあるのです。IBMのメインフレーム販売台数が減少しているのは事実かも知れませんが、天文学的な水平スケーラビリティを備えていることにより、既存マシンのアップグレードや拡張は好調です。
老朽化しているのはマシンではなく、メインフレームアプリケーションであり、アプリケーションプログラマなのです。
ならば、私たちは間違っているのだろうか？
2000年問題の時と同じです。すべてのシステムがクラッシュする、と言われていましたが、そうはなりませんでした。何ともなかったのです。マネジメントが最終的に、2桁の年を4桁にする必要性を理解したからです。ですから、マネジメントがメインフレーマのスキル損失を真剣に受け止めれば、問題はないでしょう。
詳しい説明の前に、メインフレームコーダの引退や死亡という問題に対して、私の提案する解決策を要約しましょう。
- データベースの最新化
- アプリケーションコードのリファクタリング
- 既存のメインフレーマのアジャイルおよびトレーナとしてのトレーニング
- 優秀な人材に対するメインフレーム開発キャリアの必須化
- 既存コードのAPIへの転換
データベースの最新化
第1段階はデータベースの最新化です。20～40年前のアプリケーションの裏には、世界最高のデータベースとオペレーティングシステムに保護された豊富なデータがあります。メインフレームのデータベースの多くは、今日よく知られているデータベースの正規化や最適化のテクニックが生み出される前に作られています。10年程前に私は、きれいに整理され、一時的にパンチカードデッキに収納されていたテーブルのWebフロントエンドを設置したことがあります。古いデータベーススキーマの構造を模倣するツールやテクニックがあるので、レガシプログラムはほとんど、あるいはまったく手を加えることなく運用を継続することが可能です。私の経験から、データベースのリファクタリングは、それほど難しいものではありません。
アプリケーションコードのリファクタリング
メインフレームコードの状態については、これまでも大きな問題として取り上げてきました。メインフレームコードをリファクタリングすれば、開発をよりアジャイルにすることが可能です。リライトではありません。リファクタリングは既存コードの動作を変えることなく、構造を再構成するプロセスです。大掛かりなリライトにありがちなダウンタイムについて、経営幹部が心配する必要もなくなります。
リファクタリングの第一歩は、コードをソース管理下に置くことです。ここでは特にgitをお勧めします。すでにソース管理パッケージが導入されているかも知れませんが、私の経験では、メインフレームのソース管理パッケージは、開発遅延を伝搬させて、通常のリファクタリング戦略を邪魔するものでしかありません。コードをgitに置いたら、最初にコメントアウトされたコードを削除してください -- 旧バージョンを維持するのはソース管理の仕事です。
次のステップは、開発環境のアップデートです。この20年で強力なIDEが利用可能になったにも関わらず、メインフレーマの多くは、依然としてグリーンモニタ上でエディタを使っています。最新のIDEにはリファクタリングツールがバンドルされています。
第３のステップは、ユニットテスト戦略を立てることです。ユニットテストでは通常、プログラムの振る舞いを非常に具体的かつ詳細にテストします。しかし、そんな時間はありません。私は、Llewellyn Falco (http://llewellynfalco.blogspot.com/)氏の開発した、Approvals Testing戦略に従うことをお勧めします。Approvals Testingの基本的な概念は、ルーチンの実行前と実行後のスナップショットを取得することです。スナップショットはデータベースのクエリ結果から、PDFやCSVなど、何でも構いません。クリエイティブに考えてください。スナップショットが取得できる状態で、ルーチンの修正前および修正後のイメージを使用して、リファクタリングが動作を変えていないことを確認します。メインフレームのルーチンを起動するために、JavaやRuby、あるいはPythonを使ったテストインフラストラクチャが必要かも知れませんが、このレイヤはそれほど複雑にはならないでしょう。
ユニットテスト戦略を構築したならば、リファクタリングの手始めとして、変数名を読みやすく、理解しやすいものにしましょう。その後で、モジュール化のために、グローバル変数の使用を減らす作業に入ります。メインフレームのコードには重複が非常に多いので、重複コードを探すツールを使用して、それらを共通化してください。
既存開発者の強化
リファクタリング戦略を成功させる鍵は、優秀なメインフレーム開発者たちにあります。酷い言い方をするならば、メインフレーム開発者は雇用者によって、あたかもバスの運転手のような扱いを受けています。データをある場所から次の場所へ移動することがプログラマの仕事だ、と経営陣は考えています。何か問題が発生したらバスに戻って、データの移動を再開できるまで、エンジンをいじり回すことを期待しているのです。個人的な経験から言えば、彼らはいつも過小評価され、 低い賃金で働いています。彼らメインフレーマの多くは学位を持たず、MBAを所持する経営幹部からは、四半期以上のROIを考える能力を持っていないとみなされているのです。
このようなメインフレーマには権限が必要です。アジャイル開発プラクティスのトレーニングが必要であり、自らがトレーナになることも必要です。リファクタリングや、その後のモジュールAPIの開発を支援する必要があります。引退や死亡という問題もあるので、新たな開発者のトレーニングの管理も、メインフレーマが権限を認められた仕事の一部になります。
プロジェクトリーダの役割を果たせそうなメインフレーマがいなければ、外部から招聘してください。ここで問題になるのは、そのような人材の多くは、仕事を進める上で必要な能力以上のものを持っている、ということです。彼らは管理職やトレーニング、あるいは私のように他のプログラミング言語やプラットフォームに移ってきた人たちです。このような人たちに関して問題なのは、何十年か前に近代化への提言を拒否した経営陣と、その結果として回転ドアのように延々と続いた開発作業に、彼らが疲れ果ててしまっていることです。彼ら元メインフレーマたちは、ERPの購入やOracleへの連絡、あるいは全面的なリライト(恐らく失敗に終わるのは、彼らも経験から知っています)を主張するかも知れません。こういった人たちとの駆け引きに備えておいてください。
このような元メインフレーマには、どこに行けば会えるのでしょう？メインフレームでの経験を隠しながら、優れたコミュニケーションスキルを備え、新しい技術やアジャイルの経験を持つ人材をLinkedInで探すのです。あるいはJavaやRuby、JavaScriptのカンファレンスに参加して、50歳以上の人たちと話してみてください。この年代の人たちは恐らく元メインフレーマですが、新しい技術や、さらに重要な点として、アジャイル開発にも精通しています。
探しているものが分かれば、遠くを見る必要はありません。この記事の編集者は元メインフレーマでアジャイルコーチです。彼は数年前にメインフレームのバス運転手を止めているので、この章は彼によって削除されるかも知れません。メインフレームの近代化プロジェクトを任せるために、彼のような人材を見つけてください。[編集者より - 私もそのとおりだと思いますので、この章は残しました]
優秀な人材に対するメインフレーム開発キャリアの必須化
大学ではCobolやRPGは教えていません。スキルロスに関するブログや記事では、大学にメインフレームコースを加えることや、あるいはディジタル世代(millennials)にとって、メインフレームのキャリアを魅力的なものにすることの必要性を訴えています。
私はディジタル世代が解決策だとは思いませんし、若い人たちにメインフレーム開発のキャリアを勧めるつもりもありません。仕事の機会が少なく、開発速度も遅いので、満足のいくキャリアにはなり得ないからです。私の提案は、1) 既存の非IT要員を再訓練すること、2) 30代から40代の人材にメインフレームのキャリアを強制すること、この２つです。いずれもクレイジーに思えますが、私としては、メインフレームでキャリアを始めようという若いIT卒業生の能力が疑問に思えてならないのです。
メインフレーム開発者になるために必要な技術知識は、今日主流の開発者の多言語でマルチプラットフォームなプログラミングよりも重要です。企業が必要なのはNodeJSや関数プログラミングのスキルではなく、ビジネス的判断や学習意欲を持った、要するにスマートな人材なのです。IT以外の中堅ブルーカラーの中には、1年間の職業再訓練で収入を倍増させる機会を得たいという、スマートな人々がたくさんいます。最初にその候補になりそうな分野は退役軍人でしょう。
既存コードのAPIへの転換
メインフレームの近代化プロセスの最後のステップは、リファクタしたコードのAPIへの転換です。目的は、ソフトウェアコンポーネントを再利用可能にすることです。メインフレームコードのパラメータリストは非常に複雑なことが多く、APIの作成が不可能に思えるかも知れません。そのような場合は、ひとつないしそれ以上のラッパプログラム(Cobol、RPG、あるいは新しい言語でも構いません)を作成します。私がよく用いるのは、既存モジュールをラップするSQLストアドプロシージャを作る方法です。SQLストアドプロシージャを公開すれば、SQLインターフェース(JDBDやODBCドライバなど)さえあれば、誰でもこれらのルーチンを利用できるようになります。
既存コードがAPI(SOAP、RESTなど)経由で公開され、すべてのユニットテストが可能になれば、開発は完全にアジャイル化できます。新たに作成するコードの言語は自由に選択できるようになります。そうなれば、そう、ディジタル世代を雇用できるのです。
あなたの心配リストの上位にある繊細で複雑なプログラムは、こうすることで、新しい言語に転換する計画を立てられるようになります。
メインフレームのアジリティ
半世紀を越える驚異的な信頼性を備えたメインフレームアプリケーションですが、自動テストはほとんどないに等しい粗末なものですし、リファクタリング戦略に至っては、メインフレーム作業者が知らなかったり、あるいは経営層の支援を得られていなかったりという状況です。要するに、ビジネス要件の変化に対応できないのです。現職のメインフレームプログラマは異常な速さで退職している上に、人員の補充もありません。
メインフレームを廃止するというのは、理想的な解決策から程遠いものです。完全なリライトやERPへの転換はコストが必要であると同時に、危険でもあります。メインフレームマシン自体は老朽化していませんし、パフォーマンスやスケーラビリティ、セキュリティ、信頼性といった性能では、実際にMicrosoftやLinuxを凌駕しています。老朽化しているのはマシンではなく、アプリケーションであり、プログラマなのです。
データベースを最新のものにして、コードをリファクタリングし、アジャイルを導入し、社内トレーニングでプログラムスタッフを強化しましょう。最終的には、メリットのある部分について、モジュール化した新しいコードを新言語に移行してください。
問題なのは、これらのソリューションが経営層の胸三寸で決まる点です。彼らがそれを決めるには、過去の四半期実績を見た上で、過小評価されているメインフレーム開発者たちを失う今後2～5年間がどのようなものかを考えなくてはなりません。
著者について
Don Denoncourtはsimplethread.comの開発者です。氏はWindowsやLinux、さらにはインターネットのない時代からコーディングをしています。90年代の初めにRPGとCobolからCとC++に移行し、実用的になる以前の1996年からJavaを採用しています。急増したJavaフレームワークを自身のコードで試した後、RubyとRailsの“設定より規約(Convention-over-Configuration)”方式のフレームワークを熱望するようになった氏は、GroovyとGrailsを経て、2011年には最終的にRailsに移行しました。また氏は執筆を嗜み、数冊の著書と数百の技術記事を発表しています。氏は20世紀から自宅で仕事を続けていて、仕事をしていない時には、3人の孫と過ごす時間を楽しんでいます。心を若々しく保つために氏は、イタリアの小説を聞いたり、読んだりしています。 また、身体を若く保つために、オフロードやストリートでの一輪車に熱中しています。