金融業界におけるレガシーシステム問題、解決の本質とは
大手保険会社の元CIOが語る、「2025年の崖」との向き合い方

——矢部さんは保険会社のCIOなどの立場から、金融業界の情報システムに長く関わってこられました。保険業界における「2025年の崖」問題への対応状況をどう見ていますか。

私は、「2025年の崖」という言葉で表される問題が大きく2つあると考えています。システムの老朽化によってDXをはじめとした新しい取り組みができないことと、システム開発の担い手が高齢化・不足することです。

まず歴史ある国内大手保険会社の多くでは、この2つについて大きな問題は生じていないという認識です。大手の多くが1980年代に「メインフレーム」と呼ばれる大型コンピューターで基幹システムを構築し、オンライン化をしました。メインフレームは主に米IBM製のものが利用されてきました。

それ以降、国内の大手保険会社は定期的に基幹システムのリニューアルを実施して老朽化を防ぐとともに、リニューアルを人材育成の機会として活用してきました。こうした取り組みの結果、大手の多くはシステムの老朽化を防ぐことができていますし、社内と外部委託先の両方にレガシーシステムを扱える人材を十分に確保できていると思います。

IBMはメインフレームの継続提供を明言しています。現在同社製のメインフレームを使っている保険会社であれば、今後10年ほどは使い続けても全く問題がないはずです。IBM製のメインフレームは現在でも、安定していて性能が良く、1台で多くの機能をまかなえるとても使いやすいハードです。マイグレーションなどでシステムを移行しても、コストメリットはそれほど出せないでしょう。

——メインフレームは高額であるとよくいわれますが、それでも移行しない方がメリットがあるのですね。

企業情報化協会
顧問
矢部 剛 氏

メインフレームは1台で多くのことが実現できるので運用が楽なのです。オープン化した場合、データベースを運用するデータベースサーバー、お客様向けの画面を作るWebサーバー、通信用の通信サーバーと、用途ごとに複数のサーバーを立てることになります。そのため運用の負荷・コストは高まります。このような運用コストや移行にかかるコスト、移行するリスクなどを考え、メインフレームを使い続ける方がメリットが大きいと多くの保険会社が判断しています。

ただし、今後10年を超えてもメインフレームを使い続けるメリットがあるかは現時点では分かりません。各社は今後どうするかを慎重に判断していくはずです。

IBM製のメインフレームを利用している保険会社の中にも、システムの定期的なリニューアル・メンテナンスをおろそかにしたせいで、業務アプリケーションがブラックボックス化しているケースがあります。そうした会社は、コストをかけてオープンシステムへのマイグレーションを実施してアプリケーションのブラックボックス化を解消するか、このままIBMのメインフレームを使い続けてアプリケーションを塩漬けにするか、悩んでいると思います。

——アプリケーションを塩漬けにするとどのような問題に直面しますか。

既存の保険商品に手を加えたり、新しい商品を開発するのが難しくなります。DXも進められないでしょう。アプリケーションは使い続けるうちに肥大化し、必要のない部分も増えて、保守・運用の費用がかさんでしまうという特徴があります。そのため、アプリケーションを定期的にメンテナンスしている会社に比べて、運用コストは高まってしまいます。

——IBM製以外のメインフレームを使っていたり、オフィスコンピューターなどで構築した中小規模のレガシーシステムを使ったりしている保険会社の状況はいかがですか。

まずメインフレームについては、先ほど国内の大手保険会社の多くがIBM製を利用しているというお話をしました。一部、国産ITベンダー製のメインフレームを利用している保険会社もあります。国産のメインフレームはもう後継機が発売されないことが決まってしまったので、それを使っている保険会社は新しい基盤に移行するためのマイグレーションを急いでいる状況です。

国産のメインフレームを利用している保険会社であっても、アプリケーションを定期的にリニューアル・メンテナンスしてブラックボックス化を防いできた場合は、比較的低コストかつ容易にマイグレーションが進むはずです。反対に、ブラックボックス化が進んでいる場合は、ハードウエアもアプリケーションも同時に見直すわけですから、移行はかなり大変でしょう。

IBMのAS/400（IBM i）や、他社のオフィスコンピューターを使って構築した中小規模の基幹系システム、分散系システムについても、移行が必須です。現在はLinuxベースのサーバーも安定感や性能が十分なので、使用するハードウエアとしては全く問題ありません。中小規模の基幹系システム、分散系システムの場合、アプリケーションのブラックボックス化がかなり進んでいるケースが多いことも課題です。

——現在、レガシーシステムといわれるようなメインフレームやオフコンを使って構築したシステムは、何割くらいの保険会社が使っているのでしょうか。

