上田　企業にとってDX推進が不可避なテーマとなっています。それに向けたレガシーシステムを取り巻く課題が、「2025年の崖」という言葉で指摘されていますが、まずは、企業がこの状況をどのように捉えるべきかについて話し合いたいと思います。

西尾　10年くらい前であれば、現行の業務ロジックを新しいプラットフォーム上で再現したりすること自体がそれほど難しくなかったかもしれません。しかし、ここ10年で企業システムは急速に肥大化しました。それに伴い、飛び越えるべき崖は広く、深くなっていると感じます（図1）。

　もちろん、ばく大な投資を行って現行ニーズとのギャップを埋める、あるいは現行システムを捨てて新しいものをつくるなどの方法はあります。ただ、安全性を考えれば、目の前の崖をしっかり見極めて確実に降りていく、つまりレガシーモダナイゼーションを手堅く進めていく方法が望ましいのではないでしょうか。

10 年前くらいまでは飛び越えられる崖だったが、現在ではその幅も深さも広がり、容易には飛び越えられない状態になってしまっている

上田　レガシーシステムの問題で代表的なものの１つが、「メインフレームで構築されたシステムをどうすべきか」ということだと思います。メインフレームを運用し続けることのリスクはどこにありますか。

西尾　機器メーカーやソリューションベンダー各社は、メインフレームのビジネスからすでに撤退を始めています。つまり今後、新規事業を支えるシステムを整備する際に、メインフレームを調達し、COBOL、PL/I、アセンブラといったレガシーな開発言語を使ってシステム開発を行う企業はいないということですね。そう考えると、メインフレームを存続させていくことのリスクは大きいと言わざるを得ません。

中野　私は1980年代に、現在はレガシーシステムと言われるようなシステムの開発に携わっていました。その立場から言うと、構築したシステムをその後20年以上にわたって使い続けることは、当時は想定していませんでした。時代ごとのテクノロジーやインフラの進化に合わせて、作り変えていくという前提で構築していたわけです。

　かつて騒がれた「2000年問題」は、西暦を下2桁でコーディングしていたことに起因するものです。それも、システムが2000年以降には使われていないという想定で設計されていたからにほかなりません。想定外の利用を続けるリスクは、間違いなく存在します。

西尾　「COBOLのプログラマを自社で育てれば、リスクを回避できるのではないか」という声も聞きます。ただ現実には、COBOLで開発を続けたいと考える企業は激減しています。そうなると、優秀な技術者は市場価値が下がっているCOBOLのスキルを獲得しようとは考えないでしょう。優秀な技術者は一般的な技術者の何倍もの価値を生み出します。そのような人たちがCOBOLから離れていけば、今後、COBOLが衰退していくこともやむなしと思われます。

上田　このような状況を回避するため、多くの企業がレガシーモダナイゼーションに取り組んでいます。私たちアクセンチュアも数多くのお客様を支援してきましたが、そこで見えてきたお客様の主な課題についてご紹介ください。

西尾　まず、増加するトランザクションデータを見据えた設計をどう実現するかという課題があります。

　私は様々なお客様のレガシー脱却プロジェクトに携わってきましたが、現状の機能やロジックを新しいインフラに移行すること自体は、時間と工数をかければ実現可能です。そのため、これを支援できるベンダーは世の中に多く存在すると思います。

　ただ、そこでより重要なのは、移行したシステムを、その後どう活用していくのかということです。例えば、モダナイゼーションのプロジェクトでは、COBOLで構築されたシステムをJavaベースに移行するケースが多くあります。これによってAPI化などを可能にし、外部システムとの接続性を飛躍的に高めるのです。

　その過程では必然的にシステム全体のトランザクションが増加します。つまり、システムを単にJava化するだけではなく、その後の状況も見据えて、ビジネスを支え得る設計にしておく必要があるわけですが、実はこれがとても難しいと考えています。

水上　西尾さんの言う通り、モダナイズ後に初めて可能になることが、システムやビジネスにどんな影響をもたらすのかを事前に考えておく必要があります。システムの移行がゴールなのではなく、その先のDX推進を見据えておく。このことがモダナイゼーションには不可欠です。

上田　この「仕組みを変えるだけではダメ」という視点は、業務の面にも当てはまりそうですね。つまり、「新しいプラットフォームにシステムを移行しただけでは、業務変革は実現できない」という課題です。

中野　その通りですね。私は、1970～ 80年代に構築されたメインフレームのモダナイゼーションのご相談を受けることがあります。それらのシステムでは、アプリケーション自体が、当時の紙の文化を念頭に置いたバッチ処理主体のものとなっています。例えば、営業拠点で集めた受注データを計算センターに送り、それをバッチ処理によって集計し、生産計画を立てて、工場で製品を生産し、出荷する――といった形ですね。

　このような業務をいくら効率化しても、業務自体が時代の要請に応えられていないため、大きな成果にはつなげられません。DXを推進するには、業務自体をいかにリアルタイム化し、スピード化していくかがカギを握ります。

上田　ということは、現行のシステムや業務を良く知る現行ベンダーにモダナイゼーションを委ねるのが、企業にとって自然な選択になりそうです。これについてはどう考えますか。

中野　確かに一理ありますね。ただ私は、必ずしもそれがベストだとは思いません。そもそも、現行ベンダーが本当に現行のシステムや業務に精通しているのかをまず精査すべきです。実際は、ベンダー側でも人材の世代交代が進んでいるので、業務やアプリケーションを深いレベルまで理解できているケースは少ないのではないでしょうか。

