コード変換だけではない──DXを阻むメインフレーム資産の課題
アマゾン ウェブ サービス ジャパン合同会社 金融事業開発本部長 飯田哲夫氏
オンプレミス環境で稼働する従来型のシステムを最新のクラウド環境に移行したい。背景にあるのは、多くの日本企業が取り組むDXを加速させたいという思いだ。特に、メインフレーム資産が残る場合、レガシーシステムをビジネスの変化に追随できるものへのモダナイズは急務だ。「お客様は皆、レガシーシステムがDXの足枷になると理解している。その一方で、悩める企業の移行に求めるレベルは高い。『短期間で移行したい』『業務への影響を極力減らしたい』『運用コストの低減を図りたい』など、難しいものが多い」と、瀧澤与一氏は打ち明ける。
銀行、証券、保険、決済と業態を問わず、金融業の企業と接する機会の多い飯田哲夫氏も、「金融のお客様の悩みは、エンジニア人口の減少に伴うスキルギャップ」と指摘する。メインフレームに依存している限り、新しい事業機会の創出は難しい。銀行のように、デジタル人材の採用を強化している業態もあるが、雇われる個人の立場からすると、レガシーシステムの担当にはなりたくない。雇う企業側も適材適所の観点からそれは避けたいと考えるためだ。
メインフレーム資産が残るのは金融だけではない。政府機関、製造業、流通業でも同様だ。飯田氏が指摘するように、エンジニアのスキルの問題は移行したくてもできない状況を招く。例えば、メインフレームの場合、COBOLと並んでPL/Iやアセンブラのプログラミング言語の名前をよく聞く一方で、クラウドのエンジニアが使うプログラミング言語は、Java、Python、あるいはRubyのようなものが主流だ。「私個人はCOBOLを悪いプログラミング言語とは考えていない。しかし、従来の基幹システムを支えたプログラミング言語とは異なる、オープンかつクラウド環境で使われるものを今のお客様は好む傾向が見られる」と瀧澤氏は語った。
問題はコードだけではない。瀧澤氏は「数十年以上、メインフレームは企業の基幹システムを支えてきた。その貢献は大きいが、オープンアーキテクチャーに基づくものではない。特に、ビジネスプロセスとデータが1つの筐体の中にあるため、メインフレームテクノロジーをよく知るエンジニアでなくては、容易に変更もできない」と、メインフレーム資産を維持する問題を挙げた。例えば、メインフレームの中のデータを機械学習で使いたい時は、中からデータを取り出して、使う場所に持ってくる処理が必要になる。機械学習だけでなく、データから示唆を得ることもままならない。