レガシーシステムで全てをまかなっている会社はほとんどありません。しかし、お客様の契約管理など保険業務の中核となる機能をレガシーシステムで実現している会社は多いです。全体の9割ほどに当たると思います。

新興の保険会社の場合は最初からオープン系で全てのシステムを構築している場合があります。

——メインフレームを使っていて、定期的に基幹システムのリニューアルに取り組んできた保険会社は、具体的にどのようなことをしてきたのでしょうか。

伊勢神宮など日本の神社のいくつかは、「式年遷宮」と呼ばれる取り組みをしています。本殿と同じ社殿を定期的に建て、新しい社殿に本殿を移転するのです。伊勢神宮は20年に一度、遷宮をしていると聞いています。

式年遷宮の目的はいくつかあるようですが、その1つが宮大工などの人材育成です。遷宮によって定期的に人材を育成することで、伝統的な技術を継承するようにしています。

国内の大手保険会社の多くが基幹システムの運用において、式年遷宮を模した取り組みをしてきました。10年程度の間隔で、ほぼ同じ機能を持つ基幹システムを作りなおし、アプリケーションやミドルウエアのリニューアルとバージョンアップ、人材育成を果たしてきたのです。

——10年間隔だと、前回のリニューアルを経験した人材がまだ多く残っているので、ノウハウも継承しやすそうですね。リニューアルの間隔はどのように決めていますか。

IBM製メインフレームのOSのサポート期限が6〜7年に設定されているので、本当はそれに合わせてリニューアルするのが一番良いのです。しかし、この間隔ではコストがかかり過ぎてしまいます。ですから、少し延命して10年程度、といった具合です。

もう1つ、間隔を決めるポイントとしてあるのは、神社の宮大工と情報システムのエンジニアが持つスキルの違いです。神社の遷宮の場合、一度の遷宮で宮大工の方の技術が次世代にしっかり継承されるのだと思います。そのため、20〜60年といった間隔を空けて遷宮をします。

一方、情報システムの場合、先ほどお話ししたように使い続けるうちにアプリケーションが肥大化します。これが理由となり、一度リニューアルを経験したエンジニアであっても、システムの稼働からしばらく時間がたつと、アプリケーションの中身が徐々に分からなくなってしまうのです。そのため、熟練した技術者であっても、10年程度でアプリケーションの中身を把握し直す必要がある、というわけです。もちろん、リニューアルを初めて経験するエンジニアであれば、技術力自体が大きく高まります。

ソフトの中身が明確に分かるようになり、エンジニアの技術力が底上げされると、システム開発のスピードが上がります。私が日本生命に在籍していた際、基幹システムのリニューアル前の時期には新商品向けの業務アプリケーションの開発に2年以上かかりましたが、リニューアル後は1年未満で済みました。

ただし、こうした効果が見込めるとはいえ、「エンジニアのスキル向上のために、現在の基幹システムと同じものをもう一度作らせてくれ」と伝えるだけでは、経営陣の許可が下りません。そこは各社が工夫をしているところだと思います。

——矢部さんはどうやって稟議を通していたのですか。

いろいろな取り組みをすることで、「システムをリニューアルすると投資に見合うコストメリットがある」と説明していました。例えば、不要になったコードを整理する、既存の複数のアプリケーションが重複して持っているプログラム・機能をミドルウエアに切り出して共通利用する形に変える、最新のハードにすることで計算力を高める、といった具合です。これらを組み合わせることで、業務効率化等十分な効果が期待できると説得するわけです。こじつけに近い、かなり強引な説明をした場合もありましたが、それでも絶対に定期的なリニューアルは必要だと考えていました。

——マイグレーションを考えている保険会社の場合、具体的に何が課題になるのでしょうか。

マイグレーションで一番重要なのは、現行の業務アプリケーションの機能分析です。ブラックボックス化が進んでいるアプリケーションの機能分析はとても難しいですが、そこを乗り越える必要があります。

——機能分析が難しいというのは、機能分析に付き合ってくれるITベンダーを見つけられない・人が足りない、ということなのか、人はいるけれども業務アプリケーションの機能を紐解けないのか、どちらでしょうか。

明らかに後者です。ITベンダー各社が定年延長などを利用して、レガシーシステムの技術者をまだ何とか確保できている状況です。そのため全く人が足りない、というわけではありません。ノウハウ保持者を中心にコストもかけてコンサル会社やITベンダーに協力を仰いで体制を作れば、時間はかかりますが、機能分析は可能だと思います。

AI（人工知能）を使ったアプリケーションの機能分析ツールも出てきましたが、まだ現状では厳しいと感じます。保険会社は各社で独自の業務用語の使い方をしていて、AIでプログラムを読み解いた際に、それぞれの単語が何を意味しているか分からないケースが多いのです。そうした単語が無数にあるため、AIでプログラムを解析しても、業務プロセス全体とプログラムの関係がうまくつかめない、といった具合になってしまいます。