西尾　私も中野さんと同様の考えです。また個人的に、現行ベンダーは「現状のシステムを一新しましょう」という提案をするケースが多いように見受けます。仮にうまくいかなかったとしても、既存のメインフレームは残るので、ビジネスが存続するというケースも多いですね。

中野　その意味では、現行システムに対する既得権益を持たず、かつシステムのモダナイゼーションに関する十分な能力を備えた第三のベンダーにアドバイスを求めることは、1つの有効な方法だと思います。

上田　現行システムのブラックボックス化が進んでいる場合、それを新たなプラットフォーム上で再構築（リビルド）するのは非常に困難な作業になりそうです。しかし、「リビルドによる対応が可能だ」と考えるお客様は多いのではないでしょうか。

西尾　そうですね。もちろん、リビルドによるモダナイゼーションが不可能なわけではありません。ただ現実には、リビルドの取り組みがうまくいかず、あらためて当社にご相談いただくお客様が多いのも事実です。

　お客様が運用しているレガシーシステムは、長年、膨大なヒト・モノ・カネを投入して構築してきた巨大な鉄筋コンクリート建築のようなもの。そのレガシーシステムの全貌が分からない方がDIY感覚で再構築しようと取り組んでいるケースもあります。巨大な鉄筋コンクリートの建て替えは、経験のある専門家にお願いすべきということを、まずはご認識いただく必要があると思います。

上田　ここまで挙がったような課題を解決し、お客様にとって最適なモダナイゼーションのあり方を提案する。そして、実際のシステム構築を支援することが、アクセンチュアのミッションです。そのためのアプローチについて紹介してください。

水上　当社が提供しているのが「モダナイゼーション2DX」です。これは当社が開発した3つのソリューションを組み合わせたもの。具体的には、COBOL資産のJava変換を実現する「MAJALIS」、変換後のシステムのAPI化を支援する「API Conversion & Integration Mediator（AIM）」、そしてDX推進に不可欠なモバイルアプリやWebアプリケーションの効率的な開発を支援する「Accenture Connected Technology Solution（ACTS）」で構成されています（図2）。

「MAJALIS」「AIM」「ACTS」という3つのソリューションで構成される。これを基に、顧客企業のモダナイゼーションからDXまでを一気通貫で支援する

　これにより、レガシーシステムのモダナイゼーションから、その後のDX推進までを一気通貫で支援できます。モダナイズして終わりではなく、新たな価値の創出までを伴走する。これが、我々アクセンチュアの最大の強みだと考えています（図3）。

アクセンチュアは、30～50年前に構築されたレガシーシステムからDXを実現するモダンなシステムまで、各領域の知見を備えた専門家を擁する。モダナイゼーションとDXを“地続き”で推進可能だ

西尾　ソリューションを順に紹介します。まずMAJALISは、レガシー言語からJavaへの自動変換を実現するものです。COBOLはもちろん、PL/Iなどの開発言語にも対応しています。メインフレーム基盤も、IBMや富士通、NECなどの多様な製品に対応可能です。ソースコードの変換からプログラム実行結果に基づく現新比較テストまでをトータルにサポートし、各工程の作業の完全自動化を目指している点がMAJALISの特長といえます。

水上　次のAIMは、モダナイゼーション2DXの肝になるソリューションです。古いプログラム資産はMAJALISでJava化できますが、それだけで外部システムとの連携が実現できるわけではありません。そこで、Java化した後のレガシーシステムと、連携したい外部システムとの間にAIMを置くことで、API経由でシステムを動作させられるようにします。

　具体的には、AIMが画面スクレイピングなどの技術によってレガシーシステムの画面を内部的に操作します。文字通り、AIMが仲介者（Mediator）になるイメージです（図4）。

既存資産を変換した後のシステム画面を内部的に呼び出し、データの検索や入力が行える仕組みをAPI経由で呼び出せるようにする。変換後のシステムに手を入れず、DXに不可欠なシステム連携を実現できる

中野　「AIMが間に入るのに、なぜCOBOLのままではいけないのか」という疑問を持つ方もいるかもしれません。ただ、やはりCOBOLのままではダメなのです。COBOLを残してしまうと、Javaなどで書かれた新規システムとCOBOLで書かれた旧システムの両方を見る要員が必要になります。この状態で、DXを推進するのは至難の業です。それが、我々がJava化を勧める理由です。

水上　なお、「どの画面にどうアクセスするか」をいちいちプログラムするのは大変です。そこでAIMは、プログラミングレスの設定ベースで動かせるようにしています。そのほか、画面アクセス時に必要な認証をクリアするためのスクリプトを記載し実装することも可能です。

水上　3つ目のACTSは、既に多くのお客様ビジネスに新たな価値をもたらしているソリューションです。DX推進に不可欠なモバイルアプリやWebアプリケーションの効率的な開発を支援します。

　特長は、開発を支えるモダンな機能の数々をあらかじめ用意していることです。例えば、パーソナライズしたサービス提供によって顧客体験を向上するための機能を揃えており、API経由で呼び出してアプリに実装できます。また、アジャイル開発のプロセスを定義し提供しているところも、このソリューションが多くのお客様に評価されている理由の1つだと考えています。

西尾　繰り返しになりますが、モダナイゼーション2DXでは、レガシーシステムのモダナイゼーションのみならず、DXに向けたシステムの実装も射程に据えています。モダナイズした後にDXに取り組むという“二段構え”の対応ではなく、両者を“地続き”にして進めていく。これが成功のカギだと我々は考えており、それを支援できるのは、レガシーから新規システムまで、多様な専門家を有するアクセンチュアだけだと自負しています。