ただし、AIは時間がたてば成長します。複数の保険会社の業務アプリケーション解析をAIが経験することで、どのような保険会社の業務アプリケーションであっても妥当な推測ができるようになる可能性があります。AIが成長するまで待ってから、ブラックボックス化の解消に取り組むと考える会社は多いでしょう。。

——改めて現状で取り得る選択肢を教えてください。

まず、ノウハウ保持者を中心にコストをかけて外部ベンダーを含めた体制を構築し、システムの業務アプリケーション全体を紐解きブラックボックス化を解消する方法があります。これは最初にかなりのコストがかかることが課題ですが、オープンシステムへの移行後は運用コストも下がりますし、新規アプリケーションの開発やDXへの取り組みも容易になります。

稼働している業務アプリケーションをそのまま塩漬けにし、ハードウエアのみ入れ替える「リホスト」という方法もあります。オープンシステムの上でも、従来のアプリケーションを使い続けることは一応できます。例えば、ミドルウエアを使ってレガシーな言語を新しい基盤上でもそのまま使えるようにする、ツールを使ってレガシーな言語を別の言語に自動で書き換える、といったことが可能です。ただしこの場合、プログラムは肥大化したままなので、運用コストがかなりかかります。当然、ブラックボックス化も解消していないので、機能の追加や変更も大変です。ハードが替わることによってトラブルが起きる可能性も否定できません。

先の2つの中間的な手法もあります。一部のアプリケーションだけを切り出し、機能分析してブラックボックス化を解消する、もしくは全く新しく作り直すのです。切り出したアプリケーション以外は塩漬けにします。これにより主要なアプリケーションや頻繁に手を入れたいアプリケーションはブラックボックス化が解消できます。どうしても現行アプリケーションの機能分析が難しい場合は、0から業務プロセスを考えて新たなアプリケーションを作ります。この方法で、必要なところから順々に取り組み、最終的にレガシーシステムを代替する、という道筋が考えられます。

AIを使った機能分析も、今後時間がある程度たてば、効果的かつ安価に利用できる可能性があります。様々なパターンが考えられるので、どの時点でどの方式に取り組めば最もメリットがあるかは、判断が難しいところですね。保険会社によって正解は異なるでしょう。

——ＦＰＴグループとして、日本の保険会社におけるレガシーシステムの承継・移行にどう貢献できるかを教えてください。

ベトナムでのオフショア開発の実績として、中規模のオフコンのLinuxサーバーへの移行など、これまで多くのレガシーマイグレーションを重ねてきました。グループウエア「Notes/Domino」など、古いアプリケーションをリプレースした経験も多くあります。

ブラックボックス化した業務アプリケーションの解消にも貢献できると自負しています。日本法人に現在約4800人のスタッフが在籍しており、お客様の要望をしっかりヒアリングする体制が整っています。ベトナムの開発体制と組み合わせることで、他のコンサル会社などより安価に、適切なマイグレーションができます。

メインフレーム上でのアプリケーション開発に多用されている、COBOLというプログラミング言語の技術者を供給・育成する取り組みにも力を入れています。ＦＰＴジャパンホールディングスとSCSKが合弁会社「COBOL PARK」を設立し、事業を開始しました。メインフレームの開発ノウハウを豊富に持っているSCSKのシニア人材と、ＦＰＴグループでCOBOLを熟知した若手技術者が協力してサービスを提供します。

AIツールの研究にも力を注いでいます。ベトナム中部の都市クイニョンにAIの専門人材を集め、研究に取り組んでいます。AIを使った業務アプリケーション解析についても、常に最新の状況をお伝えすることが可能です。

——日本の大手保険会社はレガシーシステムについて十分な人材を内外に確保しているケースが多い、というお話でしたが、それでもCOBOL技術者に対するニーズはあるのですか。そういった保険会社以外の、マイグレーションに苦しんでいる会社からの受注を狙っているのでしょうか。

もちろんマイグレーションに苦しんでいる保険会社のサポートはしていきます。一方で、人材を確保できている大手保険会社からもニーズはあるはずです。

保険会社のエンジニアは、レガシーシステムのような伝統的な技術だけでなく、JavaやPython、AI、クラウドといった新しい技術に関わりたいと考えています。人材が整っている会社であっても、伝統的な技術の活用については外部からの支援を多く受け、社員に新しい技術に関わる機会を与える必要があります。そのため、順調にメインフレームを運用している保険会社からも、COBOL PARKのサービスには大いに興味を持っていただいています。